Malware RSS Feed

BusyGasper – the unfriendly spy

Malware Alerts - Wed, 08/29/2018 - 06:00

In early 2018 our mobile intruder-detection technology was triggered by a suspicious Android sample that, as it turned out, belonged to an unknown spyware family. Further investigation showed that the malware, which we named BusyGasper, is not all that sophisticated, but demonstrates some unusual features for this type of threat. From a technical point of view, the sample is a unique spy implant with stand-out features such as device sensors listeners, including motion detectors that have been implemented with a degree of originality. It has an incredibly wide-ranging protocol – about 100 commands – and an ability to bypass the Doze battery saver. As a modern Android spyware it is also capable of exfiltrating data from messaging applications (WhatsApp, Viber, Facebook). Moreover, BusyGasper boasts some keylogging tools – the malware processes every user tap, gathering its coordinates and calculating characters by matching given values with hardcoded ones.

The sample has a multicomponent structure and can download a payload or updates from its C&C server, which happens to be an FTP server belonging to the free Russian web hosting service Ucoz. It is noteworthy that BusyGasper supports the IRC protocol which is rarely seen among Android malware. In addition, the malware can log in to the attacker’s email inbox, parse emails in a special folder for commands and save any payloads to a device from email attachments.

This particular operation has been active since approximately May 2016 up to the present time.

Infection vector and victims

While looking for the infection vector, we found no evidence of spear phishing or any of the other common vectors. But some clues, such as the existence of a hidden menu for operator control, point to a manual installation method – the attackers used physical access to a victim’s device to install the malware. This would explain the number of victims – there are less than 10 of them and according to our detection statistics, they are all located in the Russia.

Intrigued, we continued our search and found more interesting clues that could reveal some detailed information about the owners of the infected devices. Several TXT files with commands on the attacker’s FTP server contain a victim identifier in the names that was probably added by the criminals:

CMDS10114-Sun1.txt CMDS10134-Ju_ASUS.txt CMDS10134-Tad.txt CMDS10166-Jana.txt CMDS10187-Sun2.txt CMDS10194-SlavaAl.txt CMDS10209-Nikusha.txt

Some of them sound like Russian names: Jana, SlavaAl, Nikusha.

As we know from the FTP dump analysis, there was a firmware component from ASUS firmware, indicating the attacker’s interest in ASUS devices, which explains the victim file name that mentions “ASUS”.

Information gathered from the email account provides a lot of the victims’ personal data, including messages from IM applications.

Gathered file Type Description lock Text Implant log ldata sqlite3 Location data based on network (cell_id) gdata sqlite3 Location data based on GPS coordinates sdata sqlite3 SMS messages f.db sqlite3 Facebook messages v.db sqlite3 Viber messages w.db sqlite3 WhatsApp messages

Among the other data gathered were SMS banking messages that revealed an account with a balance of more than US$10,000.But as far as we know, the attacker behind this campaign is not interested in stealing the victims’ money.

We found no similarities to commercial spyware products or to other known spyware variants, which suggests BusyGasper is self-developed and used by a single threat actor. At the same time, the lack of encryption, use of a public FTP server and the low opsec level could indicate that less skilled attackers are behind the malware.

Technical details

Here is the meta information for the observed samples, certificates and hardcoded version stamps:

Certificate MD5 Module Version Serial Number: 0x76607c02
Issuer: CN=Ron
Validity: from = Tue Aug 30 13:01:30 MSK 2016
to = Sat Aug 24 13:01:30 MSK 2041
Subject: CN=Ron 9e005144ea1a583531f86663a5f14607 1 – 18abe28730c53de6d9e4786c7765c3d8 2 2.0 Serial Number: 0x6a0d1fec
Issuer: CN=Sun
Validity: from = Mon May 16 17:42:40 MSK 2016
to = Fri May 10 17:42:40 MSK 2041
Subject: CN=Sun 9ffc350ef94ef840728564846f2802b0 2 v2.51sun 6c246bbb40b7c6e75c60a55c0da9e2f2 2 v2.96s 7c8a12e56e3e03938788b26b84b80bd6 2 v3.09s bde7847487125084f9e03f2b6b05adc3 2 v3.12s 2560942bb50ee6e6f55afc495d238a12 2 v3.18s

It’s interesting that the issuer “Sun” matches the “Sun1” and “Sun2” identifiers of infected devices from the FTP server, suggesting they may be test devices.

The analyzed implant has a complex structure, and for now we have observed two modules.

First (start) module

The first module, which was installed on the targeted device, could be controlled over the IRC protocol and enable deployment of other components by downloading a payload from the FTP server:

@install command

As can be seen from the screenshot above, a new component was copied in the system path, though that sort of operation is impossible without root privileges. At the time of writing we had no evidence of an exploit being used to obtain root privileges, though it is possible that the attackers used some unseen component to implement this feature.

Here is a full list of possible commands that can be executed by the first module:

Command name Description @stop Stop IRC @quit System.exit(0) @start Start IRC @server Set IRC server (default value is “”), port is always 6667 @boss Set IRC command and control nickname (default value is “ISeency”) @nick Set IRC client nickname @screen Report every time when screen is on (enable/disable) @root Use root features (enable/disable) @timer Set period of IRCService start @hide Hide implant icon @unhide Unhide implant icon @run Execute specified shell @broadcast Send command to the second module @echo Write specified message to log @install Download and copy specified component to the system path

The implant uses a complex intent-based communication mechanism between its components to broadcast commands:

Approximate graph of relationships between BusyGasper components

Second (main) module

This module writes a log of the command execution history to the file named “lock”, which is later exfiltrated. Below is a fragment of such a log:

Log with specified command

Log files can be uploaded to the FTP server and sent to the attacker’s email inbox. It’s even possible to send log messages via SMS to the attacker’s number.

As the screenshot above shows, the malware has its own command syntax that represents a combination of characters while the “#” symbol is a delimiter. A full list of all possible commands with descriptions can be found in Appendix II below.

The malware has all the popular capabilities of modern spyware. Below is a description of the most noteworthy:

  • The implant is able to spy on all available device sensors and to log registered events. Moreover, there is a special handler for the accelerometer that is able to calculate and log the device’s speed:

    This feature is used in particular by the command “tk0” that mutes the device, disables keyguard, turns off the brightness, uses wakelock and listens to device sensors. This allows it to silently execute any backdoor activity without the user knowing that the device is in an active state. As soon as the user picks up the device, the implant will detect a motion event and execute the “tk1” and “input keyevent 3” commands.

    “tk1” will disable all the effects of the “tk0” command, while “input keyevent 3” is the shell command that simulates the pressing of the ‘home’ button so all the current activities will be minimized and the user won’t suspect anything.

  • Location services to enable (GPS/network) tracking:
  • The email command and control protocol. The implant can log in to the attackers email inbox, parse emails for commands in a special “Cmd” folder and save any payloads to a device from email attachments.

    Accessing the “Cmd” folder in the attacker’s email box

    Moreover, it can send a specified file or all the gathered data from the victim device via email.

  • Emergency SMS commands. If an incoming SMS contains one of the following magic strings: ” 2736428734″ or ” 7238742800″ the malware will execute multiple initial commands:
Keylogger implementation

Keylogging is implemented in an original manner.

Immediately after activation, the malware creates a textView element in a new window with the following layout parameters:

All these parameters ensure the element is hidden from the user.

Then it adds onTouchListener to this textView and is able to process every user tap.

Interestingly, there is a whitelist of tapped activities:


The listener can operate with only coordinates, so it calculates pressed characters by matching given values with hardcoded ones:

Additionally, if there is a predefined command, the keylogger can make a screenshot of the tapped display area:

Manual access and operator menu

There is a hidden menu (Activity) for controlling implant features that looks like it was created for manual operator control. To activate this menu the operator needs to call the hardcoded number “9909” from the infected device:

A hidden menu then instantly appears on the device display:

The operator can use this interface to type any command for execution. It also shows a current malware log.

Infrastructure FTP server

The attackers used ftp://213.174.157[.]151/ as a command and control server. The IP belongs to the free Russian web hosting service Ucoz.

Files Description CMDS*.txt Text files with commands to execute supersu.apk SuperSU(eu.chainfire.supersu) tool
us.x SuperSU ELF binaries supersu.cfg
supersu.cfg.old SuperSU configs with spyware implant mention bb.txt BusyBox v1.26.2 ELF file bdata.xml Config file for excluding malware components from Android battery saver feature Doze bdatas.apk Main implant module Start implant module MobileManagerService.apk ASUS firmware system component (clean) mobilemanager.apk Corrupted archive privapp.txt Looks like a list of system applications (including spyware components) from the infected device run-as.x
run-as.y Run-as tool ELF file

SuperSU config fragment for implant components and the busybox tool supersu.cfg:

This config allows the implant to use all root features silently.

Content of bdata.xml file:

It can be added to the /system/etc/sysconfig/ path to whitelist specified implant components from the battery saving system.

Email account

A Gmail account with password is mentioned in the sample’s code:

It contains the victim’s exfiltrated data and “cmd” directory with commands for victim devices.

Appendix I: Indicators of compromise MD5




Appendix II: List of all possible commands

These values are valid for the most recently observed version (v3.18s).

Decimal Char Description 33 ! Interrupt previous command execution 36 $ Make a screenshot 48 0 Execute following shell: rm c/*; rm p/*; rm sdcard/Android/system/tmp/r/* (wipe environment paths?) 63 ? Log device info and implant meta information 66(98) B(b) Broadcast specified command to another component 67(99) C(c) Set specified command on timer to execute Debug 68(100) 65(97) D(d) A(a) Log last 10 tasks by getRecentTasks api 68(100) 83(115) D(d) S(s) Log info about device sensors (motion, air temperature and pressure, etc.) 68(100) 84(116) D(d) T(t) Log stack trace and thread information GPS module 101 e Broadcast command to GPS-tracking external component 71(103) G(g) Location tracking GPS/network Interaction with operators 73(105) 102 114 I(i) f r Get specified file from FTP (default – CMDS file with commands) 73(105) 102 115 I(i) f s Upload exfiltrated data 73(105) 73(105) I(i) I(i) Start/stop IRC service 73(105) 76(108) I(i) L(l) Send current location to IRC 73(105) 77(109) I(i) M(m) Push specified message to IRC 73(105) 82(114) I(i) R(r) Read commands from the email inbox 73(105) 83(115) I(i) S(s) Send specified file or all gathered data in email with UID as a subject Network geolocation 76(108) L(l) Get info on current cell_id Camera features 77(109) 99 M(m) c Capture photo 77(109) 108 M(m) l Log information about available cameras 77(109) 114 97 M(m) r a Start/stop audio recording (default duration – 2 minutes) 77(109) 114 98 M(m) r b Start/stop audio recording with specified duration 77(109) 114 44(114) M(m) r ,(r) Start fully customizable recording (allow to choose specific mic etc.) 77(109) 114 115 M(m) r s Stop previous recording 77(109) 114 116 M(m) r t Set recording duration 77(109) 118 M(m) v Capture video with specified duration and quality Common 79(111) 102 O(o) f Hard stop of implant services, unregister receivers 79(111) 110 O(o) n Start main implant service with all components 80(112) P(p) Find specified images and scale them with “inSampleSize” API 81(113) Q(q) Stop main implant service 82(114) R(r) Execute specified shell command Shared preferences setup 83(115) 33 S(s) ! On/off hidden operator activity 83(115) 61 S(s) = Shared preferences control (set/remove specified value) 83(115) 98 S(s) b On/off sending SMS message after device boot 83(115) 99 S(s) c Put boolean value in shared preference “cpyl” 83(115) 100 S(s) d Put boolean value in shared preference “dconn” 83(115) 101 S(s) e On/off periodically reenabling data connectivity 83(115) 102 S(s) f Set GPS location update period 83(115) 105 S(s) i Put boolean value in shared preference “imsg” 83(115) 108 97 S(s) l a On/off foreground process activity logging 83(115) 108 99 S(s) l c Start watching on captured photos and videos 83(115) 108 102 S(s) l f Start watching on Facebook messenger database changes 83(115) 108 108 S(s) l l On/off browser history logging 83(115) 108 116 S(s) l t Start watching on Telegram messenger cache database changes 83(115) 108 118 S(s) l v Start watching on Viber messenger database changes 83(115) 108 119 S(s) l w Start watching on WhatsApp messenger database changes 83(115) 109 S(s) m On/off sending log SMS messages 83(115) 110(112) S(s) o(p) Set operator telephone number (for SMS logging) 83(115) 113 S(s) q Set implant stop-mode (full or only main service) 83(115) 114 S(s) r On/off execution shell as root 83(115) 115 S(s) s On/off screen state logging 83(115) 116 S(s) t On/off screen touches logging and number of related screenshots 83(115) 117 S(s) u On/off debug logging mode with system thread info 83(115) 120 S(s) x Use FTP connection via busybox or default Socket API Sensor and display control 84(116) 98 T(t) b On/off screen brightness 84(116) 100 T(t) d On/off network data (internet) 84(116) 75(107) 48 T(t) K(k) 0 Mute, turn off brightness, disable keyguard, use wakelock and listen on device sensors. 84(116) 75(107) 49 T(t) K(k) 1 Disable features from previous command 84(116) 75(107) 50 T(t) K(k) 2 Disable Keyguard instance 84(116) 75(107) 51 T(t) K(k) 3 Write “userActivity” to log 84(116) 115 48 T(t) s 0 Disable sensor listener 84(116) 115 49 T(t) s 1 Register listener for specified sensor 84(116) 115 108 T(t) s l Log int value from file /dev/lightsensor 84(116) 119 48 T(t) w 0 Turn WiFi off 84(116) 119 49 T(t) w 1 Turn WiFi on 84(116) 119 108 T(t) w l Control WiFi lock Common backdoor commands 85(117) U(u) Download payload, remount “system” path and push payload there. Based on the code commentaries, this feature might be used to update implant components 87(119) W(w) Send SMS with specified text and number Updates from the newest version 122 33 z ! Reboot device 122 99 z c Dump call logs 122 102 z f p Send gathered data to FTP 122 102 z f g Get CMDS* text file and execute contained commands 122 103 z g Get GPS location (without log, only intent broadcasting) 122 108 102 z l f Dump Facebook messages during specified period 122 108 116 z l t Dump Telegram cache 122 108 118 z l v Dump Viber messages during specified period 122 108 119 z l w Dump WhatsApp messages during specified period 122 110 z n Get number of all SMS messages 122 111 z o Set ringer mode to silent 122 112 z p Open specified URL in webview 122 114 z r Delete all raw SMS messages 122 116 z t Set all internal service timers 122 122 z z Remove shared preferences and restart the main service 126 ~ On/off advanced logging mode with SMS and UI activity

The rise of mobile banker Asacub

Malware Alerts - Tue, 08/28/2018 - 06:00

We encountered the Trojan-Banker.AndroidOS.Asacub family for the first time in 2015, when the first versions of the malware were detected, analyzed, and found to be more adept at spying than stealing funds. The Trojan has evolved since then, aided by a large-scale distribution campaign by its creators (in spring-summer 2017), helping Asacub to claim top spots in last year’s ranking by number of attacks among mobile banking Trojans, outperforming other families such as Svpeng and Faketoken.

We decided to take a peek under the hood of a modern member of the Asacub family. Our eyes fell on the latest version of the Trojan, which is designed to steal money from owners of Android devices connected to the mobile banking service of one of Russia’s largest banks.

Asacub versions

Sewn into the body of the Trojan is the version number, consisting of two or three digits separated by periods. The numbering seems to have started anew after the version 9.

The name Asacub appeared with version 4 in late 2015; previous versions were known as Trojan-SMS.AndroidOS.Smaps. Versions 5.X.X-8.X.X were active in 2016, and versions 9.X.X-1.X.X in 2017. In 2018, the most actively distributed versions were 5.0.0 and 5.0.3.

Communication with C&C

Although Asacub’s capabilities gradually evolved, its network behavior and method of communication with the command-and-control (C&C) server changed little. This strongly suggested that the banking Trojans, despite differing in terms of capability, belong to the same family.

Data was always sent to the C&C server via HTTP in the body of a POST request in encrypted form to the relative address /something/index.php. In earlier versions, the something part of the relative path was a partially intelligible, yet random mix of words and short combinations of letters and numbers separated by an underscore, for example, “bee_bomb” or “my_te2_mms”.

Example of traffic from an early version of Asacub (2015)

The data transmitted and received is encrypted with the RC4 algorithm and encoded using the base64 standard. The C&C address and the encryption key (one for different modifications in versions 4.x and 5.x, and distinct for different C&Cs in later versions) are stitched into the body of the Trojan. In early versions of Asacub, .com, .biz, .info, .in, .pw were used as top-level domains. In the 2016 version, the value of the User-Agent header changed, as did the method of generating the relative path in the URL: now the part before /index.php is a mix of a pronounceable (if not entirely meaningful) word and random letters and numbers, for example, “muromec280j9tqeyjy5sm1qy71” or “parabbelumf8jgybdd6w0qa0”. Moreover, incoming traffic from the C&C server began to use gzip compression, and the top-level domain for all C&Cs was .com:

Since December 2016, the changes in C&C communication methods have affected only how the relative path in the URL is generated: the pronounceable word was replaced by a rather long random combination of letters and numbers, for example, “ozvi4malen7dwdh” or “f29u8oi77024clufhw1u5ws62”. At the time of writing this article, no other significant changes in Asacub’s network behavior had been observed:

The origin of Asacub

It is fairly safe to say that the Asacub family evolved from Trojan-SMS.AndroidOS.Smaps. Communication between both Trojans and their C&C servers is based on the same principle, the relative addresses to which Trojans send network requests are generated in a similar manner, and the set of possible commands that the two Trojans can perform also overlaps. What’s more, the numbering of Asacub versions is a continuation of the Smaps system. The main difference is that Smaps transmits data as plain text, while Asacub encrypts data with the RC4 algorithm and then encodes it into base64 format.

Let’s compare examples of traffic from Smaps and Asacub — an initializing request to the C&C server with information about the infected device and a response from the server with a command for execution:

Smaps request

Asacub request

Decrypted data from Asacub traffic:

{“id”:”532bf15a-b784-47e5-92fa-72198a2929f5″,”type”:”get”,”info”:”imei:365548770159066, country:PL, cell:Tele2, android:4.2.2, model:GT-N5100, phonenumber:+486679225120, sim:6337076348906359089f, app:null, ver:5.0.2″}

Data sent to the server

[{“command”:”sent&&&”,”params”:{“to”:”+79262000900″,”body”:”\u0410\u0412\u0422\u041e\u041f\u041b\u0410\u0422\u0415\u0416 1000 50″,”timestamp”:”1452272572″}},

Instructions received from the server

A comparison can also be made of the format in which Asacub and Smaps forward incoming SMS (encoded with the base64 algorithm) from the device to the C&C server:

Smaps format

Asacub format

Decrypted data from Asacub traffic:



The banking Trojan is propagated via phishing SMS containing a link and an offer to view a photo or MMS. The link points to a web page with a similar sentence and a button for downloading the APK file of the Trojan to the device.

The Trojan download window

Asacub masquerades under the guise of an MMS app or a client of a popular free ads service. We came across the names Photo, Message, Avito Offer, and MMS Message.

App icons under which Asacub masks itself

The APK files of the Trojan are downloaded from sites such as mmsprivate[.]site, photolike[.]fun, you-foto[.]site, and mms4you[.]me under names in the format:

  • photo_[number]_img.apk,
  • mms_[number]_img.apk
  • avito_[number].apk,
  • mms.img_[number]_photo.apk,
  • mms[number]_photo.image.apk,
  • mms[number]_photo.img.apk,
  • mms.img.photo_[number].apk,
  • photo_[number]_obmen.img.apk.

For the Trojan to install, the user must allow installation of apps from unknown sources in the device settings.


During installation, depending on the version of the Trojan, Asacub prompts the user either for Device Administrator rights or for permission to use AccessibilityService. After receiving the rights, it sets itself as the default SMS app and disappears from the device screen. If the user ignores or rejects the request, the window reopens every few seconds.

The Trojan requests Device Administrator rights

The Trojan requests permission to use AccessibilityService

After installation, the Trojan starts communicating with the cybercriminals’ C&C server. All data is transmitted in JSON format (after decryption). It includes information about the smartphone model, the OS version, the mobile operator, and the Trojan version.

Let’s take an in-depth look at Asacub 5.0.3, the most widespread version in 2018.

Structure of data sent to the server:

{ "type":int, "data":{ data }, "id":hex }

Structure of data received from the server:

{ "command":int, "params":{ params, "timestamp":int, "x":int }, "waitrun":int }

To begin with, the Trojan sends information about the device to the server:

{ "type":1, "data":{ "model":string, "ver":"5.0.3", "android":string, "cell":string, "x":int, "country":int, //optional "imei":int //optional }, "id":hex }

In response, the server sends the code of the command for execution (“command”), its parameters (“params”), and the time delay before execution (“waitrun” in milliseconds).

List of commands sewn into the body of the Trojan:

Command code Parameters Actions 2 – Sending a list of contacts from the address book of the infected device to the C&C server 7 “to”:int Calling the specified number 11 “to”:int, “body”:string Sending an SMS with the specified text to the specified number 19 “text”:string, “n”:string Sending SMS with the specified text to numbers from the address book of the infected device, with the name of the addressee from the address book substituted into the message text 40 “text”:string Shutting down applications with specific names (antivirus and banking applications)

The set of possible commands is the most significant difference between the various flavors of Asacub. In the 2015-early 2016 versions examined in this article, C&C instructions in JSON format contained the name of the command in text form (“get_sms”, “block_phone”). In later versions, instead of the name of the command, its numerical code was transmitted. The same numerical code corresponded to one command in different versions, but the set of supported commands varied. For example, version 9.0.7 (2017) featured the following set of commands: 2, 4, 8, 11, 12, 15, 16, 17, 18, 19, 20.

After receiving the command, the Trojan attempts to execute it, before informing C&C of the execution status and any data received. The “id” value inside the “data” block is equal to the “timestamp” value of the relevant command:

{ "type":3, "data":{ "data":JSONArray, "command":int, "id":int, "post":boolean, "status":resultCode }, "id":hex }

In addition, the Trojan sets itself as the default SMS application and, on receiving a new SMS, forwards the sender’s number and the message text in base64 format to the cybercriminal:

{ "type":2, "data":{ "n":string, "t":string }, "id":hex }

Thus, Asacub can withdraw funds from a bank card linked to the phone by sending SMS for the transfer of funds to another account using the number of the card or mobile phone. Moreover, the Trojan intercepts SMS from the bank that contain one-time passwords and information about the balance of the linked bank card. Some versions of the Trojan can autonomously retrieve confirmation codes from such SMS and send them to the required number. What’s more, the user cannot check the balance via mobile banking or change any settings there, because after receiving the command with code 40, the Trojan prevents the banking app from running on the phone.

User messages created by the Trojan during installation typically contain grammatical and spelling errors, and use a mixture of Cyrillic and Latin characters.

The Trojan also employs various obfuscation methods: from the simplest, such as string concatenation and renaming of classes and methods, to implementing functions in native code and embedding SO libraries in C/C++ in the APK file, which requires the use of additional tools or dynamic analysis for deobfuscation, since most tools for static analysis of Android apps support only Dalvik bytecode. In some versions of Asacub, strings in the app are encrypted using the same algorithm as data sent to C&C, but with different keys.

Example of using native code for obfuscation

Examples of using string concatenation for obfuscation

Example of encrypting strings in the Trojan

Asacub distribution geography

Asacub is primarily aimed at Russian users: 98% of infections (225,000) occur in Russia, since the cybercriminals specifically target clients of a major Russian bank. The Trojan also hit users from Ukraine, Turkey, Germany, Belarus, Poland, Armenia, Kazakhstan, the US, and other countries.


The case of Asacub shows that mobile malware can function for several years with minimal changes to the distribution scheme.

It is basically SMS spam: many people still follow suspicious links, install software from third-party sources, and give permissions to apps without a second thought. At the same time, cybercriminals are reluctant to change the method of communication with the C&C server, since this would require more effort and reap less benefit than modifying the executable file. The most significant change in this particular Trojan’s history was the encryption of data sent between the device and C&C. That said, so as to hinder detection of new versions, the Trojan’s APK file and the C&C server domains are changed regularly, and the Trojan download links are often one-time-use.


C&C IP addresses:


IP addresses from which the Trojan was downloaded: