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.

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.

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.

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:

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:

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

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.

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.

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:

• In hot pursuit of elusive threats: AI-driven behavior-based blocking stops attacks in their tracks
• Behavioral blocking and containment: Transforming optics into protection

Ankit Garg and Geoff McDonald

Microsoft Defender ATP Research Team

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Threat Protection tech community.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

Listen to the Security Unlocked podcast

Hear more from the author of this blog on episode #2 of Security Unlocked. Subscribe for new episodes each week covering the latest in security news.

Listen now

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

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 are 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_MACHINESoftwareMicrosoftWindowsCurrentVersionRun

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.

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.

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.

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.

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.

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

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 wscript.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 the previous location using a command-line executed by a process spawned by wscript.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.

Listen to the Security Unlocked podcast

Hear more from the author of this blog on episode #1 of Security Unlocked. Subscribe for new episodes each week covering the latest in security news.

Listen now

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

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%MicrosoftExchange Server<version>ClientAccess
• %ProgramFiles%MicrosoftExchange 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. 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.

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

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

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

5. Prioritize alerts

The distinctive patterns of Exchange server compromise aid in detecting malicious behaviors and inform security operations teams to quickly respond to the initial stages of compromise. 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 malicious behaviors associated with Exchange server compromise. Behavior-based Exchange-specific alerts include “Suspicious w3wp.exe activity in Exchange”, which indicates that attackers are running arbitrary commands via the IIS processes in an Exchange server.

Figure 8. Microsoft Defender ATP alert and process tree for suspicious w3wp.exe activity in Exchange

These alerts should be immediately prioritized and fully investigated, and any credentials present on the Exchange server, including those used for service accounts and scheduled tasks, should be considered compromised.

Beyond resolving these alerts in the shortest possible time, 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 customers can use the threat analytics report we published on Exchange server attacks to track threats like web shells, exploits, and others, know the impact of these threats to their networks, and get recommendations for building organizational resilience.

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

• Exploit Public-Facing Application

Execution

• Command-line interface
• Windows Management Instrumentation
• PowerShell

Persistence

• Web Shell
• Create Account
• New Service
• Scheduled Task

Privilege escalation

• Valid Accounts
• Web Shell

Defense evasion

• Indicator Removal from Tools
• Obfuscated Files or Information
• Masquerading

Credential access

• Credential Dumping

Discovery

• System Network Configuration Discovery
• Remote System Discovery
• Account Discovery
• Permission Groups Discovery

Lateral movement

• Windows Admin Shares
• Pass the Hash
• Remote File Copy
• Windows Management Instrumentation
• New Service
• Scheduled Task

Collection

• Data From Local System
• Data Staged
• Email Collection

Command and control

• Remote File Copy
• Connection Proxy

Exfiltration

• Data Compressed
• Exfiltration Over Command and Control Channel

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.

Listen to the Security Unlocked podcast

Hear more from the author of this blog on episode #3 of Security Unlocked. Subscribe for new episodes each week covering the latest in security news.

Listen now

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

Figure 1. Microsoft Defender ATP data showing revival of Astaroth campaigns

Figure 2. Geographic distribution of Astaroth campaigns this year, with majority of encounters recorded in Brazil

When we first blogged about Astaroth’s methods, we noted how it completely lived off the land to avoid detection: only system tools that are already existing on the machine are ever executed. In fact, it was an unusual spike in activities related to Windows Management Instrumentation Command-line (WMIC) that prompted our investigation and eventually exposed the Astaroth campaign.

Astaroth now completely avoids the use of WMIC and related techniques to bypass existing detections. Instead, the attackers introduced new techniques that make the attack chain even stealthier:

• Abusing Alternate Data Streams (ADS) to hide malicious payloads
• Abusing the legitimate process ExtExport.exe, a highly uncommon attack vector, to load the payload

Astaroth exemplifies how living-off-the-land techniques have become standard components of today’s attacks intent on evading security solutions. However, as we mentioned in our previous blog on Astaroth, fileless threats are very much observable. These threats still leave a great deal of memory footprint that can be inspected and blocked as they happen. Next-generation protection and behavioral containment and blocking capabilities in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) lead the charge in exposing threats like Astaroth.

In this blog, we’ll share our technical analysis of the revamped Astaroth attack chain and demonstrate how specific Microsoft technologies tackle the multiple advanced components of the attack.

Dismantling the new Astaroth attack chain

The attackers were careful to ensure the updates didn’t make Astaroth easier to detect; on the contrary, the updates only make Astaroth’s activities even more invisible.

One of the most significant updates is the use of Alternate Data Stream (ADS), which Astaroth abuses at several stages to perform various activities. ADS is a file attribute that allows a user to attach data to an existing file. The stream data and its size are not visible in File Explorer, so attacks abuse this feature to hide malicious code in plain sight.

Figure 2. Astaroth attack chain 2020

In the case of Astaroth, attackers hide binary data inside the ADS of the file desktop.ini, without changing the file size. By doing this, the attackers create a haven for the payloads, which are read and decrypted on the fly.

Figure 3. Desktop.ini before and after infection

The complex attack chain, which involves the use of multiple living-off-the-land binaries (LOLBins), results in the eventual loading of the Astaroth malware directly in memory. When running, Astaroth decrypts plugins that allow it to steal sensitive information, like email passwords and browser passwords.

In the succeeding sections, we describe each step of Astaroth’s attack chain in detail.

Arrival

The attack begins with an email with a message in Portuguese that translates to: “Please find in the link below the STATEMENT #56704/2019 AND LEGAL DECISION, for due purposes”. The email contains a link that points to URL hosting an archive file, Arquivo_PDF_<date>.zip, which contains a LNK file with a similarly misleading name. When clicked, the LNK file runs an obfuscated BAT command line.

Figure 4. Sample email used in latest Astaroth attacks

The BAT command drops a single-line JavaScript file to the Pictures folder and invokes explorer.exe to run the JavaScript file.

The dropped one-liner script uses the GetObject technique to fetch and run the much larger main JavaScript directly in memory:

BITSAdmin abuse

The main script then invokes multiple instances of BITSAdmin using a benign looking command-line to download multiple binary blobs from a command-and-control (C2) server:

The downloaded payloads are encrypted and have the following file names:

• masihaddajjaldwwn.gif
• masihaddajjalc.jpg
• masihaddajjala.jpg
• masihaddajjalb.jpg
• masihaddajjaldx.gif
• masihaddajjalg.gif
• masihaddajjalgx.gif
• masihaddajjali.gif
• masihaddajjalxa.~
• masihaddajjalxb.~
• masihaddajjalxc.~
• masihaddajjal64w.dll
• masihaddajjal64q.dll
• masihaddajjal64e.dll

Alternate Data Streams abuse

As mentioned, the new Astaroth attacks use a clever technique of copying downloaded data to the ADS of desktop.ini. For each download, the content is copied to the ADS, and then the original content is deleted. These steps are repeated for all downloaded payloads.

Another way that Astaroth abuses ADS is when it runs a script to find installed security products. A malicious script responsible for enumerating security products is dropped and then copied as an ADS to an empty text file. The execution command-line looks like this:

ExtExport.exe abuse

The main script combines three separately downloaded binary blobs to form the first-stage malware code:

The script then uses a LOLBin not previously seen in Astaroth attacks to load the first-stage malware code: ExtExport.exe, which is a legitimate utility shipped as part of Internet Explorer. Attackers can load any DLL by passing an attacker-controlled path to the tool. The tool searches for any DLL with the following file names: mozcrt19.dll, mozsqlite3.dll, or sqlite3.dll. Attackers need only to rename the malicious payload to one of these names, and it is loaded by ExtExport.exe.

Userinit.exe abuse

The newly loaded DLL (mozcrt19.dll, mozsqlite3.dll, or sqlite3.dll) is a proxy that reads three binary ADS streams (desktop.ini:masihaddajjalxa.~, desktop.ini:masihaddajjalxb.~, and desktop.ini:masihaddajjalxc.~) and combines these into a DLL. The newly formed DLL is the second-stage malware code and is loaded in the same process using the reflective DLL loading technique.

The newly loaded DLL is also a proxy that reads and decrypts another ADS stream (desktop.ini:masihaddajjalgx.gif) into a DLL. This DLL is injected into userinit.exe using the process hollowing technique.

