Tag: Recent News

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.

Microsoft’s 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 Microsoft’s 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 is the latest variant of a ransomware family that’s 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 it’s 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 doesn’t 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 can’t 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

What’s innovative about this ransomware is how it displays its ransom note. In this blog, we’ll detail the innovative ways in which this ransomware surfaces its ransom note using Android features we haven’t seen leveraged by malware before, as well as incorporating an open-source machine learning module designed for context-aware cropping of its ransom note.

New scheme, same goal

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 can’t 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:

1. Removing the SYSTEM_ALERT_WINDOW error and alert window types, and introducing a few other types as replacement
2. Elevating the permission status of SYSTEM_ALERT_WINDOW to special permission by putting it into the “above dangerous” category, which means that users have to go through many screens to approve apps that ask for permission, instead of just one click
3. Introducing an overlay kill switch on Android 8.0 and later that users can activate anytime to deactivate a system alert window

To adapt, Android malware evolved to misusing other features, but these aren’t 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, it’s 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 we’ve seen before. To surface its ransom note, it uses a series of techniques that take advantage of the following components on Android:

1. The “call” notification, among several categories of notifications that Android supports, which requires immediate user attention.
2. The “onUserLeaveHint()” callback method of the Android Activity (i.e., the typical GUI screen the user sees) is called as part of the activity lifecycle when the activity is about to go into the background as a result of user choice, for example, when the user presses the Home key.

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:

1. setCategory(“call”) – This means that the notification is built as a very important notification that needs special privilege.
2. setFullScreenIntent() – This API wires the notification to a GUI so that it pops up when the user taps on it. At this stage, half the job is done for the malware. However, the malware wouldn’t want to depend on user interaction to trigger the ransomware screen, so, it adds another functionality of Android callback:

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.

Machine learning module indicates continuous evolution

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 family’s 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 note—typically fake police notice or explicit images supposedly found on the device—would 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 malware’s 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.

Protecting organizations from threats across domains and platforms

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 Microsoft’s 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 Endpoint’s 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.

Technical analysis

Obfuscation

On top of recreating ransomware behavior in ways we haven’t 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:

1. The main application class gCHotRrgEruDv, which is involved when the application opens
2. A helper class that has definition for custom encryption and decryption

This means that there’s 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

Decryption with a twist

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. It’s 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

Payload deployment

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

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:

1. number – The default number to be send to the server (in case the number is not available from the device)
2. api – The API key
3. url – The URL to be used in WebView to display on the ransom note

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

Fighting the security battle so our customers don’t have to

IoT devices are becoming more prevalent in almost every aspect of our lives—we will rely on them in our homes, our businesses, as well as our infrastructure. In February, Microsoft announced the general availability of Azure Sphere, an integrated security solution for IoT devices and equipment. General availability means that we are ready to provide OEMs and organizations with quick and cost-effective device security at scale. However, securing those devices does not stop once we put them into the hands of our customers. It is only the start of a continual battle between the attackers and the defenders.

Building a solution that customers can trust requires investments before and after deployment by complementing up-front technical measures with ongoing practices to find and mitigate risks. In April, we highlighted Azure Sphere’s approach to risk management and why securing IoT is not a one-and-done. Products improve over time, but so do hackers, as well as their skills and tools. New security threats continue to evolve, and hackers invent new ways to attack devices. So, what does it take to stay ahead?

As a Microsoft security product team, we believe in finding and fixing vulnerabilities before the bad guys do. While Azure Sphere continuously invests in code improvements, fuzzing, and other processes of quality control, it often requires the creative mindset of an attacker to expose a potential weakness that otherwise might be missed. Better than trying to think like a hacker is working with them. This is why we operate an ongoing program of red team exercises with security researchers and the hacker community: to benefit from their unique expertise and skill set. That includes being able to test our security promise not just against yesterday’s and today’s, but against even tomorrow’s attacks on IoT devices before they become known more broadly. Our recent Azure Sphere Security Research Challenge, which concluded on August 31, is a reflection of this commitment.

Partnering with MSRC to design a unique challenge

Our goal with the three-month Azure Sphere Security Research Challenge was twofold: to drive new high-impact security research, and to validate Azure Sphere’s security promise against the best challengers in their field. To do so, we partnered with the Microsoft Security Response Center (MSRC) and invited some of the world’s best researchers and security vendors to try to break our device by using the same kinds of attacks as any malicious actor might. To make sure participants had everything they needed to be successful, we provided each researcher with a dev kit, a direct line to our OS Security Engineering Team, access to weekly office hours, and email support in addition to our publicly available operating system kernel source code.

Our goal was to focus the research on the highest impact on customer security, which is why we provided six research scenarios with additional rewards of up to 20 percent on top of the Azure Bounty (up to $40,000), as well as $100,000 for two high-priority scenarios proving the ability to execute code in Microsoft Pluton or in Secure World. We received more than 3,500 applications, which is a testament to the strong interest of the research community in securing IoT. More information on the design of the challenge and our collaboration with MSRC can be found here on their blog post.

Researchers identify high impact vulnerabilities before hackers

The quality of submissions from participants in the challenge far exceeded our expectations. Several participants helped us find multiple potentially high impact vulnerabilities in Azure Sphere. The quality is a testament to the expertise, determination, and the diligence of the participants. Over the course of the challenge, we received a total of 40 submissions, of which 30 led to improvements in our product. Sixteen were bounty-eligible; adding up to a total of $374,300 in bounties awarded. The other 10 submissions identified known areas where potential risk is specifically mitigated in another part of the system—something often referred to in the field as “by design.” The high ratio of valid submissions to total submissions speaks to the extremely high quality of the research demonstrated by the participants.

Jewell Seay, Azure Sphere Operating System Platform Security Lead, has shared detailed information of many of the cases in three recent blog posts describing the security improvements delivered in our 20.07, 20.08, and 20.09 releases. Cisco Talos and McAfee Advanced Threat Research (ATR), in particular, found several important vulnerabilities, and one particular attack chain is highlighted in Jewell’s 20.07 blog.

While the described attack required physical access to a device and could not be executed remotely, it exposed potential weaknesses spanning both cloud and device components of our product. The attack included a potential zero-day exploit in the Linux kernel to escape root privileges. The vulnerability was reported to the Linux kernel security team, leading to a fix for the larger open source community which was shared with the Linux community. If you would like to learn more and get an inside view of the challenge from two of our research partners, we highly recommend McAfee ATR’s blog post and whitepaper, or Cisco Talos’ blog post.

What it takes to provide renewable and improving security

With Azure Sphere, we provide our customers with a robust defense based on the Seven Properties of Highly Secured Devices. One of the properties, renewable security, ensures that a device can update to a more secure state—even if it has been compromised. While this is essential, it is not sufficient on its own. An organization must be equipped with the resources, people, and processes that allow for a quick resolution before vulnerabilities impact customers. Azure Sphere customers know that they have the strong commitment of our Azure Sphere Engineering team—that our team is searching for and addressing potential vulnerabilities, even from the most recently invented attack techniques.

We take this commitment to heart, as evidenced by all the fixes that went into our 20.07, 20.08, and 20.09 releases. In less than 30 days of McAfee reporting the attack chain to us, we shipped a fix to all of our customers, without the need for them to take any action due to how Azure Sphere manages updates. Although we received a high number of submissions throughout multiple release cycles, we prioritized analyzing every single report as soon as we received it. The success of our challenge should not just be measured by the number and quality of the reports, but also by how quickly reported vulnerabilities were fixed in the product. When it came to fixing the found vulnerabilities, there was no distinction made between the ones that were proven to be exploited or the ones that were only theoretical. Attackers get creative, and hope is not part of our risk assessment or our commitment to our customers.

Our engagement with the security research community

On behalf of the entire team and our customers, we would like to thank all participants for their help in making Azure Sphere more secure! We were genuinely impressed by the quality and number of high impact vulnerabilities that they found. In addition, we would also like to thank the MSRC team for partnering with us on this challenge.

Our goal is to continue to engage with this community on behalf of our customers going forward, and we will continue to review every potential vulnerability report for Azure Sphere for eligibility under the Azure Bounty Program awards.

Our team learned a lot throughout this challenge, and we will explore and announce additional opportunities to collaborate with the security research community in the future. Protecting our platform and the devices our customers build and deploy on it is a key priority for us. Working with the best security researchers in the field, we will continue to invest in finding potential vulnerabilities before the bad guys do—so you don’t have to!

If you are interested in learning more about how Azure Sphere can help you securely unlock your next IoT innovation: