Attackers are persistent and motivated to continuously evolve and no platform is immune. That is why Microsoft has been working to extend its industry-leading endpoint protection capabilities beyond Windows. The addition of mobile threat defense into these capabilities means that Microsoft Defender for Endpoint (previously Microsoft Defender Advanced Threat Protection) now delivers protection on all major platforms.
Microsofts mobile threat defense capabilities further enrich the visibility that organizations have on threats in their networks, as well as provide more tools to detect and respond to threats across domains and across platforms. Like all of Microsofts security solutions, these new capabilities are likewise backed by a global network of threat researchers and security experts whose deep understanding of the threat landscape guide the continuous innovation of security features and ensure that customers are protected from ever-evolving threats.
For example, we found a piece of a particularly sophisticated Android ransomware with novel techniques and behavior, exemplifying the rapid evolution of mobile threats that we have also observed on other platforms. The mobile ransomware, detected by Microsoft Defender for Endpoint as AndroidOS/MalLocker.B, is the latest variant of a ransomware family thats been in the wild for a while but has been evolving non-stop. This ransomware family is known for being hosted on arbitrary websites and circulated on online forums using various social engineering lures, including masquerading as popular apps, cracked games, or video players. The new variant caught our attention because its an advanced malware with unmistakable malicious characteristic and behavior and yet manages to evade many available protections, registering a low detection rate against security solutions.
As with most Android ransomware, this new threat doesnt actually block access to files by encrypting them. Instead, it blocks access to devices by displaying a screen that appears over every other window, such that the user cant do anything else. The said screen is the ransom note, which contains threats and instructions to pay the ransom.
Figure 1. Sample ransom note used by older ransomware variants
Whats innovative about this ransomware is how it displays its ransom note. In this blog, well detail the innovative ways in which this ransomware surfaces its ransom note using Android features we havent seen leveraged by malware before, as well as incorporating an open-source machine learning module designed for context-aware cropping of its ransom note.
In the past, Android ransomware used a special permission called SYSTEM_ALERT_WINDOW to display their ransom note. Apps that have this permission can draw a window that belongs to the system group and cant be dismissed. No matter what button is pressed, the window stays on top of all other windows. The notification was intended to be used for system alerts or errors, but Android threats misused it to force the attacker-controlled UI to fully occupy the screen, blocking access to the device. Attackers create this scenario to persuade users to pay the ransom so they can gain back access to the device.
To catch these threats, security solutions used heuristics that focused on detecting this behavior. Google later implemented platform-level changes that practically eliminated this attack surface. These changes include:
To adapt, Android malware evolved to misusing other features, but these arent as effective. For example, some strains of ransomware abuse accessibility features, a method that could easily alarm users because accessibility is a special permission that requires users to go through several screens and accept a warning that the app will be able to monitor activity via accessibility services. Other ransomware families use infinite loops of drawing non-system windows, but in between drawing and redrawing, its possible for users to go to settings and uninstall the offending app.
The new Android ransomware variant overcomes these barriers by evolving further than any Android malware weve seen before. To surface its ransom note, it uses a series of techniques that take advantage of the following components on Android:
The malware connects the dots and uses these two components to create a special type of notification that triggers the ransom screen via the callback.
Figure 2. The notification with full intent and set as call category
As the code snippet shows, the malware creates a notification builder and then does the following:
Figure 3. The malware overriding onUserLeaveHint
As the code snippet shows, the malware overrides the onUserLeaveHint() callback function of Activity class. The function onUserLeaveHint() is called whenever the malware screen is pushed to background, causing the in-call Activity to be automatically brought to the foreground. Recall that the malware hooked the RansomActivity intent with the notification that was created as a call type notification. This creates a chain of events that triggers the automatic pop-up of the ransomware screen without doing infinite redraw or posing as system window.
As mentioned, this ransomware is the latest variant of a malware family that has undergone several stages of evolution. The knowledge graph below shows the various techniques this ransomware family has been seen using, including abusing the system alert window, abusing accessibility features, and, more recently, abusing notification services.
Figure 4. Knowledge graph of techniques used by ransomware family
This ransomware familys long history tells us that its evolution is far from over. We expect it to churn out new variants with even more sophisticated techniques. In fact, recent variants contain code forked from an open-source machine learning module used by developers to automatically resize and crop images based on screen size, a valuable function given the variety of Android devices.
The frozen TinyML model is useful for making sure images fit the screen without distortion. In the case of this ransomware, using the model would ensure that its ransom notetypically fake police notice or explicit images supposedly found on the devicewould appear less contrived and more believable, increasing the chances of the user paying for the ransom.
The library that uses tinyML is not yet wired to the malwares functionalities, but its presence in the malware code indicates the intention to do so in future variants. We will continue to monitor this ransomware family to ensure customers are protected and to share our findings and insights to the community for broad protection against these evolving mobile threats.
Mobile threats continue to rapidly evolve, with attackers continuously attempting to sidestep technological barriers and creatively find ways to accomplish their goal, whether financial gain or finding an entry point to broader network compromise.
This new mobile ransomware variant is an important discovery because the malware exhibits behaviors that have not been seen before and could open doors for other malware to follow. It reinforces the need for comprehensive defense powered by broad visibility into attack surfaces as well as domain experts who track the threat landscape and uncover notable threats that might be hiding amidst massive threat data and signals.
Microsoft Defender for Endpoint on Android, now generally available, extends Microsofts industry-leading endpoint protection to Android. It detects this ransomware (AndroidOS/MalLocker.B), as well as other malicious apps and files using cloud-based protection powered by deep learning and heuristics, in addition to content-based detection. It also protects users and organizations from other mobile threats, such as mobile phishing, unsafe network connections, and unauthorized access to sensitive data. Learn more about our mobile threat defense capabilities in Microsoft Defender for Endpoint on Android.
Malware, phishing, and other threats detected by Microsoft Defender for Endpoint are reported to the Microsoft Defender Security Center, allowing SecOps to investigate mobile threats along with endpoint signals from Windows and other platforms using Microsoft Defender for Endpoints rich set of tools for detection, investigation, and response.
Threat data from endpoints are combined with signals from email and data, identities, and apps in Microsoft 365 Defender (previously Microsoft Threat Protection), which orchestrates detection, prevention, investigation, and response across domains, providing coordinated defense. Microsoft Defender for Endpoint on Android further enriches organizations visibility into malicious activity, empowering them to comprehensively prevent, detect, and respond to against attack sprawl and cross-domain incidents.
On top of recreating ransomware behavior in ways we havent seen before, the Android malware variant uses a new obfuscation technique unique to the Android platform. One of the tell-tale signs of an obfuscated malware is the absence of code that defines the classes declared in the manifest file.
Figure 5. Manifest file
The classes.dex has implementation for only two classes:
This means that theres no code corresponding to the services declared in the manifest file: Main Activity, Broadcast Receivers, and Background. How does the malware work without code for these key components? As is characteristic for obfuscated threats, the malware has encrypted binary code stored in the Assets folder:
Figure 6. Encrypted executable code in Assets folder
When the malware runs for the first time, the static block of the main class is run. The code is heavily obfuscated and made unreadable through name mangling and use of meaningless variable names:
Figure 7. Static block
The malware uses an interesting decryption routine: the string values passed to the decryption function do not correspond to the decrypted value, they correspond to junk code to simply hinder analysis.
On Android, an Intent is a software mechanism that allows users to coordinate the functions of different Activities to achieve a task. Its a messaging object that can be used to request an action from another app component.
The Intent object carries a string value as action parameter. The malware creates an Intent inside the decryption function using the string value passed as the name for the Intent. It then decrypts a hardcoded encrypted value and sets the action parameter of the Intent using the setAction API. Once this Intent object is generated with the action value pointing to the decrypted content, the decryption function returns the Intent object to the callee. The callee then invokes the getAction method to get the decrypted content.
Figure 8. Decryption function using the Intent object to pass the decrypted value
Once the static block execution is complete, the Android Lifecycle callback transfers the control to the OnCreate method of the main class.
Figure 9. onCreate method of the main class decrypting the payload
Next, the malware-defined function decryptAssetToDex (a meaningful name we assigned during analysis) receives the string CuffGmrQRT as the first argument, which is the name of the encrypted file stored in the Assets folder.
Figure 10. Decrypting the assets
After being decrypted, the asset turns into the .dex file. This is a notable behavior that is characteristic of this ransomware family.
Figure 11. Asset file before and after decryption
Once the encrypted executable is decrypted and dropped in the storage, the malware has the definitions for all the components it declared in the manifest file. It then starts the final detonator function to load the dropped .dex file into memory and triggers the main payload.
Figure 12. Loading the decrypted .dex file into memory and triggering the main payload
When the main payload is loaded into memory, the initial detonator hands over the control to the main payload by invoking the method XoqF (which we renamed to triggerInfection during analysis) from the gvmthHtyN class (renamed to PayloadEntry).
Figure 13. Handover from initial module to the main payload
As mentioned, the initial handover component called triggerInfection with an instance of appObj and a method that returns the value for the variable config.
Figure 14. Definition of populateConfigMap, which loads the map with values
Correlating the last two steps, one can observe that the malware payload receives the configuration for the following properties:
The malware saves this configuration to the shared preferences of the app data and then it sets up all the Broadcast Receivers. This action registers code components to get notified when certain system events happen. This is done in the function initComponents.
Figure 15. Initializing the BroadcastReceiver against system events
From this point on, the malware execution is driven by callback functions that are triggered on system events like connectivity change, unlocking the phone, elapsed time interval, and others.
Dinesh Venkatesan
Microsoft Defender Research
Read the rest here:
Sophisticated new Android malware marks the latest evolution of mobile ransomware - Microsoft