The newly loaded DLL inside userinit.exe is again a proxy that reads and decrypts another ADS stream (desktop.ini:masihaddajjalg.gif) into a DLL. This DLL is the malicious info-stealer known as Astaroth and is reflectively loaded inside userinit.exe. Hence, Astaroth never touches the disk and is loaded directly in memory, making it very evasive.

Astaroth payload

When running, the Astaroth payload then reads and decrypts more components from the ADS stream of desktop.ini (desktop.ini:masihaddajjaldwwn.gif, desktop.ini:masihaddajjalc.jpg, desktop.ini:masihaddajjala.jpg, desktop.ini:masihaddajjalb.jpg, and desktop.ini:masihaddajjali.gif).

Some of these components are credential-stealing plugins hidden inside the ADS stream of desktop.ini. Astaroth abuses these plugins to steal information from compromised systems:

• NirSoft’s MailPassView – an email client password recovery tool
• NirSoft’s WebBrowserPassView – a web browser password recovery tool

As mentioned, Astaroth also finds installed security products. It then attempts to disable these security products. For Microsoft Defender Antivirus customers, tamper protection prevents such malicious and unauthorized changes to security settings.

Comprehensive, dynamic protection against living-off-the-land, fileless, and other sophisticated threats with Microsoft Threat Protection

Attackers are increasingly turning to living-off-the-land techniques to attempt running undetected for as long as possible on systems. Because these attacks use multiple executables that are native to the system and have legitimate uses, they require a comprehensive, behavior-based approach to detection.

Microsoft Threat Protection combines and orchestrates into a single solution the capabilities of multiple Microsoft security services to coordinate protection, detection, response, and prevention across endpoints, email, identities, and apps.

In the case of Astaroth, Office 365 ATP detects the malware delivery via email. Using detonation-based heuristics and machine learning, Office 365 ATP inspects links and attachments to identify malicious artifacts.

On endpoints, next-generation protection capabilities in Microsoft Defender ATP detect and prevent some components of Astaroth’s new attack chain. Notably, through Antimalware Scan Interface (AMSI), Microsoft Defender ATP can inspect the encrypted malicious scripts used in the initial stages of the attack.

For the more sophisticated sections of the attack chain, behavioral blocking and containment capabilities provide dynamic protection that can stop malicious behaviors and process trees. Behavior-based protections are key to exposing living-off-the-land threats that abuse and hide behind legitimate processes. These protections identify suspicious behavior sequences and advanced attack techniques observed on the client, which are used as triggers to analyze the process tree using real-time machine learning models in the cloud.

Figure 5. Preventive and behavior-based blocking & containment protections against Astaroth

These behavior-based detections raise alerts in Microsoft Defender Security Center. With behavioral blocking and containment, not only are evasive threats exposed, detected, and stopped; security operations personnel are also notified so they can thoroughly investigate and remediate the root cause.

Figure 6. Sample Microsoft Defender ATP alerts on behavior-based detections of Astaroth’s activities

Microsoft Defender ATP’s EDR capabilities also have very strong coverage of advanced techniques employed by Astaroth, including cross-process migration, code injection, and use of LOLBins.

Figure 7. Sample Microsoft Defender ATP EDR alert and process tree on Astaroth’s behaviors

We expect Astaroth to further develop and increase in complexity, as long-running malware campaigns do. We will continue to watch this evolving threat and ensure that customers are protected from future updates through durable behavior-based protections.

Hardik Suri

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 Latest Astaroth living-off-the-land attacks are even more invisible but not less observable appeared first on Microsoft Security Blog.

Behavioral blocking and containment capabilities leverage multiple Microsoft Defender ATP components and features to immediately stop attacks before they can progress. For example, next-generation protection uses engines that specialize in detecting threats by analyzing behavior, stopping threats after they have started running.

In continuing to diminish the chances of sophisticated threats slipping through defenses, we have expanded behavioral blocking and containment capabilities to get even broader visibility into malicious behavior by using a rapid protection loop engine that leverages endpoint and detection response (EDR) sensors.

Microsoft Defender ATP’s EDR is informed by massive amounts of security signals on network, endpoint, and kernel behavior. As a component of Microsoft Threat Protection, Microsoft Defender ATP also has optics on other surfaces, including identities, email and data, and apps. Microsoft Defender ATP processes and correlates these signals to raise detection alerts that empower security operations (SecOps) teams to respond to attacks. Notably, unlike traditional behavior monitoring components on a device that provides discrete signals from that device, the aggregation of threat intelligence sources provides Microsoft Defender ATP with continuous signals on events that span across machines and surfaces.

With expanded behavioral blocking and containment capabilities, even more threats could be prevented, or blocked if they somehow manage to start running. In this blog, we’ll share several case studies of real-world attacks stopped by behavior-based blocking and containment capabilities informed by EDR alerts.

Stopping the spread of new malware in an organization and beyond

When Microsoft Defender ATP raises an alert on an observed suspicious behavior, information about the process, associated file, process tree, and various such signals that span across devices are sent to multiple classifiers. The rapid protection loop engine inspects and correlates the info with other signals to arrive at a decision whether to block a file.

This results in the rapid blocking of confirmed malware on a machine where EDR capabilities detected suspicious behaviors. This decision is then used to drive protection across the entire ecosystem through rapid blocking and containment. Such a detection could stop an attack on the machine, on other machines in the organization, and other organizations as an attack attempts to broaden its foothold.

For example, on January 10, 2020, Microsoft Defender ATP detected a privilege escalation activity on a machine in a certain organization and raised the alert “Possible privilege escalation using NTLM relay”.

The malware is a new, first-seen variant of the notorious hacking tool Juicy Potato, which attackers use for privilege escalation, a critical step in attacks.

In a matter of a few minutes, using information from the alert, the rapid protection loop engine’s classifiers automatically analyzed the file that exhibited the behavior (SHA-256: ec00ffadffb20954b3809e61d01a965ab1210ce10b5f4b7431bb2a458e31686f) and confirmed it was malicious, stopping and blocking the process. The malware was detected as EUS:Win32/Graphez!cl, and the alert “Artifact was blocked based on malicious behavior in prior incidents” was raised in Microsoft Defender Security Center.

In the next few minutes, multiple instances of the same file were blocked on the same machine, indicating multiple attempts by attackers or another malware to deploy the file on the machine. With behavioral blocking and containment capabilities, not only do SecOps get alerted on compromise attempts; Microsoft Defender ATP also automatically contains the incident while the SecOps performs a thorough investigation to understand and remediate the root cause.

Adding to multiple layers of protection

A defense in depth strategy requires multiple layers of protection. Multiple security components inspect Microsoft Defender ATP alerts for various actions. Auto-investigation and response capabilities kick in to automatically remediate threats. Cloud-based machine learning models in next-generation protection engines also run multiple classifiers to determine whether a file is confirmed malicious and should be blocked. The expanded behavioral blocking and containment adds another layer of protection that helps ensure there are multiple points at which an attack can be stopped.

On January 13, a file named DowloadX.exe (SHA-256: 971bc7eb2be734262a573ca7dc086c334f3a40ae874af90e7f380ec1a6221d7c) triggered the Microsoft Defender ATP alert “A suspicious file was observed” on a machine in one organization. The file was attempting to connect to certain domains to download files.

The file is a downloader Trojan used in a widespread campaign that aimed to deploy various malware payloads, including information stealers, cryptocurrency miners, and ransomware.

Within a few moments of observing the file, machine learning models operating on the EDR data, which come with richer granular details, determined the file to be malware, raised an alert, and provided feedback to the rapid protection loop engine. This insight led to the immediate blocking of the file on subsequent machines.

As the campaign progressed, the file was blocked on thousands of machines that same day, with multiple Microsoft Defender ATP technologies providing several layers of protection. By detecting and stopping the downloader using multiple detection technologies, Microsoft Defender ATP protected thousands of machines from more dangerous malware payloads.

Amplifying Microsoft Threat Protection

Through Microsoft Threat Protection, behavioral blocking and containment and other solutions that are informed by Microsoft Defender ATP’s EDR alerts also benefit from the signal-sharing across Microsoft security services. This broadens defense in depth even further, demonstrating how signals from multiple points in the attack chain allow Microsoft Threat Protection to deliver unparalleled comprehensive protection.

For example, on January 14, 2019, Microsoft Defender ATP’s EDR raised an alert on a new malicious Java Archive (JAR) file (SHA-256: 0d646ac10665f629adde73f1e3bb1afcc69e12a6f286d516c579c6ce0b22e892) based on information from Office 365 ATP. The alert, “A malicious file was detected based on indication provided by Office 365”, means that the malware had previously been observed and blocked in an organization protected by Office 365 ATP. Using information from Office 365 ATP, Microsoft Defender ATP EDR instantly raised an alert when it encountered the file in other organizations, while cloud-based protections blocked the file in these organizations.

This case demonstrates how various protection components provide multiple layers of protection, enrich each other through signal-sharing, and result in overall better protection for customers. For example, even if the threat arrived outside the context of email, Microsoft Defender ATP would still block the file based on information from Office 365 ATP.

In total, on the first day of the campaign, Microsoft Defender ATP blocked the file on hundreds of machines, indicating an attack that was more targeted in nature, not a massive campaign. The attack appeared to end the next day, only to be revived and blocked on even more machines two days later. The campaign would drag on for the next couple of days.

Further analysis identified the malware as a variant of QRat, a family of remote access Trojans (RATs) also known as JRat or Adwind. If not blocked, it connects to a command-and-control server and attempts to disable antivirus software and security analysis tools. A remote attacker can command the malware to downloaded and run files, access the command line, and steal information by logging keystrokes, taking screenshots, or recording through the webcam or microphone.

Conclusion: Security signals actualized

Microsoft Defender ATP’s industry-leading visibility into threats enable security teams to detect, investigate, and respond to attacks. To continue empowering organizations to defend their organizations efficiently and confidently, we build new and richer security operations tools. Another important way that we further help security operations teams is to block and stop threats when there are enough signals for engines to accurately make a classification on a file.

Behavioral-based detection enables the blocking of new and unknown malware when suspicious behavior is observed, helping curb further malware activities on compromised machines and, as we saw in the case studies on this blog, blocking the spread of malware to other machines within the organization and beyond.

The threat landscape relentlessly serves increasingly complex threats intent on evading detection. In line with the wide-ranging innovations across Microsoft security technologies, we won’t stop improving behavioral blocking and containment capabilities to cover more scenarios and protect more customers.

Jeong Mun and Eric Avena

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 Behavioral blocking and containment: Transforming optics into protection appeared first on Microsoft Security Blog.

With the new version, sLoad has added the ability to track the stage of infection on every affected machine. Version 2.0 also packs an anti-analysis trick that could identify and isolate analyst machines vis-à-vis actual infected machines.

We’re calling the new version “Starslord” based on strings in the malware code, which has clues indicating that the name “sLoad” may have been derived from a popular comic book superhero.

We discovered the new sLoad version over the holidays, in our continuous monitoring of the malware. New sLoad campaigns that use version 2.0 follow an attack chain similar to the previous version, with some updates, including dropping the dynamic list of command-and-control (C2) servers and upload of screenshots.

Tracking the stage of infection

With the ability to track the stage of infection, malware operators with access to the Starslord backend could build a detailed view of infections across affected machines and segregate these machines into different groups.

The tracking mechanism exists in the final-stage, which, as with the old version, loops infinitely (with sleep interval of 2400 seconds, higher than the 1200 seconds in version 1.0). In line with the previous version, at every iteration of the final stage, the malware uses a download BITS job to exfiltrate stolen system information and receive additional payloads from the active C2 server.

As we noted in our previous blog, creating a BITS job with an extremely large RemoteURL parameter that includes non-encrypted system information, as the old sLoad version did, stands out and is relatively easy to detect. However, with Starslord, the system information is encoded into Base64 data before being exfiltrated.

The file received by Starslord in response to the exfiltration BITS job contains a tuple of three values separated by an asterisk (*):

• Value #1 is a URL to download additional payload using a download BITS job
• Value #2 specifies the action, which can be any of the following, to be taken on the payload downloaded from the URL in value#1:
  • “eval” – Run (possibly very large) PowerShell scripts
  • “iex” – Load and invoke (possibly small) PowerShell code
  • “run” – Download encoded PE file, decode using exe, and run the decoded executable
• Value #3 is an integer that can signify the stage of infection for the machine

Supplying the payload URL as part of value #1 allows the malware infrastructure to house additional payloads on different servers from the active C2 servers responding to the exfiltration BITS jobs.

Value#3 is the most noteworthy component in this setup. If the final stage succeeds in downloading additional payload using the URL provided in value #1 and executing it as specified by the command in value #2, then a variable is used to form the string “td”:”<value#3>”,”tds”:”3”. However, if the final stage fails to download and execute the payload, then the string formed is “td”:”<value #3>”,”tds”:”4”.

The infinite loop ensures that the exfiltration BITS jobs are created at a fixed interval. The backend infrastructure can then pick up the pulse from each infected machine. However, unlike the previous version, Starslord includes the said string in succeeding iterations of data exfiltration. This means that the malware infrastructure is always aware of the exact stage of the infection for a specific affected machine. In addition, since the numeric value for value #3 in the tuple is always governed by the malware infrastructure, malware operators can compartmentalize infected hosts and could potentially set off individual groups on unique infection paths. For example, when responding to exfiltration BITS jobs, malware operators can specify a different URL (value #1) and action (value #2) for each numeric value for value #3 of the tuple, essentially deploying a different malware payload for different groups.

Anti-analysis trap

Starslord comes built-in with a function named checkUniverse, which is in-fact an anti-analysis trap.

As mentioned in our previous blog post, the final stage of sLoad is a piece of PowerShell code obtained by decoding one of the dropped .ini files. The PowerShell code appears in the memory as a value assigned to a variable that is then executed using the Invoke-Expression cmdlet. Because this is a huge piece of decrypted PowerShell code that never hits the disk, security researchers would typically dump it into a file on the disk for further analysis.

The sLoad dropper PowerShell script drops four files:

• a randomly named .tmp file
• a randomly named .ps1 file
• a ini file
• a ini file

It then creates a scheduled task to run the .tmp file every 3 minutes, similar to the previous version. The .tmp file is a proxy that does nothing but run the .ps1 file, which decrypts the contents of main.ini into the final stage. The final stage then decrypts contents of domain.ini to obtain active C2 and perform other activities as documented.

As a unique anti-analysis trap, Starslord ensures that the .tmp and.ps1 files have the same random name. When an analyst dumps the decrypted code of the final stage into a file in the same folder as the .tmp and .ps1 files, the analyst could end up naming it something other than the original random name. When this dumped code is run from such differently named file on the disk, a function named checkUniverse returns the value 1, and the analyst gets trapped:

What comes next is not very desirable for a security researcher: being profiled by the malware operator.

If the host belongs to a trapped analyst, the file downloaded from the backend in response to the exfiltration BITS job, if any, is discarded and overwritten by the following new tuple:

hxxps://<active C2>/doc/updx2401.jpg*eval*-1

In this case, the value #1 of the tuple is a URL that’s known to the backend for being associated with trapped hosts. BITS jobs from trapped hosts don’t always get a response. If they do, it’s a copy of the dropper PowerShell script. This could be to create an illusion that the framework is being updated as the URL in value #1 of the tuple suggests (hxxps://<active C2>/doc/updx2401.jpg).

However, the string that is included in all successive exfiltration BITS jobs from such host is “td”:”-1”,”tds”:”3”, eventually leading to all such hosts getting grouped under value “td”:”-1”. This forms the group of all trapped machines that are never delivered a payload. For the rest, so far, evidence suggests that it has been delivering the file infector Ramnit intermittently.

Durable protection against evolving malware

sLoad’s multi-stage attack chain, use of mutated intermediate scripts and BITS as an alternative protocol, and its polymorphic nature in general make it a piece malware that can be quite tricky to detect. Now, it has evolved into a new and polished version Starlord, which retains sLoads most basic capabilities but does away with spyware capabilities in favor of new and more powerful features, posing even higher risk.

Starslord can track and group affected machines based on the stage of infection, which can allow for unique infection paths. Interestingly, given the distinct reference to a fictional superhero, these groups can be thought of as universes in a multiverse. In fact, the malware uses a function called checkUniverse to determine if a host is an analyst machine.

Microsoft Threat Protection defends customers from sophisticated and continuously evolving threats like sLoad using multiple industry-leading security technologies that protect various attack surfaces. Through signal-sharing across multiple Microsoft services, Microsoft Threat Protection delivers comprehensive protection for identities, endpoints, data, apps, and infrastructure.

On endpoints, behavioral blocking and containment capabilities in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) ensure durable protection against evolving threats. Through cloud-based machine learning and data science informed by threat research, Microsoft Defender ATP can spot and stop malicious behaviors from threats, both old and new, in real-time.

Sujit Magar

Microsoft Defender ATP Research Team

The post sLoad launches version 2.0, Starslord appeared first on Microsoft Security Blog.

Attackers target RDP servers that use weak passwords and are without multi-factor authentication, virtual private networks (VPNs), and other security protections. Through RDP brute force, threat actor groups can gain access to target machines and conduct many follow-on activities like ransomware and coin mining operations.

In a brute force attack, adversaries attempt to sign in to an account by effectively using one or more trial-and-error methods. Many failed sign-ins occurring over very short time frequencies, typically minutes or even seconds, are usually associated with these attacks. A brute force attack might also involve adversaries attempting to access one or more accounts using valid usernames that were obtained from credential theft or using common usernames like “administrator”. The same holds for password combinations. In detecting RDP brute force attacks, we focus on the source IP address and username, as password data is not available.

In the Windows operating system, whenever an attempted sign-in fails for a local machine, Event Tracing for Windows (ETW) registers Event ID 4625 with the associated username. Meanwhile, source IP addresses connected to RDP can be accessed; this information is very useful in assessing if a machine is under brute force attack. Using this information in combination with Event ID 4624 for non-server Windows machines can shed light on which sign-in sessions were successfully created and can further help in detecting if a local machine has been compromised.

In this blog we’ll present a study and a detection logic that uses these signals. This data science-driven approach to detecting RDP brute force attacks has proven valuable in detecting human adversary activity through Microsoft Threat Experts, the managed threat hunting service in Microsoft Defender Advanced Threat Protection. This work is an example of how the close collaboration between data scientists and threat hunters results in protection for customers against real-world threats.

Insights into brute force attacks

Observing a sudden, relatively large count of Event ID 4625 associated with RDP network connections might be rare, but it does not necessarily imply that a machine is under attack. For example, a script that performs the following actions would look suspicious looking at a time series of counts of failed sign-in but is most likely not malicious:

• uses an expired password
• retries sign-in attempts every N-minutes with different usernames
• over a public IP address within a range owned by the enterprise

In contrast, behavior that includes the following is indicative of an attack:

• extreme counts of failed sign-ins from many unknown usernames
• never previously successfully authenticated
• from multiple RDP connections
• from new source IP addresses

Understanding the context of failed sign-ins and inbound connections is key to discriminating between true positive (TP) and false positive (FP) brute force attacks, especially if the goal is to automatically raise only high-precision alerts to the appropriate recipients, as we do in Microsoft Defender ATP.

We analyzed several months’ worth of data to mine insights into the types of RDP brute force attacks occurring across Microsoft Defender ATP customers. Out of about 45,000 machines that had both RDP public IP connections and at least 1 network failed sign-in, we discovered that, on average, several hundred machines per day had high probability of undergoing one or more RDP brute force attack attempts. Of the subpopulation of machines with detected brute force attacks, the attacks lasted 2-3 days on average, with about 90% of cases lasting for 1 week or less, and less than 5% lasting for 2 weeks or more.

Figure 1: Empirical distribution in number of days per machine where we observed 1 or more brute force attacks

As discussed in numerous other studies ^[1], large counts of failed sign-ins are often associated with brute force attacks. Looking at the count of daily failed sign-ins, 90% of cases exceeded 10 attempts, with a median larger than 60. In addition, these unusual daily counts had high positive correlation with extreme counts in shorter time windows (see Figure 2). In fact, the number of extreme failed sign-ins per day typically occurred under 2 hours, with about 40% failing in under 30 minutes.

Figure 2: Count of daily and maximum hourly network failed sign-ins for a local machine under brute force attack

While a detection logic based on thresholding the count of failed sign-ins during daily or finer grain time window can detect many brute force attacks, this will likely produce too many false positives. Worse, relying on just this will yield false negatives, missing successful enterprise compromises: our analysis revealed several instances where brute force attacks generated less than 5-10 failed attempts at a daily granularity but often persisted for many days, thereby avoiding extreme counts at any point in time. For such a brute force attack, thresholding the cumulative number of failed sign-ins across time could be more useful, as depicted in Figure 3.

Figure 3: Daily and cumulative failed network sign-in

Looking at counts of network failed sign-ins provides a useful but incomplete picture of RDP brute force attacks. This can be further augmented with additional information on the failed sign-in, such as the failure reason, time of day, and day of week, as well as the username itself. An especially strong signal is the source IP of the inbound RDP connection. Knowing if the external IP has a high reputation of abuse, as can be looked up on sites like https://www.abuseipdb.com/, can directly confirm if an IP is a part of an active brute force.

Unfortunately, not all IP addresses have a history of abuse; in addition, it can be expensive to retrieve information about many external IP addresses on demand. Maintaining a list of suspicious IPs is an option, but relying on this can result in false negatives as, inevitably, new IPs continually occur, particularly with the adoption of cloud computing and ease of spinning up virtual machines. A generic signal that can augment failed sign-in and user information is counting distinct RDP connections from external IP addresses. Again, extreme values occurring at a given time or cumulated over time can be an indicator of attack.

Figure 4 shows histograms (i.e., counts put into discrete bins) of daily counts of RDP public connections per machine that occurred for an example enterprise with known brute force attacks. It’s evident that normal machines have a lower probability of larger counts compared to machines attacked.

Figure 4: Histograms of daily count of RDP inbound across machines for an example enterprise

Given that some enterprises have machines under brute force attack daily, the priority may be to focus on machines that have been compromised, defined by a first successful sign-in following failed attempts from suspicious source IP addresses or unusual usernames. In Windows logs, Event ID 4624 can be leveraged to measure successful sign-in events for local machine in combination with failed sign-ins (Event ID 4625).

Out of the hundreds of machines with RDP brute force attacks detected in our analysis, we found that about .08% were compromised. Furthermore, across all enterprises analyzed over several months, on average about 1 machine was detected with high probability of being compromised resulting from an RDP brute force attack every 3-4 days. Figure 5 shows a bubble chart of the average abuse score of external IPs associated with RDP brute force attacks that successfully compromised machines. The size of the bubbles is determined by the count of distinct machines across the enterprises analyzed having a network connection from each IP. While there is diversity in the origin of the source IPs, Netherlands, Russia, and the United Kingdom have a larger concentration of inbound RDP connections from high-abuse IP.

Figure 5: Bubble chart of IP abuse score versus counts of machine with inbound RDP

A key takeaway from our analysis is that successful brute force attempts are not uncommon; therefore, it’s critical to monitor at least the suspicious connections and unusual failed sign-ins that result in authenticated sign-in events. In the following sections we describe a methodology to do this. This methodology was leveraged by Microsoft Threat Experts to augment threat hunting and resulted in new targeted attack notifications.

Combining many relevant signals

As discussed earlier (with the example of scripts connecting via RDP using outdated passwords yielding failed sign-ins), simply relying on thresholding failed attempts per machine for detecting brute force attacks can be noisy and may result in many false positives. A better strategy is to utilize many contextually relevant signals, such as:

• the timing, type, and count of failed sign-in
• username history
• type and frequency of network connections
• first-time username from a new source machine with a successful sign-in

This can be even further extended to include indicators of attack associated with brute force, such as port scanning.

Combining multiple signals along the attack chain has been proposed and shown promising results ^[2]. We considered the following signals in detecting RDP inbound brute force attacks per machine:

• hour of day and day of week of failed sign-in and RDP connections
• timing of successful sign-in following failed attempts
• Event ID 4625 login type (filtered to network and remote interactive)
• Event ID 4625 failure reason (filtered to %%2308, %%2312, %%2313)
• cumulative count of distinct username that failed to sign in without success
• count (and cumulative count) of failed sign-ins
• count (and cumulative count) of RDP inbound external IP
• count of other machines having RDP inbound connections from one or more of the same IP

Unsupervised probabilistic time series anomaly detection

For many cybersecurity problems, including detecting brute force attacks, previously labeled data is not usually available. Thus, training a supervised learning model is not feasible. This is where unsupervised learning is helpful, enabling one to discover and quantify unknown behaviors when examples are too sparse. Given that several of the signals we consider for modeling RDP brute force attacks are inherently dependent on values observed over time (for example, daily counts of failed sign-ins and counts of inbound connections), time series models are particularly beneficial. Specifically, time series anomaly detection naturally provides a logical framework to quantify uncertainty in modeling temporal changes in data and produce probabilities that then can be ranked and thresholded to control a desirable false positive rate.

Time series anomaly detection captures the temporal dynamics of signals and accurately quantifies the probability of observing values at any point in time under normal operating conditions. More formally, if we introduce the notation Y(t) to denote the signals taking on values at time t, then we build a model to compute reliable estimates of the probability of Y(t) exceeding observed values given all known and relevant information, represented by P[y(t)], sometimes called an anomaly score. Given a false positive tolerance rate r (e.g., .1% or 1 out of 10,000 per time), for each time t, values y*(t) satisfying P[y*(t)] < r would be detected as anomalous. Assuming the right signals reflecting the relevant behaviors of the type of attacks are chosen, then the idea is simple: the lowest anomaly scores occurring per time will be likely associated with the highest likelihood of real threats.

For example, looking back at Figure 2, the time series of daily count of failed sign-ins occurring on the brute force attack day 8/4/2019 had extreme values that would be associated with an empirical probability of about .03% out of all machine and days with at least 1 failed network sign-in for the enterprise.

As discussed earlier, applying anomaly detection to 1 or a few signals to detect real attacks can yield too many false positives. To mitigate this, we combined anomaly scores across eight signals we selected to model RDP brute force attack patterns. The details of our solution are included in the Appendix, but in summary, our methodology involves:

• updating statistical discrete time series models sequentially for each signal, capturing time of day, day of week, and both point and cumulative effects
• combining anomaly scores using an approach that yields accurate probability estimates, and
• ranking the top N anomalies per day to control a desired number of false positives

Our approach to time series anomaly detection is computationally efficient, automatically learns how to update probabilities and adapt to changes in data.

As we describe in the next section, this approach has yielded successful attack detection at high precision.

Protecting customers from real-word RDP brute force attacks through Microsoft Threat Experts

The proposed time series anomaly detection model was deployed and utilized by Microsoft Threat Experts to detect RDP brute force attacks during threat hunting activities. A list that ranks machines across enterprises with the lowest anomaly scores (indicating the likelihood of observing a value at least as large under expected conditions in all signals considered) is updated and reviewed every day. See Table 1 for an example.

Table 1: Sample ranking of detected RDP inbound brute force attacks

For each machine with detection of a probable brute force attack, each instance is assigned TP, FP, or unknown. Each TP is then assigned priority based on the severity of the attack. For high-priority TP, a targeted attack notification is sent to the associated organization with details about the active brute force attack and recommendations for mitigating the threat; otherwise the machine is closely monitored until more information is available.

We also added an extra capability to our anomaly detection: automatically sending targeted attack notifications about RDP brute force attacks, in many cases before the attack succeeds or before the actor is able to conduct further malicious activities. Looking at the most recent sample of about two weeks of graded detections, the average precision per day (i.e., true positive rate) is approximately 93.7% at a conservative false positive rate of 1%.

In conclusion, based on our careful selection of signals found to be highly associated with RDP brute force attacks, we demonstrated that proper application of time series anomaly detection can be very accurate in identifying real threats. In addition, we are working on integrating this capability into Microsoft Defender ATP’s endpoint and detection response capabilities so that the detection logic can raise alerts on RDP brute force attacks in real-time.

Monitoring suspicious activity in failed sign-ins and network connections should be taken seriously—a real-time anomaly detection capable of self-updating with the changing dynamics in a network can indeed provide a sustainable solution. While Microsoft Defender ATP already has many anomaly detection capabilities integrated into its EDR capabilities, which enrich advanced threat protection across the broader Microsoft Threat Protection, we will continue to enhance these detections to cover more security scenarios. Using data science, we will continue to combine robust statistical and machine learning approaches with threat expertise and intelligence to deliver industry-leading protection to our customers through Microsoft Threat Protection.

Cole Sodja, Justin Carroll, Joshua Neil
Microsoft Defender ATP Research Team

Appendix 1: Models formulation

We utilize hierarchical zero-adjusted negative binomial dynamic models to capture the characteristics of the highly discrete count time series. Specifically, as shown in Figure 2, it’s expected that most of the time there won’t be failed sign-ins for valid credentials on a local machine; hence, there are excess zeros that would not be explained by standard probability distributions such as the negative binomial. In addition, the variance of non-zero counts is often much larger than the mean, where for example, valid scripts connecting via RDP can generate counts in the 20s or more over several minutes because of an outdated password. Moreover, given a combination of multiple users or scripts connecting to shared machines at the same time, this can generate more extreme counts at higher quantiles resulting in heavier tails, as seen in Figure 6.

Figure 6: Daily count of network failed sign-in for a machine with no brute force attack

Parametric discrete location/scale distributions do not generate well-calibrated p-values for rare time series, as seen in Figure 6, and thus if used to detect anomalies can result in too many FPs when looking across many machines at high time frequencies. To overcome this challenge dealing with the sparse time series of counts of failed sign-in and RDP inbound public connections we specify a mixture model, where, based on our analysis, a zero-inflated two-component negative binomial distribution was adequate.

Our formulation is based on thresholding values that determine when to transition to a distribution with larger location and/or scale as given in Equation 1. Hierarchical priors are given from empirical estimates of the sample moments across machines using about 1 month of data.

Equation 1: Zero-adjusted negative binomial threshold model

Negative binomial distribution (NB):

To our knowledge, this formulation does not yield a conjugate prior, and so directly computing probabilities from the posterior predicted density is not feasible. Instead, anomaly scores are generated based on drawing samples from all distributions and then computing the empirical right-tail p-value.

Updating parameters is done based on applying exponential smoothing. To avoid outliers skewing estimates, such as machines under brute force or other attacks, trimming is applied to sample from the distribution at a specified false positive rate, which was set to .1% for our study. Algorithm 1 outlines the logic.

The smoothing parameters were learned based on maximum likelihood estimation and then fixed during each new sequential update. To induce further uncertainty, bootstrapping across machines is done to produce a histogram of smoothing weights, and samples are drawn in accordance to their frequency. We found that weights concentrated away from 0 vary between .06% and 8% for over 90% of machines, thus leading to slow changes in the parameters. An extension using adaptive forgetting factors will be considered in future work to automatically learn how to correct smoothing in real time.

Algorithm 2: Updating model parameters real-time

Appendix 2: Fisher Combination

For a given device, for each signal that exists a score is computed defined as a p-value, where lower values are associated with higher likelihood of being an anomaly. Then the p-values are combined to yield a joint score across all signals based on using the Fisher p-value combination method as follows:

The use of Fisher’s test applied to anomaly scores produces a scalable solution that yields interpretable probabilities that thus can be controlled to achieve a desired false positive rate. This has even been applied in a cybersecurity context. ^[3]

^[1] Najafabadi et al, Machine Learning for Detecting Brute Force Attacks at the Network Level, 2014 IEEE 14th International Conference on Bioinformatics and Bioengineering
^[2] Sexton et al, Attack chain detection, Statistical Analysis and Data Mining, 2015
^[3] Heard, Combining Weak Statistical Evidence in Cyber Security, Intelligent Data Analysis XIV, 2015

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Defender ATP community.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Data science for cybersecurity: A probabilistic time series model for detecting RDP inbound brute force attacks appeared first on Microsoft Security Blog.

Background Intelligent Transfer Service (BITS) is a component of the Windows operating system that provides an ability to transfer files in an asynchronous and throttled fashion using idle bandwidth. Abusing BITS, which provides the ability to create self-contained jobs that can be prioritized and queued up and that can launch other programs, has become a prevalent attack technique. Recent sophisticated malware campaigns like Astaroth have found success in the use of BITS for downloading payloads or additional components, especially in systems where the firewall is not configured to block malicious traffic from BITS jobs.

sLoad, detected by Windows Defender Antivirus as TrojanDownloader:PowerShell/sLoad, is used by adversaries for exfiltrating system information and delivering additional payloads in targeted attacks. It has been around for a few years and has not stopped evolving. What hasn’t changed, though, is its use of BITS for all of its exfiltration activities, as well as command-and-control (C2) communications from handshake to downloading additional payloads.

Once sLoad has infiltrated a machine, it can allow attackers to do further, potentially more damaging actions. Using exfiltrated information, attackers can identify what security solutions are running and test payloads before they are sneaked into the compromised system or, worse, high-priced targets. sLoad uses scheduled tasks, which runs the malware every three minutes, opening the window of opportunity for further compromise—hence raising the risk for the affected machine—every time it runs. We have already seen the malware attempt to deliver several other, potentially more dangerous Trojans to compromised machines.

While several malware campaigns have leveraged BITS, sLoad’s almost exclusive use of the service is notable. sLoad uses BITS as an alternative protocol to perform data exfiltration and most of its other malicious activities, enabling the malware to evade defenders and protections that may not be inspecting this unconventional protocol. Cloud-based machine learning-driven behavioral blocking and containment capabilities in Microsoft Defender Advanced Threat Protection detect and block sLoad’s activities as Behavior:Win32/sLoad.A.

In this blog we’ll share our analysis of the multiple ways in which sLoad is abusing BITS and share how Microsoft Defender Advanced Threat Protection defeats these advanced malware techniques.

[Update 1/21/2020: sLoad has released version 2.0, which has the ability to track the stage of infection on each affected machine and packs a unique anti-analysis trap. Read: sLoad launches version 2.0, Starslord.]

Stealthy installation via multiple cascaded scripts

sLoad is known to infect machines using spear-phishing emails and a common but effective detection evasion technique: the cascaded scripts. One script drops or downloads one or more scripts, passes control to one of these scripts, and repeats the process multiple times until the final component is installed.

Over time, we’ve seen some variations of this technique. One sLoad campaign used the link target field of a LNK file to run PowerShell commands that extracts and runs the first-stage PowerShell code, which is appended to the end of the LNK file or, in one instance, the end of the ZIP file that originally contained the LNK file. In another campaign, the first-stage PowerShell code itself uses a download BITS job to download either the sLoad script and the C2 URL file or the sLoad dropper PowerShell script that embeds the encrypted sLoad script and C2 URL file within itself.

In the most recent attacks, for the first stage, sLoad shifted from using PowerShell script to VBScript. The randomly named VBScript file is simply a proxy that builds and then drops and runs a PowerShell script, always named rr.ps1. This is none other than the same sLoad PowerShell dropper mentioned earlier that embeds the encrypted sLoad script and C2 URL file within itself.

In most variations of the installation, the sLoad dropper script is the last intermediate stage that performs the following actions, and eventually decrypts and runs the final sLoad script:

1. Creates an installation folder in the %APPDATA% folder named after the first 6 characters of the Win32 Product UUID. 
2. Drops an infection marker file named _in, and during the successive executions, uses the LastWriteTime on this file to check whether the malware is installed within last 30 mins, in which case, it terminates. 
3. Drops the encrypted sLoad script and the C2 URL file as config.ini and web.ini, respectively. 
4. Builds and drops two more randomly named scripts: one VBScript and one PowerShell script. 
5. Uses schtasks.exe to create a scheduled task named AppRunLog to run the randomly named VBScript from the previous step with decryption key supplied as a command line parameter; deletes the previously created related tasks (if found) before creating this one. The scheduled task is configured to start at 7:00 AM and run every 3 mins. 

The dropped VBScript that runs under the scheduled task is yet another proxy that simply runs the dropped PowerShell script with the same command line parameter (the decryption key). The PowerShell script decrypts the contents of the previously dropped config.ini in the memory into another piece of PowerShell code, which it then runs. This is the final component, the script detected as TrojanDownloader:PowerShell/sLoad, that uses BITS to perform every important malicious activity.

BITS abuse

The sLoad PowerShell script (the final component) then abuses BITS to carry out all of the following activities:

Finding an active C2 server

The malware decrypts the contents of previously dropped web.ini into a set of 2 URLs and creates a BITS download jobs to test the connection to these URLs. It then saves the URL that responds in the form of a file that contains a message “sok”, being downloaded as part of created BITS job. This ensures that the handshake is complete.

If none responds, the script appends the number “1” to the domain names in both URLs, saves the encrypted data back to the web.ini file, and exits from the script. As a result, the next time the scheduled job runs, the script uses the modified web.ini to obtain the modified URLs to attempt connecting to an active C2. With each unsuccessful attempt of connecting with C2s, the number appended to the domain names is increased by increments of 1 until it reaches 50, at which time it resets to 1. This technique offers a bit of a cushion and ensures continued contact between a compromised machine and a C2, in case the primary C2 is blocked.

This prevents the malware infrastructure from losing a compromised host if the primary C2 is blocked. It’s also interesting to see how the URLs used to reach C2 are structured to appear related to CAPTCHA verification, an attempt to escape watchful eyes.

Fetching a new list of C2s

For continued exfiltration of information, it’s important to maintain contact with an active C2. As the malicious domains cannot stay up running for a long time, the malware packs a functionality to refresh the list of C2 every time the scheduled task runs. Using a BITS download job, the malware downloads a new copy of web.ini from the active C2 to provisions a new set of C2s for future use.

Exfiltrating system information

Once an active C2 is identified, the malware starts collecting system information by performing the following:

• saves the output of “net view” command
• enumerates network drives and saves the provider names and device ids
• produces the list of all running processes
• obtains the OS caption
• looks for Outlook folder, as well as Independent Computing Architecture (ICA) files, which are used by Citrix application servers to store configuration information

It then creates a BITS download job with the RemoteURL built using the URL for active C2 and the system information collected up this point.

Crafting URLs infused with stolen info is not a novel attacker technique. In addition, creating a BITS job with an extremely large RemoteURL parameter that includes non-encrypted system information stands out and is relatively easy to detect. However, this malware’s use of a download job instead of an upload job is a clever move to achieve stealth.

Deploying additional payloads

Because the malware exfiltrates system information using a BITS download job, it gets an opportunity to receive a response in the form of a file downloaded to the machine. It uses this opportunity to obtain additional payloads from the C2.

It sleeps and waits for the file to be downloaded. If the downloaded file instructs to download and invoke additional PowerShell codes, the supplied URL is used for the task. If not, then the URL is assumed to be pointing to an encoded PE image payload. The malware creates another BITS download job to download this payload, creates a copy of this newly downloaded encoded file, and uses another Windows utility, certutil.exe, to decode it into a portable executable (PE) file with .exe extension. Finally, it uses PowerShell.exe to run the decoded PE payload. One more BITS download job is created to download additional files.

Spying

The malware comes built with one of the most notorious spyware features: uploading screenshots. At several stages during the installation as well as when running additional payloads, the malware takes several screenshots at short intervals. It then uses a BITS upload job to send the stolen screenshots to the active C2. This is the only time that it uses an upload job, and these are the only files it uploads to the C2. Once uploaded, the screenshots are deleted from the machine.

Conclusion: Multiple layers of protection against multi-stage living-off-the-land threats

sLoad is just one example of the increasingly more prevalent threats that can perform most of their malicious activities by simply living off the land. In this case, it’s a dangerous threat that’s equipped with notorious spyware capabilities, infiltrative payload delivery, and data exfiltration capabilities. sLoad’s behavior can be classified as a Type III fileless technique: while it drops some malware files during installation, its use of only BITS jobs to perform most of its harmful behaviors and scheduled tasks for persistence achieves an almost fileless presence on compromised machines.

To defeat multi-stage, stealthy, and persistent threats like sLoad, Microsoft Defender ATP’s antivirus component uses multiple next-generation protection engines on the client and in the cloud. While most threats are identified and stopped by many of these engines, behavioral blocking and containment capabilities detects malicious behaviors and blocks threats after they have started running:

These detections are also surfaced in Microsoft Defender Security Center. Security operations teams can then use Microsoft Defender ATP’s other capabilities like endpoint detection and response (EDR), automated investigation and response, Threat and Vulnerability Management, and Microsoft Threat Experts to investigate and respond to attacks. This reflects the defense-in-depth strategy that is central to the unified endpoint protection provided by Microsoft Defender ATP.

As part of Microsoft Threat Protection, Microsoft Defender ATP shares security signals about this threat to other security services, which likewise inform and enrich endpoint protection. For example, Office 365 ATP’s intelligence on the emails that carry sLoad is shared to and used by Microsoft Defender ATP to build even stronger defenses at the source of infection. Real-time signal-sharing across Microsoft’s security services gives Microsoft Threat Protection unparalleled visibility across attack vectors and the unique ability to provide comprehensive protection for identities, endpoints, data, cloud apps, and infrastructure.

Sujit Magar
Microsoft Defender ATP Research Team

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Defender ATP community.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Multi-stage downloader Trojan sLoad abuses BITS almost exclusively for malicious activities appeared first on Microsoft Security Blog.

The Dexphot attack used a variety of sophisticated methods to evade security solutions. Layers of obfuscation, encryption, and the use of randomized file names hid the installation process. Dexphot then used fileless techniques to run malicious code directly in memory, leaving only a few traces that can be used for forensics. It hijacked legitimate system processes to disguise malicious activity. If not stopped, Dexphot ultimately ran a cryptocurrency miner on the device, with monitoring services and scheduled tasks triggering re-infection when defenders attempt to remove the malware.

In the months that followed, we closely tracked the threat and witnessed the attackers upgrade the malware, target new processes, and work around defensive measures:

While Microsoft Defender Advanced Threat Protection’s pre-execution detection engines blocked Dexphot in most cases, behavior-based machine learning models provided protection for cases where the threat slipped through. Given the threat’s persistence mechanisms, polymorphism, and use of fileless techniques, behavior-based detection was a critical component of the comprehensive protection against this malware and other threats that exhibit similar malicious behaviors.

Microsoft Defender ATP data shows the effectiveness of behavioral blocking and containment capabilities in stopping the Dexphot campaign. Over time, Dexphot-related malicious behavior reports dropped to a low hum, as the threat lost steam.

Our close monitoring of Dexphot helped us ensure that our customers were protected from the evolving threat. More importantly, one year’s worth of intelligence helped us gain insight not only into the goals and motivations of Dexphot’s authors, but of cybercriminals in general.

Complex attack chain

The early stages of a Dexphot infection involves numerous files and processes. During the execution stage, Dexphot writes five key files to disk:

1. An installer with two URLs
2. An MSI package file downloaded from one of the URLs
3. A password-protected ZIP archive
4. A loader DLL, which is extracted from the archive
5. An encrypted data file that holds three additional executables that are loaded into system processes via process hollowing

Except for the installer, the other processes that run during execution are legitimate system processes. This can make detection and remediation more difficult. These legitimate system processes include msiexec.exe (for installing MSI packages), unzip.exe (for extracting files from the password-protected ZIP archive), rundll32.exe (for loading the loader DLL), schtasks.exe (for scheduled tasks), powershell.exe (for forced updates). In later stages, Dexphot targets a few other system processes for process hollowing: svchost.exe, tracert.exe, and setup.exe.

Multiple layers of security evasion

Based on Microsoft Defender ATP signals, SoftwareBundler:Win32/ICLoader and its variants are primarily used to drop and run the Dexphot installer. The installer uses two URLs to download malicious payloads. These are the same two URLs that Dexphot use later to establish persistence, update the malware, and re-infect the device.

The installer downloads an MSI package from one of the two URLs, and then launches msiexec.exe to perform a silent install. This is the first of several instances of Dexphot employing living-off-the-land techniques, the use of legitimate system processes for nefarious purposes.

Dexphot’s package often contains an obfuscated batch script. If the package contains this file, the script is the first thing that msiexec.exe runs when it begins the installation process. The said obfuscated script is designed to check for antivirus products. Dexphot halts the infection process immediately if an antivirus product is found running.

When we first began our research, the batch script only checked for antivirus products from Avast and AVG. Later, Windows Defender Antivirus was added to the checklist.

If the process is not halted, Dexphot decompresses the password-protected ZIP archive from the MSI package. The password to this archive is within the MSI package. Along with the password, the malware’s authors also include a clean version of unzip.exe so that they don’t have to rely on the target system having a ZIP utility. The unzip.exe file in the package is usually named various things, such as z.exe or ex.exe, to avoid scrutiny.

The ZIP archive usually contains three files: the loader DLL, an encrypted data file (usually named bin.dat), and, often, one clean unrelated DLL, which is likely included to mislead detection.

Dexphot usually extracts the decompressed files to the target system’s Favorites folder. The files are given new, random names, which are generated by concatenating words and numbers based on the time of execution (for example, C:\Users\<user>\Favorites\\Res.Center.ponse\<numbers>). The commands to generate the new names are also obfuscated, for example:

Msiexec.exe next calls rundll32.exe, specifying loader DLL (urlmon.7z in the example above) in order to decrypt the data file. The decryption process involves ADD and XOR operations, using a key hardcoded in the binary.

The decrypted data contains three executables. Unlike the files described earlier, these executables are never written to the filesystem. Instead, they exist only in memory, and Dexphot runs them by loading them into other system processes via process hollowing.

Stealthy execution through fileless techniques

Process hollowing is a technique that can hide malware within a legitimate system process. It replaces the contents of the legitimate process with malicious code. Detecting malicious code hidden using this method is not trivial, so process hollowing has become a prevalent technique used by malware today.

This method has the additional benefit of being fileless: the code can be run without actually being saved on the file system. Not only is it harder to detect the malicious code while it’s running, it’s harder to find useful forensics after the process has stopped.

To initiate process hollowing, the loader DLL targets two legitimate system processes, for example svchost.exe or nslookup.exe, and spawns them in a suspended state. The loader DLL replaces the contents of these processes with the first and second decrypted executables. These executables are monitoring services for maintaining Dexphot’s components. The now-malicious processes are released from suspension and run.

Next, the loader DLL targets the setup.exe file in SysWoW64. It removes setup.exe’s contents and replaces them with the third decrypted executable, a cryptocurrency miner. Although Dexphot always uses a cryptocurrency miner of some kind, it’s not always the same miner. It used different programs like XMRig and JCE Miner over the course of our research.

Persistence through regularly scheduled malware updates

The two monitoring services simultaneously check the status of all three malicious processes. Having dual monitoring services provides redundancy in case one of the monitoring processes is halted. If any of the processes are terminated, the monitors immediately identify the situation, terminate all remaining malicious processes, and re-infect the device. This forced update/re-infection process is started by a PowerShell command similar to the one below:

The monitoring components also detect freshly launched cmd.exe processes and terminate them promptly. As a final fail-safe, Dexphot uses schtasks.exe to create scheduled tasks, with the command below.

This persistence technique is interesting, because it employs two distinct MITRE ATT&CK techniques: Scheduled Task and Signed Binary Proxy Execution.

The scheduled tasks call msiexec.exe as a proxy to run the malicious code, much like how msiexec.exe was used during installation. Using msiexec.exe, a legitimate system process, can make it harder to trace the source of malicious activity.

Furthermore, the tasks allow Dexphot to conveniently update the payload from the web every time the tasks run. They automatically update all of Dexphot’s components, both upon system reboot as well as every 90 or 110 minutes while the system is running.

Dexphot also generates the names for the tasks at runtime, which means a simple block list of hardcoded task names will not be effective in preventing them from running. The names are usually in a GUID format, although after we released our first round of Dexphot-blocking protections, the threat authors began to use random strings.

The threat authors have one more evasion technique for these scheduled tasks: some Dexphot variants copy msiexec.exe to an arbitrary location and give it a random name, such as %AppData%\<random>.exe. This makes the system process running malicious code a literal moving target.

Polymorphism

Dexphot exhibits multiple layers of polymorphism across the binaries it distributes. For example, the MSI package used in the campaign contains different files, as shown in the table below. The MSI packages generally include a clean version of unzip.exe, a password-protected ZIP file, and a batch file that checks for currently installed antivirus products. However, the batch file is not always present, and the names of the ZIP files and Loader DLLs, as well as the password for extracting the ZIP file, all change from one package to the next.

