Archive

Archive for the ‘Microsoft security intelligence’ Category

Trickbot disrupted

October 12th, 2020 No comments

As announced today, Microsoft took action against the Trickbot botnet, disrupting one of the world’s most persistent malware operations. Microsoft worked with telecommunications providers around the world to take down key Trickbot infrastructure. As a result, operators will no longer be able to use this infrastructure to distribute the Trickbot malware or activate deployed payloads like ransomware.

Microsoft actively tracks the threat landscape, monitoring threat actors, their campaigns, specific tactics, and evolution of malware. We share this intelligence with the community and use our research to continuously improve our products. Below, we will detail the evolution of the Trickbot malware, associated tactics, recent campaigns, and dive into the anatomy of a particular attack we observed.

Trickbot was first spotted in 2016 as a banking trojan that was created as a successor to Dyre and designed to steal banking credentials. Over the years, Trickbot’s operators were able to build a massive botnet, and the malware evolved into a modular malware available for malware-as-a-service. The Trickbot infrastructure was made available to cybercriminals who used the botnet as an entry point for human-operated campaigns, including attacks that steal credentials, exfiltrate data, and deploy additional payloads, most notably Ryuk ransomware, in target networks.

Trickbot was typically delivered via email campaigns that used current events or financial lures to entice users to open malicious file attachments or click links to websites hosting the malicious files. Trickbot campaigns usually used Excel or Word documents with malicious macro codes, but other types of attachments have been used. The campaigns were observed in a wide range of verticals and geolocation, with operators frequently reusing previously compromised email accounts from earlier campaigns to distribute emails without narrowing targets.

In addition to phishing emails, Trickbot was also deployed through lateral movement via Server Message Block (SMB) or as a second-stage payload of other malware like Emotet. Once Trickbot was launched, operators utilized it to install reconnaissance tools like PowerShell Empire, Metasploit, and Cobalt Strike. They used these tools to steal credentials and network configuration information, move laterally to high-value assets, or deliver additional malicious payloads.

Threat data from Microsoft 365 Defender, which correlates signals from endpoints, email and data, identities, and cloud apps to deliver comprehensive protection against threats, shows that Trickbot showed up in both large and small enterprises across the globe, helped no doubt by its modular nature and widespread misconception of it being a “commodity” banking trojan.

Anatomy of a Trickbot campaign

Trickbot is one of the most prolific malware operations in the world, churning out multiple campaigns in any given period. In one specific campaign, the Trickbot operators used several disparate compromised email accounts to send out hundreds of malicious emails to both enterprise and consumer accounts. Recipients were from a variety of industry verticals and geolocations and do not appear to have been specifically targeted. This campaign used a shipping and logistics theme, and had the following subject lines:

  • Shipment receipt
  • Delivery finished
  • Urgent receipt comment
  • Essential receipt reminder
  • Required declaration

The emails contained a malicious Excel attachment that, when opened, prompted the user to enable macros. If enabled, the macro wrote a malicious JScript Encoded (JSE) file to the disk, which is then executed via WScript. The JSE script connected to the affected organization’s domain controller and performed several LDAP queries to gather information about Active Directory, including the schema and user lists. The script then exfiltrated the information to attacker-controlled infrastructure. The script used the jscript.encode command to encode both server-side and client-side files in order to obfuscate content and evade detection.

Next, the JSE file performed several reconnaissance queries to obtain information about the device’s network adapter, antivirus products, domain role, and email. Once the exfiltration was completed, a dropped .bat file established a connection with two separate C2 servers: an IP address and a domain hosted on a separate IP address. Trickbot used both these C2 servers to evade network filtering configurations. The .bat file performed reconnaissance commands to find domain administrators on the network. It then dropped and launched the Greenshot screenshot tool and Cobalt Strike beacon on the device.

At this point, the operators had gained control of the affected device, only 8.5 hours after the user opened the malicious email attachment. The operators then started to copy the freeware tool ADFind.exe, which they used for discovery as well as for gathering domain configuration and organization information. They then archived data found during this discovery to a .7z file for later exfiltration.

The attackers ran several commands to obtain information about the domain controller and gather Kerberos tickets, conducted port scanning on SMB port 445, NetBIOS 139, and queried LDAP for multiple server devices. Using the information gathered, attackers pinged several potentially high-value devices. From there, they viewed the contents of specific text and log files, likely gleaned from their reconnaissance. Upon finding a device with an open port 445, they used runas /netonly (logon type 9, which is intentionally used to confuse analysis of logon events) for authentication and interactively executed commands on the device.

Once authenticated, the attackers viewed existing RDP files from prior unrelated sessions for RDP settings and credentials. From there, they dropped a Trickbot executable and stole credentials from the Windows Vault and Credentials Manager, allowing the attackers to evade many well-known security mechanisms that monitor processes accessing Local Security Authority Subsystem Service (LSASS) memory to dump the credentials. They used a .bat file to view multiple shares, ping additional servers, and read several text files. Finally, the attackers exfiltrated all gathered data.

The attackers persisted in the network via a copy of the malicious .jse file in the Startup folder. Using this .jse file, they have the capability to return to this network later and attempt to log on to other, more valuable devices and steal additional information or drop additional payloads. This highlights the importance of comprehensive response to “commodity malware” like Trickbot: the original banking trojan infection may be triaged and remediated, but without a full understanding of Trickbot as an entry vector to human adversaries, the real threat remains in the network.

Modular, multi-stage malware

Trickbot is a multi-stage malware typically composed of a wrapper, a loader, and a main malware module. The wrapper, which uses multiple templates that constantly change, is designed to evade detection by producing unique samples, even if the main malware code remains the same.

When the wrapper process runs, it runs the loader fully in its memory. The loader has a highly modular design. It decrypts each function at runtime before running it, and then encrypts it back. Likewise, all human-readable strings are decrypted and all APIs are resolved at runtime. In some scenarios, Trickbot uses UAC bypasses to elevate the privileges of its processes. On 64-bit systems, Trickbot uses the “Heaven’s Gate” technique to switch 32-bit code to 64-bit, and has an additional stage where a 64-bit loader injects the main module into the suspended process.

The loader runs the main malware module directly in memory. After creating scheduled tasks for persistence, the main malware module decrypts a configuration file, which contains the information it needs for its next steps:

  • Establish HTTPS communication with command and control (C2) server
  • Download modules from the C2 server
  • Monitor the status of the downloaded modules
  • Synchronize communication between the main module and the downloaded modules

The modules are likewise run in memory via injection into the suspended process. Over the years, Trickbot has used a wide range of modules for various malicious activities. These include the following:

 

Modules Purpose
pwgrab Gathers credentials, autofill data, history and so on from browsers
networkDll Gathers network and system information
importDll Gathers browser data
injectDll Main banker module; uses static and dynamic web browser injection and data theft
tabDll Propagates Trickbot via EternalRomance Exploit
Propagates Trickbot via SMB EternalBlue Exploit
shareDll Propagates Trickbot via Windows network shares
vncDll, BCTestDll Remote control/Virtual Network Computing module; provides backdoor for further module downloads
rdpscanDll Launches brute force attacks against selected Windows systems running Remote Desktop Protocol (RDP) connection exposed to the Internet
Systeminfo Gathers system information
mailsearcher Searches all files on disk and compares their extensions to a predefined list to harvest emails addresses
outlookDll Gather Outlook credentials
psfin Gathers point of sale (POS) software credentials
squlDll Gathers email addresses stored in SQL servers
aDll Runs various commands on a Windows domain controller to steal Active Directory credentials

Trickbot sends information like domain names and IP ranges of compromised networks back to operators, who then select some of these networks for additional exploitation and reconnaissance activities. On selected networks, Trickbot operators installed additional tools like Cobalt Strike, and switch to a hands-on-keyboard attacks. Once the operators gain foothold on a network, they used tools like Mimikatz and LaZagne to steal additional credentials and tools like BloodHound and ADFind to perform reconnaissance actions. Apart from using the stolen credentials and collected data to further the attack, operators also exfiltrated data. They then leave multiple persistence points on the network to enable the eventual delivery of other payloads like Ryuk ransomware.

While much has been made of the Trickbot’s supposed antivirus evasion capabilities, it’s a simple PowerShell command being run to turn off Microsoft Defender Antivirus, but it can perform this action only if the user has administrative rights.

Recent prominent Trickbot campaigns

In June 2020, we tracked multiple Trickbot campaigns. As is typical with Trickbot, some of the email campaigns took advantage of current events as lures to entice users to click on malicious attachments. These lures include Black Lives Matter and COVID-19. Earlier in the year, we reported that Trickbot was the most prolific malware operation using COVID-19-themed lures. Many other simultaneous campaigns used more generic lures, such as shipping and logistics, invoicing and payments, customer complaints, and various financial lures.

The email body was often simple but maintained consistency with the lure used in the subject line. The emails used a wide range of attachment types, including:

  • Word macro attachments
  • Excel VBA macro attachments
  • Excel 4.0 macro attachments
  • Java Network Launch Protocol (.jnlp) attachments

Some campaigns do away with the attachments and instead use malicious links to websites that host malicious files.

The sender infrastructure for all these emails varied as well. In most campaigns, operators used compromised legitimate email accounts and compromised marketing platforms to distribute the malicious emails. However, in one instance, the operators registered several domains using less popular top-level domains (TLDs) such as “.monster” and “.us” to create their own mail server and send malicious emails from attacker-defined email addresses. At least one of these campaigns used attacker-owned email sender infrastructure that was later used to deliver Dridex malware in a separate campaign. The Dridex malware is known to be associated with the CHIMBORAZO (also known as TA505) crime group. Additionally, CHIMBORAZO ran simultaneous campaigns that delivered Trickbot.

The following graphic illustrates the various campaigns, tactics, and techniques used by the operators. The complexity of these simultaneous campaigns and techniques indicates that this is a coordinated and professional effort conducted by a sophisticated activity group.

Extended detection and response for the full range of threats

The action against Trickbot is one of the ways in which Microsoft provide real-world protection against threats. This action will result in protection for a wide range of organizations, including financial services institutions, government, healthcare, and other verticals from malware and human-operated campaigns delivered via the Trickbot infrastructure.

In the recently released Microsoft Digital Defense Report, we called out that cybercriminals of all skill sets take advantage of the perception that commodity threats are less impactful to businesses. Trickbot is proof that this assumption is obsolete, and organizations need to treat and address Trickbot and other malware infections as the broadly damaging threats that they are.

To help protect customers from the full range of threats, from common malware to highly modular, multi-stage threats like Trickbot, as well as nation-state level attacks, Microsoft 365 Defender delivers coordinated protection for identities, endpoints, cloud apps, email and documents. Microsoft Defender for Office 365 detects malicious attachments and links in email campaigns. Microsoft Defender for Endpoint detects and blocks the Trickbot malware and all related components, as well as malicious activities on endpoints. Microsoft Defender for Identity identifies and detects suspicious user activities and compromised identities.

This breadth of cross-domain visibility allows Microsoft 365 Defender to correlate signals and comprehensively detect and resolve attack chains. Security operations teams can then use the rich set of tools in Microsoft 365 Defender to further hunt for threats and gain insights for hardening networks from compromise.

 

 

Microsoft 365 Defender Threat Intelligence Team

Microsoft 365 Defender Research Team

Digital Crimes Unit (DCU)

Detection and Response Team (DART)

 

The post Trickbot disrupted appeared first on Microsoft Security.

Sophisticated new Android malware marks the latest evolution of mobile ransomware

October 8th, 2020 No comments

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.

Screenshot of mobile ransom note in Russian language

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.

Screenshot of malware code

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.

Knowledge graph showing techniques used by the Android rasomware family

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 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.

Malware code showing 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:

Screenshot of Assets folder with encrypted executable code

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.

Malware code showing onCreate method

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.

Malware code showing decryption of assets

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.

Comparison of code of Asset file before and after decryption

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.

Malware code showing loading of decrypted dex file

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).

Malware code showing handover from initial module to main payload

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.

Malware code showing definition of populateConfigMap

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.

Malware code showing initializing broadcast receiver

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

 

The post Sophisticated new Android malware marks the latest evolution of mobile ransomware appeared first on Microsoft Security.

Best practices for defending Azure Virtual Machines

October 7th, 2020 No comments

One of the things that our Detection and Response Team (DART) and Customer Service and Support (CSS) security teams see frequently during investigation of customer incidents are attacks on virtual machines from the internet.

This is one area in the cloud security shared responsibility model where customer tenants are responsible for security. Security is a shared responsibility between Microsoft and the customer and as soon as you put just one virtual machine on Azure or any cloud you need to ensure you apply the right security controls.

The diagram below illustrates the layers of security responsibilities:

Image of the shared responsibility model showing customer, service, and cloud responsibilities

Fortunately, with Azure, we have a set of best practices that are designed to help protect your workloads including virtual machines to keep them safe from constantly evolving threats. This blog will share the most important security best practices to help protect your virtual machines.

The areas of the shared responsibility model we will touch on in this blog are as follows:

  • Tools
  • Identity and directory infrastructure
  • Applications
  • Network Controls
  • Operating System

We will refer to the Azure Security Top 10 best practices as applicable for each:

Best practices

1. Use Azure Secure Score in Azure Security Center as your guide

Secure Score within Azure Security Center is a numeric view of your security posture. If it is at 100 percent, you are following best practices. Otherwise, work on the highest priority items to improve the current security posture. Many of the recommendations below are included in Azure Secure Score.

2. Isolate management ports on virtual machines from the Internet and open them only when required

The Remote Desktop Protocol (RDP) is a remote access solution that is very popular with Windows administrators. Because of its popularity, it’s a very attractive target for threat actors. Do not be fooled into thinking that changing the default port for RDP serves any real purpose. Attackers are always scanning the entire range of ports, and it is trivial to figure out that you changed from 3389 to 4389, for example.

If you are already allowing RDP access to your Azure VMs from the internet, you should check the configuration of your Network Security Groups. Find any rule that is publishing RDP and look to see if the Source IP Address is a wildcard (*). If that is the case, you should be concerned, and it’s quite possible that the VM could be under brute force attack right now.

It is relatively easy to determine if your VMs are under a brute force attack, and there are at least two methods we will discuss below:

  • Azure Defender (formerly Azure Security Center Standard) will alert you if your VM is under a brute force attack.
  • If you are not using Security Center Standard tier open the Windows Event Viewer and find the Windows Security Event Log. Filter for Event ID 4625 (an account failed to log on). If you see many such events occurring in quick succession (seconds or minutes apart), then it means you are under brute force attack.

Other commonly attacked ports would include: SSH (22), FTP (21), Telnet (23), HTTP (80), HTTPS (443), SQL (1433), LDAP 389. This is just a partial list of commonly published ports. You should always be cautious about allowing inbound network traffic from unlimited source IP address ranges unless it is necessary for the business needs of that machine.

A couple of methods for managing inbound access to Azure VMs:

Just-in-time will allow you to reduce your attack service while also allowing legitimate users to access virtual machines when necessary.

Network security groups contain rules that allow or deny traffic inbound to, or outbound traffic from several types of Azure resources including VMs. There are limits to the number of rules and they can become difficult to manage if many users from various network locations need to access your VMs.

For more information, see this top Azure Security Best Practice:

3. Use complexity for passwords and user account names

If you are required to allow inbound traffic to your VMs for business reasons, this next area is of critical importance. Do you have complete confidence that any user account that would be allowed to access this machine is using a complex username/password combination? What if this VM is also domain joined? It’s one thing to worry about local accounts, but now you must worry about any account in the domain that would have the right to log on to that Virtual Machine.

For more information, see this top Azure Security Best Practice:

4. Keep the operating system patched

Vulnerabilities of the operating system are particularly worrisome when they are also combined with a port and service that is more likely to be published. A good example is the recent vulnerabilities affecting the Remote Desktop Protocol called “BlueKeep.” A consistent patch management strategy will go a long way towards improving your overall security posture.

5. Keep third-party applications current and patched

Applications are another often overlooked area, especially third-party applications installed on your Azure VMs. Whenever possible use the most current version available and patch for any known vulnerabilities. An example is an IIS Server using a third-party Content Management Systems (CMS) application with known vulnerabilities. A quick search of the Internet for CMS vulnerabilities will reveal many that are exploitable.

For more information, see this top Azure Security Best Practice:

6. Actively monitor for threats

Utilize the Azure Security Center Standard tier to ensure you are actively monitoring for threats. Security Center uses machine learning to analyze signals across Microsoft systems and services to alert you to threats to your environment. One such example is remote desktop protocol (RDP) brute-force attacks.

For more information, see this top Azure Security Best Practice:

7. Azure Backup Service

In addition to turning on security, it’s always a good idea to have a backup. Mistakes happen and unless you tell Azure to backup your virtual machine there isn’t an automatic backup. Fortunately, it’s just a few clicks to turn on.

Next steps

Equipped with the knowledge contained in this article, we believe you will be less likely to experience a compromised VM in Azure. Security is most effective when you use a layered (defense in depth) approach and do not rely on one method to completely protect your environment. Azure has many different solutions available that can help you apply this layered approach.

If you found this information helpful, please drop us a note at csssecblog@microsoft.com.

To learn more about Microsoft Security solutions visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Best practices for defending Azure Virtual Machines appeared first on Microsoft Security.

Why we invite security researchers to hack Azure Sphere

October 6th, 2020 No comments

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.

Graph showing the submission breakdown and the total amount of money eligible to be received through the bounty system.

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 one of our research partners, we highly recommend McAfee ATR’s 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:

The post Why we invite security researchers to hack Azure Sphere appeared first on Microsoft Security.

Microsoft announces new Project OneFuzz framework, an open source developer tool to find and fix bugs at scale

September 15th, 2020 No comments

Microsoft is dedicated to working with the community and our customers to continuously improve and tune our platform and products to help defend against the dynamic and sophisticated threat landscape. Earlier this year, we announced that we would replace the existing software testing experience known as Microsoft Security and Risk Detection with an automated, open-source tool as the industry moved toward this model. Today, we’re excited to release this new tool called Project OneFuzz, an extensible fuzz testing framework for Azure. Available through GitHub as an open-source tool, the testing framework used by Microsoft Edge, Windows, and teams across Microsoft is now available to developers around the world.

Fuzz testing is a highly effective method for increasing the security and reliability of native code—it is the gold standard for finding and removing costly, exploitable security flaws. Traditionally, fuzz testing has been a double-edged sword for developers: mandated by the software-development lifecycle, highly effective in finding actionable flaws, yet very complicated to harness, execute, and extract information from. That complexity required dedicated security engineering teams to build and operate fuzz testing capabilities making it very useful but expensive. Enabling developers to perform fuzz testing shifts the discovery of vulnerabilities to earlier in the development lifecycle and simultaneously frees security engineering teams to pursue proactive work.

Microsoft’s goal of enabling developers to easily and continuously fuzz test their code prior to release is core to our mission of empowerment. The global release of Project OneFuzz is intended to help harden the platforms and tools that power our daily work and personal lives to make an attacker’s job more difficult.

Recent advancements in the compiler world, open-sourced in LLVM and pioneered by Google, have transformed the security engineering tasks involved in fuzz testing native code. What was once attached—at great expense—can now be baked into continuous build systems through:

  • Crash detection, once attached via tools such as Electric Fence, can be baked in with asan.
  • Coverage tracking, once attached via tools such as iDNA, Dynamo Rio, and Pin can be baked in with sancov.
  • Input harnessing, once accomplished via custom I/O harnesses, can be baked in with libfuzzer’s LLVMFuzzerTestOneInput function prototype.

These advances allow developers to create unit test binaries with a modern fuzzing lab compiled in: highly reliable test invocation, input generation, coverage, and error detection in a single executable. Experimental support for these features is growing in Microsoft’s Visual Studio. Once these test binaries can be built by a compiler, today’s developers are left with the challenge of building them into a CI/CD pipeline and scaling fuzzing workloads in the cloud.

Project OneFuzz has already enabled continuous developer-driven fuzzing of Windows that has allowed Microsoft to proactively harden the Windows platform prior to shipment of the latest OS builds. With a single command line (baked into the build system!) developers can launch fuzz jobs ranging in size from a few virtual machines to thousands of cores. Project OneFuzz enables:

  • Composable fuzzing workflows: Open source allows users to onboard their own fuzzers, swap instrumentation, and manage seed inputs.
  • Built-in ensemble fuzzing: By default, fuzzers work as a team to share strengths, swapping inputs of interest between fuzzing technologies.
  • Programmatic triage and result deduplication: It provides unique flaw cases that always reproduce.
  • On-demand live-debugging of found crashes: It lets you summon a live debugging session on-demand or from your build system.
  • Observable and Debug-able: Transparent design allows introspection into every stage.
  • Fuzz on Windows and Linux OSes: Multi-platform by design. Fuzz using your own OS build, kernel, or nested hypervisor.
  • Crash reporting notification callbacks: Currently supporting Azure DevOps Work Items and Microsoft Teams messages

Project OneFuzz is available now on GitHub under an MIT license. It is updated by contributions from Microsoft Research & Security Groups across Windows and by more teams as we grow our partnership and expand fuzzing coverage across the company to continuously improve the security of all Microsoft platforms and products. Microsoft will continue to maintain and expand Project OneFuzz, releasing updates to the open-source community as they occur. Contributions from the community are welcomed. Share questions, comments, and feedback with us: fuzzing@microsoft.com

To learn more about Microsoft Security solutions visit our website.  Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Microsoft announces new Project OneFuzz framework, an open source developer tool to find and fix bugs at scale appeared first on Microsoft Security.

Force firmware code to be measured and attested by Secure Launch on Windows 10

September 1st, 2020 No comments

You cannot build something great on a weak foundation – and security is no exception.

Windows is filled with important security features like Hypervisor-protected code integrity (HVCI) and Windows Defender Credential Guard that protect users from advanced hardware and firmware attacks. For these features to properly do their jobs, the platform’s firmware and hardware must be trustworthy and healthy, otherwise the chain of trust that verifies the integrity of the system by validating that every component in the boot process is cryptographically signed by a trusted source could be tampered with maliciously, thereby compromising the security of operating system features that use the firmware and hardware as a fundamental building block.

Without these detection and prevention capabilities, the system won’t be able to detect and block malicious software that runs before the operating system initialized, or during the boot process itself. The malicious software could then grant itself elevated privileges, expand foothold, and persist on the system undetected. In the case of Secured-core PCs, Secure Launch, which leverages the principle of Dynamic Root of Trust for Measurement (DRTM), is a technology that is built-in and enabled by default to greatly increase protection from these sophisticated boot attacks. By leveraging built-in silicon instructions or firmware enclaves, Secure Launch allows a system to freely boot untrusted code initially, but shortly after launches the system into a trusted state by taking control of the CPUs and forcing any untrusted code down a well-known and measured code path to verify it isn’t malicious. This removes early Unified Extensible Firmware Interface (UEFI) code from the trust boundary, meaning systems are better protected against bugs or exploits in UEFI after the Secure Launch, combating an entire class of threat.

For some time, Windows devices have been able to leverage a hardware-based root of trust to help ensure unauthorized firmware or software does not take root before the Windows bootloader launches. This root of trust comes from a UEFI feature called Secure Boot. Secure Boot leverages a Trusted Platform Module (TPM) to take cryptographic measurements of each piece of firmware or software during the early boot process. This technique of measuring these static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM).

As there are thousands of PC vendors that produce numerous models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements at startup. There are two techniques that can be used to establish trust here —either maintain a list of known ‘bad’ SRTM measurements (a block list), or a list of known ‘good’ SRTM measurements (an allow list). Each option has a drawback:

  1. A list of known ‘bad’ SRTM measurements allows a hacker to change just 1 bit in a component to create an entirely new SRTM hash that needs to be listed. This means that the SRTM flow is inherently brittle – a minor change can invalidate the chain of trust.
  2. A list of known ‘good’ SRTM measurements requires each new BIOS/PC combination measurement to be carefully added, which can be slow. In addition, a bug fix for UEFI code can take a long time to design, build, retest, validate, and redeploy.

As Windows relies on the Hypervisor being secure, trusted, and unmodified to implement numerous security technologies, it is important to protect it from any potential threats that can arise from these issues. System Guard Secure Launch was designed and introduced in Windows 10 version 1809 to address these drawbacks.

Leveraging a Dynamic Root of Trust to measure code integrity

Secure Launch is the first line of defense against exploits and vulnerabilities that try to take advantage of early-boot flaws or bugs. Firmware enclaves and built-in silicon instructions allow systems to boot into a trusted state by forcing untrusted, exploitable code down a specific and measured path before launching into a trusted state.

To achieve a security boundary between the UEFI/ firmware and later OS code, the Windows boot environment is divided into two phases. The first phase runs with UEFI and leverages boot services that are considered untrusted for Secure Launch, and the second phase is the trusted portion that runs without firmware services after the DRTM event. This trusted phase is referred to as the Trusted Computing Base (TCB) launch phase. The Trusted Computing Base includes the minimally scoped firmware enclave and hardware necessary to perform a DRTM event.

The phase with firmware support utilizes the traditional boot binaries Boot Manager and Winload. In this model, Winload no longer prepares the OS and its data structures but acts to prepare enough data in memory for the TCB phase of the boot environment to be able to operate without firmware. This includes loading all unexpanded binaries needed for the OS in memory, as well as staging other firmware or disk sourced information. All data, binaries, and associated storage structures are validated by the TCB before use.

The TCB phase of the boot environment is started by the new TCB Launch application. This binary is measured into the DRTM TPM registers and starts the chain of trust for the launched OS. TCB Launch ensures the security of the system, and then prepares the OS for execution by loading and validating all binaries as well as building data structures for OS launch.

Although all OS data is sourced from disk by Winload and firmware, the TCB phase validates all signatures and code integrity before use. TCB Launch itself is not directly code integrity checked by this phase, but the root of trust measurement provided by the DRTM event is used to attest the authenticity of the binary. For the TCB phase of boot to continue to be secure, the following state must be verified by the DRTM event and TCB Launch:

  1. Continuous protection against Direct Memory Access (DMA) of TCB Launch and OS memory
  2. Hardware description of RAM is accurate
  3. Security critical hardware description must be validated, such as IOMMU structures
  4. Memory will be cleared upon an unexpected reset from the TCB

After TCB Launch, control of the DRTM environment and associated controls are transferred to the Hypervisor. The Hypervisor is then responsible for managing DMA protections, memory clearing protections, and other DRTM- related state control.

DRTM allows the platform to mitigate real-world attacks that attempt to modify the hypervisor or perform other malicious actions during early boot/hibernate. For example, an S3 boot script exploit that attempts to tamper the hypervisor across suspend/resume would be mitigated by DRTM.

Another common tool used to perform DMA style read/writes over PCIe, frequently leveraged by attackers, is PCILeech. While Kernel DMA protections help ensure that malicious, unauthorised peripherals cannot access memory, even if an attacker does gain a foothold in early-boot, pre-DRTM firmware, the DRTM event insulates the Windows environment from these exploits.

System Management Mode isolation protections can help enforce conditional access

Another dimension of protection that comes with Secured-core PCs is System Management Mode (SMM) protection. System Management Mode (SMM) is a special-purpose CPU mode in x86 microcontrollers that handles power management, hardware configuration, thermal monitoring, and anything else the manufacturer deems useful. If an attacker can exploit SMM, they could attempt to bypass some of the checks in Secure Launch or exploit the runtime operating system. By leveraging new hardware-based supervision and attestation, Secured-core PCs can measure and detect when SMM is trying to access a platform resource (like memory, IO, or certain CPU registers) which violates our policy. This adds an additional layer of hardening to the Secure Launch event and an additional layer of hardening to Secured-core PCs.

SMM execution takes place in the form of System Management Interrupt (SMI) handlers. During the DRTM event, SMIs will be suspended to allow the DRTM event and beginning of the TCB to execute without SMM interference. A system’s SMM isolation is based on an access policy provided by the platform firmware stating what SMM does or does not require access to. This policy will then be enforced on SMM by the silicon vendor specific mechanism, and a copy of this policy will be provided to the boot loader for evaluation. TCB Launch will check that the provided isolation policy being enforced on the system meets the minimum Windows requirements. If the policy is not compliant, say for being able to access OS memory, then TCB Launch may destroy DRTM state and clear OS secrets. TCB Launch will resume SMIs after it has completed its evaluation and has taken any necessary precautions.

Exploits that previously looked to leverage SMM vulnerabilities to read/write these sensitive resources like memory, IO, or certain CPU registers to access secrets, or potentially modify the Hypervisor, are no longer permitted access as part of the policy evaluation. A detected violation upon boot will destroy the DRTM state and prevent access from previously sealed OS secrets and keys. Microsoft has worked with silicon partners and OEMs to ensure that capable Secured-core devices have SMM authored in such a way that meets the SMM policy described, hardening them against this class of attacks. The strength of the ecosystem partnership between Microsoft, silicon vendors and OEMs helps take the security burden of protecting SMM off of security operations teams and recent attacks leveraging SMI handler vulnerabilities are examples of the types of scenarios mitigated by the described SMM protections. When the exploit attempts to leverage a bug in the system management interrupt handler to gain code execution privileges in SMM and modify OS memory, the attempted OS memory access would fall outside our policy boundary and be flagged in the attestation report. The state of DRTM and the SMM protections can be used to help strengthen conditional access strategies in organizations by gating access to sensitive resources based on the health of these hardware and firmware security features.

AMD’s SMM protection component also leverages an SMM supervisor running at a higher processor privilege level (CPL0) to execute SMI handler logic at a lower processor privilege level (CPL3) to isolate and protect resources from SMI handler access and even itself from tampering. Fault handlers are used to protect IO ports & MSRs and enforces CR3 lockdown to protect memory & MMIO components. SMM Supervisor is cryptographically signed and authenticated as well as measured into PCR[17] during SKINIT launch. OEMs include support for SKINIT and AMD’s SMM protections by including the necessary packages in the OS images that are applied to Secured-core PCs.

Getting started with Secure Launch and SMM Protections

Enabling System Guard Secure Launch on a platform may be achieved when the following support is present:

  • Intel, AMD, or ARM virtualization extensions
  • Trusted Platform Module (TPM) 2.0
  • On Intel: TXT support in the BIOS
  • On AMD: SKINIT package must be integrated in the Windows system image
  • On Qualcomm: Implements DRTM TrustZone application and supports SMC memory protections.
  • Kernel DMA Protection

Further configuration information and requirements can be found here. On secured-core PCs, virtualization-based security is supported and hardware-backed security features like System Guard Secure Launch with SMM Protections are enabled by default. Learn more about the line of secured-core PCs available today.

 

Nazmus Sakib

Enterprise and OS Security

The post Force firmware code to be measured and attested by Secure Launch on Windows 10 appeared first on Microsoft Security.

Stopping Active Directory attacks and other post-exploitation behavior with AMSI and machine learning

August 27th, 2020 No comments

When attackers successfully breach a target network, their typical next step is to perform reconnaissance of the network, elevate their privileges, and move laterally to reach specific machines or spread as widely as possible. For these activities, attackers often probe the affected network’s Active Directory, which manages domain authentication and permissions for resources. Attackers take advantage of users’ ability to enumerate and interact with the Active Directory for reconnaissance, which allows lateral movement and privilege escalation. This is a common attack stage in human-operated ransomware campaigns like Ryuk.

These post-exploitation activities largely rely on scripting engines like PowerShell and WMI because scripts provide attackers flexibility and enable them to blend into the normal hum of enterprise endpoint activity. Scripts are lightweight, can be disguised and obfuscated relatively easily, and can be run fileless by loading them directly in memory through command-line or interacting with scripting engines in memory.

Antimalware Scan Interface (AMSI) helps security software to detect such malicious scripts by exposing script content and behavior. AMSI integrates with scripting engines on Windows 10 as well as Office 365 VBA to provide insights into the execution of PowerShell, WMI, VBScript, JavaScript, and Office VBA macros. Behavioral blocking and containment capabilities in Microsoft Defender Advanced Threat Protection (ATP) take full advantage of AMSI’s visibility into scripts and harness the power of machine learning and cloud-delivered protection to detect and stop malicious behavior. In the broader delivery of coordinated defense, the AMSI-driven detection of malicious scripts on endpoints helps Microsoft Threat Protection, which combines signals from Microsoft Defender ATP and other solutions in the Microsoft 365 security portfolio, to detect cross-domain attack chains.

On endpoints, performance-optimized machine learning models inspect script content and behavior through AMSI. When scripts run and malicious or suspicious behavior is detected, features are extracted from the content, including expert features, features selected by machine learning, and fuzzy hashes. The lightweight client machine learning models make inferences on the content. If the content is classified as suspicious, the feature description is sent to the cloud for full real-time classification. In the cloud, heavier counterpart machine learning models analyze the metadata and uses additional signals like file age, prevalence, and other such information to determine whether the script should be blocked or not.

These pairs of AMSI-powered machine learning classifiers, one pair for each scripting engine, allow Microsoft Defender ATP to detect malicious behavior and stop post-exploitation techniques and other script-based attacks, even after they have started running. In this blog, we’ll discuss examples of Active Directory attacks, including fileless threats, foiled by AMSI machine learning.

Diagram showing pairs of machine learning models on the endpoint and in the cloud using AMSI to detect malicious scripts

Figure 1. Pair of AMSI machine learning models on the client and in the cloud

Blocking BloodHound attacks

BloodHound is a popular open-source tool for enumerating and visualizing the domain Active Directory and is used by red teams and attackers as a post-exploitation tool. The enumeration allows a graph of domain devices, users actively signed into devices, and resources along with all their permissions. Attackers can discover and abuse weak permission configurations for privilege escalation by taking over other user accounts or adding themselves to groups with high privileges, or for planning their lateral movement path to their target privileges. Attackers, including those behind human-operated ransomware campaigns such as Ryuk, use BloodHound as part of their attacks.

To work, BloodHound uses a component called SharpHound to enumerate the domain and collect various categories of data: local admin collection, group membership collection, session collection, object property collection, ACL collection, and trust collection. This enumeration would typically then be exfiltrated to be visualized and analysed by the attacker as part of planning their next steps. SharpHound performs the domain enumeration and is officially published as a fileless PowerShell in-memory version, as well as a file-based executable tool version. It is critical to identify the PowerShell fileless variant enumeration if it is active on a network.

Code snippet of the SharpHound ingestor

Figure 2. SharpHound ingestor code snippets

When the SharpHound fileless PowerShell ingestor is run in memory, whether by a pen tester or an attacker, AMSI sees its execution buffer. The machine learning model on the client featurizes this buffer and sends it to the cloud for final classification.

Code snippet of SharpHound ingestor showing featurized details

Figure 3. Sample featurized SharpHound ingestor code

The counterpart machine learning model in the cloud analyzes the metadata, integrates other signals, and returns a verdict. Malicious scripts are detected and stopped on endpoints in real time:

Screenshot of Microsoft Defender Antivirus alert for detection of SharpHound

Figure 4. Microsoft Defender Antivirus detection of SharpHound

Detections are reported in Microsoft Defender Security Center, where SOC analysts can use Microsoft Defender ATP’s rich set of tools to investigate and respond to attacks:

Screenshot of Microsoft Defender Security Center showing detection of SharpHound

Figure 5. Microsoft Defender Security Center alert showing detection of SharpHound

This protection is provided by AI that has learned to identify and block these attacks automatically, and that will continue to adapt and learn new attack methods we observe.

Stopping Kerberoasting

Kerberoasting, like BloodHound attacks, is a technique for stealing credentials used by both red teams and attackers. Kerberoasting attacks abuse the Kerberos Ticket Granting Service (TGS) to gain access to accounts, typically targeting domain accounts for lateral movement.

Kerberoasting attacks involve scanning an Active Directory environment to generate a list of user accounts that have Kerberos Service Principal Name (SPN). Attackers then request these SPN to grant Kerberos Service Tickets to these accounts. The tickets are dumped from memory using various tools like Mimikatz and then exfiltrated for offline brute forcing on the encrypted segment of the tickets. If successful, attackers can identify the passwords associated with the accounts, which they then use to remotely sign into machines or access resources.

All the Kerberoasing attack steps leading to the hash extraction can be accomplished using a single PowerShell (Invoke-Kerberoast.ps1), and has been integrated into popular post-exploitation frameworks like PowerSploit and PowerShell Empire:

Figure 6. Single command line to download and execute Kerberoasting to extract user password hashes

Code snippet of Kerberoasting

Figure 7. Kerberoasting code

Because AMSI has visibility into PowerShell scripts, when the Invoke-Kerberoast.ps1 is run, AMSI allows for inspection of the PowerShell content during runtime. This buffer is featurized and analyzed by client-side machine learning models, and sent to the cloud for real-time ML classification.

Code snippet of Kerberoasting showing featurized details

Figure 8. Sample featurized Kerberoasting code

Microsoft Defender ATP raises an alert for the detection of Invoke-Kerberoast.ps1:

Figure 9. Microsoft Defender Security Center alert showing detection of Invoke-Kerberoast.ps1

Training the machine learning models

To ensure continued high-quality detection of threats, the AMSI machine learning models are trained per scripting engine using real-time protection data and threat investigations.

Featurization is key to machine learning models making intelligent decisions about whether content is malicious or benign. For behavior-based script logs, we extract the set of libraries, COM object, and function names used by the script. Learning the most important features within the script content is performed through a combination of character ngramming the script or behavior log, followed by semi-asynchronous stochastic dual coordinate ascent (SA-SDCA) algorithm with L1 regularization feature trimming to learn and deploy the most important character ngram features.

On top of the same features used to train the client models, other complex features used to train the cloud modes include fuzzy hashes, cluster hashes, partial hashes, and more. In addition, the cloud models have access to other information like age, prevalence, global file information, reputation and others, which allow cloud models to make more accurate decisions for blocking.

Conclusion: Broad visibility informs AI-driven protections

Across Microsoft, AI and machine learning protection technologies use Microsoft’s broad visibility into various surfaces to identify new and unknown threats. Microsoft Threat Protection uses these machine learning-driven protections to detect threats across endpoints, email and data, identities, and apps.

On endpoints, Microsoft Defender ATP uses multiple next-generation protection engines that detect a wide range of threats. One of these engines uses insights from AMSI and pairs of machine learning models on the client and in the cloud working together to detect and stop malicious scripts post-execution.

These pairs of AMSI models, one pair for each scripting engine, are part of the behavior-based blocking and containment capabilities in Microsoft Defender ATP, which are designed to detect and stop threats even after they have started running. When running, threats are exposed and can’t hide behind encryption or obfuscation. This adds another layer of protection for instances where sophisticated threats are able to slip through pre-execution defenses.

Diagram showing different next-generation protection engines on the client and in the cloud

Figure 10. Microsoft Defender ATP next-generation protection engines

In this blog post, we showed how these AMSI-driven behavior-based machine learning protections are critical in detecting and stopping post-exploitation activities like BloodHound-based and Kerberoasting attacks, which employ evasive malicious scripts, including fileless components. With AMSI, script content and behavior are exposed, allowing Microsoft Defender ATP to foil reconnaissance activities and prevent attacks from progressing.

To learn more about behavior-based blocking and containment, read the following blog posts:

 

Ankit Garg and Geoff McDonald

Microsoft Defender ATP Research Team

The post Stopping Active Directory attacks and other post-exploitation behavior with AMSI and machine learning appeared first on Microsoft Security.

Inside Microsoft Threat Protection: Solving cross-domain security incidents through the power of correlation analytics

July 29th, 2020 No comments

In theory, a cyberattack can be disrupted at every phase of the attack chain. In reality, however, defense stack boundaries should overlap in order to be effective. When a threat comes via email, for example, even with good security solutions in place, organizations must assume that the threat may slip past email defenses, reach the target recipient, and further compromise endpoints and identities. While defenses on endpoints and identities could successfully tackle the attack in isolation, coordinating signals across protection components significantly increases the ability of these solutions to block and mitigate.

Microsoft Threat Protection takes this approach and delivers coordinated defense that binds together multiple solutions in the Microsoft 365 security portfolio. Microsoft Threat Protection continuously and seamlessly scours endpoints, email and docs, cloud app, and identity activities for suspicious signals. Through deep correlation logic, Microsoft Threat Protection automatically finds links between related signals across domains. It connects related existing alerts and generates additional alerts where suspicious events that could otherwise be missed can be detected. We call these correlated entities incidents.

How Microsoft Threat Protection’s advanced correlation make SOC analysts’ work easier and more efficient

Microsoft Threat Protection’s incident creation logic combines AI technology and our security experts’ collective domain knowledge, and builds on broad optics to provide comprehensive coverage. These correlations align with the MITRE ATT&CK framework over a unified schema of attack entities, enabling Microsoft Threat Protection to automatically connect the dots between seemingly unrelated signals.

Incidents ensure that elements otherwise spread across various portals and queues are presented in a single coherent view, helping security operations centers (SOC) in important ways. First, they reduce the SOC’s workload: incidents automatically collect and correlate isolated alerts and other related security events, so analysts have fewer, more comprehensive work items in their queue. Second, SOC analysts can analyze related alerts, affected assets, and other evidence together, reducing the need for manual correlation and making it easier and faster to understand the complete attack story and take informed actions.

Attack sprawl illustrated

The level of sophistication of today’s threats, including nation-state level attacks and human operated ransomware, highlight why coordinated defense is critical in ensuring that organizations are protected.

To illustrate how Microsoft Threat Protection protects against such sophisticated attacks, we asked our security research team to simulate an end-to-end attack chain across multiple domains, based on techniques we observed in actual investigations.

Their attack starts with a spear-phishing email targeting a specific user. The email contains a link that, when clicked, leads to the download of a malicious .lnk file that stages the Meterpreter payload. With their malicious code running on the target device, the attackers perform reconnaissance to understand which users have signed into the device and which other devices these users have access to. For example, in this case, they find the credentials of an IT helpdesk team member. Impersonating this IT helpdesk team member via overpass-the-hash, the attackers are able to move laterally to a second device.

On the second device, they steal the user’s web credentials, which they use to remotely access the user’s cloud apps like OneDrive or SharePoint. This allows the attackers to insert a malicious macro into an existing online Word document, which they then deploy in a lateral phishing attack by distributing links to the malicious document to other users in the organization.

Diagram showing an attack chain involving attack sprawl and techniques like overpass-the-hash

Figure 1. Our attack case scenario showing the initial access through spear-phishing and lateral movement through overpass-the-hash attack

When we ran this attack in our simulation environment, Microsoft Threat Protection was able to track attacker activities as they accessed the target organization, established foothold, and moved across the network. Then, invoking advanced correlation, Microsoft Threat Protection automatically collected all signals, alerts, and relevant entities into a single comprehensive incident representing the whole attack:

Screenshot of the incidents view in Microsoft security center

Figure 2. Incident showing the full attack chain and affected entities

Initial access: Correlating email, identity, and endpoint signals

Let’s look behind the scenes to understand how Microsoft Threat Protection connects the dots in such an attack.

When the target of the initial spear-phishing email clicks the URL in the email, a malicious .lnk file is downloaded and run on the device. In such a scenario, Office 365 Advanced Threat Protection (ATP) flags both the email and the URL as malicious and raises an alert. Normally, SOC analysts would analyze this alert, extract attacker indicators such as the malicious URL, manually search for all devices where this malicious URL was clicked, then take remediation actions on those devices.

Microsoft Threat Protection automates this process and saves time. The intelligence behind Microsoft Threat Protection correlations combines Office 365 ATP signals, Microsoft Defender ATP events, and Azure Active Directory (Azure AD) identity data to find the relevant malicious URL click activity on affected devices, even before SOC analysts starts looking at the alert. The automatic correlation of email, identity, and endpoint signals across on-premises and cloud entities raises the alert “Suspicious URL clicked”. Through this correlation-driven alert, Microsoft Threat Protection helps the SOC to expand their understanding of the attack using all relevant pieces of evidence and automate the search for compromised devices.

Screenshot of Microsoft security center showing list of alerts and highlighting the correlation-driven alert "Suspicious URL clicked"

Figure 3. Microsoft Threat Protection correlation-driven alert “Suspicious URL clicked”

Lateral movement: Correlating overpass-the-hash attack on one device and suspicious sign-in on another

So we’ve seen how automatic correlation allows Microsoft Threat Protection to uncover attacker activity related to initial access. The same capability exposes the next stages in the attack chain: credential theft and lateral movement.

Diagram showing an attack chain and showing correlation of cross-domain signals

Figure 4. Attack scenario showing alerts raised by correlation of cross-domain signals

In the next stage, the attackers use the overpass-the-hash method, a well-known impersonation technique. They control one device in the network where a domain user, like the IT helpdesk team member, is currently signed in. They then harvest NTLM credentials stored on the device to obtain a Kerberos ticket on the user’s behalf. The Kerberos ticket is a valid ticket that’s encrypted with the credentials of the domain user, allowing the attackers to pretend to be that user and access all resources that the user can access. Once attackers obtain credentials for a user with high privileges, they use the stolen credentials to sign in to other devices and move laterally.

In such cases, Azure ATP raises an alert on the suspicious Kerberos ticket, pointing to a potential overpass-the-hash attack. What would SOC analysts do at this point when investigating an overpass-the-hash alert? They would probably start enumerating all the users who signed in to the compromised device. They would also enumerate all other sign-ins for these users and further activities propagating to other devices in the network, all while mentally building an attack graph.

Saving precious time and eliminating manual work, Microsoft Threat Protection determines that the lateral movement activity is related to the earlier initial access. As a result, Microsoft Threat Protection correlates this activity, as well as users and devices involved, into the same incident, exposing other related activities and surfacing them as additional alerts in the same incident.

Screenshot of Microsoft security center showing list of alerts and highlighting the correlation-driven alert "Successful logon using potentially stolen credentials"

Figure 5. Correlating the overpass-the-hash alert

Microsoft Threat Protection also finds related sign-in events following the overpass-the-hash attack to trace the footprint of the impersonated user and surfaces alerts for malicious sign-ins made by the attacker. This allows Microsoft Threat Protection to elevate a series of raw sign-in events (which, when considered on their own, may lack context for detection) to alerts. The correlation-driven alert “Successful logon using potentially stolen credentials” instantly flags the compromised endpoints and pinpoints the start of the malicious activity in the timeline.

Screenshot of Microsoft security center showing correlation-driven alerts that determine that start of the attack

Figure 6. Correlation-driven alert can help determine the start of the attack

Lateral phishing: Correlating email, cloud, and device data

Using the breadth and depth of information available from the incident, SOC analysts can further expand their investigation. The Go hunt action allows SOC analysts to run an exhaustive, predefined query to hunt for relevant or similar threats and malicious activities from endpoints to the cloud, whether issued from inside the network or outside organizational boundaries.

Screenshot of Microsoft security center showing the Go hunt action

Figure 7. Generating a hunting query with a single click

 In this attack scenario, the query that Go hunt auto-generates instantly reveals suspicious OneDrive activity: while the user is operating from Great Britain, somebody from Sweden with the same account name seems to have downloaded a .docx file and replaced it with a similar file with .doc extension, indicating the insertion of the malicious macro.

Screenshot of Microsoft security center showing results of the Go hunt query, which reveals additional suspicious acitivity

Figure  8. “Go hunt” on the compromised user reveals suspicious activity

SOCs can further follow the propagation of the replaced file using an additional hunting query that combines email, OneDrive, and device data to find more affected users and devices, allowing SOC analysts to assess if additional compromise occurred and to take remediation actions. In our next blog post, we’ll provide more details about the investigation and hunting aspects of this scenario.

Conclusion: Connecting the dots and enriching incidents with more signals that tell the story

In this blog we demonstrated Microsoft Threat Protection’s unique ability to correlate signals across email and docs, devices, identities, and cloud apps, and present attack evidence in a unified form. Incidents significantly improve SOC efficiency by eliminating the need to use different portals and manually finding and connecting events, as well as enabling investigation and comprehensive response to attacks. The incident view shows alerts, affected entities, and related activities from across Microsoft 365 security solutions in a unified view.

Automatic correlations enrich incidents by consolidating relevant events and raising new alerts on malicious activities that couldn’t be flagged by any individual product on its own. These correlations paint a seamless attack story across perimeters by building an attack graph that SOC analysts can follow, starting with the earliest initial access.

Diagram showing automatic correlation of signals and alerts across domains

Figure 9. Automatic correlation across domains

Microsoft Threat Protection harnesses the power of Microsoft 365 security products to deliver unparalleled coordinated defense that detects, correlates, blocks, remediates, and prevents attacks across an organization’s Microsoft 365 environment. Existing Microsoft 365 licenses provide access to Microsoft Threat Protection features in Microsoft 365 security center without additional cost. To start using Microsoft Threat Protection, go to security.microsoft.com.

Learn how Microsoft Threat Protection can help your organization to stop attacks with coordinated defense. Read these blog posts in the Inside Microsoft Threat Protection series:

 

Stefan Sellmer, Tali Ash, Tal Maor

Microsoft Threat Protection Team

 

The post Inside Microsoft Threat Protection: Solving cross-domain security incidents through the power of correlation analytics appeared first on Microsoft Security.

Seeing the big picture: Deep learning-based fusion of behavior signals for threat detection

July 23rd, 2020 No comments

The application of deep learning and other machine learning methods to threat detection on endpoints, email and docs, apps, and identities drives a significant piece of the coordinated defense delivered by Microsoft Threat Protection. Within each domain as well as across domains, machine learning plays a critical role in analyzing and correlating massive amounts of data to detect increasingly evasive threats and build a complete picture of attacks.

On endpoints, Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) detects malware and malicious activities using various types of signals that span endpoint and network behaviors. Signals are aggregated and processed by heuristics and machine learning models in the cloud. In many cases, the detection of a particular type of behavior, such as registry modification or a PowerShell command, by a single heuristic or machine learning model is sufficient to create an alert.

Detecting more sophisticated threats and malicious behaviors considers a broader view and is significantly enhanced by fusion of signals occurring at different times. For example, an isolated event of file creation is generally not a very good indication of malicious activity, but when augmented with an observation that a scheduled task is created with the same dropped file, and combined with other signals, the file creation event becomes a significant indicator of malicious activity. To build a layer for these kinds of abstractions, Microsoft researchers instrumented new types of signals that aggregate individual signals and create behavior-based detections that can expose more advanced malicious behavior.

In this blog, we describe an application of deep learning, a category of machine learning algorithms, to the fusion of various behavior detections into a decision-making model. Since its deployment, this deep learning model has contributed to the detection of many sophisticated attacks and malware campaigns. As an example, the model uncovered a new variant of the Bondat worm that attempts to turn affected machines into zombies for a botnet. Bondat is known for using its network of zombie machines to hack websites or even perform cryptocurrency mining. This new version spreads using USB devices and then, once on a machine, achieves a fileless persistence. We share more technical details about this attack in latter sections, but first we describe the detection technology that caught it.

Powerful, high-precision classification model for wide-ranging data

Identifying and detecting malicious activities within massive amounts of data processed by Microsoft Defender ATP require smart automation methods and AI. Machine learning classifiers digest large volumes of historical data and apply automatically extracted insights to score each new data point as malicious or benign. Machine learning-based models may look at, for example, registry activity and produce a probability score, which indicates the probability of the registry write being associated with malicious activity. To tie everything together, behaviors are structured into virtual process trees, and all signals associated with each process tree are aggregated and used for detecting malicious activity.

With virtual process trees and signals of different types associated to these trees, there’s still large amounts of data and noisy signals to sift through. Since each signal occurs in the context of a process tree, it’s necessary to fuse these signals in the chronological order of execution within the process tree. Data ordered this way requires a powerful model to classify malicious vs. benign trees.

Our solution comprises several deep learning building blocks such as Convolutional Neural Networks (CNNs) and Long Short-Term Memory Recurrent Neural Networks (LSTM-RNN). The neural network can take behavior signals that occur chronologically in the process tree and treat each batch of signals as a sequence of events. These sequences can be collected and classified by the neural network with high precision and detection coverage.

Behavior-based and machine learning-based signals

Microsoft Defender ATP researchers instrument a wide range of behavior-based signals. For example, a signal can be for creating an entry in the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

A folder and executable file name added to this location automatically runs after the machine starts. This generates persistence on the machine and hence can be considered an indicator of compromise (IoC). Nevertheless, this IoC is generally not enough to generate detection because legitimate programs also use this mechanism.

Another example of behavior-based signal is service start activity. A program that starts a service through the command line using legitimate tools like net.exe is not considered a suspicious activity. However, starting a service created earlier by the same process tree to obtain persistence is an IoC.

On the other hand, machine learning-based models look at and produce signals on different pivots of a possible attack vector. For example, a machine learning model trained on historical data to discern between benign and malicious command lines will produce a score for each processed command line.

Consider the following command line:

 cmd /c taskkill /f /im someprocess.exe

This line implies that taskill.exe is evoked by cmd.exe to terminate a process with a particular name. While the command itself is not necessarily malicious, the machine learning model may be able to recognize suspicious patterns in the name of the process being terminated, and provide a maliciousness probability, which is aggregated with other signals in the process tree. The result is a sequence of events during a certain period of time for each virtual process tree.

The next step is to use a machine learning model to classify this sequence of events.

Data modeling

The sequences of events described in the previous sections can be represented in several different ways to then be fed into machine learning models.

The first and simple way is to construct a “dictionary” of all possible events, and to assign a unique identifier (index) to each event in the dictionary. This way, a sequence of events is represented by a vector, where each slot constitutes the number of occurrences (or other related measure) for an event type in the sequence.

For example, if all possible events in the system are X,Y, and Z, a sequence of events “X,Z,X,X” is represented by the vector [3, 0, 1], implying that it contains three events of type X, no events of type Y, and a single event of type Z. This representation scheme, widely known as “bag-of-words”,  is suitable for traditional machine learning models and has been used for a long time by machine learning practitioners. A limitation of the bag-of-words representation is that any information about the order of events in the sequence is lost.

The second representation scheme is chronological. Figure 1 shows a typical process tree: Process A raises an event X at time t1, Process B raises an event Z at time t2, D raises X at time t3, and E raises X at time t4. Now the entire sequence “X,Z,X,X”  (or [1,3,1,1] replacing events by their dictionary indices) is given to the machine learning model.

Diagram showing process tree

Figure 1. Sample process tree

In threat detection, the order of occurrence of different events is important information for the accurate detection of malicious activity. Therefore, it’s desirable to employ a representation scheme that preserves the order of events, as well as machine learning models that are capable of consuming such ordered data. This capability can be found in the deep learning models described in the next section.

Deep CNN-BiLSTM

Deep learning has shown great promise in sequential tasks in natural language processing like sentiment analysis and speech recognition. Microsoft Defender ATP uses deep learning for detecting various attacker techniques, including malicious PowerShell.

For the classification of signal sequences, we use a Deep Neural Network that combines two types of building blocks (layers): Convolutional Neural Networks (CNN) and Bidirectional Long Short-Term Memory Recurrent Neural Networks (BiLSTM-RNN).

CNNs are used in many tasks relating to spatial inputs such as images, audio, and natural language. A key property of CNNs is the ability to compress a wide-field view of the input into high-level features.  When using CNNs in image classification, high-level features mean parts of or entire objects that the network can recognize. In our use case, we want to model long sequences of signals within the process tree to create high-level and localized features for the next layer of the network. These features could represent sequences of signals that appear together within the data, for example, create and run a file, or save a file and create a registry entry to run the file the next time the machine starts. Features created by the CNN layers are easier to digest for the ensuing LSTM layer because of this compression and featurization.

LSTM deep learning layers are famous for results in sentence classification, translation, speech recognition, sentiment analysis, and other sequence modeling tasks. Bidirectional LSTM combine two layers of LSTMs that process the sequence in opposite directions.

The combination of the two types of neural networks stacked one on top of the other has shown to be very effective and can classify long sequences of hundreds of items and more. The final model is a combination of several layers: one embedding layer, two CNNs, and a single BiLSTM. The input to this model is a sequence of hundreds of integers representing the signals associated with a single process tree during a unit of time. Figure 2 shows the architecture of our model.

Diagram showing layers of the CNN BiLSTM model

Figure 2. CNN-BiLSTM model

Since the number of possible signals in the system is very high, input sequences are passed through an embedding layer that compresses high-dimensional inputs into low-dimensional vectors that can be processed by the network. In addition, similar signals get a similar vector in lower dimensional space, which helps with the final classification.

Initial layers of the network create increasingly high-level features, and the final layer performs sequence classification. The output of the final layer is a score between 0 and 1 that indicates the probability of the sequence of signals being malicious. This score is used in combination with other models to predict if the process tree is malicious.

Catching real-world threats

Microsoft Defender ATP’s endpoint detection and response capabilities use this Deep CNN-BiLSTM model to catch and raise alerts on real-world threats. As mentioned, one notable attack that this model uncovered is a new variant of the Bondat worm, which was seen propagating in several organizations through USB devices.

Diagram showing the Bondat attack chain

Figure 3. Bondat malware attack chain

Even with an arguably inefficient propagation method, the malware could persist in an organization as users continue to use infected USB devices. For example, the malware was observed in hundreds of machines in one organization. Although we detected the attack during the infection period, it continued spreading until all malicious USB drives were collected. Figure 4 shows the infection timeline.

Column chart showing daily encounters of the Bondat malware in one organization

Figure 4. Timeline of encounters within a single organization within a period of 5 months showing reinfection through USB devices

The attack drops a JavaScript payload, which it runs directly in memory using wscript.exe. The JavaScript payload uses a randomly generated filename as a way to evade detections. However, Antimalware Scan Interface (AMSI) exposes malicious script behaviors.

To spread via USB devices, the malware leverages WMI to query the machine’s disks by calling “SELECT * FROM Win32_DiskDrive”. When it finds a match for “/usb” (see Figure 5), it copies the JavaScript payload to the USB device and creates a batch file on the USB device’s root folder. The said batch file contains the execution command for the payload. As part of its social engineering technique to trick users into running the malware in the removable device, it creates a LNK file on the USB pointing to the batch file.

Screenshot of malware code showing infection technique

Figure 5. Infection technique

The malware terminates processes related to antivirus software or debugging tools. For Microsoft Defender ATP customers, tamper protection prevents the malware from doing this. Notably, after terminating a process, the malware pops up a window that imitates a Windows error message to make it appear like the process crashed (See figure 6).

Screenshot of malware code showing infection technique

Figure 6. Evasion technique

The malware communicates with a remote command-and-control (C2) server by implementing a web client (MSXML). Each request is encrypted with RC4 using a randomly generated key, which is sent within the “PHPSESSID” cookie value to allow attackers to decrypt the payload within the POST body.

Every request sends information about the machine and its state following the output of the previously executed command. The response is saved to disk and then parsed to extract commands within an HTML comment tag. The first five characters from the payload are used as key to decrypt the data, and the commands are executed using the eval() method. Figures 7 and 8 show the C2 communication and HTML comment eval technique.

Once the command is parsed and evaluated by the JavaScript engine, any code can be executed on an affected machine, for example, download other payloads, steal sensitive info, and exfiltrate stolen data. For this Bondat campaign, the malware runs coin mining or coordinated distributed denial of service (DDoS) attacks.

Figure 7. C2 communication

Figure 8. Eval technique (parsing commands from html comment)

The malware’s activities triggered several signals throughout the attack chain. The deep learning model inspected these signals and the sequence with which they occurred, and determined that the process tree was malicious, raising an alert:

  1. Persistence – The malware copies itself into the Startup folder and drops a .lnk file pointing to the malware copy that opens when the computer starts
  2. Renaming a known operating system tool – The malware renames exe into a random filename
  3. Dropping a file with the same filename as legitimate tools – The malware impersonates legitimate system tools by dropping a file with a similar name to a known tool.
  4. Suspicious command line – The malware tries to delete itself from previous location using a command line executed by a process spawned by exe
  5. Suspicious script content – Obfuscated JavaScript payload used to hide the attacker’s intentions
  6. Suspicious network communication – The malware connects to the domain legitville[.]com

Conclusion

Modeling a process tree, given different signals that happen at different times, is a complex task. It requires powerful models that can remember long sequences and still be able to generalize well enough to churn out high-quality detections. The Deep CNN-BiLSTM model we discussed in this blog is a powerful technology that helps Microsoft Defender ATP achieve this task. Today, this deep learning-based solution contributes to Microsoft Defender ATP’s capability to detect evolving threats like Bondat.

Microsoft Defender ATP raises alerts for these deep learning-driven detections, enabling security operations teams to respond to attacks using Microsoft Defender ATP’s other capabilities, like threat and vulnerability management, attack surface reduction, next-generation protection, automated investigation and response, and Microsoft Threat Experts. Notably, these alerts inform behavioral blocking and containment capabilities, which add another layer of protection by blocking threats if they somehow manage to start running on machines.

The impact of deep learning-based protections on endpoints accrues to the broader Microsoft Threat Protection (MTP), which combines endpoint signals with threat data from email and docs, identities, and apps to provide cross-domain visibility. MTP harnesses the power of Microsoft 365 security products to deliver unparalleled coordinated defense that detects, blocks, remediates, and prevents attacks across an organization’s Microsoft 365 environment. Through machine learning and AI technologies like the deep-learning model we discussed in this blog, MTP automatically analyzes cross-domain data to build a complete picture of each attack, eliminating the need for security operations centers (SOC) to manually build and track the end-to-end attack chain and relevant details. MTP correlates and consolidates attack evidence into incidents, so SOCs can save time and focus on critical tasks like expanding investigations and proacting threat hunting.

 

Arie Agranonik, Shay Kels, Guy Arazi

Microsoft Defender ATP Research Team

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Threat Protection and Microsoft Defender ATP tech communities.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Seeing the big picture: Deep learning-based fusion of behavior signals for threat detection appeared first on Microsoft Security.

Inside Microsoft Threat Protection: Correlating and consolidating attacks into incidents

July 9th, 2020 No comments

Cybersecurity incidents are never contained to just one of your organization’s assets. Most attacks involve multiple elements across domains, including email, endpoints, identities, and applications. To rapidly understand and address incidents, your Security Operations Center (SOC) analysts need to be able to see and track all the signals from each domain, correlate and group alerts that are related, prioritize them based on their severity level, and remediate all affected assets to return them and your workforce to a secure state.

Getting a unified view of an attack is a top SOC analyst priority in quickly building the end-to-end picture of attacks and tracking all relevant details necessary for effective remediation. Navigating multiple products and switching between tools introduce friction that slows down investigations, giving attackers more time to inflict damage.

Microsoft Threat Protection (MTP) addresses this critical SOC need through incidents, which empower SOC analysts by automatically fusing attack evidence and providing a consolidated view of an attack chain and affected assets, as well as a single-click remediation with easy-to-read analyst workflows. MTP harnesses the power of multiple solutions in the Microsoft 365 security portfolio – Office 365 Advanced Threat Protection (ATP), Azure ATP, Microsoft Defender ATP, and Microsoft Cloud App Security – to deliver cross-domain visibility and coordinated defense.

A complete look at the attack chain to prevent attack sprawl

A typical attack starts with a phishing email that installs malware on an endpoint. The malware then steals the user’s credentials, which the attackers utilize to access resources on other endpoints, on-premises applications, and cloud services. Individual security solutions that focus on only one domain may alert on and remediate a portion of the attack but will likely miss other parts of the attacker operations, putting an organization at risk while creating a false sense of security.

The incidents view in Microsoft Threat Protection solves this challenge by providing a single place to view and investigate an attack across stages, from initial access to impact. Based on individual detection leads, MTP uses artificial intelligence (AI) to automatically expand an investigation, like an experienced analyst would, and gather related telemetry and other alerts that belong to the same attack. MTP also uses AI to continually analyze the vast amount of available data and, if necessary, suggest more evidence for the analyst to add to the incident. This enables your SOC analysts to focus on what matters, while MTP saves them time and helps discover undetected evidence.

Even if you don’t have all the Microsoft 365 security solutions in your organization, MTP incidents correlate threat data for the services you have deployed, reducing the clutter and providing one view of the attack, including all relevant alerts, impacted assets and associated risk levels, remediation actions and status.

Screenshot of Microsoft 365 security center showing the overview tab of the Incidents view

Streamlining investigations across domains

Microsoft Threat Protection simplifies the complex task of investigating end-to-end attacks by allowing SOC analysts to pivot and see entities – devices, files, users, emails, and processes – in the right context within a single view.

MTP breaks down the silos and combines all alerts and insights automatically across Microsoft 365 services to reveal the full picture, helping ease digital forensics work for SOC analysts. This also enables analysts to gain comprehensive understanding of attacks that they wouldn’t otherwise get from isolated out-of-context alerts.

But MTP doesn’t stop there. To help support effective triage processes, MTP prioritizes incidents, illustrates the attack chain progression, shows the attack timeline, and generates a comprehensive name for the incident. With just one click, analysts can answer questions like: Does a file observed on one device exist on other devices? Which email messages did a file come from, and was this file also shared through a cloud app?

In addition, SOC analysts can easily search for additional related activities with Go hunt, which automatically creates and runs an advanced hunting query based on information from the incident. SOC analysts can also use attack-specific insights gained during hunting to capture fine-tuned logic and nuances in a custom detection. Custom detections continuously hunt for new activities and pull new findings to the relevant incident automatically, further enriching your view of the attack.

A clear view of the remediation status

When your organization is under attack, it’s essential to act swiftly but thoughtfully through a thorough understanding at any point in time of the remediation status of all affected assets and entities. MTP incidents play a critical part in remediation by:

  • Removing some of the burden off the analysts’ shoulders by launching automated investigation and response (AIR) self-healing playbooks that conduct in-depth asset-based investigation and work to find and remediate all malicious evidence (attack tools, malware), persistence methods (Oauth apps, ASEP in devices), exfiltration activities (email FWD rules, SPO shares),
  • Orchestrating cross-asset and cross-domain playbook invocations, tracking attacker activity across the environment
  • Providing a comprehensive view of the remediation status based on actions taken by AIR, in addition to manual actions by the analyst

When the investigation is complete, MTP incidents capture the investigation comments for record-keeping and knowledge-sharing with peers, with easy and in-context information for reference.

Microsoft Threat Protection provides the SOC with a complete picture of attacks in real-time

The incidents view in Microsoft Threat Protection correlates alerts and all affected entities into a cohesive view that enables your SOC to determine the full scope of threats across your Microsoft 365 services. Armed with a complete picture of attacks in real-time, your SOCs are better empowered to defend your organization against threats.

MTP delivers coordinated defense by leveraging the power of multiple Microsoft 365 security solutions. Through automation, built-in intelligence, and end-to-end visibility into malicious activities, MTP detects, correlates, blocks, remediates, and prevents attacks.

Existing Microsoft 365 licenses provide access to Microsoft Threat Protection features in Microsoft 365 security center without additional cost or deployment. Learn how Microsoft Threat Protection can help your organization to stop attacks with coordinated defense.

To learn more about coordinated defense, read these blog posts in the Inside Microsoft Threat Protection series:

 

Idan Pelleg

Microsoft Threat Protection Team

The post Inside Microsoft Threat Protection: Correlating and consolidating attacks into incidents appeared first on Microsoft Security.

Inside Microsoft Threat Protection: Correlating and consolidating attacks into incidents

July 9th, 2020 No comments

Cybersecurity incidents are never contained to just one of your organization’s assets. Most attacks involve multiple elements across domains, including email, endpoints, identities, and applications. To rapidly understand and address incidents, your Security Operations Center (SOC) analysts need to be able to see and track all the signals from each domain, correlate and group alerts that are related, prioritize them based on their severity level, and remediate all affected assets to return them and your workforce to a secure state.

Getting a unified view of an attack is a top SOC analyst priority in quickly building the end-to-end picture of attacks and tracking all relevant details necessary for effective remediation. Navigating multiple products and switching between tools introduce friction that slows down investigations, giving attackers more time to inflict damage.

Microsoft Threat Protection (MTP) addresses this critical SOC need through incidents, which empower SOC analysts by automatically fusing attack evidence and providing a consolidated view of an attack chain and affected assets, as well as a single-click remediation with easy-to-read analyst workflows. MTP harnesses the power of multiple solutions in the Microsoft 365 security portfolio – Office 365 Advanced Threat Protection (ATP), Azure ATP, Microsoft Defender ATP, and Microsoft Cloud App Security – to deliver cross-domain visibility and coordinated defense.

A complete look at the attack chain to prevent attack sprawl

A typical attack starts with a phishing email that installs malware on an endpoint. The malware then steals the user’s credentials, which the attackers utilize to access resources on other endpoints, on-premises applications, and cloud services. Individual security solutions that focus on only one domain may alert on and remediate a portion of the attack but will likely miss other parts of the attacker operations, putting an organization at risk while creating a false sense of security.

The incidents view in Microsoft Threat Protection solves this challenge by providing a single place to view and investigate an attack across stages, from initial access to impact. Based on individual detection leads, MTP uses artificial intelligence (AI) to automatically expand an investigation, like an experienced analyst would, and gather related telemetry and other alerts that belong to the same attack. MTP also uses AI to continually analyze the vast amount of available data and, if necessary, suggest more evidence for the analyst to add to the incident. This enables your SOC analysts to focus on what matters, while MTP saves them time and helps discover undetected evidence.

Even if you don’t have all the Microsoft 365 security solutions in your organization, MTP incidents correlate threat data for the services you have deployed, reducing the clutter and providing one view of the attack, including all relevant alerts, impacted assets and associated risk levels, remediation actions and status.

Screenshot of Microsoft 365 security center showing the overview tab of the Incidents view

Streamlining investigations across domains

Microsoft Threat Protection simplifies the complex task of investigating end-to-end attacks by allowing SOC analysts to pivot and see entities – devices, files, users, emails, and processes – in the right context within a single view.

MTP breaks down the silos and combines all alerts and insights automatically across Microsoft 365 services to reveal the full picture, helping ease digital forensics work for SOC analysts. This also enables analysts to gain comprehensive understanding of attacks that they wouldn’t otherwise get from isolated out-of-context alerts.

But MTP doesn’t stop there. To help support effective triage processes, MTP prioritizes incidents, illustrates the attack chain progression, shows the attack timeline, and generates a comprehensive name for the incident. With just one click, analysts can answer questions like: Does a file observed on one device exist on other devices? Which email messages did a file come from, and was this file also shared through a cloud app?

In addition, SOC analysts can easily search for additional related activities with Go hunt, which automatically creates and runs an advanced hunting query based on information from the incident. SOC analysts can also use attack-specific insights gained during hunting to capture fine-tuned logic and nuances in a custom detection. Custom detections continuously hunt for new activities and pull new findings to the relevant incident automatically, further enriching your view of the attack.

A clear view of the remediation status

When your organization is under attack, it’s essential to act swiftly but thoughtfully through a thorough understanding at any point in time of the remediation status of all affected assets and entities. MTP incidents play a critical part in remediation by:

  • Removing some of the burden off the analysts’ shoulders by launching automated investigation and response (AIR) self-healing playbooks that conduct in-depth asset-based investigation and work to find and remediate all malicious evidence (attack tools, malware), persistence methods (Oauth apps, ASEP in devices), exfiltration activities (email FWD rules, SPO shares),
  • Orchestrating cross-asset and cross-domain playbook invocations, tracking attacker activity across the environment
  • Providing a comprehensive view of the remediation status based on actions taken by AIR, in addition to manual actions by the analyst

When the investigation is complete, MTP incidents capture the investigation comments for record-keeping and knowledge-sharing with peers, with easy and in-context information for reference.

Microsoft Threat Protection provides the SOC with a complete picture of attacks in real-time

The incidents view in Microsoft Threat Protection correlates alerts and all affected entities into a cohesive view that enables your SOC to determine the full scope of threats across your Microsoft 365 services. Armed with a complete picture of attacks in real-time, your SOCs are better empowered to defend your organization against threats.

MTP delivers coordinated defense by leveraging the power of multiple Microsoft 365 security solutions. Through automation, built-in intelligence, and end-to-end visibility into malicious activities, MTP detects, correlates, blocks, remediates, and prevents attacks.

Existing Microsoft 365 licenses provide access to Microsoft Threat Protection features in Microsoft 365 security center without additional cost or deployment. Learn how Microsoft Threat Protection can help your organization to stop attacks with coordinated defense.

To learn more about coordinated defense, read these blog posts in the Inside Microsoft Threat Protection series:

 

Idan Pelleg

Microsoft Threat Protection Team

The post Inside Microsoft Threat Protection: Correlating and consolidating attacks into incidents appeared first on Microsoft Security.

Introducing Kernel Data Protection, a new platform security technology for preventing data corruption

July 8th, 2020 No comments

Attackers, confronted by security technologies that prevent memory corruption, like Code Integrity (CI) and Control Flow Guard (CFG), are expectedly shifting their techniques towards data corruption. Attackers use data corruption techniques to target system security policy, escalate privileges, tamper with security attestation, modify “initialize once” data structures, among others.

Kernel Data Protection (KDP) is a new technology that prevents data corruption attacks by protecting parts of the Windows kernel and drivers through virtualization-based security (VBS). KDP is a set of APIs that provide the ability to mark some kernel memory as read-only, preventing attackers from ever modifying protected memory. For example, we’ve seen attackers use signed but vulnerable drivers to attack policy data structures and install a malicious, unsigned driver. KDP mitigates such attacks by ensuring that policy data structures cannot be tampered with.

The concept of protecting kernel memory as read-only has valuable applications for the Windows kernel, inbox components, security products, and even third-party drivers like anti-cheat and digital rights management (DRM) software. On top of the important security and tamper protection applications of this technology, other benefits include:

  • Performance improvements – KDP lessens the burden on attestation components, which would no longer need to periodically verify data variables that have been write-protected
  • Reliability improvements – KDP makes it easier to diagnose memory corruption bugs that don’t necessarily represent security vulnerabilities
  • Providing an incentive for driver developers and vendors to improve compatibility with virtualization-based security, improving adoption of these technologies in the ecosystem

KDP uses technologies that are supported by default on Secured-core PCs, which implement a specific set of device requirements that apply the security best practices of isolation and minimal trust to the technologies that underpin the Windows operating system. KDP enhances the security provided by the features that make up Secured-core PCs by adding another layer of protection for sensitive system configuration data.

In this blog we’ll share technical details about how Kernel Data Protection works and how it’s implemented on Windows 10, with the goal of inspiring and empowering driver developers and vendors to take full advantage of this technology designed to tackle data corruption attacks.

Kernel Data Protection: An overview

In VBS environments, the normal NT kernel runs in a virtualized environment called VTL0, while the secure kernel runs in a more secure and isolated environment called VTL1. More details on VBS and the secure kernel are available on Channel 9 here and here. KDP is intended to protect drivers and software running in the Windows kernel (i.e., the OS code itself) against data-driven attacks. It is implemented in two parts:

  • Static KDP enables software running in kernel mode to statically protect a section of its own image from being tampered with from any other entity in VTL0.
  • Dynamic KDP helps kernel-mode software to allocate and release read-only memory from a “secure pool”. The memory returned from the pool can be initialized only once.

The memory managed by KDP is always verified by the secure kernel (VTL1) and protected using second level address translation (SLAT) tables by the hypervisor. As a result, no software running in the NT kernel (VTL0) will ever be able to modify the content of the protected memory.

Both dynamic and static KDP, which are already available in the latest Windows 10 Insider Build and work with any kind of memory, except for executable pages. Protection for executable pages is already provided by hypervisor-protected code integrity (HVCI), which prevents any non-signed memory from being ever executable, granting the W^X (a page that is either writable or executable, but never both) condition. HVCI and the W^X conditions are not explained in this article (refer to the new upcoming Windows Internals book for further details).

Static KDP

A driver that wants a section of its image protected through static KDP should call the MmProtectDriverSection API, which has the following prototype:

NTSTATUS MmProtectDriverSection (PVOID AddressWithinSection, SIZE_T Size, ULONG Flags)

A driver specifies an address located inside a data section and, optionally, the size of the protected area and some flags. As of this writing, the “size” parameter is reserved for future use: the entire data section where the address resides will always be protected by the API.

In case the function succeeds, the memory backing the static section becomes read-only for VTL0 and protected through the SLAT. Unloading a driver that has a protected section is not allowed; attempting to do so will result in, by design, a blue screen error. However, we know that sometimes a driver should be able to be unloaded. Therefore, we have introduced the MM_PROTECT_DRIVER_SECTION_ALLOW _UNLOAD flag (1). If the caller specifies it, the system will be able to unload the target driver, which means that in this case, the protected section will be first unprotected and then released by NtUnloadDriver.

Dynamic KDP

Dynamic KDP allows a driver to allocate and initialize read-only memory using services provided by a secure pool, which is managed by the secure kernel. The consumer first creates a secure pool context associated with a tag. All of the consumer’s future memory allocations will be associated with the created secure pool context. After the context is created, read-only allocations can be performed through a new extended parameter to the ExAllocatePool3 API:

PVOID ExAllocatePool3 (POOL_FLAGS Flags, SIZE_T NumberOfBytes, ULONG Tag, PCPOOL_EXTENDED_PARAMETER ExtendedParameters, ULONG Count);

The caller can then specify the size of the allocation and the initial buffer from where to copy the memory in a POOL_EXTENDED_PARAMS_SECURE_POOL data structure. The returned memory region can’t be modified by any entity running in VTL0. In addition, at allocation time, the caller supplies a tag and a cookie value, which are encoded and embedded into the allocation. The consumer can, at any time, validate that an address is within the memory range reserved for dynamic KDP allocations and that the expected cookie and tag are in fact encoded into a given allocation. This allows the caller to check that their pointer to a secure pool allocation has not been switched with a different allocation.

Similar to static KDP, by default the memory region can’t be freed or modified. The caller can specify at allocation time that the allocation is freeable or modifiable using the SECURE_POOL_FLAGS_FREEABLE (1) and SECURE_POOL_FLAG_MODIFIABLE(2) flags. Using these flags reduces the security of allocation but allows dynamic KDP memory to be used in scenarios where leaking all allocations would be infeasible, such as allocations which are made per process on the machine.

Implementing KDP on Windows 10

As mentioned, both static KDP and dynamic KDP rely on the physical memory being protected by the SLAT in the hypervisor. When a processor supports the SLAT, it uses another layer for memory address translation. (Note: AMD implements the SLAT through “nested page tables”, while Intel uses the term “extended page tables”.)

The second-level address translation (SLAT)

When the hypervisor enables SLAT support, and a VM is executing in VMX non-root mode, the processor translates an initial virtual address called Guest Virtual Address (GVA, or stage 1 virtual address in ARM64) in an intermediate physical address called Guest Physical Address (GPA, or IPA in ARM64). This translation is still managed by the page tables, addressed by the CR3 control register managed by the Guest OS. The final result of the translation yields back to the processor a GPA, with the access protection specified in the guest page tables. Note that only software operating in kernel mode can interact with page tables. A rootkit usually operates in kernel mode and can indeed modify the protection of the intermediate physical pages.

The hypervisor helps the processor to translate the GPA using the extended (or nested) page tables. On non-SLAT systems, when a virtual address is not present in the TLB, the processor needs to consult all the page tables in the hierarchy to reconstruct the final physical address. As shown in Figure 1, the virtual address is split into four parts (on LA48 systems). Each part represents the index into a page table of the hierarchy. The physical address of the initial PML4 table is specified by the CR3 register. This explains why the processor is always able to translate the address and get the next physical address of the next table in the hierarchy. It’s important to note that in each page table entry of the hierarchy, the NT kernel specifies a page protection through a set of attributes. The final physical address is accessible only if the sum of the protections specified in each page table entry allows it.

Diagram showing X64 stage 1 address translation from virtual address to guest physical address

Figure 1. The X64 Stage 1 address translation (Virtual address to guest physical address)

When the SLAT is on, the intermediate physical address specified in the guest’s CR3 register needs to be translated to a real system physical address (SPA). The mechanism is similar: the hypervisor configures the nCR3 field of the active virtual machine control block (VMCB) representing the currently executing VM to the physical address of the nested (or extended) page tables (note that the field is called “EPT pointer” in the Intel architecture). The nested page tables are built in a similar way to standard page tables, so the processor needs to scan the entire hierarchy to find the correct physical address, as illustrated in figure 2. In the figure, “n” indicates nested page tables in the hierarchy, which is managed by the hypervisor, while “g” indicates guest page tables, which is managed by the NT Kernel.

Diagram showing X64 stage 2 physical address translation from GPA to SPA

Figure 2. The X64 Stage 2 physical address translation (GPA to SPA)

As shown, the final translation of a guest virtual address to a system physical address goes through two translation types: GVA to GPA, configured by the guest VM’s kernel, and GPA to SPA, configured by the hypervisor. Note that in the worst case, the translation involves all four page hierarchy levels, which results in 20 table lookups. The mechanism could be slow and is mitigated by processor support for an enhanced TLB. In the TLB entries, another ID that identifies the currently executing VM is included (called virtual processor identifier or VPID in Intel systems, address space ID or ASID in AMD systems), so the processor can cache the translation result of a virtual address belonging to two different VMs without any collision.

Diagram showing nested entry of an NPT page table in the hierarchy

Figure 3. Nested entry of an NPT page table in the hierarchy

As highlighted in Figure 3, an NPT entry specifies multiple access protection attributes. This allows the hypervisor to further protect the system physical address (the NPT cannot be accessed by any other entity except for the hypervisor itself). When the processor attempts to read, write, or run an address to which the NPTs disallow access, an NPT violation (EPT violation in Intel architecture) is raised, and a VM exit is generated. A VM exit generated by NTP violation does not happen frequently. In general, it is produced in nested configurations or when Software MBEC is in use for HVCI. If the NPT violation happens for other reasons, the Microsoft Hypervisor injects an access violation exception to the current virtual processor (VP), which is managed by the guest OS in different ways but typically through a bug check if no exception handler elects to handle the exception.

Static KDP implementation

The SLAT protection is the main principle that allows KDP to exist. In Windows, dynamic and static KDP implementations are similar and are managed by the secure kernel. The secure kernel is the only entity that is able to emit the ModifyVtlProtectionMask hypercall to the hypervisor with the goal of modifying the SLAT access protection for a physical page mapped in the lower VTL0.

For static KDP, the NT kernel verifies that the driver is not a session driver or mapped with large pages. If one of these conditions exists, or if the section is a discardable section, static KDP can’t be applied. If the entity that called the MmProtectDriverSection API did not request the target image to be unloadable, the NT kernel performs the first call into the secure kernel, which pins the normal address range (NAR) associated with the driver. The “pinning” operation prevents the address space of the driver from being reused, making the driver not unloadable. The NT kernel then brings all the pages that belong to the section in memory and makes them private (i.e., not addressed by the prototype PTEs). The pages are then marked as read-only in the leaf PTE structures (highlighted as “gPTE” in figure 2). At this stage, the NT kernel can finally call the secure kernel for protecting the underlying physical pages through the SLAT. The secure kernel applies the protection in two phases:

  1. Register all the physical pages that belong to the section and mark them as “owned by VTL0” by adding the proper NTEs (normal table addresses) in the database and updating the underlying secure PFNs, which belong to VTL1. This allows the secure kernel to track the physical pages, which still belong to the NT kernel.
  2. Apply the read-only protection to the VTL0 SLAT table. The hypervisor uses one SLAT table and VMCB per VTL.

The target image’s section is now protected. No entity in VTL0 will be able to write to any of the pages belonging to the section. As highlighted, the secure kernel in this scenario has protected some memory pages that were initially allocated by the NT kernel in VTL0.

Dynamic KDP implementation

Dynamic KDP uses services provided by the new segment heap for allocating memory from a secure pool, which is almost entirely managed by the secure kernel.

In early phases of its boot process, the NT memory manager calculates the randomized virtual base address of a 512GB region used for the secure pool, which spans exactly one of the 256 kernel PML4 entries. Later in phase 1, the NT memory manager emits a secure call, internally named  INITIALIZE_SECURE_POOL, which includes the calculated memory region and allows the secure kernel to initialize the secure pool.

The secure kernel creates a NAR representing the entire 512GB virtual region belonging to the unsecure NT kernel, and initializes all the relative NTEs belonging to the NAR. The secure pool virtual address space in the secure kernel is 256GB wide, which means that the PML4 mapping it is shared with some other content and is not at the same base address compared to the NT one. So, while initializing the secure pool descriptor, the secure kernel also calculates a delta value, which is the difference between the secure pool base address in the secure kernel and the one reserved in the NT kernel (as shown in figure 4). This is important, because it allows the secure kernel to specify to the NT kernel where to map a physical page belonging to the secure pool.

Diagram showing the secure pool from VTL1 to VT0 delta

Figure 4. The Secure Pool VTL1 to VTL 0 DELTA value.

When software running in VTL0 kernel requests some memory to be allocated from the secure pool, a secure call is made to the secure kernel, which invokes the internal RtlpHpAllocateHeap heap function, which is exposed in both VTLs. If the segment heap calculates that there are no more free memory segments left in the secure pool, it calls the SkmmAllocatePoolMemory routine, which allocates new memory pages for the pool. The heap always tries to avoid committing new memory pages if it doesn’t really need to.

Like the NtAllocateVirtualMemory API, which is exposed by the NT kernel, the SkmmAllocatePoolMemory API supports two kinds of operations: reserve and commit. A reserve operation allows the secure kernel’s memory manager to reserve some PTEs needed for the pool allocation. A commit operation actually allocates free physical pages.

Physical pages are allocated from a bundle of free pages that belong to the secure kernel, whose secure PFNs are in the secure state, and mapped in the VTL 1’s page table, which means that all the VTL 1 paging table hierarchy are allocated. Like static KDP, the secure kernel sends the “ModifyVtlProtectionMask” hypercall to the hypervisor, with the goal of mapping the physical pages as read-only in the VTL0 SLAT table. After the pages become accessible to VTL0, the secure kernel copies the data specified by the caller and calls back NT.

The NT kernel uses services provided by the memory manager to map the guest physical pages in VTL0. Remember that the entire root partition physical address space of both VTL0 and VTL1 is mapped with the identity mapping, meaning that a guest physical page number valid in VTL0 is also valid in VTL1. The secure kernel asks the NT memory manager to map a page belonging to the secure pool by knowing exactly which virtual address the page should be mapped to. This is thanks to the delta value calculated previously in phase 1 (figure 4).

The allocation is returned to the caller in VTL0. The underlaying pages, as with static KDP, are no more writable from any entity in VTL0.

Astute readers will note that the above description of KDP deals only with establishing SLAT protections for the guest physical address(es) backing a given protected memory region. KDP does not enforce how the virtual address range mapping a protected region is translated. Today, the secure kernel verifies only on a periodic basis that protected memory regions translate to the appropriate, SLAT-protected GPA. The design of KDP permits the possibility of future extensions to assert more direct control over the address translation hierarchy of protected memory regions.

Applications of KDP on inbox components

To demonstrate how KDP can provide value two inbox components, we’re highlighting how it’s implemented in CI.dll, the code integrity engine in Windows, and the Windows Defender System Guard runtime attestation engine.

First, CI.dll. The goal of using KDP is to protect internal policy state after it has been initialized (i.e., read from the registry or generated at boot time). These data structures are critical to protect as if they are tampered with—a driver that is properly signed but vulnerable could attack the policy data structures and then install an unsigned driver on the system. With KDP, this attack is mitigated by ensuring the policy data structures cannot be tampered with.

Second, Windows Defender System Guard. To provide runtime attestation, the attestation broker is only allowed to connect to the attestation driver one time. This is because the state is stored in VTL1 memory. The driver stores the connection state in its memory and this needs to be protected to prevent an attack from trying to reset the connection with a potentially tampered with broker agent. KDP can lock these variables and ensure that only a single connection between the broker and driver can be established.

Code integrity and Windows Defender System Guard are two of the critical features of Secured-core PCs. KDP enhances protection for these vital security systems and raise the bar that attackers need to overcome to compromise Secured-core PCs.

These are just a few examples of how useful protecting kernel and driver memory as read-only can be for the security and integrity of the system. As KDP is adopted more broadly, we expect to be able to expand the scope of protection as we look to protect against data corruption attacks more broadly.

Getting started with KDP

Both dynamic and static KDP do not have any further requirements other than the ones needed for running virtualization-based security. In ideal conditions, VBS can be started on any computer that supports:

  • Intel, AMD or ARM virtualization extensions
  • Second-level address translation: NPT for AMD, EPT for Intel, Stage 2 address translation for ARM
  • Optionally, hardware MBEC, which reduces the performance cost associated with HVCI

More info on the requirements for VBS can be found here. On Secured-core PCs, virtualization-based security is supported and hardware-backed security features are enabled by default. Customers can find Secured-core PCs from a variety of partner vendors that feature the comprehensive Secured-core security features that are now enhanced by KDP.

 

Andrea Allievi

Security Kernel Core Team

The post Introducing Kernel Data Protection, a new platform security technology for preventing data corruption appeared first on Microsoft Security.

Defending Exchange servers under attack

June 24th, 2020 No comments

Securing Exchange servers is one of the most important things defenders can do to limit organizational exposure to attacks. Any threat or vulnerability impacting Exchange servers should be treated with the highest priority because these servers contain critical business data, as well as highly privileged accounts that attackers attempt to compromise to gain admin rights to the server and, consequently, complete control of the network.

If compromised, Exchange servers provide a unique environment that could allow attackers to perform various tasks using the same built-in tools or scripts that admins use for maintenance. This is exacerbated by the fact that Exchange servers have traditionally lacked antivirus solutions, network protection, the latest security updates, and proper security configuration, often intentionally, due to the misguided notion that these protections interfere with normal Exchange functions. Attackers know this, and they leverage this knowledge to gain a stable foothold on a target organization.

There are two primary ways in which Exchange servers are compromised. The first and more common scenario is attackers launching social engineering or drive-by download attacks targeting endpoints, where they steal credentials and move laterally to other endpoints in a progressive dump-escalate-move method until they gain access to an Exchange server.

The second scenario is where attackers exploit a remote code execution vulnerability affecting the underlying Internet Information Service (IIS) component of a target Exchange server. This is an attacker’s dream: directly landing on a server and, if the server has misconfigured access levels, gain system privileges.

The first scenario is more common, but we’re seeing a rise in attacks of the second variety; specifically, attacks that exploit Exchange vulnerabilities like CVE-2020-0688. The security update that fixes this vulnerability has been available for several months, but, notably, to this day, attackers find vulnerable servers to target.

In many cases, after attackers gain access to an Exchange server, what follows is the deployment of web shell into one of the many web accessible paths on the server. As we discussed in a previous blog, web shells allow attackers to steal data or perform malicious actions for further compromise.

Behavior-based detection and blocking of malicious activities on Exchange servers

Adversaries like using web shells, which are relatively small pieces of malicious code written in common programming languages, because these can be easily modified to evade traditional file-based protections. A more durable approach to detecting web shell activity involves profiling process activities originating from external-facing Exchange applications.

Behavior-based blocking and containment capabilities in Microsoft Defender ATP, which use engines that specialize in detecting threats by analyzing behavior, surface suspicious and malicious activities on Exchange servers. These detection engines are powered by cloud-based machine learning classifiers that are trained by expert-driven profiling of legitimate vs. suspicious activities in Exchange servers.

In April, multiple Exchange-specific behavior-based detections picked up unusual activity. The telemetry showed attackers operating on on-premises Exchange servers using deployed web shells. Whenever attackers interacted with the web shell, the hijacked application pool ran the command on behalf of the attacker, generating an interesting process chain. Common services, for example Outlook on the web  (formerly known as Outlook Web App or OWA) or Exchange admin center (EAC; formerly known as the  Exchange Control Panel or ECP), executing net.exe, cmd.exe, and other known living-off-the-land binaries (LOLBins) like mshta.exe is very suspicious and should be further investigated.

Figure 1. Behavior-based detections of attacker activity on Exchange servers

In this blog, we’ll share our investigation of the Exchange attacks in early April, covering multiple campaigns occurring at the same time. The data and techniques from this analysis make up an anatomy of Exchange server attacks. Notably, the attacks used multiple fileless techniques, adding another layer of complexity to detecting and resolving these threats, and demonstrating how behavior-based detections are key to protecting organizations.

Figure 2. Anatomy of an Exchange server attack

Initial access: Web shell deployment

Attackers started interacting with target Exchange servers through web shells they had deployed. Any path accessible over the internet is a potential target for web shell deployment, but in these attacks, the most common client access paths were:

  • %ProgramFiles%\Microsoft\Exchange Server\<version>\ClientAccess
  • %ProgramFiles%\Microsoft\Exchange Server\<version>\FrontEnd

The ClientAccess and FrontEnd directories provide various client access services such as Outlook on the web, EAC, and AutoDiscover, to name a few. These IIS virtual directories are automatically configured during server installation and provide authentication and proxy services for internal and external client connections.

These directories should be monitored for any new file creation. While file creation events alone cannot be treated as suspicious, correlating such events with the responsible process results in more reliable signals. Common services like OWA or ECP dropping .aspx or .ashx files in any of the said directories is highly suspicious.

In our investigation, most of these attacks used the China Chopper web shell. The attackers tried to blend the web shell script file with other .aspx files present on the system by using common file names. In many cases, hijacked servers used the ‘echo’ command to write the web shell. In other cases, certutil.exe or powershell.exe were used. Here are some examples of the China Chopper codes that were dropped in these attacks:

We also observed the attackers switching web shells or introducing two or more for various purposes. In one case, the attackers created an .ashx version of a popular, publicly available .aspx web shell, which exposes minimum functionality:

Figure 3. Microsoft Defender ATP alert for web shell

Reconnaissance

After web shell deployment, attackers typically ran an initial set of exploratory commands like whoami, ping, and net user. In most cases, the hijacked application pool services were running with system privileges, giving attackers the highest privilege.

Attackers enumerated all local groups and members on the domain to identify targets. Interestingly, in some campaigns, attackers used open-source user group enumerating tools like lg.exe instead of the built-in net.exe. Attackers also used the EternalBlue exploit and nbtstat scanner to identify vulnerable machines on the network.

Next, the attackers ran built-in Exchange Management Shell cmdlets to gain more information about the exchange environment. Attackers used these cmdlets to perform the following:

  • List all Exchange admin center virtual directories in client access services on all Mailbox servers in the network
  • Get a summary list of all the Exchange servers in the network
  • Get information on mailboxes, such as size and number of items, along with role assignments and permissions.

Figure 4. Microsoft Defender ATP alert showing process tree for anomalous account lookups

Persistence

On misconfigured servers where they have gained the highest privileges, attackers were able to add a new user account on the server. This gave the attackers the ability to access the server without the need to deploy any remote access tools.

The attackers then added the newly created account to high-privilege groups like Administrators, Remote Desktop Users, and Enterprise Admins, practically making the attackers a domain admin with unrestricted access to any users or group in the organization.

Figure 5. Microsoft Defender ATP alert showing process tree for addition of local admin using Net commands

Credential access

Exchange servers contain the most sensitive users and groups in an organization. Gaining credentials to these accounts could virtually give attackers domain admin privileges.

In our investigation, the attackers first dumped user hashes by saving the Security Account Manager (SAM) database from the registry.

Next, the attackers used the ProcDump tool to dump the Local Security Authority Subsystem Service (LSASS) memory. The dumps were later archived and uploaded to a remote location.

In some campaigns, attackers dropped Mimikatz and tried to dump hashes from the server.

Figure 6. Microsoft Defender ATP alert on detection of Mimikatz

In environments where Mimiktaz was blocked, attackers dropped a modified version with hardcoded implementation to avoid detection. Attackers also added a wrapper written in the Go programming language to make the binary more than 5 MB. The binary used the open-source MemoryModule library to load the binary using reflective DLL injection. Thus, the payload never touched the disk and was present only in memory, achieving a fileless persistence.

The attackers also enabled ‘wdigest’ registry settings, which forced the system to use WDigest protocol for authentication, resulting in lsass.exe retaining a copy of the user’s plaintext password in memory. This change allowed the attacker to steal the actual password, not just the hash.

Another example of stealthy execution that attackers implemented was creating a wrapper binary for ProcDump and Mimikatz. When run, the tool dropped and executed the ProcDump binary to dump the LSASS memory. The memory dump was loaded inside the same binary and parsed to extract passwords, another example of reflective DLL injection where the Mimikatz binary was present only in memory.

With attacker-controlled accounts now part of Domain Admins group, the attackers performed a technique called DCSYNC attack, which abuses the Active Directory replication capability to request account information, such as the NTLM hashes of all the users’ passwords in the organization. This technique is extremely stealthy because it can be performed without running a single command on the actual domain controller.

Lateral movement

In these attacks, the attackers used several known methods to move laterally:

  • The attackers heavily abused WMI for executing tools on remote systems.

  • The attackers also used other techniques such as creating service or schedule task on remote systems.

  • In some cases, the attackers simply run commands on remote systems using PsExec.

Exchange Management Shell abuse

The Exchange Management Shell is the PowerShell interface for administrators to manage the Exchange server. As such, it exposes many critical Exchange PowerShell cmdlets to allow admins to perform various maintenance tasks, such as assigning roles and permissions, and migration, including importing and exporting mailboxes. These cmdlets are available only on Exchange servers in the Exchange Management Shell or through remote PowerShell connections to the Exchange server.

To understand suspicious invocation of the Exchange Management Shell, we need to go one step back in the process chain and analyze the responsible process. As mentioned, common application pools MSExchangeOWAAppPool or MSExchangeECPAppPool accessing the shell should be considered suspicious.

In our investigation, attackers leveraged these admin cmdlets to perform critical tasks such as exporting mailboxes or running arbitrary scripts. Attackers used different ways to load and run PowerShell cmdlets through the Exchange Management Shell.

In certain cases, attackers created a PowerShell wrapper around the commands to effectively hide behind legitimate PowerShell activity.

These cmdlets allowed the attackers to perform the following:

  • Search received email

In our investigations, attackers were primarily interested in received emails. They searched for message delivery information filtered by the event ‘Received’. The search time frame showed the attackers were initially interested in the entire log history. Later, a similar command was run with a trimmed timeline of one year.

  • Export mailbox

Attackers exported mailboxes through these four steps:

    1. Granted ApplicationImpersnation role to the attacker-controlled account. This effectively allowed the supplied account to access all mailboxes in the organization.
    2. Granted ‘Mailbox Import Export’ role to the attacker-controlled account. This role is required to be added before attempting mailbox export.
    3. Exported the mailbox with filter “Received -gt ‘01/01/2020 0:00:00’”.
    4. Removed the mailbox export request to avoid raising suspicion.

Tampering with security tools

As part of lateral movement, the attackers attempted to disable Microsoft Defender Antivirus. Attackers also disabled archive scanning to bypass detection of tools and data compressed in .zip files, as well as created exclusion for .dat extension. The attackers tried to disable automatic updates to avoid any detection by new intelligence updates. For Microsoft Defender ATP customers, tamper protection prevents such malicious and unauthorized changes to security settings.

Remote access

The next step for attackers was to create a network architecture using port forwarding tools like plink.exe, a command line connection tool like ssh. Using these tools allowed attackers to bypass network restrictions and remotely access machines through Remote Desktop Protocol (RDP). This is a very stealthy technique: attackers reused dumped credentials to access the machines through encrypted tunneling software, eliminating the need to deploy backdoors, which may have a high chance of getting detected.

Exfiltration

Finally, dumped data was compressed using the utility tool rar.exe. The compressed data mostly comprised of the extracted .pst files, along with memory dumps.

Improving defenses against Exchange server compromise

As these attacks show, Exchange servers are high-value targets. These attacks also tend to be advanced threats with highly evasive, fileless techniques. For example, at every stage in the attack chain above, the attackers abused existing tools (LOLBins) and scripts to accomplish various tasks. Even in cases where non-system binaries were introduced, they were either legitimate and signed, like plink.exe, or just a proxy for the malicious binary, for example, the modified Mimikatz where the actual malicious payload never touched the disk.

Keeping these servers safe from these advanced attacks is of utmost importance. Here are steps that organizations can take to ensure they don’t fall victim to Exchange server compromise.

  1. Apply the latest security updates

Identify and remediate vulnerabilities or misconfigurations in Exchange servers. Deploy the latest security updates, especially for server components like Exchange, as soon as they become available. Specifically, check that the patches for CVE-2020-0688 is in place. Use threat and vulnerability management to audit these servers regularly for vulnerabilities, misconfigurations, and suspicious activity.

  1. Keep antivirus and other protections enabled

It’s critical to protect Exchange servers with antivirus software and other security solutions like firewall protection and MFA. Turn on cloud-delivered protection and automatic sample submission to use artificial intelligence and machine learning to quickly identify and stop new and unknown threats. Use attack surface reduction rules to automatically block behaviors like credential theft and suspicious use of PsExec and WMI. Turn on tamper protection features to prevent attackers from stopping security services.

If you are worried that these security controls will affect performance or disrupt operations, engage with IT pros to help determine the true impact of these settings. Security teams and IT pros should collaborate on applying mitigations and appropriate settings.

  1. Review sensitive roles and groups

Review highly privileged groups like Administrators, Remote Desktop Users, and Enterprise Admins. Attackers add accounts to these groups to gain foothold on a server. Regularly review these groups for suspicious additions or removal. To identify Exchange-specific anomalies, review the list of users in sensitive roles such as mailbox import export and Organization Management using the Get-ManagementRoleAssignment cmdlet in Exchange PowerShell.

  1. Restrict access

Practice the principle of least-privilege and maintain credential hygiene. Avoid the use of domain-wide, admin-level service accounts. Enforce strong randomized, just-in-time local administrator passwords and Enable MFA. Use tools like LAPS.

Place access control list (ACL) restrictions on ECP and other virtual directories in IIS. Don’t expose the ECP directory to the web if it isn’t necessary and to anyone in the company who doesn’t need to access it. Apply similar restrictions to other application pools.

  1. Prioritize alerts

Pay attention to and immediately investigate alerts indicating suspicious activities on Exchange servers. Catching attacks in the exploratory phase, the period in which attackers spend several days exploring the environment after gaining access, is key. Common application pools like ‘MSExchangeOWAAppPool’ or ‘MSExchangeECPAppPool’ are commonly hijacked by attackers through web shell deployment. Prioritize alerts related to processes such as net.exe, cmd.exe, and mshta.exe originating from these pools or w3wp.exe in general.

Behavior-based blocking and containment capabilities in Microsoft Defender Advanced Threat Protection stop many of the malicious activities we described in this blog. Behavior-based blocking and containment stops advanced attacks in their tracks by detecting and halting malicious processes and behaviors.

 

 

Figure 7. Microsoft Defender ATP alerts on blocked behaviors

In addition, Microsoft Defender ATP’s endpoint detection and response (EDR) sensors provide visibility into other suspicious and malicious activities on Exchange servers, which are raised as alerts. The new alert page presents data in an investigation-driven approach meant to empower SecOps teams to easily investigate and take actions.

Figure 8. Microsoft Defender ATP alert and process tree

If these alerts are immediately prioritized, security operations teams can better mitigate attacks and prevent further damage. Beyond resolving these alerts in the shortest possible time, however, organizations should focus on investigating the end-to-end attack chain and trace the vulnerability, misconfiguration, or other weakness in the infrastructure that allowed the attack to occur.

Microsoft Defender ATP is a component of the broader Microsoft Threat Protection (MTP), which provides comprehensive visibility into advanced attacks by combining the capabilities of Office 365 ATP, Azure ATP, Microsoft Cloud App Security, and Microsoft Defender ATP. Through the incidents view, MTP provides a consolidated picture of related attack evidence that shows the complete attack story, empowering SecOps teams to thoroughly investigate attacks.

In addition, MTP’s visibility into malicious artifacts and behavior empowers security operations teams to proactively hunt for threats on Exchange servers. For example, MTP can be connected to Azure Sentinel to enable web shell threat hunting.

Through built-in intelligence and automation, Microsoft Threat Protection coordinates protection, detection, and response across endpoints, identity, data, and apps. Learn more.

 

Hardik Suri

Microsoft Defender ATP Research Team

 

MITRE ATT&CK techniques

Initial access

Execution

Persistence

Privilege escalation

Defense evasion

Credential access

Discovery

Lateral movement

Collection

Command and control

Exfiltration

 

The post Defending Exchange servers under attack appeared first on Microsoft Security.

Microsoft continues to extend security for all with mobile protection for Android

June 23rd, 2020 No comments

Just a year ago, we shared our first steps on a journey to enable our customers to protect endpoints running a variety of platforms with our announcement of Microsoft Defender ATP for Mac. Knowing that each of our customers have unique environments and unique needs and are looking for more unification in their security solutions, we communicated our commitment to build security solutions from Microsoft, not just for Microsoft. Since then, we’ve announced capabilities for Linux servers, and at RSA, and we offered you a sneak peek into our mobile threat defense investments.

Today, I’m proud to announce the public preview of Microsoft Defender ATP for Android.

Protecting mobile devices from evolving threats, phishing attacks, unwanted apps

As more business is getting done on mobile devices, the lines blur between work and personal life. The threats here are unique. For example, one of the biggest and fastest growing threats on mobile is phishing attacks, majority of which happen outside of email, such as via phishing sites, messaging apps, games, and other applications, and are tricky to spot on smaller form factors. Other common mobile threats include malicious applications that users are lured into downloading, as well as increased risk introduced by rooted devices that may allow unnecessary escalated privileges and the installation of unauthorized applications.

In this rapidly evolving world of mobile threats, Microsoft is taking a holistic approach to tackling these challenges and to securing enterprises and their data with our new mobile threat defense capabilities. We’re leveraging our unique visibility into the threat landscape and the vast signal, intelligence, and security expertise we have from across domains, such as our expertise in phishing and email, our endpoint threat research on malware and attacker techniques, and our focus on identity and zero trust to bring protection capabilities to mobile. Our integrated approach to security enables us to provide more complete coverage. Leveraging these capabilities, Microsoft Defender ATP for Android will help to protect our customers and their users by delivering:

  • Protection from phishing and access to risky domains and URLs through web protection capabilities that will block unsafe sites accessed through SMS/text, WhatsApp, email, browsers, and other apps. We’re using the same Microsoft Defender SmartScreen services that are on Windows to quickly detect malicious sites which means that a decision to block a suspicious site will apply across all devices in the enterprise.
  • Proactive scanning of malicious applications, files, and potentially unwanted applications (PUA) that users may download to their mobile devices. Our capabilities and investments in cloud-powered protection and intelligence on application reputation allow us to quickly detect sophisticated malware and apps that that may display undesirable behavior.
  • Adding layers of protection to help prevent and limit the impact of breaches in an organization. By leveraging tight integration with Microsoft Endpoint Manager and Conditional Access, mobile devices that have been compromised with malicious apps or malware are considered high risk and are blocked from accessing corporate resources.
  • A unified security experience through Microsoft Defender Security Center where defenders can see alerts and easily get the additional context they need to quickly assess and respond to threats across Windows, Mac, Linux, and now mobile devices.

There’s more to share on how these capabilities work and how to get started on the blog in the Microsoft Defender ATP tech community.

In the coming months we will be releasing additional capabilities on Android and you will hear more from us about our investments in mobile threat defense for iOS devices as well.

I’m also thrilled to share that our initial release of Microsoft Defender ATP for Linux is now generally available. Customers have asked us to broaden our selection of platforms natively supported by Microsoft Defender ATP, and today we’re excited to officially start our journey with Linux. This release marks an important moment for all Microsoft Defender ATP customers when Microsoft Defender ATP becomes a truly unified solution to secure the full spectrum of desktop and server platforms that are common across enterprise environments: Windows, macOS, and Linux.

We are committed to helping organizations secure their unique and heterogenous environments and we have so much more in store for you this year. We’re excited for you to join us in our journey as we continue to deliver the industry’s best in integrated threat protection solutions.

For more information on Microsoft Security Solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

 

-Rob

The post Microsoft continues to extend security for all with mobile protection for Android appeared first on Microsoft Security.

Barracuda and Microsoft: Securing applications in public cloud

June 18th, 2020 No comments

This blog was written by a MISA partner. To learn more about MISA, visit our website.

Barracuda Cloud Application Protection (CAP) platform features integrations with Microsoft Azure Active Directory (Azure AD) and Azure Security Center. A component of CAP, Barracuda WAF-as-a-Service is built on Microsoft Azure and provides advanced WAF capabilities in an easy to deploy and manage solution.

In our last blog, I spoke about how Barracuda and Microsoft are working together to remove barriers to faster public cloud adoption. The post focused on remote access, networks, and secure connectivity to public cloud. The topic of this blog post is to share some thoughts on how web applications in public cloud are secured. 

Accelerating digital transformation

As I mentioned last time, digital transformation is fundamentally changing today’s enterprises, making digital assets—data and applications—key to doing business. Organizations are increasingly competing based on their digital agility, and of course web applications are central to how digital businesses operate today.

In order to develop and update applications faster, organizations are deploying DevOps processes and agile methodologies, and they are moving their infrastructure to the cloud. However, while applications are developed and deployed faster than ever, secure coding practices have not kept pace, resulting in a constantly growing number of open vulnerabilities that can be exploited.

At the same time, the threat environment is continuously evolving and becoming more challenging. Hackers are getting more sophisticated; they are now professional criminals or even nation states. In addition to manual hacking attacks, bots and botnets are increasingly used to attack enterprise infrastructures through web applications. These automated exploits are often executed as Distributed Denial of Service (or DDoS) attacks, at both network and application layer. And of course, malware is constantly getting more advanced. The growth in the number of unprotected application vulnerabilities, coupled with the increase in hacking and malware, has resulted in a perfect storm of data breaches. So, application security is a key requirement for successful digital transformation. A recent Microsoft Build 2020 blog post focused on how Microsoft is helping developers build more secure applications.

Is the latest health crisis going to slow down the digital transformation process? In fact, it appears the opposite is occurring—it is acting as a catalyst. In the last blog, we discussed how the sudden increase in remote work is accelerating the network evolution. In addition, similar changes are occurring in the applications landscape.

As people stay at home due to government orders, they are increasingly transacting online. Brick-and-mortar stores are closed, and to stay in business retailers and other businesses are shifting all their operations online.

Leveraging public cloud for web applications

Such rapid scaling of online operations is difficult and expensive to achieve using traditional datacenters. Fortunately, public cloud providers such as Microsoft Azure provide robust platforms that allow customers to quickly scale up application infrastructure—now things can be completed in days or even hours, instead of weeks or months. And of course, the flexibility that comes with public cloud deployments is especially valuable now, as there is a lot of uncertainty about how long lockdowns will continue and whether online capacity would need to be reduced in the future.

We have seen a significant increase in hacking, DDoS, and bot attacks during the last couple of months, so in addition to scaling up online capacity, it is critically important to ensure security and availability. Using a complete application security platform is the best way to protect applications from all attack vectors, including hacking, DDoS, bots, and even API attacks.

Types and number of online threats in the public cloud.

In the new report, Future shock: the cloud is the new network,1 published in February, Barracuda surveyed 750 IT decision makers responsible for their organizations’ cloud infrastructure. We learned that organizations are well on their way to moving their infrastructure to public cloud, with 45 percent of IT infrastructure already running in the cloud today and rising to an estimated 76 percent in 5 years.

At the same time, the top concern restricting an even faster adoption of public cloud is security, with 70 percent of the respondents indicating that security concerns restrict their organizations’ adoption of public cloud.

If you look at the type of security issues that are the biggest blockers to public cloud adoption, the top two are sophisticated hackers and open vulnerabilities in applications. Also on the list are DDoS attacks and advanced bots/botnets, and from conversations with both customers and analysts since the onset of COVID-19, it appears that both DDoS attacks and bot attacks have spiked up even higher.

Barracuda Cloud Application Protection (CAP) platform is a comprehensive, scalable and easy-to-deploy platform that secures applications wherever they reside.

 

About Barracuda

At Barracuda we strive to make the world a safer place. We believe every business deserves access to cloud-enabled, enterprise-grade security solutions that are easy to buy, deploy, and use. We protect email, networks, data, and applications with innovative solutions that grow and adapt with our customers’ journey. More than 150,000 organizations worldwide trust Barracuda to protect them—in ways they may not even know they are at risk—so they can focus on taking their business to the next level. For more information, visit barracuda.com.

View our integration videos

For more information on Microsoft Security Solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

 


1Future shock: the cloud is the new network, Barracuda, February 2020

The post Barracuda and Microsoft: Securing applications in public cloud appeared first on Microsoft Security.

Inside Microsoft Threat Protection: Mapping attack chains from cloud to endpoint

June 18th, 2020 No comments

The increasing pervasiveness of cloud services in today’s work environments, accelerated by a crisis that forced companies around the globe to shift to remote work, is significantly changing how defenders must monitor and protect organizations. Corporate data is spread across multiple applications—on-premises and in the cloud—and accessed by users from anywhere using any device. With traditional surfaces expanding and network perimeters disappearing, novel attack scenarios and techniques are introduced.

Every day, we see attackers mount an offensive against target organizations through the cloud and various other attack vectors with the goal of finding the path of least resistance, quickly expanding foothold, and gaining control of valuable information and assets. To help organizations fend off these advanced attacks, Microsoft Threat Protection (MTP) leverages the Microsoft 365 security portfolio to automatically analyze cross-domain threat data, building a complete picture of each attack in a single dashboard. With this breadth and depth of clarity, defenders can focus on critical threats and hunting for sophisticated breaches across endpoints, email, identities and applications.

Among the wide range of actors that Microsoft tracks—from digital crime groups to nation-state activity groups—HOLMIUM is one of the most proficient in using cloud-based attack vectors. Attributed to a Middle East-based group and active since at least 2015, HOLMIUM has been performing espionage and destructive attacks targeting aerospace, defense, chemical, mining, and petrochemical-mining industries. HOLMIUM’s activities and techniques overlap with what other researchers and vendors refer to as APT33, StoneDrill, and Elfin.

HOLMIUM has been observed using various vectors for initial access, including spear-phishing email, sometimes carrying archive attachments that exploit the CVE-2018-20250 vulnerability in WinRAR, and password-spraying. Many of their recent attacks, however, have involved the penetration testing tool Ruler used in tandem with compromised Exchange credentials.

The group used Ruler to configure a specially crafted Outlook Home Page URL to exploit the security bypass vulnerability CVE-2017-11774, which was fixed shortly after it was discovered. Successful exploitation automatically triggered remote code execution of a script when an Outlook client synced with a mailbox and rendered the profile Home Page URL. These scripts, usually VBScript followed by PowerShell, in turn initiated the delivery of various payloads.

In this blog, the first in the Inside Microsoft Threat Protection series, we will show how MTP provides unparalleled end-to-end visibility into the activities of nation-state level attacks like HOLMIUM. In succeeding blog posts in this series, we will shine a spotlight on aspects of the coordinated defense delivered by Microsoft Threat Protection.

Tracing an end-to-end cloud-based HOLMIUM attack

HOLMIUM has likely been running cloud-based attacks with Ruler since 2018, but a notable wave of such attacks was observed in the first half of 2019. These attacks combined the outcome of continuous password spray activities against multiple organizations, followed by successful compromise of Office 365 accounts and the use of Ruler in short sequences to gain control of endpoints. This wave of attacks was the subject of a warning from US Cybercom in July 2019.

These HOLMIUM attacks typically started with intensive password spray against exposed Active Directory Federation Services (ADFS) infrastructure; organizations that were not using multi-factor authentication (MFA) for Office 365 accounts had a higher risk of having accounts compromised through password spray. After successfully identifying a few user and password combinations via password spray, HOLMIUM used virtual private network (VPN) services with IP addresses associated with multiple countries to validate that the compromised accounts also had access to Office 365.

Figure 1. Password spray and compromised account sign-ins by HOLMIUM as detected in Azure Advanced Threat Protection (ATP) and Microsoft Cloud App Security (MCAS)

Armed with a few compromised Office 365 accounts and not blocked by MFA defense, the group launched the next step with Ruler and configured a malicious Home Page URL which, once rendered during a normal email session, resulted in the remote code execution of a PowerShell backdoor through the exploitation of a vulnerability like CVE-2017-11774. The two domains abused by HOLMIUM and observed during this 2019 campaign were “topaudiobook.net” and “customermgmt.net”.

Figure 2. Exploitation of Outlook Home Page feature using Ruler-like tools

Figure 3. Weaponized home page and initial PowerShell payload

This initial foothold allowed HOLMIUM to run their custom PowerShell backdoor (known as POWERTON) directly from an Outlook process and to perform the installation of additional payloads on the endpoint with different persistence mechanisms, such as WMI subscription (T1084) or registry autorun keys (T1060). Once the group has taken control of the endpoint (in addition to the cloud identity), the next phase was hours of exploration of the victim’s network, enumerating user accounts and machines for additional compromise, and lateral movement within the perimeter. HOLMIUM attacks typically took less than a week from initial access via the cloud to obtaining unhampered access and full domain compromise, which then allowed the attackers to stay persistent for long periods of time, sometimes for months on end.

Figure 4. Snippets of HOLMIUM PowerShell backdoor (POWERTON) implementing two different persistence mechanisms: WMI event subscription (T1084) and Registry run keys or Startup folder (T1060)

HOLMIUM attacks as seen and acted upon by Microsoft Threat Protection

HOLMIUM attacks demonstrate how hybrid attacks that span from cloud to endpoints require a wide range of sensors for comprehensive visibility. Enabling organizations to detect attacks like these by correlating events in multiple domains – cloud, identity, endpoints – is the reason why we build products like Microsoft Threat Protection. As we described in our analysis of HOLMIUM attacks, the group compromised identities in the cloud and leveraged cloud APIs to gain code execution or persist. The attackers then used a cloud email configuration to run specially crafted PowerShell on endpoints every time the Outlook process is opened.

During these attacks, many target organizations reacted too late in the attack chain—when the malicious activities started manifesting on endpoints via the PowerShell commands and subsequent lateral movement behavior. The earlier attack stages like cloud events and password spray activities were oftentimes missed or sometimes not linked with activities observed on the endpoint. This resulted in gaps in visibility and, subsequently, incomplete remediation.

While it’s relatively easy to remediate and stop malicious processes and downloaded malware on endpoints using endpoint security solutions, such a conventional approach would mean that the attack is persistent in the cloud, so the endpoint could be immediately compromised again. Remediating identities in the cloud is a different story.

Figure 5. The typical timeline of a HOLMIUM attack kill-chain

In an organization utilizing MTP, multiple expert systems that monitor various aspects of the network would detect and raise alerts on HOLMIUM’s activities. MTP sees the full attack chain across domains beyond simply blocking on endpoints or zapping emails, thus putting organizations in a superior position to fight the threat.

Figure 6. MTP components able to prevent or detect HOLMIUM techniques across the kill chain.

These systems work in unison to prevent attacks or detect, block, and remediate malicious activities. Across affected domains, MTP detects signs of HOLMIUM’s attacks:

  • Azure ATP identifies account enumeration and brute force attacks
  • MCAS detects anomalous Office 365 sign-ins that use potentially compromised credentials or from suspicious locations or networks
  • Microsoft Defender ATP exposes malicious PowerShell executions on endpoints triggered from Outlook Home Page exploitation

Figure 7. Activities detected across affected domains by different MTP expert systems

Traditionally, these detections would each be surfaced in its own portal, alerting on pieces of the attack but requiring the security team to stitch together the full picture. With Microsoft Threat Protection, the pieces of the puzzle are fused automatically through deep threat investigation. MTP generates a combined incident view that shows the end-to-end attack, with all related evidence and affected assets in one view.

Figure 8. The MTP incident brings together in one view the entire end-to-end attack across domain boundaries

Understanding the full attack chain enables MTP to automatically intervene to block the attack and remediate assets holistically across domains. In HOLMIUM attacks, MTP not only stops the PowerShell activity on endpoints but also contains the impact of stolen user accounts by marking them as compromised in Azure AD. This invokes Conditional Access as configured in Azure AD and applies conditions like MFA or limitations on the user account’s permissions to access organizational resources until the account is remediated fully.

Figure 9. Coordinated automatic containment and remediation across email, identity, and endpoints

Security teams can dig deep and expand their investigation into the incident in Microsoft 365 Security Center, where all details and related activities are available in one place. Furthermore, security teams can hunt for more malicious activities and artifacts through advanced hunting, which brings together all the raw data collected across product domains into one unified schema with powerful query constructs.

Figure 10. Hunting for activities across email, identity, endpoint and cloud applications

Finally, when the attack is blocked and all affected assets are remediated, MTP helps organizations identify improvements to their security configuration that would prevent the attacker from returning. The Threat Analytics report provides an exposure view and recommends prevention measures relevant to the threat. For example, the Analytics Report for HOLMIUM recommended, among other things, applying the appropriate security updates to prevent tools like Ruler from operating, as well as completely eliminating this attack vector in the organization.

Figure 11. Threat Analytics provides organizational exposure and recommended mitigations for HOLMIUM 

Microsoft Threat Protection: Stop attacks with automated cross-domain security

HOLMIUM exemplifies the sophistication of today’s cyberattacks, which leverage techniques spanning organizational cloud services and on-prem devices. Organizations must equip themselves with security tools that enable them to see the attack sprawl and respond to these attacks holistically and automatically. Protecting organizations from sophisticated attacks like HOLMIUM is the backbone of MTP.

Microsoft Threat Protection harnesses the power of Microsoft 365 security products and brings them together into an unparalleled coordinated defense that detects, correlates, blocks, remediates, and prevents such attacks across an organization’s Microsoft 365 environment. Existing Microsoft 365 licenses provide access to Microsoft Threat Protection features in Microsoft 365 security center without additional cost. Learn how Microsoft Threat Protection can help your organization to stop attacks with coordinated defense.

 

The post Inside Microsoft Threat Protection: Mapping attack chains from cloud to endpoint appeared first on Microsoft Security.

UEFI scanner brings Microsoft Defender ATP protection to a new level

June 17th, 2020 No comments

Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) is extending its protection capabilities to the firmware level with a new Unified Extensible Firmware Interface (UEFI) scanner.

Hardware and firmware-level attacks have continued to rise in recent years, as modern security solutions made persistence and detection evasion on the operating system more difficult. Attackers compromise the boot flow to achieve low-level malware behavior that’s hard to detect, posing a significant risk to an organization’s security posture.

Windows Defender System Guard helps defend against firmware attacks by providing guarantees for secure boot through hardware-backed security features like hypervisor-level attestation and Secure Launch, also known as Dynamic Root of Trust (DRTM), which are enabled by default in Secured-core PCs. The new UEFI scan engine in Microsoft Defender ATP expands on these protections by making firmware scanning broadly available.

The UEFI scanner is a new component of the built-in antivirus solution on Windows 10 and gives Microsoft Defender ATP the unique ability to scan inside of the firmware filesystem and perform security assessment. It integrates insights from our partner chipset manufacturers and further expands the comprehensive endpoint protection provided by Microsoft Defender ATP.

How the UEFI scanner in Microsoft Defender ATP works

The new UEFI scanner reads the firmware file system at runtime by interacting with the motherboard chipset. To detect threats, it performs dynamic analysis using multiple new solution components that include:

  • UEFI anti-rootkit, which reaches the firmware through Serial Peripheral Interface (SPI)
  • Full filesystem scanner, which analyzes content inside the firmware
  • Detection engine, which identifies exploits and malicious behaviors

Firmware scanning is orchestrated by runtime events like suspicious driver load and through periodic system scans. Detections are reported in Windows Security, under Protection history.

Screenshot of Windows Security notification showing detection of malicious content in non-volatile memory (NVRAM)

Figure 1. Windows Security notification showing detection of malicious content in non-volatile memory (NVRAM)

Microsoft Defender ATP customers will also see these detections raised as alerts in Microsoft Defender Security Center, empowering security operations teams to investigate and respond to firmware attacks and suspicious activities at the firmware level in their environments.

Screenshot of Microsoft Defender ATP alert for detection of malicious code in firmware

Figure 2. Microsoft Defender ATP alert for detection of malicious code in firmware

Security operations teams can also use the advanced hunting capabilities in Microsoft Defender ATP to hunt for these threats:

DeviceEvents
| where ActionType == "AntivirusDetection"
| extend ParsedFields=parse_json(AdditionalFields)
| extend ThreatName=tostring(ParsedFields.ThreatName)
| where ThreatName contains_cs "UEFI"
| project ThreatName=tostring(ParsedFields.ThreatName),
 FileName, SHA1, DeviceName, Timestamp
| limit 100

To detect unknown threats in SPI flash, signals from the UEFI scanner are analyzed to identify anomalies and where they have been executed. Anomalies are reported to the Microsoft Defender Security Center for investigation.

Screenshot of Microsoft Defender ATP alert for possible malware implant in UEFI file system

Figure 3. Microsoft Defender ATP alert for possible malware implant in UEFI file system

These events can likewise be queried through advanced hunting:

DeviceAlertEvents
| where Title has "UEFI"
| summarize Titles=makeset(Title) by DeviceName, DeviceId, bin(Timestamp, 1d)
| limit 100

How we built the UEFI scanner

The Unified Extensible Firmware Interface (UEFI) is a replacement for legacy BIOS. If the chipset is configured correctly (UEFI & chipset configuration itself) and secure boot is enabled, the firmware is reasonably secure. To perform a hardware-based attack, attackers exploit a vulnerable firmware or a misconfigured machine to deploy a rootkit, which allows attackers to gain foothold on the machine.

Figure 4. Expected boot flow vs. compromised boot flow

As figure 4 shows, for devices that are configured correctly, the boot path from power-on to OS initialization is reliable. If secure boot is disabled or if the motherboard chipset is misconfigured, attackers can change the contents of UEFI drivers that are unsigned or tampered with in the firmware. This could allow attackers to take over control of devices and give them the capability to deprivilege the operating system kernel or antivirus to reconfigure the security of the firmware.

Diagram of UEFI platform initalization

Figure 5. UEFI platform initialization

The Serial Peripheral Interface (SPI) flash stores important information. Its structure depends on OEMs design, and commonly includes processor microcode update, Intel Management Engine (ME), and boot image, a UEFI executable. When a computer runs, processors execute the firmware code from SPI flash for a while during UEFI’s SEC phase. Instead of memory, the flash is permanently mapped to x86 reset vector (physical address 0xFFFF_FFF0). However, attackers can interfere with memory access to reset vector by software. They do this by reprogramming the BIOS control register on misconfigured devices, making it even harder for security software to determine exactly what gets executed during boot.

Once an implant is deployed, it’s hard to detect. To catch threats at this level, security solutions at the OS level relies on information from the firmware, but the chain of trust is weakened.

Technically, the firmware is not stored and is not accessible from main memory. As opposed to other software, it’s stored in SPI flash storage, so the new UEFI scanner must follow the hardware protocol provided by hardware manufacturers. To be compatible and be up to date with all platforms, it needs to take into consideration protocol differences.

Diagram of UEFI scanner internals

Figure 6. UEFI scanner internals overview

The UEFI scanner performs dynamic analysis on the firmware it gets from the hardware flash storage. By obtaining the firmware, the scanner is able to parse the firmware, enabling Microsoft Defender ATP to inspect firmware content at runtime.

Comprehensive security levels up with low-level protections

The new UEFI scanner adds to a rich set of Microsoft technologies that integrate to deliver chip-to-cloud security, from a strong hardware root of trust to cloud-powered security solutions at the OS level.

Hardware backed security features like Secure Launch and device attestation help stop firmware attacks. These features, which are enabled by default in Secured-core PCs, seamlessly integrate with Microsoft Defender ATP to provide comprehensive endpoint protection.

With its UEFI scanner, Microsoft Defender ATP gets even richer visibility into threats at the firmware level, where attackers have been increasingly focusing their efforts on. Security operations teams can use this new level of visibility, along with the rich set of detection and response capabilities in Microsoft Defender ATP, to investigate and contain such advanced attacks.

This level of visibility is also available in Microsoft Threat Protection (MTP), which delivers an even broader cross-domain defense that coordinates protection across endpoints, identities, email, and apps.

 

 

Kelvin Chan, Shweta Jha, Gowtham Reddy A

Microsoft Defender ATP team

 

 

The post UEFI scanner brings Microsoft Defender ATP protection to a new level appeared first on Microsoft Security.

Exploiting a crisis: How cybercriminals behaved during the outbreak

June 16th, 2020 No comments

In the past several months, seemingly conflicting data has been published about cybercriminals taking advantage of the COVID-19 outbreak to attack consumers and enterprises alike. Big numbers can show shifts in attacker behavior and grab headlines. Cybercriminals did indeed adapt their tactics to match what was going on in the world, and what we saw in the threat environment was parallel to the uptick in COVID-19 headlines and the desire for more information.

If one backtracked to early February, COVID-19 news and themed attacks were relatively scarce. It wasn’t until February 11, when the World Health Organization named the global health emergency as “COVID-19”, that attackers started to actively deploy opportunistic campaigns. The week following that declaration saw these attacks increase eleven-fold. While this was below two percent of overall attacks Microsoft saw each month, it was clear that cybercriminals wanted to exploit the situation: eople around the world were becoming aware of the outbreak and were actively seeking information and solutions to combat it.

Worldwide, we observed COVID-19 themed attacks peak in the first two weeks of March. That coincided with many nations beginning to take action to reduce the spread of the virus and travel restrictions coming into effect. By the end of March, every country in the world had seen at least one COVID-19 themed attack.

Graph showing trend of COVID-19 themed attacks and mapping key events during the outbreak

Figure 1. Trend of COVID-19 themed attacks

The rise in COVID-19 themed attacks closely mirrored the unfolding of the worldwide event. The point of contention was whether these attacks were new or repurposed threats. Looking through Microsoft’s broad threat intelligence on endpoints, email and data, identities, and apps, we concluded that this surge of COVID-19 themed attacks was really a repurposing from known attackers using existing infrastructure and malware with new lures.

In fact, the overall trend of malware detections worldwide (orange line in Figure 2) did not vary significantly during this time. The spike of COVID-19 themed attacks you see above (yellow line in Figure 1) is barely a blip in the total volume of threats we typically see in a month. Malware campaigns, attack infrastructure, and phishing attacks all showed signs of this opportunistic behavior. As we documented previously, these cybercriminals even targeted key industries and individuals working to address the outbreak. These shifts were typical of the global threat landscape, but what was peculiar in this case was how the global nature and universal impact of the crisis made the cybercriminal’s work easier. They preyed on our concern, confusion, and desire for resolution.

Graph showing trend of all attacks versus COVID-19 themed attacks

Figure 2. Trend of overall global attacks vs. COVID-19 themed attacks

After peaking in early March, COVID-19 themed attacks settled into a “new normal”. While these themed attacks are still higher than they were in early February and are likely to continue as long as COVID-19 persists, this pattern of changing lures prove to be outliers, and the vast majority of the threat landscape falls into typical phishing and identity compromise patterns.

Cybercriminals are adaptable and always looking for the best and easiest ways to gain new victims. Commodity malware attacks, in particular, are looking for the biggest risk-versus-reward payouts. The industry sometimes focuses heavily on advanced attacks that exploit zero-day vulnerabilities, but every day the bigger risk for more people is being tricked into running unknown programs or Trojanized documents. Likewise, defenders adapt and drive up the cost of successful attacks. Starting in April, we observed defenders greatly increasing phishing awareness and training for their enterprises, raising the cost and complexity barrier for cybercriminals targeting their employees. These dynamics behave very much like economic models if you turn “sellers” to “cybercriminals” and “customers” to “victims”.

Graph showing trend of COVID-19 themed attacks

Figure 3. Trend of COVID-19 themed attacks

Lures, like news, are always local

Cybercriminals are looking for the easiest point of compromise or entry. One way they do this is by ripping lures from the headlines and tailoring these lures to geographies and locations of their intended victims. This is consistent with the plethora of phishing studies that show highly localized social engineering lures. In enterprise-focused phishing attacks this can look like expected documents arriving and asking the user to take action.

During the COVID-19 outbreak, cybercriminals closely mimicked the local developments of the crisis and the reactions to them. Here we can see the global trend of concern about the outbreak playing out with regional differences. Below we take a deeper look at three countries and how local events landed in relation to observed attacks.

FOCUS: United Kingdom

Attacks targeting the United Kingdom initially followed a trajectory similar to the global data, but spiked early, appearing to be influenced by the news and concerns in the nation. Data shows a first peak approximately at the first confirmed COVID-19 death in the UK, with growth beginning again with the FTSE 100 stock crash on March 9, and then ultimately peaking around the time the United States announced a travel ban to Europe.

Graph showing trend of COVID-19 themed attacks and mapping key events during the outbreak in the UK

Figure 4. Trend of COVID-19 themed attacks in the United Kingdom showing unique encounters (distinct malware files) and total encounters (number of times the files are detected)

In the latter half of March, the United Kingdom increased transparency and information to the public as outbreak protocols were implemented, including the closure of schools. The attacks dropped considerably all the way to April 5, when Queen Elizabeth II made a rare televised address to the nation. The very next day, Prime Minister Boris Johnson, who was hospitalized on April 6 due to COVID-19, was moved to intensive care. Data shows a corresponding increase in attacks until April 12, the day the Prime Minister was discharged from the hospital. The level of themed attacks then plateaued at about 3,500 daily attacks until roughly the end of April. The UK government proclaimed the country had passed the peak of infections and began to restore a new normalcy. Attacks took a notable drop to around 2,000 daily attacks.

Sample phishing email with COVID-19 themed lure

Sample phishing email using COVID-19 themed lure

Figure 5. Sample COVID-19 themed lures in attacks seen in the UK

FOCUS: Republic of Korea

The Republic of Korea was one of the earliest countries hit by COVID-19 and one of the most active in combating the virus. We observed attacks in Korea increase and, like the global trend, peak in early March. However, the spike in attacks for this country is steeper than the worldwide average, coinciding with the earlier arrival of the virus here.

Graph showing trend of COVID-19 themed attacks and key events during the outbreak in South Korea

Figure 6. Trend of COVID-19 themed attacks in the Republic of Korea showing unique encounters (distinct malware files) and total encounters (number of times the files are detected)

Interestingly, themed attacks were minimal at the beginning of February despite the impact of the virus. Cybercriminals did not truly ramp up attacks until the middle of February, closely mapping key events like identifying patients from the Shincheonji religious organization, military base lock downs, and international travel restrictions. While these national news events did not create the attacks, it’s clear cybercriminals saw an opening to compromise more victims.

Increased testing and transparency about the outbreak mapped to a downward trajectory of attacks in the first half of March. Looking forward through the end of May, the trend of themed attacks targeting Korean victims significantly departed from the global trajectory. We observed increasing attacks as the country restored some civic life. Attacks ultimately reached a peak around May 23. Analysis is still ongoing to understand the dynamics that drove this atypical increase.

FOCUS: United States

COVID-19 themed attacks in the United States largely followed the global attack trend. The initial ascent began mid-February after the World Health Organization officially named the virus. Attacks reached first peak at the end of February, coinciding with the first confirmed COVID-19 death in the country, and hit its highest point by mid-March, coinciding with the announced international travel ban. The last half of March saw a significant decrease in themed attacks. Telemetry from April and May shows themed attacks leveling off between 20,000 and 30,000 daily attacks. The same pattern of themed attacks mirroring the development of the outbreak and local concern likely played out at the state level, too.

Graph showing trend of COVID-19 themed attacks and mapping key events during the outbreak in the United States

Figure 7. Trend of COVID-19 themed attacks in the United States showing unique encounters (distinct malware files) and total encounters (number of times the files are detected)

Sample COVID-19 themed lure

Figure 8. Sample COVID-19 themed lures in attacks seen in the US

Conclusions

The COVID-19 outbreak has truly been a global event. Cybercriminals have taken advantage of the crisis to lure new victims using existing malware threats. In examining the telemetry, these attacks appear to be highly correlated to local interest and news.

Overall, COVID-19 themed attacks are just a small percentage of the overall threats the Microsoft has observed over the last four months. There was a global spike of themed attacks cumulating in the first two weeks of March. Based on the overall trend of attacks it appears that the themed attacks were at the cost of other attacks in the threat environment.

These last four months have seen a lot of focus on the outbreak – both virus and cyber. The lessons we draw from Microsoft’s observations are:

  • Cybercriminals adapt their tactics to take advantage of local events that are likely to lure the most victims to their schemes. Those lures change quickly and fluidly while the underlying malware threats remain.
  • Defender investment is best placed in cross-domain signal analysis, update deployment, and user education. These COVID-19 themed attacks show us that the threats our users face are constant on a global scale. Investments that raise the cost of attack or lower the likelihood of success are the optimal path forward.
  • Focus on behaviors of attackers will be more effective than just examining indicators of compromise, which tend to be more signals in time than durable.

To help organizations stay protected from the opportunistic, quickly evolving threats we saw during the outbreak, as well as the much larger total volume of threats, Microsoft Threat Protection (MTP) provides cross-domain visibility. It delivers coordinated defense by orchestrating protection, detection, and response across endpoints, identities, email, and apps.

Organizations should further improve security posture by educating end users about spotting phishing and social engineering attacks and practicing credential hygiene. Organizations can use Microsoft Secure Score to assesses and measure security posture and apply recommended improvement actions, guidance, and control. Using a centralized dashboard in Microsoft 365 security center, organizations can compare their security posture with benchmarks and establish key performance indicators (KPIs).

 

The post Exploiting a crisis: How cybercriminals behaved during the outbreak appeared first on Microsoft Security.

Blue teams helping red teams: A tale of a process crash, PowerShell, and the MITRE ATT&CK evaluation

June 11th, 2020 No comments

In September 2019, MITRE evaluated Microsoft Threat Protection (MTP) and other endpoint security solutions. The ATT&CK evaluation lasted for three days, with a professional red team from MITRE emulating many advanced attack behaviors used by the nation-state threat group known as YTTRIUM (APT29). After releasing the results of the evaluation, MITRE published the emulation methodology, including all of the attack scripts, tools, and code.

During the evaluation, the Microsoft Threat Protection team noted an interesting behavior related to one of the steps in the APT29 attack chain: Step 19 was supposed to perform stealthy deletion of files using the SDELETE tool reflectively loaded in memory. However, we observed that the step repeatedly caused process crashes during the execution of red team operations.

Crashes are unexpected surprises that could be a true gem for defenders for being a major indicator of an imminent attack, ruining the party for red teams and real attackers alike. Inspired by the transparency of MITRE publishing all the payloads and tools used in the attack simulation, in this blog post, we’ll describe the mystery that is Step 19, share our root cause analysis of the Step 19 attack script, and tell a story about how blue teams, once in a while, share important learnings for red teams and their tools.

Step 19 of the APT29 evaluation

The APT29 emulation involved 20 steps consisting of attacker techniques from the MITRE ATT&CK matrix related to the APT29 group. These steps were executed in the course of two days (plus an extra day reserved as a buffer), 10 steps per day. Since these steps spanned the entire attack chain, each step logically flowed from the previous one.

Step 19 was part of the attack chain executed on the second day. It emulated the attacker’s goal of deleting artifacts from the machine at the end of the breach using the SDELETE tool, which was loaded via PowerShell through a reflective loader mechanism, without ever touching disk.

Figure 1. Step 19 of the MITRE evaluation

This was done by dropping and running a script file called wipe.ps1, in a process that included:

  1. Loading a PowerShell reflective loader
  2. Reflectively loading sdelete.exe, a Sysinternals tool for secure file deletions
  3. Running the reflected exe with the desired files to be deleted

It’s important to note that the wipe.ps1 payload was based on and inspired by the famous “Invoke-ReflectivePEInjection” script from Joseph Bialek (@JosephBialek) and Matt Graeber (@mattifestation), which is also affected by the same issue that we discovered in our investigation and root cause analysis.

Figure 2. Microsoft Threat Protection detection of the reflective loader with relevant cmdlets

Figure 3. Entire script fetched using advanced hunting (truncated for brevity)

Microsoft Threat Protection automatically detected the execution of the reflective loader via PowerShell; however, during the execution of this attack, the telemetry provided by the product also captured the launch of WerFault.exe process (the Windows Error Reporting process) forked from PowerShell.exe, which was a sign of a crashing process.

Having noticed the repeated process crashing behavior, we decided to investigate further to understand what was happening in Step 19, and we observed the following:

 

Test Result
Execution in MITRE test environment #1 (primary) with MTP wipe.ps1 generated crash
Execution in MITRE test environment #2 (backup) with MTP wipe.ps1 generated crash
Execution in MITRE private environment without MTP wipe.ps1 executed with no crashes
Onboarding MTP to MITRE private environment wipe.ps1 generated crash

Indeed, it looked as if MTP was the cause of the wipe.ps1 script crashing. However, we validated that this shouldn’t be the case. Therefore, we performed an extensive analysis independent of the MITRE test, with the hope of finding the root cause of this behavior and sharing with MITRE, red teams, and other researchers.

Deep dive into the crash

Debugging the script wipe.ps1, we noticed an unexpected crash in the GetCommandLineW API, which was quite odd.

Figure 4. Call stack analysis for crash

Since the crash happens at kernelbase!GetCommandLineW, we examined its code before reflective loading:

Figure 5. GetCommandLineW code before patching

Note that the code consists of:

  1. An assignment to the RAX register (the return value register); the returned Unicode string is pointed by address 00007ffd200f9e68, as shown in the debugging session
  2. The RET instruction, which causes the function to return from the function
  3. Padding with the byte CC, which is encoded as INT 3; this is a debug-breakpoint and should never be executed due to the RET instruction

We then examined the code at the moment of the crash:

Figure 6. GetCommandLineW code at the crash

Note that there’s no RET instruction, so INT 3 (debug-breakpoint) was executed, causing the crash during the test (since no debugger is attached). Noting the byte encoding of the instructions and comparing them at a normal state and in the moment of the crash, we noticed a one-byte difference: the second byte changed from 8B to B8, causing a complete modification of the interpreted instruction! 8B is the opcode for a relative addressing move, while B8 is an immediate value move. The first byte 48 is a REX.W prefix, making the instruction refer to 64-bit operands.

Clearly, something strange was happening in the attack script wipe.ps1, so we decided to perform an extensive, line-by-line analysis of the attack script internals.

Anatomy of the reflective loader

As mentioned, the reflective loader used in the MITRE evaluation was inspired by Invoke-ReflectivePEInjection from PowerSploit, so analysis was relatively easier, vis-à-vis reverse engineering a new reflective loader.

A reflective loader is a tool for loading executable code into a process address space without invoking the operating system API, allowing attackers to avoid security products’ instrumentation of APIs such as LoadLibrary WinAPI that loads a DLL. Since .exe files are compiled with relocation tables (due to address space layout randomization (ASLR) support), many reflective loaders support loading of .exe files as well as DLLs.

When reflectively loading an .exe file, special care must be taken, as processes tend to rely on certain memory structures to be uniquely reserved to them. This is especially true for structures like the Process Environment Block (PEB), which contains important information about the current running process without transitioning into kernel mode. The reflective loader used by MITRE indeed takes special care of certain APIs that obtain information from the PEB; it does so by inline hooking.

Specifically, the reflective loader hooks the function GetCommandLineW that we saw earlier. Unless it does so, the reflected .exe code (sdelete.exe in this case) would fetch the original command line (the one for PowerShell.exe in this case) instead of the intended command line. Here’s a step-by-step analysis of the hooking:

  1. In the Update-ExeFunctions PowerShell function, the code fetches GetCommandLineW (and GetCommandLineA) by calling GetProcAddress on kernelbase.dll.

  1. The reflective loader then prepares a shellcode composed of the following parts:
    1. Possible REX.W prefix (byte 48) in case of a 64-bit process
    2. The MOV immediate instruction opcode (byte B8)
    3. An immediate value, which is an allocated address for the new command line buffer
    4. The RET instruction (byte C3)

  1. The reflective loader hooks the GetCommandLineW function by doing the following:
    1. Change the page permissions to RWX with the VirtualProtect API
    2. Call Write-BytesToMemory to copy the REX.W prefix and the MOV opcode to their place
    3. Call StructureToPtr to encode the new address after the MOV instructionl; this also takes care of endianness
    4. Call Write-BytesToMemory again, this time to copy the RET instruction

When performed correctly and fully, this should work well. However, our debugging showed only one-byte change (from 8B to B8) and no RET instruction. This meant that either StructureToPtr had some bug, or that patching was done partially. Assuming the latter, we concluded that the crash happens during the patching itself, after placing the MOV instruction but before encoding the new address, i.e. right after invoking Write-BytesToMemory.

Partial patching and unexpected callbacks

Debugging further, we discovered that the crash indeed happens after the first Write-BytesToMemory cmdlet. The call stack analysis showed that the call originates from PowerShell itself (or more precisely, from the CLR which is invoked by PowerShell), which is odd. This means that some code in PowerShell somehow tries to fetch the current process command line immediately after the cmdlet is executed.

We discovered that the code responsible for fetching the command line is the code that generates Event Tracing for Windows (ETW) for cmdlets. The Microsoft-Windows-PowerShell event provider exposes event IDs that log cmdlets, such as event 7937. Here’s an example of such an event:

Figure 7. Cmdlet tracing with ETW

Note the captured information, such as the cmdlet name, cmdlet type, and the process command line. The ETW writer for cmdlets is invoked after the cmdlet has finished running and has logged all the information. The command line itself is fetched by the ETW writer by invoking GetCommandLineW.

This means that an the ETW writer invoked for the first Write-BytesToMemory would invoke GetCommandLineW, but since only the first two bytes were patched, then GetCommandLineW is “half-patched”, eventually executing INT 3 and causing a crash.

While this explains the crash, it doesn’t explain why there was no crash when Microsoft Threat Protection was not present. The solution for this is simple: if there are no ETW listeners to the event, the ETW writer is never invoked, and therefore never tries to fetch the command line. Indeed, Microsoft Threat Protection listens to many ETW providers, including the Microsoft-Windows-PowerShell ETW.

To summarize, here is a flow diagram showing how this scenario runs:

Figure 8. Flow chart for the first Write-BytesToMemory cmdlet run

This conclusively proves that if any ETW listener registers to this ETW event (and not just Microsoft Threat Protection), the PowerSploit reflective loader implementation will crash. We reproduced this behavior without Microsoft Threat Protection and reported it to the MITRE red team to decide the course of action with Step 19.

What red teams can learn from this incident

PowerSploit is a known and widely used infrastructure for red teams. It’s used extensively and its codebase is regularly checked and updated. Even such a well-established project may contain unexpected bugs, some of which could only occur under special conditions such as specific environment changes like the one we described here.

Data we gathered using the advanced hunting capability in MTP further establishes this strong correlation: in real-world environments, 66% of the Invoke-ReflectivePEInjection invocations end up crashing their hosting PowerShell instance. This is a statistically significant proof of this bug in PowerSploit.

Figure 9. Advanced hunting query for correlating PowerShell crashes and Cmdlet invocation

The TL;DR advice for red teams is this: if you use “Invoke-ReflectivePEInjection” script during your regular penetration testing, be aware of an unexpected surprise in certain circumstances that may lead to immediate detection.

We thank MITRE for leading a transparent and collaborative evaluation process that encourages partnership and threat intelligence sharing. To learn how Microsoft Threat Protection did in the evaluation, read: Microsoft Threat Protection leads in real-world detection in MITRE ATT&CK evaluation.

 

 

Jonathan Bar Or

Microsoft Threat Protection Research Team

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Threat Protection and Microsoft Defender ATP tech communities.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Blue teams helping red teams: A tale of a process crash, PowerShell, and the MITRE ATT&CK evaluation appeared first on Microsoft Security.

The science behind Microsoft Threat Protection: Attack modeling for finding and stopping evasive ransomware

June 10th, 2020 No comments

The linchpin of successful cyberattacks, exemplified by nation state-level attacks and human-operated ransomware, is their ability to find the path of least resistance and progressively move across a compromised network. Determining the full scope and impact of these attacks is one the most critical, but often most challenging, parts of security operations.

To provide security teams with the visibility and solutions to fight cyberattacks, Microsoft Threat Protection (MTP) correlates threat signals across multiple domains and point solutions, including endpoints, identities, data, and applications. This comprehensive visibility allows MTP to coordinate prevention, detection, and response across your Microsoft 365 data.

One of the many ways that MTP delivers on this promise is by providing high-quality consolidation of attack evidence through the concept of incidents. Incidents combine related alerts and attack behaviors within an enterprise. An example of an incident is the consolidation of all behaviors indicating ransomware is present on multiple machines, and connecting lateral movement behavior with initial access via brute force. Another example can be found in the latest MITRE ATT&CK evaluation, where Microsoft Threat Protection automatically correlated 80 distinct alerts into two incidents that mirrored the two attack simulations.

The incident view helps empower defenders to quickly understand and respond to the end-to-end scope of real-world attacks. In this blog we will share details about a data-driven approach for identifying and augmenting incidents with behavioral evidence of lateral movement detected through statistical modeling. This novel approach, an intersection of data science and security expertise, is validated and leveraged by our own Microsoft Threat Experts in identifying and understanding the scope of attacks.

Identifying lateral movement

Attackers move laterally to escalate privileges or to steal information from specific machines in a compromised network. Lateral movement typically involves adversaries attempting to co-opt legitimate management and business operation capabilities, including applications such as Server Message Block (SMB), Windows Management Instrumentation (WMI), Windows Remote Management (WinRM), and Remote Desktop Protocol (RDP). Attackers target these technologies that have legitimate uses in maintaining functionality of a network because they provide ample opportunities to blend in with large volumes of expected telemetry and provide paths to their objectives. More recently, we have observed attackers performing lateral movement, and then using the aforementioned WMI or SMB to deploy ransomware or data-wiping malware to multiple target machines in the network.

A recent attack from the PARINACOTA group, known for human-operated attacks that deploy the Wadhrama ransomware, is notable for its use of multiple methods for lateral movement. After gaining initial access to an internet-facing server via RDP brute force, the attackers searched for additional vulnerable machines in the network by scanning on ports 3389 (RDP), 445 (SMB), and 22 (SSH).

The adversaries downloaded and used Hydra to brute force targets via SMB and SSH. In addition, they used credentials that they stole through credential dumping using Mimikatz to sign into multiple other server machines via Remote Desktop. On all additional machines they were able to access, the attackers performed mainly the same activities, dumping credentials and searching for valuable information.

Notably, the attackers were particularly interested in a server that did not have Remote Desktop enabled. They used WMI in conjunction with PsExec to allow remote desktop connections on the server and then used netsh to disable blocking on port 3389 in the firewall. This allowed the attackers to connect to the server via RDP.

They eventually used this server to deploy ransomware to a huge portion of the organization’s server machine infrastructure. The attack, an example of a human-operated ransomware campaign, crippled much of the organization’s functionality, demonstrating that detecting and mitigating lateral movement is critical.

PARINACOTA ransomware attack chain

Figure 1. PARINACOTA attack with multiple lateral movement methods

A probabilistic approach for inferring lateral movement

Automatically correlating alerts and evidence of lateral movement into distinct incidents requires understanding the full scope of an attack and establishing the links of an attacker’s activities that show movement across a network. Distinguishing malicious attacker activities among the noise of legitimate logons in complex networks can be challenging and time-consuming. Failing to get an aggregated view of all related alerts, assets, investigations, and evidence may limit the action that defenders take to mitigate and fully resolve an attack.

Microsoft Threat Protection uses its unique cross-domain visibility and built-in automation powered to detect lateral movement The data-driven approach to detecting lateral movement involves understanding and statistically quantifying behaviors that are observed to a part of one attack chain, for example, credential theft followed by remote connections to other devices and further unexpected or malicious activity.

Dynamic probability models, which are capable of self-learning over time using new information, quantify the likelihood of observing lateral movement given relevant signals. These signals can include the frequency of network connections between endpoints over certain ports, suspicious dropped files, and types of processes that are executed on endpoints. Multiple behavioral models encode different facets of an attack chain by correlating specific behaviors associated with attacks. These models, in combination with anomaly detection, drive the discovery of both known and unknown attacks.

Evidence of lateral movement can be modeled using a graph-based approach, which involves constructing appropriate nodes and edges in the right timeline. Figure 2 depicts a graphical representation of how an attacker might laterally move through a network. The objective of graphing an attack is to discover related subgraphs with high enough confidence to surface for immediate further investigation. Building behavioral models that can accurately compute probabilities of attacks is key to ensuring that confidence is correctly measured and all related events are combined.

Visualization of network with an attacker moving laterally

Figure 2. Visualization of network with an attacker moving laterally (combining incidents 1, 2, 4, 5)

Figure 3 outlines the steps involved for modeling lateral movement and encoding behaviors that are later referenced for augmenting incidents. Through advanced hunting, examples of lateral movement are surfaced, and real attack behaviors are analyzed. Signals are then formed by aggregating telemetry, and behavioral models are defined and computed.

Diagram showing steps for specifying statistical models for detecting lateral movement

Figure 3. Specifying statistical models to detect lateral movement encoding behaviors

Behavioral models are carefully designed by statisticians and threat experts working together to combine best practices from probabilistic reasoning and security, and to precisely reflect the attacker landscape.

With behavioral models specified, the process for incident augmentation proceeds by applying fuzzy mapping to respective behaviors, followed by estimating the likelihood of an attack. For example, if there’s sufficient confidence that the relative likelihood of an attack is higher, including the lateral movement behaviors, then the events are linked. Figure 4 shows the flow of this logic. We have demonstrated that the combination of this modeling with a feedback loop based on expert knowledge and real-world examples accurately discovers attack chains.

Diagram showing steps of algorithm for augmenting incidents using graph inference

Figure 4. Flow of incident augmentation algorithm based on graph inference

Chaining together the flow of this logic in a graph exposes attacks as they traverse a network. Figure 5 shows, for instance, how alerts can be leveraged as nodes and DCOM traffic (TCP port 135) as edges to identify lateral movement across machines. The alerts on these machines can then be fused together into a single incident. Visualizing these edges and nodes in a graph shows how a single compromised machine could allow an attacker to move laterally to three machines, one of which was then used for even further lateral movement.

Diagram showing relevant alerts as an attack move laterally from one machine to other machines

Figure 5. Correlating attacks as they pivot through machines

Augmenting incidents with lateral movement intel

The PARINACOTA attack we described earlier is a human-operated ransomware campaign that involved compromising six newly onboarded servers. Microsoft Threat Protection automatically correlated the following events into an incident that showed the end-to-end attack chain:

  • A behavioral model identified RDP inbound brute force attempts that started a few days before the ransomware was deployed, as depicted in Figure 6.
  • When the initial compromise was detected, the brute force attempts were automatically identified as the cause of the breach.
  • Following the breach, attackers dropped multiple suspicious files on the compromised server and proceeded to move laterally to multiple other servers and deploy the ransomware payload. This attack chain raised 16 distinct alerts that Microsoft Threat Protection, applying the probabilistic reasoning method, correlated into the same incident indicating the spread of ransomware, as illustrated in Figure 7.

Graph showing increased daily inbound RDP traffic

Figure 6. Indicator of brute force attack based on time series count of daily inbound public IP

Diagram showing ransomware being deployed after an attacker has moved laterally

Figure 7. Representation of post breach and ransomware spreading from initial compromised server

Another area where constructing graphs is particularly useful is when attacks originate from unknown devices. These unknown devices can be misconfigured machines, rogue devices, or even IoT devices within a network. Even when there’s no robust telemetry from devices, they can still be used as linking points for correlating activity across multiple monitored devices.

In one example, as demonstrated in figure 8, we saw lateral movement from an unmonitored device via SMB to a monitored device. That device then established a connection back to a command-and-control (C2), set up persistence, and collected a variety of information from the device. Later, the same unmonitored device established an SMB connection to a second monitored device. This time, the only actions the attacker took was to collect information from the device.

The two devices shared a common set of events that were correlated into the same incident:

  • Sign-in from an unknown device via SMB
  • Collecting device information

Diagram showing suspicious traffic from unknown devices

Figure 8: Correlating attacks from unknown devices

Conclusion

Lateral movement is one of the most challenging areas of attack detection because it can be a very subtle signal amidst the normal hum of a large environment. In this blog we described a data-driven approach for identifying lateral movement in enterprise networks, with the goal of driving incident-level discovery of attacks, delivering on the Microsoft Threat Protection (MTP) promise to provide coordinated defense against attacks. This approach works by:

  • Consolidating signals from Microsoft Threat Protection’s unparalleled visibility into endpoints, identities, data, and applications.
  • Forming automated, compound questions of the data to identify evidence of an attack across the data ecosystem.
  • Building subgraphs of lateral movement across devices by modeling attack behavior probabilistically.

This approach combines industry-leading optics, expertise, and data science, resulting in automated discovery of some of the most critical threats in customer environments today. Through Microsoft Threat Protection, organizations can uncover lateral movement in their networks and gain understanding of end-to-end attack chains. Microsoft Threat Protection empowers defenders to automatically stop and resolve attacks, so security operations teams can focus their precious time and resources to more critical tasks, including performing mitigation actions that can remove the ability of attackers to move laterally in the first place, as outlined in some of our recent investigations here and here.

 

 

Justin Carroll, Cole Sodja, Mike Flowers, Joshua Neil, Jonathan Bar Or, Dustin Duran

Microsoft Threat Protection Team

 

The post The science behind Microsoft Threat Protection: Attack modeling for finding and stopping evasive ransomware appeared first on Microsoft Security.