Vitor Ventura authored this post.
Executive summaryCisco Talos has uncovered a new Android-based campaign targeting Australian financial institutions. As the investigation progressed, Talos came to understand that this campaign was associated with the "ChristinaMorrow" text message spam scam previously spotted in Australia.
Although this malware's credential-harvest mechanism is not particularly sophisticated, it does have an advanced self-preservation mechanism. Even though this is not a traditional remote access tool (RAT), this campaign seems to target mainly private users. Aside from the credential stealing, this malware also includes features like the theft of users' contact list, collecting phone numbers associated names, and files and photos on the device. But that doesn't mean companies and organizations are out of the woods. They should still be on the lookout for these kinds of trojans, as the attackers could target corporate accounts that contain large amounts of money.
The information collected by the malware and the control over the victim's mobile device allows their operators to perform more complex social engineering attacks. A motivated attacker can use this trojan to harvest usernames and passwords and then reuse them to login into the organization's system where the victim works. This is a good example where two-factor authentication based on SMS would fail since the attacker can read the SMS. Corporations can protect themselves from these side-channel attacks by deploying client-based two-factor authentication, such as Duo Security.
One of the most impressive features of this malware is its resilience. If the command and control (C2) server is taken down, the malicious operator can still recover the malware control by sending SMS messages directly to the infected devices. This makes the taking down and recovery of the network much harder and poses a considerable challenge for defenders.
The malware's primary infection vector is SMS. Just like the old-school mail worms that used the victim's address book to select the next victims, this banking trojan's activation cycle includes the exfiltration of the victim's address book. The trojan will receive instructions from the C2 to spread.
Spread command from C2
The victim receives the command sendSMSMass. Usually, this message targets four or five people at a time. The body contains a message and URL. Again, the concept is that new victims are more likely to install the malware if the SMS comes from someone they know. When a victim tries to access the URL in the SMS body, the C2 will check if the mobile device meets the criteria to receive the malware (see infrastructure section). If the device does not meet the criteria, it won't receive any data, otherwise, it will be redirected to a second server to receive a copy of the malware to install on their device.
The domain on this campaign was registered on Jan. 19, 2019. However, Talos has identified that was used at least since November 2018. During the investigation, Talos was also able to determine that the same infrastructure has been used to deploy similar campaigns using different versions of the malware.
Distribution of victims.
Talos assess with high confidence that this campaign is targeting Australian financial institutions based on several factors. Our Umbrella telemetry shows that the majority of the request comes from Australia and the majority of the phone numbers infected have the international indicative for Australia. Finally, the specific overlays are designed for Australian financial institutions, and Australia is one of the geographic regions that is accepted by the C2.
DNS queries distribution over time
The campaign doesn't seem to be growing at a fast pace. Our data shows, on average, about three requests per hour to the drop host. This request is only made upon installation, but there is no guarantee that it will be installed. This data, when analyzed with the number of commands to send SMSs that Talos received during the investigation, lead us to conclude that the malicious operator is aggressively spreading the malware, but that doesn't seem to result in the same number of new infections.
Examples of the overlays available to the malware
Above, you can see examples of the injections that distributed to the malware as part of this specific campaign.
While doing our investigation we were able to identify other malware packages with different names. Some of these might have been used on old campaigns or were already prepared for new campaigns.
Malware technical details
During our investigation, researchers uncovered a malware known as "Gustuff." . Given the lack of indicators of compromise, we decided to check to see if this was the same malware we had been researching. Our Threat Intelligence and Interdiction team found the Gustuff malware being advertised in the Exploit.in forum as a botnet for rent. The seller, known as "bestoffer," was, at some point, expelled from the forum.
Gustuff advertising screenshot
The companies advertised in the image above were from Australia, which matches up with the campaign we researched. The screenshots provided by the author align with the advertised features and the features that we discovered while doing our analysis.
The administration panel shows the application configuration, which matches the commands from the C2.
The administration console screenshots also show the ability to filter the results by country. In this case, "AU" is the code shown, which is Australia.
Based on this information, Talos assesses with high confidence that the malware is the same and this is, in fact, the Gustuff malware.
In the manifest, the malware requests a large number of permissions. However, it doesn't request permissions like BIND_ADMIN. To perform some of its activities, the malware does not need high privileges inside the device, as we will explain ahead.
Permissions in the manifest
This malware is designed to avoid detection and analysis. It has several protections in place, both in the C2 and the malware's code. The code is not only obfuscated but also packed. The packer, besides making the static analysis more complex, will break the standard debugger.
Manifest activity declaration
Class list inside the dex file
The main malware classes are packed, to a point where the class defined in the manifest has a handler for the MAIN category that does not exist in the DEX file.
Error when trying to debug the malware using the Android Studio IDE.
One of the side effects of this packer is the inability of Android Studio IDE to debug the code. This happens because the IDE executes the code from the Android debug bridge (ADB) by calling the activity declared in the manifest by name. Since the class does not exist at startup, the application does not run on the debugger. Although Talos analyzed the unpacked version of the code, the packer analysis is beyond the scope of this post.
Check code for emulators
As part of its defense, the malware payload first checks for emulators to prevent analysis on sandboxes. It checks for different kinds of emulators, including QEMU, Genymotion, BlueStacks and Bignox. If the malware determines that is not running on an emulator, it then performs additional checks to ensure that it won't be detected.
Code to check the existence of SafetyNet Google API
It also checks if the Android SafetyNet is active and reporting back to the C2. This helps the C2 define what actions it can do before being detected on the mobile device.
List of anti-virus packages that are checked
The payload goes a long way to protect itself and checks for anti-virus software installed on the mobile device. The trojan uses the Android Accessibility API to intercept all interactions between the user and the mobile device.
The Android developer documentation describes the accessibility event class as a class that "represents accessibility events that are seen by the system when something notable happens in the user interface. For example, when a button is clicked, a view is focused, etc."
For each interaction, the malware will check if the generator is a package that belongs to the anti-virus list, the malware will abuse another feature of the Accessibility API. There is a function called "performGlobalAction" with the description below.
Android documentation describes that function as "a global action. Such an action can be performed at any moment, regardless of the current application or user location in that application. For example, going back, going home, opening recents, etc."
The trojan calls this function with the action GLOBAL_ACTION_BACK, which equals the pressing of the back button on the device, thus canceling the opening of the anti-virus application.
The same event interception is used to place the webview overlay when the user tries to access the targeted applications, allowing it to display its overlay, thus intercepting the credentials.
The beaconing only starts after the application is installed and removed from the running tasks.
The ID is generated for each installation of the malware, while the token remains unique. Some of the checks performed previously are immediately sent to the C2, like the safetyNet, admin and defaultSMSApp. The beaconing is sent to the URL http://<SERVER>/api/v2/get.php with an interval of 60 seconds.
Answer from the C2
The C2 will check the country field, if it's empty or if the country is not targeted, it will reply with a "Unauthorized" answer. Otherwise, it will return a JSON encoded "OK," and if that is the case, the command to be executed.
List of available commands
The command names are self-explanatory. The command will be issued as an answer to the beaconing, and the result will be returned to the URL http://<SERVER>/api/v2/set_state.php
Example of the command "changeServer"
The commands are issued in a JSON format, and the obfuscation is part of the malware code and not added by the packer. It is a custom obfuscation partly based on base85 encoding, which is in itself unusual, in malware. Base85 encoding is usually used on pdf and postscript documentsThe configuration of the malware is stored in custom preferences files, using the same obfuscation scheme.
As we have explained above, the malware has several defence mechanisms. Beside the obfuscation and the environment checks, the malware also has some interesting anti-sandbox mechanisms.
After installation, the user needs to run the application. The user needs to press the "close" button to finish the installation. However, this won't close the application, it will send it to the background, instead. While the application is in the background, although the service is already running, the beaconing will not start. The beaconing will only start after the application is removed from the background, ultimately stopping it. This will be the trigger for the service to start the beaconing.
As mentioned previously, the beaconing is done every 60 seconds. However, no command is received from the C2 until the inactiveTime field (see beaconing information image above) has at least the value of 2000000. This time resets every time the user performs some activity.
After the checks, the malware becomes active, but first, it goes through seven steps, each one calling a different command:
- uploadPhoneNumbers: Exfiltrates all phone numbers that are in the contact list. Aside from the natural value of phone numbers associated with the names of their owners. Using the SMS has an initial infection vector is another possibility for the exfiltration. One of the purposes of the exfiltration of the contact list is to use them to attack other victims using SMS as an initial vector.
- checkApps: Asks the malware to see if the packages sent as parameters are installed. The malware contains a list of 209 packages hardcoded in its source code. However, the C2 can send an updated list.
- adminNumber: Setup of the admin phone number. In our case, the administrator phone number belongs to a mobile network in Australia.
- changeServer: At this point, the malware changes the C2 to a new host, even though the API and communication protocol continues to be the same.
- changeActivity: This command will set up the webview to overlay any of the target activities.
- params: This command allows the malicious operator to change configuration parameters in the malware. During this stage of the activation cycle, the malware increases the beaconing time to avoid detection.
- changeArchive: The final command of the activation cycle is the download of an archive. This archive is stored in the same host has the webviews. The archive is a ZIP containing several files, which is protected with a password.
List of packages received from the C2
Phone number for administration
Change server request
The URL's for the new server is obfuscated, preventing easy network identification.
The webview injects are not hosted on the C2, they are hosted on a completely different server.
Command to change the beaconing
Change archive command
After this activation cycle, the malware will start the collection of information activities and dissemination.
Once the activation cycle ends, the trojan will start its malicious activities. These activities depend on the device configuration. Depending if the victim has any of the targeted applications, the anti-virus installed or geographic location, the malware can harvest credentials from the targeted applications, exfiltrate all personal information or simply use the victim's device to send SMS to spread the trojan
The malware deploys overlaying webviews to trick the user and eventually steal their login credentials. These are adapted to the information the malicious operator wants to retrieve. The first webview overlay is created on step 6 of the activation cycle.
Pin request overlay
This overlay asks the user to provide their PIN to unlock the mobile device, which is immediately exfiltrated to the C2. The last step of the activation cycle is the download of a password-protected ZIP file. This file contains all HTML, CSS and PNG files necessary to create overlays. Talos found 189 logos from banks to cryptocurrency exchanges inside the archive, all of which could be targeted. The archive also contained all the necessary codes to target Australian financial institutions. The overlays are activated by the malicious operator using the command changeActivity, as seen on step 5 of the activation cycle. In this case, we can see that the HTML code of the overlay is stored in the C2 infrastructure. However, since the archive that is downloaded into the device has all the necessary information and the malicious actor has access to the device via SMS, the malicious operator can keep its activity even without the C2 infrastructure.
The infrastructure supporting this malware is rather complex. It is clear that on all stages there are at least two layers.
The infrastructure has several layers, although not being very dynamic, still has several layers each one providing some level of protection. All the IP addresses belong to the same company Hetzner, an IP-hosting firm in Germany.
CoverageCisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.
Email Security can block malicious emails sent by threat actors as part of their campaign.
Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), and Meraki MX can detect malicious activity associated with this threat.
AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.
Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.
Open Source SNORTⓇ Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
Indicators of compromise (IOCs)