In addition, the contents of each Loader DLL differs from package to package, as does the encrypted data included in the ZIP file. This leads to the generation of a different ZIP archive and, in turn, a unique MSI package, each time the attacker bundles the files together. Because of these carefully designed layers of polymorphism, a traditional file-based detection approach wouldn’t be effective against Dexphot.

A multitude of payload hosts

Besides tracking the files and processes that Dexphot uses to execute an attack, we have also been monitoring the domains used to host malicious payloads. The URLs used for hosting all follow a similar pattern. The domain address usually ends in a .info or .net TLD, while the file name for the actual payload consists of random characters, similar to the randomness previously seen being used to generate file names and scheduled tasks. Some examples from our research are shown in the table below.

Many of the URLs listed were in use for an extended period. However, the MSI packages hosted at each URL are frequently changed or updated. In addition, every few days more domains are generated to host more payloads. After a few months of monitoring, we were able to identify around 200 unique Dexphot domains.

Conclusion: Dynamic, comprehensive protection against increasingly complex everyday threats

Dexphot is not the type of attack that generates mainstream media attention; it’s one of the countless malware campaigns that are active at any given time. Its goal is a very common one in cybercriminal circles — to install a coin miner that silently steals computer resources and generates revenue for the attackers — yet Dexphot exemplifies the level of complexity and rate of evolution of even everyday threats, intent on evading protections and motivated to fly under the radar for the prospect of profit.

To combat threats, several next-generation protection engines in Microsoft Defender Advanced Threat Protection’s antivirus component detect and stop malicious techniques at multiple points along the attack chain. For Dexphot, machine learning-based detections in the cloud recognize and block the DLLs loaded by rundll32.exe, stopping the attack chain in its early stages. Memory scans detect and terminate the loading of malicious code hidden by process hollowing — including the monitoring processes that attempt to update the malware code and re-infect the machine via PowerShell commands.

Behavioral blocking and containment capabilities are especially effective in defeating Dexphot’s fileless techniques, detection evasion, and persistence mechanisms, including the periodic and boot-time attempts to update the malware via scheduled tasks. As mentioned, given the complexity of the attack chain and of Dexphot’s persistence methods, we released a remediation solution that prevents re-infection by removing artifacts.

The detection, blocking, and remediation of Dexphot on endpoints are exposed in Microsoft Defender Security Center, where Microsoft Defender ATP’s rich capabilities like endpoint detection and response, automated investigation and remediation, and others enable security operations teams to investigate and remediate attacks in enterprise environments. With these capabilities, Microsoft Defender ATP provides comprehensive protection against Dexphot and the countless other complex and evolving threats that we face every day.

Sample indicators of compromise (IoCs)

Installer (SHA-256):
72acaf9ff8a43c68416884a3fff3b23e749b4bb8fb39e16f9976643360ed391f

MSI files (SHA-256):
22beffb61cbdc2e0c3eefaf068b498b63a193b239500dab25d03790c467379e3
65eac7f9b67ff69cefed288f563b4d77917c94c410c6c6c4e4390db66305ca2a
ba9467e0d63ba65bf10650a3c8d36cd292b3f846983032a44a835e5966bc7e88

Loader DLLs  (SHA-256):
537d7fe3b426827e40bbdd1d127ddb59effe1e9b3c160804df8922f92e0b366e
504cc403e0b83233f8d20c0c86b0611facc040b868964b4afbda3214a2c8e1c5
aa5c56fe01af091f07c56ac7cbd240948ea6482b6146e0d3848d450977dff152

Hazel Kim

Microsoft Defender ATP Research Team

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Defender ATP community.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Insights from one year of tracking a polymorphic threat appeared first on Microsoft Security Blog.

BlueKeep is what researchers and the media call CVE-2019-0708, an unauthenticated remote code execution vulnerability in Remote Desktop Services on Windows 7, Windows Server 2008, and Windows Server 2008 R2. Microsoft released a security fix for the vulnerability on May 14, 2019.

While similar vulnerabilities have been abused by worm malware in the past, initial attempts at exploiting this vulnerability involved human operators aiming to penetrate networks via exposed RDP services.

Microsoft had already deployed a behavioral detection for the BlueKeep Metasploit module in early September, so Microsoft Defender ATP customers had protection from this Metasploit module by the time it was used against Beaumont’s honeypot. The module, which appears to be unstable as evidenced by numerous RDP-related crashes observed on the honeypot, triggered the behavioral detection in Microsoft Defender ATP, resulting in the collection of critical signals used during the investigation.

Microsoft security signals showed an increase in RDP-related crashes that are likely associated with the use of the unstable BlueKeep Metasploit module on certain sets of vulnerable machines. We saw:

• An increase in RDP service crashes from 10 to 100 daily starting on September 6, 2019, when the Metasploit module was released
• A similar increase in memory corruption crashes starting on October 9, 2019
• Crashes on external researcher honeypots starting on October 23, 2019

Figure 1. Increase in RDP-related service crashes when the Metasploit module was released

Coin miner campaign using BlueKeep exploit

After extracting indicators of compromise and pivoting to various related signal intelligence, Microsoft security researchers found that an earlier coin mining campaign in September used a main implant that contacted the same command-and-control infrastructure used during the October BlueKeep Metasploit campaign, which, in cases where the exploit did not cause the system to crash, was also observed installing a coin miner. This indicated that the same attackers were likely responsible for both coin mining campaigns—they have been actively staging coin miner attacks and eventually incorporated the BlueKeep exploit into their arsenal.

Our machine learning models flagged the presence of the coin miner payload used in these attacks on machines in France, Russia, Italy, Spain, Ukraine, Germany, the United Kingdom, and many other countries.

Figure 2. Geographic distribution of coin miner encounters

​These attacks were likely initiated as port scans for machines with vulnerable internet-facing RDP services. Once attackers found such machines, they used the BlueKeep Metasploit module to run a PowerShell script that eventually downloaded and launched several other encoded PowerShell scripts.

Figure 3. Techniques and components used in initial attempts to exploit BlueKeep

We pieced together the behaviors of the PowerShell scripts using mostly memory dumps. The following script activities have also been discussed in external researcher blogs:

1. Initial script downloaded another encoded PowerShell script from an attacker-controlled remote server (5.135.199.19) hosted somewhere in France via port 443.
2. The succeeding script downloaded and launched a series of three to four other encoded PowerShell scripts.
3. The final script eventually downloaded the coin miner payload from another attacker-controlled server (109.176.117.11) hosted in Great Britain.
4. Apart from downloading the payload, the final script also created a scheduled task to ensure the coin miner stayed persistent.​

Figure 4. Memory dump of a PowerShell script used in the attacks

The final script saved the coin miner as the following file:

C:\Windows\System32\spool\svchost.exe

The coin miner connected to command-and-control infrastructure at 5.100.251.106 hosted in Israel. Other coin miners deployed in earlier campaigns that did not exploit BlueKeep also connected to this same IP address.

Defending enterprises against BlueKeep

Security signals and forensic analysis show that the BlueKeep Metasploit module caused crashes in some cases, but we cannot discount enhancements that will likely result in more effective attacks. In addition, while there have been no other verified attacks involving ransomware or other types of malware as of this writing, the BlueKeep exploit will likely be used to deliver payloads more impactful and damaging than coin miners.

The new exploit attacks show that BlueKeep will be a threat as long as systems remain unpatched, credential hygiene is not achieved, and overall security posture is not kept in check. Customers are encouraged to identify and update vulnerable systems immediately. Many of these unpatched devices could be unmonitored RDP appliances placed by suppliers and other third-parties to occasionally manage customer systems. Because BlueKeep can be exploited without leaving obvious traces, customers should also thoroughly inspect systems that might already be infected or compromised.

To this end, Microsoft customers can use the rich capabilities in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) to gain visibility on exploit activities and defend networks against attacks. On top of the behavior-based antivirus and endpoint detection and response (EDR) detections, we released a threat analytics report to help security operations teams to conduct investigations specific to this threat. We also wrote advanced hunting queries that customers can use to look for multiple components of the attack.

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Defender ATP community.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Microsoft works with researchers to detect and protect against new RDP exploits appeared first on Microsoft Security Blog.