Welcome back to the android malware analysis series, today we are going to analyze one of the sample from "zazdi" botnet campaign that is found back at around 2019. What is really interesting about this particular type of malware species is how creative the malware author utilizes a known good service to launch their operation.
as we know in the world of malware analysis, botnet requires to talk to its C&C server(Command & Control server) in order to take the next step of the attack. C&C server naturally easy to spot by malware analyzer since it always used a rogue server
But zazdi botnet uses Firebase Cloud Messaging (FCM) as its C&C server to send communication messages with its infected device. FCM is basically just a new version of Google Cloud Messaging
the malware samples can be download from https://github.com/ashishb/android-malware/blob/master/zazdi_botnet/4593635ba742e49a64293338a383f482f0f1925871157b5c4b1222e79909e838.apk
Static Analysis:
to get certificate information you can use jarsigner utility, this might come in handy since some malware author uses the same certification across its malware samples.
Certificate Information:
- Signed by "CN=JAWAL APPLICATIONS, OU=DEV UNIT, O=MOBISTARTAPP, L=CASABLANCA, ST=CASA SETTAT, C=MA"
Digest algorithm: SHA1
Signature algorithm: SHA1withRSA, 2048-bit key
to get the permissions of the app you could use jadx utility and be aware that this command also extracts the source code.
Uses Permissions:
- android.permission.READ_EXTERNAL_STORAGE
- android.permission.WRITE_EXTERNAL_STORAGE
- android.permission.ACCESS_NETWORK_STATE
- android.permission.ACCESS_WIFI_STATE
- android.permission.INTERNET
- android.permission.ACCESS_COARSE_LOCATION
- android.permission.ACCESS_FINE_LOCATION
- android.permission.WAKE_LOCK
- com.android.launcher.permission.READ_SETTINGS
- com.google.android.providers.gsf.permission.READ_GSERVICES
- com.android.launcher.permission.INSTALL_SHORTCUT
- android.permission.RECEIVE_BOOT_COMPLETED
- android.permission.GET_ACCOUNTS
- android.permission.GET_TASKS
- com.google.android.c2dm.permission.RECEIVE
- com.mobistartapp.windows7launcher.permission.C2D_MESSAGE
The result shows that the malware ask a lot of permission to run this is common in android malware world since the author wants to have better control in the device.
lets try to grab some hardcoded URL in the app to see if there is any interesting backend connection instead of the firebase
~# grep -r "http://"
~# grep -r "https://"
mobistartapp domain:
http://www.mobistartapp.com/Apps/privacy-policy.php?app_id=com.mobistartapp.flashlight http://www.mobistartapp.com/fcm_server_php/fcm_users_sms_register.php http://www.mobistartapp.com/social/facebook/index.php?app_id=com.mobistartapp.windows7launcher
http://www.mobistartapp.com/fcm_server_php/fcm_users_inventory_register.php
hizaxytv domains:
http://www.hizaxytv.com
coderoute domains:
http://www.coderoute.ma
In the end, I was able to find three domains that are contacted by the application. All of the URL that comes from mobistartapp domain is already shut down so I can't go any further on investigating the website but according to SonicWall security teams this URL have one of the .php files that contains the Firebase dashboard used to send commands for controlling the operations of the infected devices.
but rest of the two domains still alive and virus total already marked this as a dodgy website
hizaxytv domains:
coderoute domains:
Dynamic Analysis:
To get more information about the malware samples I try to install it in my android emulator and redirect all of the network communication to the burp suite proxy in my host.Android emulator setup for proxy:
Make sure the burp suite certification is installed on the device so we can also listen to https connection:
When you start to install and click the malware app in the emulator it will automatically change the appearance on your android GUI like Windows 7 (just like the name implies) and what interesting is that the malware installs three additional application that also part of the zazdi botnet campaign :
- com.mobistartapp.flashlight (dodgy flashlight app)
- com.hzdi.flappybee (dodgy flabby bird app game)
- com.tassaly.santaskiingchallenge (another dodgy santa skiing app game)
flashlight and Santa skiing app:
the app connects to the app store to install these applications:
interesting enough this app contact the previously listed domain that we got from the static analysis:
all of this domain lead to the same url which is /Win7Launcher/settings_win7launcher.xml but unfortunately, this URL is not exist anymore thus I just assume this .xml file contains different options which can be used to send messages/notifications to the victim.
but there is one domain that is not listed when we do static analysis. So I got the bottom of this and found other interesting findings at the application.
file: com.mobistartapp.windows7launcher.helpers.c
take a look at the stringbuilder() variable we can see that the domain string is in reversed so this is the reason why it is not identified when we do grep.
from the result also we can get another URL path used by mobistartapp domain:
- /fcm_server_php/windows7_launcher/fcm_log_windows7_launcher/fcm_insert_log.php
- /fcm_server_php/windows7_launcher/fcm_register.php
- /fcm_server_php/hzpermis/fcm_register_accounts.php
- /fcm_server_php/hzpermis/fcm_register_location.php
- /fcm_server_php/hzpermis/fcm_register_clipboard.php
- /fcm_server_php/hzpermis/fcm_register_login.php
file: com.mobistartapp.windows7launcher.services.NetworkChangeReceiverList
we can see that every second the code will probe the same URL path with different domains over and over again.
Obtain screenshot and send to backend:
I found out that there is an activity in android that can be invoked through implicit intent to be able to invoke screenshot at the device and send it to the firebase server.file: com.mobistartapp.windows7launcher.activities.ScreenshotActivity
as you can see from the image above in order for us to invoke the screenshot activity we need to have an android with SDK environment equal or above 21.
Furthermore, it also needs three parameters that need to be passed which is app_id, upload_server_url and is_firebase_upload
Persistent activity through broadcast:
The app used broadcast receiver to listen for android.intent.action.BOOT_COMPLETE event in the devices this means that this receiver will execute it task when the device boot up and from the image the task that is going to be execute is to call the main activity which is SplashActivity
we can see the intent that was send set to have flag 268435456 this equivalent to FLAG_ACTIVITY_NEW_TASK according to the android developer page this means that the malicious apps will be placed inside and on top of the targeted task.
"Thus the malicious activity hijacks the target's task," The next time the target app is launched from Launcher, the hijacked task will be brought to the front and the malicious activity will be visible.
I think that's all folks. Now, there are many things that I still didn't cover in this analysis I hope from this blog you can continue my analysis and found something more interesting.
So I hope you enjoy this post and see you at the next android malware analysis series.
References:
https://github.com/firebase/quickstart-android/tree/master/messaging
https://securitynews.sonicwall.com/xmlpost/the-android-zazdi-botnet-uses-fcm-to-communicate-with-its-infected-bots/
https://arstechnica.com/information-technology/2019/12/vulnerability-in-fully-patched-android-phones-under-active-attack-by-bank-thieves/
Comments
Post a Comment