LSASS credential dumping was first observed in the tactics, techniques, and procedures (TTPs) of several sophisticated threat activity groups—including actors that Microsoft tracks as HAFNIUM and GALLIUM— and has become prevalent even in the cybercrime space, especially with the rise of the ransomware as a service gig economy. Detecting and stopping OS credential theft is therefore important because it can spell the difference between compromising or encrypting one device versus an entire network. Security solutions must provide specific measures and capabilities to help harden the LSASS process—for example, Microsoft Defender for Endpoint has advanced detections and a dedicated attack surface reduction rule (ASR) to block credential stealing from LSASS.

In May 2022, Microsoft participated in an evaluation conducted by independent testing organization AV-Comparatives specifically on detecting and blocking the LSASS credential dumping technique. The test, which evaluated several endpoint protection platforms (EPP) and endpoint detection and response (EDR) vendors, is the first time AV-Comparatives focused on a single attack technique, and we’re happy to report that Defender for Endpoint passed all 15 test cases used to dump user OS credentials from the LSASS process, achieving 100% detection and prevention scores. Notably, we also passed all test cases with only Defender for Endpoint’s default settings configured, that is, with LSASS ASR and Protective Process Light (PPL) turned off to validate our antivirus protection durability in itself. Such results demonstrate our continued commitment to provide organizations with industry-leading defense.

In this blog, we share examples of various threat actors that we’ve recently observed using the LSASS credential dumping technique. We also provide details on the testing methodology done by AV-Comparatives, which they also shared in their blog and detailed report. Finally, we offer additional recommendations to further harden systems and prevent attackers from taking advantage of possible misconfigurations should they fail to leverage credential dumping.

LSASS credential dumping: What we see in the wild

Dumping LSASS credentials is important for attackers because if they successfully dump domain passwords, they can, for example, then use legitimate tools such as PsExec or Windows Management Instrumentation (WMI) to move laterally across the network. They can also use techniques like pass-the-hash for lateral movement if they manage to obtain the password hashes.

Microsoft researchers are constantly monitoring the threat landscape, including the different ways threat actors attempt to steal user credentials. The table below is a snapshot of the most popular credential theft techniques these actors used from March to August 2022 based on our threat data:

The first column shows the technique attackers most frequently used in their attempt to dump credentials from LSASS, while the second column shows which threat actor uses this technique most frequently. Based on the incidents we tracked from March to August 2022, credential theft attacks using  LOLBins such as comsvc.dll, procdump.exe, or taskmgr.exe are still popular. These LOLBins are legitimate, digitally signed binaries that are either already present on the target device or are downloaded onto the system for the attacker to misuse for malicious activities.

Microsoft Defender Antivirus prevents the execution of these command lines due to its synchronous command line-blocking capabilities.

AV-Comparatives test

To evaluate EPP and EDR capabilities against the LSASS credential dumping technique, AV-Comparatives ran 15 different test cases to dump credentials from the LSASS process using both publicly available hacking tools like Mimikatz (which the tester modified to bypass antivirus signatures) and privately developed ones. These test cases were as follows:

Each test case implemented a comprehensive approach on how to dump credentials from LSASS. After the evaluation, AV-Comparatives shared the logs and detailed description of the test cases. Microsoft participated using Defender for Endpoint, both its antivirus and EDR capabilities, with only the default settings configured.

During the initial run, Defender for Endpoint prevented 11 out of 15 test cases and alerted/detected three of the remaining ones (Figure 1). We then made improvements in our protection and detection capabilities and asked AV-Comparatives to re-test the missed test cases. During the re-test, we prevented all the remaining four test cases, achieving 15 out of 15 prevention score.

We’d like to thank AV-Comparatives for this thorough test, which led us to improve our protection and detection capabilities in Defender for Endpoint. These improvements have already been rolled out to benefit our customers, and we’re looking forward to the next similar test. We aim to provide industry-leading, cross-domain defense, so it’s important for us to participate in tests like AV-Comparatives and MITRE Engenuity ATT&CK Evaluations because they help us ensure that we’re delivering solutions that empower organizations to defend their environments.

Securing the LSASS process with coordinated threat defense and system hardening

The continuous evolution of the threat landscape has seen attacks leveraging OS credential theft, and threat actors will continue to find new ways to dump LSASS credentials in their attempts to evade detection. For Microsoft, our industry-leading defense capabilities in Microsoft Defender for Endpoint are able to detect such attempts. We’ve also introduced new security features in Windows 11 to harden the operating system, such as enabling PPL for the LSASS process and Credential Guard by default. However, evaluations like this AV-Comparatives test go hand in hand with threat monitoring and research because they provide security vendors additional insights and opportunities to continuously improve capabilities.

Our teams performed an in-house test of all these test cases with the LSASS ASR rule enabled to check the protection level of that rule. We’re happy to report that the ASR rule alone successfully prevented all the tested techniques. The LSASS ASR rule is a generic yet effective protection our customers can implement to stop currently known user-mode LSASS credential dumping attacks. Defender customers should therefore enable this ASR rule—along with tamper protection—as an added protection layer for the LSASS process.

On top of the various dumping techniques, we’ve also observed threat actors attempt to weaken the device settings in case they can’t dump credentials. For example, they attempt to enable “UseLogonCredential” in WDigest registry, which enables plaintext passwords in memory. Microsoft Defender Antivirus detects such techniques, too, as Behavior:Win32/WDigestNegMod.B.

Windows administrators can also perform the following to further harden the LSASS process on their devices:

• Enable PPL for LSASS process; note that for new, enterprise-joined Windows 11 installs (22H2 update), this is already enabled by default
• Enable Windows Defender Credential Guard; this is also now enabled by default for organizations using the Enterprise edition of Windows 11
• Enable restricted admin mode for Remote Desktop Protocol (RDP)
• Disable “UseLogonCredential” in WDigest

Finally, customers with Azure Active Directory (Azure AD) can follow our recommendations on hardening environments:

• Ransomware as a service: Understanding the cybercrime gig economy and how to protect yourself – Microsoft Security Blog
• Best Practices for Securing Active Directory | Microsoft Learn
• Pass the Hash | Microsoft Learn

The post Detecting and preventing LSASS credential dumping attacks appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. HAFNIUM is now tracked as Silk Typhoon.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

As Microsoft continues to track the high-priority state-sponsored threat actor HAFNIUM, new activity has been uncovered that leverages unpatched zero-day vulnerabilities as initial vectors. The Microsoft Detection and Response Team (DART) in collaboration with the Microsoft Threat Intelligence Center (MSTIC) identified a multi-stage attack targeting the Zoho Manage Engine Rest API authentication bypass vulnerability to initially implant a Godzilla web shell with similar properties detailed by the Unit42 team in a previous blog.

Microsoft observed HAFNIUM from August 2021 to February 2022, target those in the telecommunication, internet service provider and data services sector, expanding on targeted sectors observed from their earlier operations conducted in Spring 2021.

Further investigation reveals forensic artifacts of the usage of Impacket tooling for lateral movement and execution and the discovery of a defense evasion malware called Tarrask that creates “hidden” scheduled tasks, and subsequent actions to remove the task attributes, to conceal the scheduled tasks from traditional means of identification.

The blog outlines the simplicity of the malware technique Tarrask uses, while highlighting that scheduled task abuse is a very common method of persistence and defense evasion—and an enticing one, at that. In this post, we will demonstrate how threat actors create scheduled tasks, how they cover their tracks, how the malware’s evasion techniques are used to maintain and ensure persistence on systems, and how to protect against this tactic.

Right on schedule: Maintaining persistence via scheduled tasks

Windows Task Scheduler is a service that allows users to perform automated tasks (scheduled tasks) on a chosen computer for legitimate administrative purposes (e.g., scheduled updates for browsers and other applications).

Throughout the course of our research, we’ve found that threat actors commonly make use of this service to maintain persistence within a Windows environment.

We’ve noted that the Tarrask malware generates several artifacts upon the creation of a scheduled task, whether using the Task Scheduler GUI or the schtasks command line utility. Profiling the use of either of these tools can aid investigators in tracking this persistence mechanism.

The following registry keys are created upon creation of a new task:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\TASK_NAME
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID}

The first subkey, created within the Tree path, matches the name of the scheduled task. The values created within it (Id, Index, and SD) contain metadata for task registration within the system. The second subkey, created within the Tasks path, is a GUID mapping to the Id value found in the Tree key. The values created within (Actions, Path, Triggers, etc.) contain the basic parameters necessary to facilitate execution of the task.

To demonstrate the value in the artifacts generated, shown in the following figures, we have created “My Special Task” which is set to execute the binary “C:\Windows\System32\calc.exe” on a regular interval.

Similar information is also stored within an extensionless XML file created within C:\Windows\System32\Tasks, where the name of the file matches the name of the task. This is displayed in Figure 2, where we name the task “My Special Task” as an example.

Note that the “Actions” value stored within the Tasks\{GUID} key points to the command line associated with the task. In Figure 2, there is a reference to “C:\Windows\System32\calc.exe” within the “Edit Binary Value” dialog, and there is a path referenced within the “<Command>” section in the extensionless XML file in Figure 3. The fact that this value is stored within two different locations can prove useful in recovering information regarding the task’s purpose in the event the threat actor has taken steps to cover their tracks.

Finally, there are two Windows event logs that record actions related to the creation and operation of Scheduled Tasks – Event ID 4698 within the Security.evtx log, and the Microsoft-Windows-TaskScheduler/Operational.evtx log.

Neither of these are audited by default and must be explicitly turned on by an administrator. Microsoft-Windows-TaskScheduler/Maintenance.evtx will exist by default, but only contains maintenance-related information for the Task Scheduler engine.

Effectively hiding scheduled tasks

In this scenario, the threat actor created a scheduled task named “WinUpdate” via HackTool:Win64/Tarrask in order to re-establish any dropped connections to their command and control (C&C) infrastructure. This resulted in the creation of the registry keys and values described in the earlier section, however, the threat actor deleted the SD value within the Tree registry path.

In this context, SD refers to the Security Descriptor, which determines the users allowed to run the task. Interestingly, removal of this value results in the task “disappearing” from “schtasks /query” and Task Scheduler. The task is effectively hidden unless an examiner manually inspects the aforementioned registry paths.

Issuing a “reg delete” command to delete the SD value will result in an “Access Denied” error even when run from an elevated command prompt. Deletion must occur within the context of the SYSTEM user. It is for this reason that the Tarrask malware utilized token theft to obtain the security permissions associated with the lsass.exe process. Upon execution of the token theft, the malware could operate with the same privileges as LSASS, making the deletion possible.

It is also important to note that the threat actor could have chosen to completely remove the two registry keys within Tree and Tasks, and the XML file created within C:\Windows\System32\Tasks. This would effectively remove the on-disk artifacts associated with the scheduled task, but the task would continue to run according to the defined triggers until the system rebooted, or until the associated svchost.exe process responsible for executing the task was terminated.

It’s possible the threat actor wanted to ensure persistence across reboots and therefore chose not to perform those steps, instead deleting only the SD value; however, we also speculate that the threat actor was unaware that the task would continue to run even after these components were removed.

Recommendations and cyber resilience guidance

Job or task schedulers are services that have been present in the Windows operating system for many years. The attacks we described signify how the threat actor HAFNIUM displays a unique understanding of the Windows subsystem and uses this expertise to mask activities on targeted endpoints to maintain persistence on affected systems and hide in plain sight.

As such, we recognize that scheduled tasks are an effective tool for adversaries to automate certain tasks while achieving persistence, which brings us to raising awareness about this oft-overlooked technique. We also want to bring attention to the fact that threat actors may utilize this method of evasion to maintain access to high value targets in a manner that will likely remain undetected. This could be especially problematic for systems that are infrequently rebooted (e.g., critical systems such as domain controllers, database servers, etc.).

The techniques used by the actor and described in this post can be mitigated or detected by adopting the following recommendations and security guidelines¹:

• Enumerate your Windows environment registry hives looking in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree registry hive and identify any scheduled tasks without SD (security descriptor) Value within the Task Key. Perform analysis on these tasks as needed.
• Modify your audit policy to identify Scheduled Tasks actions by enabling logging “TaskOperational” within Microsoft-Windows-TaskScheduler/Operational. Apply the recommended Microsoft audit policy settings suitable to your environment.
• Enable and centralize the following Task Scheduler logs. Even if the tasks are ‘hidden’, these logs track key events relating to them that could lead you to discovering a well-hidden persistence mechanism
  • Event ID 4698 within the Security.evtx log
  • Microsoft-Windows-TaskScheduler/Operational.evtx log
• The threat actors in this campaign used hidden scheduled tasks to maintain access to critical assets exposed to the internet by regularly re-establishing outbound communications with C&C infrastructure. Remain vigilant and monitor uncommon behavior of your outbound communications by ensuring that monitoring and alerting for these connections from these critical Tier 0 and Tier 1 assets is in place.

Indicators of compromise (IOCs)

The following list provides IOCs observed during our investigation. We encourage customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

Microsoft 365 Defender Detections

How customers can identify this in Microsoft 365 Defender:

Microsoft Defender Antivirus

Microsoft Defender for Endpoint on detects implants and components as the following:

• HackTool:Win64/Tarrask!MSR
• HackTool:Win64/Ligolo!MSR

Microsoft Defender for Endpoint detects malicious behavior observed as the following:

• Behavior:Win32/ScheduledTaskHide.A

Microsoft Sentinel Detections

Microsoft Sentinel customers can use the following detection queries to look for this activity:

• Tarrask malware hash IOC: This query identifies a hash match related to Tarrask malware across various data sources.
• Scheduled Task Hide: This query uses Windows Security Events to detect attempts by malware to hide the scheduled task by deleting the SD (Security Descriptor) value. Removal of SD value results in the scheduled task “disappearing” from “schtasks /query” and Task Scheduler.
• Microsoft Defender AV Hits: This query looks for Microsoft Defender AV detections related to Tarrask malware using SecurityAlerts table. In Microsoft Sentinel the SecurityAlerts table includes only the Device Name of the affected device, this query joins the DeviceInfo table to clearly connect other information such as Device group, IP, logged on users etc. This way, the Microsoft Sentinel user can have all the pertinent device info in one view for the alerts.

¹ The technical information contained in this article is provided for general informational and educational purposes only and is not a substitute for professional advice. Accordingly, before taking any action based upon such information, we encourage you to consult with the appropriate professionals. We do not provide any kind of guarantee of a certain outcome or result based on the information provided. Therefore, the use or reliance of any information contained in this article is solely at your own risk.

The post Tarrask malware uses scheduled tasks for defense evasion appeared first on Microsoft Security Blog.

January 10, 2022 recap – The Log4j vulnerabilities represent a complex and high-risk situation for companies across the globe. This open-source component is widely used across many suppliers’ software and services. By nature of Log4j being a component, the vulnerabilities affect not only applications that use vulnerable libraries, but also any services that use these applications, so customers may not readily know how widespread the issue is in their environment. Customers are encouraged to utilize scripts and scanning tools to assess their risk and impact. Microsoft has observed attackers using many of the same inventory techniques to locate targets. Sophisticated adversaries (like nation-state actors) and commodity attackers alike have been observed taking advantage of these vulnerabilities. There is high potential for the expanded use of the vulnerabilities.

In January, we started seeing attackers taking advantage of the vulnerabilities in internet-facing systems, eventually deploying ransomware. We have observed many existing attackers adding exploits of these vulnerabilities in their existing malware kits and tactics, from coin miners to hands-on-keyboard attacks. Organizations may not realize their environments may already be compromised. Microsoft recommends customers to do additional review of devices where vulnerable installations are discovered.  At this juncture, customers should assume broad availability of exploit code and scanning capabilities to be a real and present danger to their environments. Due to the many software and services that are impacted and given the pace of updates, this is expected to have a long tail for remediation, requiring ongoing, sustainable vigilance.

January 19, 2022 update – We added new information about an unrelated vulnerability we discovered while investigating Log4j attacks.

January 21, 2022 update – Threat and vulnerability management can now discover vulnerable Log4j libraries, including Log4j files and other files containing Log4j, packaged into Uber-JAR files.

The remote code execution (RCE) vulnerabilities in Apache Log4j 2 referred to as “Log4Shell” (CVE-2021-44228, CVE-2021-45046, CVE-2021-44832) has presented a new attack vector and gained broad attention due to its severity and potential for widespread exploitation. The majority of attacks we have observed so far have been mainly mass-scanning, coin mining, establishing remote shells, and red-team activity, but it’s highly likely that attackers will continue adding exploits for these vulnerabilities to their toolkits.

With nation-state actors testing and implementing the exploit and known ransomware-associated access brokers using it, we highly recommend applying security patches and updating affected products and services as soon as possible. Refer to the Microsoft Security Response Center blog for technical information about the vulnerabilities and mitigation recommendations.

Meanwhile, defenders need to be diligent in detecting, hunting for, and investigating related threats. This blog reports our observations and analysis of attacks that take advantage of the Log4j 2 vulnerabilities. It also provides our recommendations for using Microsoft security solutions to (1) find and remediate vulnerable services and systems and (2) detect, investigate, and respond to attacks.

This blog covers the following topics:

1. Attack vectors and observed activity
2. Finding and remediating vulnerable apps and systems
   • Threat and vulnerability management
     • Discovering affected components, software, and devices via a unified Log4j dashboard
     • Applying mitigation directly in the Microsoft 365 Defender portal
   • Microsoft 365 Defender advanced hunting
   • Microsoft Defender for Cloud
     • Microsoft Defender for servers
     • Microsoft Defender for Containers
   • Microsoft Sentinel queries
   • RiskIQ EASM and Threat Intelligence
3. Detecting and responding to exploitation attempts and other related attacker activity
   • Microsoft 365 Defender
     • Microsoft Defender Antivirus
     • Microsoft Defender for Endpoint
     • Microsoft Defender for Cloud Apps
     • Microsoft Defender for Office 365
     • Microsoft 365 Defender advanced hunting
   • Microsoft Defender for Cloud
   • Microsoft Defender for IoT
   • Microsoft Sentinel
     • Microsoft Sentinel queries
   • Azure Firewall Premium
   • Azure Web Application Firewall (WAF)
4. Indicators of compromise (IoCs)

Attack vectors and observed activity

Microsoft’s unified threat intelligence team, comprising the Microsoft Threat Intelligence Center (MSTIC), Microsoft 365 Defender Threat Intelligence Team, RiskIQ, and the Microsoft Detection and Response Team (DART), among others, have been tracking threats taking advantage of the remote code execution (RCE) vulnerabilities in Apache Log4j 2 referred to as “Log4Shell”.

The bulk of attacks that Microsoft has observed at this time have been related to mass scanning by attackers attempting to thumbprint vulnerable systems, as well as scanning by security companies and researchers. An example pattern of attack would appear in a web request log with strings like the following:

An attacker performs an HTTP request against a target system, which generates a log using Log4j 2 that leverages JNDI to perform a request to the attacker-controlled site. The vulnerability then causes the exploited process to reach out to the site and execute the payload.  In many observed attacks, the attacker-owned parameter is a DNS logging system, intended to log a request to the site to fingerprint the vulnerable systems.

The specially crafted string that enables exploitation of the vulnerabilities can be identified through several components. The string contains “jndi”, which refers to the Java Naming and Directory Interface. Following this, the protocol, such as “ldap”, “ldaps”, “rmi”, “dns”, “iiop”, or “http”, precedes the attacker domain.

As security teams work to detect the exploitation, attackers have added obfuscation to these requests to evade detections based on request patterns. We’ve seen things like running a lower or upper command within the exploitation string and even more complicated obfuscation attempts, such as the following, that are all trying to bypass string-matching detections:

The vast majority of observed activity has been scanning, but exploitation and post-exploitation activities have also been observed. Based on the nature of the vulnerabilities, once the attacker has full access and control of an application, they can perform a myriad of objectives. Microsoft has observed activities including installing coin miners, using Cobalt Strike to enable credential theft and lateral movement, and exfiltrating data from compromised systems.

Exploitation continues on non-Microsoft hosted Minecraft servers

Minecraft customers running their own servers are encouraged to deploy the latest Minecraft server update as soon as possible to protect their users. More information can be found here: https://aka.ms/mclog.

Microsoft can confirm public reports of the Khonsari ransomware family being delivered as payload post-exploitation, as discussed by Bitdefender. In Microsoft Defender Antivirus data we have observed a small number of cases of this being launched from compromised Minecraft clients connected to modified Minecraft servers running a vulnerable version of Log4j 2 via the use of a third-party Minecraft mods loader.

In these cases, an adversary sends a malicious in-game message to a vulnerable Minecraft server, which exploits CVE-2021-44228 to retrieve and execute an attacker-hosted payload on both the server and on connected vulnerable clients. We observed exploitation leading to a malicious Java class file that is the Khonsari ransomware, which is then executed in the context of javaw.exe to ransom the device.

While it’s uncommon for Minecraft to be installed in enterprise networks, we have also observed PowerShell-based reverse shells being dropped to Minecraft client systems via the same malicious message technique, giving an actor full access to a compromised system, which they then use to run Mimikatz to steal credentials. These techniques are typically associated with enterprise compromises with the intent of lateral movement. Microsoft has not observed any follow-on activity from this campaign at this time, indicating that the attacker may be gathering access for later use.

Due to the shifts in the threat landscape, Microsoft reiterates the guidance for Minecraft customers running their own servers to deploy the latest Minecraft server update and for players to exercise caution by only connecting to trusted Minecraft servers.

Nation-state activity

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. To learn more about this evolution, how the new taxonomy represents the origin, unique traits, and impact of threat actors, and a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

MSTIC has also observed the CVE-2021-44228 vulnerability being used by multiple tracked nation-state activity groups originating from China, Iran, North Korea, and Turkey. This activity ranges from experimentation during development, integration of the vulnerabilities to in-the-wild payload deployment, and exploitation against targets to achieve the actor’s objectives.

For example, MSTIC has observed PHOSPHORUS, an Iranian actor known to deploy ransomware, acquiring and making modifications of the Log4j exploit. We assess that PHOSPHORUS has operationalized these modifications.

In addition, HAFNIUM, a threat actor group operating out of China, has been observed utilizing the vulnerability to attack virtualization infrastructure to extend their typical targeting. In these attacks, HAFNIUM-associated systems were observed using a DNS service typically associated with testing activity to fingerprint systems.

Access brokers associated with ransomware

MSTIC and the Microsoft 365 Defender team have confirmed that multiple tracked activity groups acting as access brokers have begun using the vulnerability to gain initial access to target networks. These access brokers then sell access to these networks to ransomware-as-a-service affiliates. We have observed these groups attempting exploitation on both Linux and Windows systems, which may lead to an increase in human-operated ransomware impact on both of these operating system platforms.

Mass scanning activity continues

The vast majority of traffic observed by Microsoft remains mass scanners by both attackers and security researchers. Microsoft has observed rapid uptake of the vulnerability into existing botnets like Mirai, existing campaigns previously targeting vulnerable Elasticsearch systems to deploy cryptocurrency miners, and activity deploying the Tsunami backdoor to Linux systems. Many of these campaigns are running concurrent scanning and exploitation activities for both Windows and Linux systems, using Base64 commands included in the JDNI:ldap:// request to launch bash commands on Linux and PowerShell on Windows.

Microsoft has also continued to observe malicious activity performing data leakage via the vulnerability without dropping a payload. This attack scenario could be especially impactful against network devices that have SSL termination, where the actor could leak secrets and data.

Additional RAT payloads

We’ve observed the dropping of additional remote access toolkits and reverse shells via exploitation of CVE-2021-44228, which actors then use for hands-on-keyboard attacks. In addition to the Cobalt Strike and PowerShell reverse shells seen in earlier reports, we’ve also seen Meterpreter, Bladabindi, and HabitsRAT. Follow-on activities from these shells have not been observed at this time, but these tools have the ability to steal passwords and move laterally.

This activity is split between a percentage of small-scale campaigns that may be more targeted or related to testing, and the addition of CVE-2021-44428 to existing campaigns that were exploiting vulnerabilities to drop remote access tools. In the HabitsRAT case, the campaign was seen overlapping with infrastructure used in prior campaigns.

Webtoos

The Webtoos malware has DDoS capabilities and persistence mechanisms that could allow an attacker to perform additional activities. As reported by RiskIQ, Microsoft has seen Webtoos being deployed via the vulnerability. Attackers’ use of this malware or intent is not known at this time, but the campaign and infrastructure have been in use and have been targeting both Linux and Windows systems prior to this vulnerability.

A note on testing services and assumed benign activity

While services such as interact.sh, canarytokens.org, burpsuite, and dnslog.cn may be used by IT organizations to profile their own threat footprints, Microsoft encourages including these services in your hunting queries and validating observations of these in environments to ensure they are intentional and legitimate activity.

Exploitation in internet-facing systems leads to ransomware

As early as January 4, attackers started exploiting the CVE-2021-44228 vulnerability in internet-facing systems running VMware Horizon. Our investigation shows that successful intrusions in these campaigns led to the deployment of the NightSky ransomware.

These attacks are performed by a China-based ransomware operator that we’re tracking as DEV-0401. DEV-0401 has previously deployed multiple ransomware families including LockFile, AtomSilo, and Rook, and has similarly exploited Internet-facing systems running Confluence (CVE-2021-26084) and on-premises Exchange servers (CVE-2021-34473).

Based on our analysis, the attackers are using command and control (CnC) servers that spoof legitimate domains. These include service[.]trendmrcio[.]com, api[.]rogerscorp[.]org, api[.]sophosantivirus[.]ga, apicon[.]nvidialab[.]us, w2zmii7kjb81pfj0ped16kg8szyvmk.burpcollaborator[.]net, and 139[.]180[.]217[.]203.

Attackers propagating Log4j attacks via previously undisclosed vulnerability

During our sustained monitoring of threats taking advantage of the Log4j 2 vulnerabilities, we observed activity related to attacks being propagated via a previously undisclosed vulnerability in the SolarWinds Serv-U software. We discovered that the vulnerability, now tracked as CVE-2021-35247, is an input validation vulnerability that could allow attackers to build a query given some input and send that query over the network without sanitation.

We reported our discovery to SolarWinds, and we’d like to thank their teams for immediately investigating and working to remediate the vulnerability. We strongly recommend affected customers to apply security updates released by referring to the SolarWinds advisory here: https://www.solarwinds.com/trust-center/security-advisories/cve-2021-35247.

Microsoft customers can use threat and vulnerability management in Microsoft Defender for Endpoint to identify and remediate devices that have this vulnerability. In addition, Microsoft Defender Antivirus and Microsoft Defender for Endpoint detect malicious behavior related to the observed activity.

Finding and remediating vulnerable apps and systems

Threat and vulnerability management

Threat and vulnerability management capabilities in Microsoft Defender for Endpoint monitor an organization’s overall security posture and equip customers with real-time insights into organizational risk through continuous vulnerability discovery, intelligent prioritization, and the ability to seamlessly remediate vulnerabilities.

Discovering affected components, software, and devices via a unified Log4j dashboard

Threat and vulnerability management automatically and seamlessly identifies devices affected by the Log4j vulnerabilities and the associated risk in the environment and significantly reduces time-to-mitigate. Microsoft continues to iterate on these features based on the latest information from the threat landscape. This section will be updated as those new features become available for customers.

The wide use of Log4j across many supplier’s products challenge defender teams to mitigate and address the risks posed by the vulnerabilities (CVE-2021-44228 or CVE-2021-45046).  The threat and vulnerability management capabilities within Microsoft 365 Defender can help identify vulnerable installations. On December 15, we began rolling out updates to provide a consolidated view of the organizational exposure to the Log4j 2 vulnerabilities—on the device, software, and vulnerable component level—through a range of automated, complementing capabilities. These capabilities are supported on Windows 10, Windows 11, and Windows Server 2008, 2012, and 2016. They are also supported on Linux, but they require updating the Microsoft Defender for Endpoint Linux client to version 101.52.57 (30.121092.15257.0) or later. The updates include the following:

• Discovery of vulnerable Log4j library components (paths) on devices
• Discovery of vulnerable installed applications that contain the Log4j library on devices
• A dedicated Log4j dashboard that provides a consolidated view of various findings across vulnerable devices, vulnerable software, and vulnerable files
• Introduction of a new schema in advanced hunting, DeviceTvmSoftwareEvidenceBeta, which surfaces file-level findings from the disk and provides the ability to correlate them with additional context in advanced hunting:

DeviceTvmSoftwareEvidenceBeta
| mv-expand DiskPaths
| where DiskPaths contains "log4j"
| project DeviceId, SoftwareName, SoftwareVendor, SoftwareVersion, DiskPaths

To complement this new table, the existing DeviceTvmSoftwareVulnerabilities table in advanced hunting can be used to identify vulnerabilities in installed software on devices:

DeviceTvmSoftwareVulnerabilities 
| where CveId in ("CVE-2021-44228", "CVE-2021-45046")

These capabilities integrate with the existing threat and vulnerability management experience and are gradually rolling out. As of December 27, 2021, discovery is based on installed application CPEs that are known to be vulnerable to Log4j RCE, as well as the presence of vulnerable Log4j Java Archive (JAR) files.

As of January 20, 2022, threat and vulnerability management can discover vulnerable Log4j libraries, including Log4j files and other files containing Log4j, packaged into Uber-JAR files. This capability is supported on Windows 10, Windows 11, Windows Server 2019, and Windows Server 2022. It is also supported on Windows Server 2012 R2 and Windows Server 2016 using the Microsoft Defender for Endpoint solution for earlier Windows server versions.

Threat and vulnerability management provides layers of detection to help customers discover and mitigate vulnerable Log4j components. Specifically, it:

1. determines if a JAR file contains a vulnerable Log4j file by examining JAR files and searching for the following file: \META-INF\maven\org.apache.logging.log4j\log4j-core\pom.properties; if the said file exists, the Log4j version is read and extracted 
2. searches for the JndiLookup.class file inside the JAR file by looking for paths that contain the string “/log4j/core/lookup/JndiLookup.class”; if the JndiLookup.class file exists, threat and vulnerability management determines if this JAR contains a Log4j file with the version defined in pom.properties 
3. searches for any vulnerable Log4j-core JAR files embedded within nested-JAR by searching for paths that contain any of these strings:
   • lib/log4j-core- 
   • WEB-INF/lib/log4j-core- 
   • App-INF/lib/log4j-core- 

Figure 1. Threat and Vulnerability recommendation “Attention required: Devices found with vulnerable Apache Log4j versions”

In the Microsoft 365 Defender portal, go to Vulnerability management > Dashboard > Threat awareness, then click View vulnerability details to see the consolidated view of organizational exposure to the Log4j 2 vulnerability (for example, CVE-2021-44228 dashboard, as shown in the following screenshots) on the device, software, and vulnerable component level.

Figure 2. Threat and vulnerability management dedicated CVE-2021-44228 dashboard

Figure 3. Threat and vulnerability management finds exposed paths

Figure 4. Threat and vulnerability management finds exposed devices based on vulnerable software and vulnerable files detected on disk

Note: Scan results may take some time to reach full coverage, and the number of discovered devices may be low at first but will grow as the scan reaches more devices. A regularly updated list of vulnerable products can be viewed in the Microsoft 365 Defender portal with matching recommendations. We will continue to review and update this list as new information becomes available.

Through device discovery, unmanaged devices with products and services affected by the vulnerabilities are also surfaced so they can be onboarded and secured.

Figure 5. Finding vulnerable applications and devices via software inventory

Applying mitigation directly in the Microsoft 365 Defender portal

We have released two new threat and vulnerability management capabilities that can significantly simplify the process of turning off JNDI lookup, a workaround that can prevent the exploitation of the Log4j vulnerabilities on most devices, using an environment variable called LOG4J_FORMAT_MSG_NO_LOOKUPS. These new capabilities provide security teams with the following:

1. View the mitigation status for each affected device. This can help prioritize mitigation and/or patching of devices based on their mitigation status.

To use this feature, open the Exposed devices tab in the dedicated CVE-2021-44228 dashboard and review the Mitigation status column. Note that it may take a few hours for the updated mitigation status of a device to be reflected.

Figure 6. Viewing each device’s mitigation status

2. Apply the mitigation (that is, turn off JNDI lookup) on devices directly from the portal. This feature is currently available for Windows devices only.

The mitigation will be applied directly via the Microsoft Defender for Endpoint client. To view the mitigation options, click on the Mitigation options button in the Log4j dashboard:

You can choose to apply the mitigation to all exposed devices or select specific devices for which you would like to apply it. To complete the process and apply the mitigation on devices, click Create mitigation action.

Figure 7. Creating mitigation actions for exposed devices.

In cases where the mitigation needs to be reverted, follow these steps:

1. Open an elevated PowerShell window
2. Run the following command:

[Environment]::SetEnvironmentVariable("LOG4J_FORMAT_MSG_NO_LOOKUPS", $null, [EnvironmentVariableTarget]::Machine)

The change will take effect after the device restarts.

Microsoft 365 Defender advanced hunting

Advance hunting can also surface affected software. This query looks for possibly vulnerable applications using the affected Log4j component. Triage the results to determine applications and programs that may need to be patched and updated.

DeviceTvmSoftwareInventory
| where SoftwareName contains "log4j"
| project DeviceName, SoftwareName, SoftwareVersion

Figure 8. Finding vulnerable software via advanced hunting

Microsoft Defender for Cloud

Microsoft Defender for servers

Organizations using Microsoft Defender for Cloud can use Inventory tools to begin investigations before there’s a CVE number. With Inventory tools, there are two ways to determine exposure across hybrid and multi-cloud resources:

• Vulnerability assessment findings – Organizations who have enabled any of the vulnerability assessment tools (whether it’s Microsoft Defender for Endpoint’s threat and vulnerability management module, the built-in Qualys scanner, or a bring your own license solution), they can search by CVE identifier:

Figure 9. Searching vulnerability assessment findings by CVE identifier

• Software inventory – With the combined integration with Microsoft Defender for Endpoint and Microsoft Defender for servers, organizations can search for resources by installed applications and discover resources running the vulnerable software:

Figure 10. Searching software inventory by installed applications

Note that this doesn’t replace a search of your codebase. It’s possible that software with integrated Log4j libraries won’t appear in this list, but this is helpful in the initial triage of investigations related to this incident. For more information about how Microsoft Defender for Cloud finds machines affected by CVE-2021-44228, read this tech community post.

Microsoft Defender for Containers

Microsoft Defender for Containers is capable of discovering images affected by the vulnerabilities recently discovered in Log4j 2: CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105. Images are automatically scanned for vulnerabilities in three different use cases: when pushed to an Azure container registry, when pulled from an Azure container registry, and when container images are running on a Kubernetes cluster. Additional information on supported scan triggers and Kubernetes clusters can be found here. 

Log4j binaries are discovered whether they are deployed via a package manager, copied to the image as stand-alone binaries, or included within a JAR Archive (up to one level of nesting). 

We will continue to follow up on any additional developments and will update our detection capabilities if any additional vulnerabilities are reported.

Finding affected images

To find vulnerable images across registries using the Azure portal, navigate to the Microsoft Defender for Cloud service under Azure Portal. Open the Container Registry images should have vulnerability findings resolved recommendation and search findings for the relevant CVEs. 

Figure 11. Finding images with the CVE-2021-45046 vulnerability 

Find vulnerable running images on Azure portal [preview] 

To view only vulnerable images that are currently running on a Kubernetes cluster using the Azure portal, navigate to the Microsoft Defender for Cloud service under Azure Portal. Open the Vulnerabilities in running container images should be remediated (powered by Qualys) recommendation and search findings for the relevant CVEs: 

Figure 12. Finding running images with the CVE-2021-45046 vulnerability

Note: This recommendation requires clusters to run Microsoft Defender security profile to provide visibility on running images.

Search Azure Resource Graph data 

Azure Resource Graph (ARG) provides instant access to resource information across cloud environments with robust filtering, grouping, and sorting capabilities. It’s a quick and efficient way to query information across Azure subscriptions programmatically or from within the Azure portal. ARG provides another way to query resource data for resources found to be affected by the Log4j vulnerability.

The following query finds resources affected by the Log4j vulnerability across subscriptions. Use the additional data field across all returned results to obtain details on vulnerable resources: 

securityresources 
| where type =~ "microsoft.security/assessments/subassessments"
| extend assessmentKey=extract(@"(?i)providers/Microsoft.Security/assessments/([^/]*)", 1, id), subAssessmentId=tostring(properties.id), parentResourceId= extract("(.+)/providers/Microsoft.Security", 1, id)
| extend Props = parse_json(properties)
| extend additionalData = Props.additionalData
| extend cves = additionalData.cve
| where isnotempty(cves) and array_length(cves) > 0
| mv-expand cves
| where tostring(cves) has "CVE-2021-44228" or tostring(cves) has "CVE-2021-45046" or tostring(cves) has "CVE-2021-45105" 

Microsoft Sentinel queries

Microsoft Sentinel customers can use the following detection query to look for devices that have applications with the vulnerability:

• Vulnerable machines related to Log4j CVE-2021-44228

This query uses the Microsoft Defender for Cloud nested recommendations data to find machines vulnerable to Log4j CVE-2021-44228.

Microsoft Sentinel also provides a CVE-2021-44228 Log4Shell Research Lab Environment for testing the vulnerability: https://github.com/OTRF/Microsoft-Sentinel2Go/tree/master/grocery-list/Linux/demos/CVE-2021-44228-Log4Shell

RiskIQ EASM and Threat Intelligence

RiskIQ has published a few threat intelligence articles on this CVE, with mitigation guidance and IOCs. The latest one with links to previous articles can be found here. Both Community users and enterprise customers can search within the threat intelligence portal for data about potentially vulnerable components exposed to the Internet. For example, it’s possible to surface all observed instances of Apache or Java, including specific versions. Leverage this method of exploration to aid in understanding the larger Internet exposure, while also filtering down to what may impact you. 

For a more automated method, registered users can view their attack surface to understand tailored findings associated with their organization. Note, you must be registered with a corporate email and the automated attack surface will be limited. Digital Footprint customers can immediately understand what may be vulnerable and act swiftly and resolutely using the Attack Surface Intelligence Dashboard Log4J Insights tab. 

Detecting and responding to exploitation attempts and other related attacker activity

Microsoft 365 Defender

Microsoft 365 Defender coordinates multiple security solutions that detect components of observed attacks taking advantage of this vulnerability, from exploitation attempts to remote code execution and post-exploitation activity.

Figure 13. Microsoft 365 Defender solutions protect against related threats

Customers can click Need help? in the Microsoft 365 Defender portal to open up a search widget. Customers can key in “Log4j” to search for in-portal resource, check if their network is affected, and work on corresponding actionable items to mitigate them.

Microsoft Defender Antivirus

Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block the majority of new and unknown variants. Microsoft Defender Antivirus detects components and behaviors related to this threat as the following detection names:

On Windows:

• Trojan:Win32/Capfetox.AA– detects attempted exploitation on the attacker machine
• HackTool:Win32/Capfetox.A!dha – detects attempted exploitation on the attacker machine
• VirTool:Win64/CobaltSrike.A, TrojanDropper:PowerShell/Cobacis.A – detects Cobalt Strike Beacon loaders
• TrojanDownloader:Win32/CoinMiner – detects post-exploitation coin miner
• Trojan:Win32/WebToos.A – detects post-exploitation PowerShell
• Ransom:MSIL/Khonsari.A – detects a strain of the Khonsari ransomware family observed being distributed post-exploitation
• Trojan:Win64/DisguisedXMRigMiner – detects post-exploitation cryptocurrency miner
• TrojanDownloader:Java/Agent.S – detects suspicious class files used in post-exploitation
• TrojanDownloader:PowerShell/NitSky.A – detects attempts to download CobaltStrike Beacon payload

On Linux:

• Trojan:Linux/SuspectJavaExploit.A, Trojan:Linux/SuspectJavaExploit.B, Trojan:Linux/SuspectJavaExploit.C – blocks Java processes downloading and executing payload through output redirection
• Trojan:Linux/BashMiner.A – detects post-exploitation cryptocurrency miner
• TrojanDownloader:Linux/CoinMiner – detects post-exploitation cryptocurrency miner
• TrojanDownloader:Linux/Tusnami – detects post-exploitation Backdoor Tsunami downloader
• Backdoor:Linux/Tusnami.C – detects post-exploitation Tsunami backdoor
• Backdoor:Linux/Setag.C – detects post-exploitation Gates backdoor
• Exploit:Linux/CVE-2021-44228.A, Exploit:Linux/CVE-2021-44228.B – detects exploitation
• TrojanDownloader:Linux/Capfetox.A, TrojanDownloader:Linux/Capfetox.B
• TrojanDownloader:Linux/ShAgnt!MSR, TrojanDownloader:Linux/ShAgnt.A!MTB
• Trojan:Linux/Kinsing.L – detects post-exploitation cryptocurrency Kinsing miner
• Trojan:Linux/Mirai.TS!MTB – detects post-exploitation Mirai malware capable of performing DDoS
• Backdoor:Linux/Dakkatoni.az!MTB – detects post-exploitation Dakkatoni backdoor trojan capable of downloading more payloads
• Trojan:Linux/JavaExploitRevShell.A – detects reverse shell attack post-exploitation
• Trojan:Linux/BashMiner.A, Trojan:Linux/BashMiner.B – detects post-exploitation cryptocurrency miner

Microsoft Defender for Endpoint

Users of Microsoft Defender for Endpoint can turn on the following attack surface reduction rule to block or audit some observed activity associated with this threat.

• Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Due to the broad network exploitation nature of vectors through which this vulnerability can be exploited and the fact that applying mitigations holistically across large environments will take time, we encourage defenders to look for signs of post-exploitation rather than fully relying on prevention. Observed post exploitation activity such as coin mining, lateral movement, and Cobalt Strike are detected with behavior-based detections.

Alerts with the following titles in the Security Center indicate threat activity related to exploitation of the Log4j vulnerability on your network and should be immediately investigated and remediated. These alerts are supported on both Windows and Linux platforms: 

• Log4j exploitation detected – detects known behaviors that attackers perform following successful exploitation of the CVE-2021-44228 vulnerability
• Log4j exploitation artifacts detected (previously titled Possible exploitation of CVE-2021-44228) – detects coin miners, shells, backdoor, and payloads such as Cobalt Strike used by attackers post-exploitation
• Log4j exploitation network artifacts detected (previously titled Network connection seen in CVE-2021-44228 exploitation) – detects network traffic connecting traffic connecting to an address associated with CVE-2021-44228 scanning or exploitation activity 

The following alerts may indicate exploitation attempts or testing/scanning activity. Microsoft advises customers to investigate with caution, as these alerts don’t necessarily indicate successful exploitation:

• Possible target of Log4j exploitation – detects a possible attempt to exploit the remote code execution vulnerability in the Log4j component of an Apache server in communication received by this device
• Possible target of Log4j vulnerability scanning – detects a possible attempt to scan for the remote code execution vulnerability in a Log4j component of an Apache server in communication received by this device
• Possible source of Log4j exploitation – detects a possible attempt to exploit the remote code execution vulnerability in the Log4j component of an Apache server in communication initiated from this device  
• Possible Log4j exploitation – detects multiple behaviors, including suspicious command launch post-exploitation
• Possible Log4j exploitation (CVE-2021-44228) – inactive, initially covered several of the above, now replaced with more specific titles

The following alerts detect activities that have been observed in attacks that utilize at least one of the Log4j vulnerabilities. However, these alerts can also indicate activity that is not related to the vulnerability. We are listing them here, as it is highly recommended that they are triaged and remediated immediately given their severity and the potential that they could be related to Log4j exploitation:

• Suspicious remote PowerShell execution 
• Download of file associated with digital currency mining 
• Process associated with digital currency mining 
• Cobalt Strike command and control detected 
• Suspicious network traffic connection to C2 Server 
• Ongoing hands-on-keyboard attacker activity detected (Cobalt Strike) 

Some of the alerts mentioned above utilize the enhanced network inspection capabilities in Microsoft Defender for Endpoint. These alerts correlate several network and endpoint signals into high-confidence detection of successful exploitation, as well as providing detailed evidence artifacts valuable for triage and investigation of detected activities.

Figure 14. Example detection leveraging network inspection provides details about the Java class returned following successful exploitation

Microsoft Defender for Cloud Apps (previously Microsoft Cloud App Security)

Microsoft 365 Defender detects exploitation patterns in different data sources, including cloud application traffic reported by Microsoft Defender for Cloud Apps. The following alert surfaces exploitation attempts via cloud applications that use vulnerable Log4j components:

• Log4j exploitation attempt via cloud application (previously titled Exploitation attempt against Log4j (CVE-2021-44228))

Figure 15. Microsoft 365 Defender alert “Exploitation attempt against Log4j (CVE-2021-44228)”

Microsoft Defender for Office 365

To add a layer of protection against exploits that may be delivered via email, Microsoft Defender for Office 365 flags suspicious emails (e.g., emails with the “jndi” string in email headers or the sender email address field), which are moved to the Junk folder.

We also added the following new alert, which detects attempts to exploit CVE-2021-44228 through email headers:

• Log4j exploitation attempt via email (previously titled Log4j Exploitation Attempt – Email Headers (CVE-2021-44228))

Figure 16. Sample alert on malicious sender display name found in email correspondence

This detection looks for exploitation attempts in email headers, such as the sender display name, sender, and recipient addresses. The alert covers known obfuscation attempts that have been observed in the wild. If this alert is surfaced, customers are recommended to evaluate the source address, email subject, and file attachments to get more context regarding the authenticity of the email.

Figure 17. Sample email with malicious sender display name

In addition, this email event as can be surfaced via advanced hunting:

Figure 18. Sample email event surfaced via advanced hunting

Microsoft 365 Defender advanced hunting queries

To locate possible exploitation activity, run the following queries:

Possible malicious indicators in cloud application events

This query is designed to flag exploitation attempts for cases where the attacker is sending the crafted exploitation string using vectors such as User-Agent, Application or Account name. The hits returned from this query are most likely unsuccessful attempts, however the results can be useful to identity attackers’ details such as IP address, Payload string, Download URL, etc.

CloudAppEvents
| where Timestamp > datetime("2021-12-09")
| where UserAgent contains "jndi:" 
or AccountDisplayName contains "jndi:"
or Application contains "jndi:"
or AdditionalFields contains "jndi:"
| project ActionType, ActivityType, Application, AccountDisplayName, IPAddress, UserAgent, AdditionalFields

Alerts related to Log4j vulnerability

This query looks for alert activity pertaining to the Log4j vulnerability.

AlertInfo
| where Title in~('Suspicious script launched',
'Exploitation attempt against Log4j (CVE-2021-44228)',
'Suspicious process executed by a network service',
'Possible target of Log4j exploitation (CVE-2021-44228)',
'Possible target of Log4j exploitation',
'Possible Log4j exploitation',
'Network connection seen in CVE-2021-44228 exploitation',
'Log4j exploitation detected',
'Possible exploitation of CVE-2021-44228',
'Possible target of Log4j vulnerability (CVE-2021-44228) scanning',
'Possible source of Log4j exploitation',
'Log4j exploitation attempt via cloud application', // Previously titled Exploitation attempt against Log4j
'Log4j exploitation attempt via email' // Previously titled Log4j Exploitation Attempt
)

Devices with Log4j vulnerability alerts and additional other alert-related context

This query surfaces devices with Log4j-related alerts and adds additional context from other alerts on the device.  

// Get any devices with Log4J related Alert Activity
let DevicesLog4JAlerts = AlertInfo
| where Title in~('Suspicious script launched',
'Exploitation attempt against Log4j (CVE-2021-44228)',
'Suspicious process executed by a network service',
'Possible target of Log4j exploitation (CVE-2021-44228)',
'Possible target of Log4j exploitation',
'Possible Log4j exploitation',
'Network connection seen in CVE-2021-44228 exploitation',
'Log4j exploitation detected',
'Possible exploitation of CVE-2021-44228',
'Possible target of Log4j vulnerability (CVE-2021-44228) scanning',
'Possible source of Log4j exploitation'
'Log4j exploitation attempt via cloud application', // Previously titled Exploitation attempt against Log4j
'Log4j exploitation attempt via email' // Previouskly titled Log4j Exploitation Attempt
)
// Join in evidence information
| join AlertEvidence on AlertId
| where DeviceId != ""
| summarize by DeviceId, Title;
// Get additional alert activity for each device
AlertEvidence
| where DeviceId in(DevicesLog4JAlerts)
// Add additional info
| join kind=leftouter AlertInfo on AlertId
| summarize DeviceAlerts = make_set(Title), AlertIDs = make_set(AlertId) by DeviceId, bin(Timestamp, 1d)

Suspected exploitation of Log4j vulnerability

This query looks for exploitation of the vulnerability using known parameters in the malicious string. It surfaces exploitation but may surface legitimate behavior in some environments.

DeviceProcessEvents
| where ProcessCommandLine has_all('${jndi') and ProcessCommandLine has_any('ldap', 'ldaps', 'http', 'rmi', 'dns', 'iiop')
//Removing FPs 
| where not(ProcessCommandLine has_any('stackstorm', 'homebrew')) 

Regex to identify malicious exploit string

This query looks for the malicious string needed to exploit this vulnerability.

DeviceProcessEvents
| where ProcessCommandLine matches regex @'(?i)\$\{jndi:(ldap|http|https|ldaps|dns|rmi|iiop):\/\/(\$\{([a-z]){1,20}:([a-z]){1,20}\})?(([a-zA-Z0-9]|-){2,100})?(\.([a-zA-Z0-9]|-){2,100})?\.([a-zA-Z0-9]|-){2,100}\.([a-z0-9]){2,20}(\/).*}'     
or InitiatingProcessCommandLine matches regex @'(?i)\$\{jndi:(ldap|http|https|ldaps|dns|rmi|iiop):\/\/(\$\{([a-z]){1,20}:([a-z]){1,20}\})?(([a-zA-Z0-9]|-){2,100})?(\.([a-zA-Z0-9]|-){2,100})?\.([a-zA-Z0-9]|-){2,100}\.([a-z0-9]){2,20}(\/).*}'

Suspicious process event creation from VMWare Horizon TomcatService

This query identifies anomalous child processes from the ws_TomcatService.exe process associated with the exploitation of the Log4j vulnerability in VMWare Horizon installations. These events warrant further investigation to determine if they are in fact related to a vulnerable Log4j application.

DeviceProcessEvents
| where InitiatingProcessFileName has "ws_TomcatService.exe"
| where FileName != "repadmin.exe"

Suspicious JScript staging comment

This query identifies a unique string present in malicious PowerShell commands attributed to threat actors exploiting vulnerable Log4j applications. These events warrant further investigation to determine if they are in fact related to a vulnerable Log4j application.

DeviceProcessEvents
| where FileName has "powershell.exe"
| where ProcessCommandLine has "VMBlastSG"

Suspicious PowerShell curl flags

This query identifies unique, uncommon PowerShell flags used by curl to post the results of an attacker-executed command back to the command-and-control infrastructure. If the event is a true positive, the contents of the “Body” argument are Base64-encoded results from an attacker-issued comment. These events warrant further investigation to determine if they are in fact related to a vulnerable Log4j application.

DeviceProcessEvents
| where FileName has "powershell.exe"
| where ProcessCommandLine has_all("-met", "POST", "-Body")

Microsoft Defender for Cloud

Microsoft Defender for Cloud’s threat detection capabilities have been expanded to surface exploitation of CVE-2021-44228 in several relevant security alerts:

On Windows:

• Detected obfuscated command line
• Suspicious use of PowerShell detected

On Linux:

• Suspicious file download
• Possible Cryptocoinminer download detected
• Process associated with digital currency mining detected
• Potential crypto coin miner started
• A history file has been cleared
• Suspicious Shell Script Detected
• Suspicious domain name reference
• Digital currency mining related behavior detected
• Behavior similar to common Linux bots detected

Microsoft Defender for IoT

Microsoft Defender for IoT has released a dedicated threat Intelligence update package for detecting Log4j 2 exploit attempts on the network (example below).  

Figure 19. Microsoft Defender for IoT alert 

The package is available for download from the Microsoft Defender for IoT portal (Click Updates, then Download file (MD5: 4fbc673742b9ca51a9721c682f404c41).  

Figure 20. Microsoft Defender for IoT sensor threat intelligence update

Microsoft Defender for IoT now pushes new threat intelligence packages to cloud-connected sensors upon release, click here for more information. Starting with sensor version 10.3, users can automatically receive up-to-date threat intelligence packages through Microsoft Defender for IoT.

Working with automatic updates reduces operational effort and ensures greater security. Enable automatic updating on the Defender for IoT portal by onboarding your cloud-connected sensor with the toggle for Automatic Threat Intelligence Updates turned on. For more information about threat intelligence packages in Defender for IoT, please refer to the documentation.

Microsoft Sentinel

A new Microsoft Sentinel solution has been added to the Content Hub that provides a central place to install Microsoft Sentinel specific content to monitor, detect, and investigate signals related to exploitation of the CVE-2021-44228 vulnerability.

Figure 21. Log4j Vulnerability Detection solution in Microsoft Sentinel

To deploy this solution, in the Microsoft Sentinel portal, select Content hub (Preview) under Content Management, then search for Log4j in the search bar. Select the Log4j vulnerability detection solution, and click Install. Learn how to centrally discover and deploy Microsoft Sentinel out-of-the-box content and solutions.

Figure 22. Microsoft Sentinel Analytics showing detected Log4j vulnerability

Note: We recommend that you check the solution for updates periodically, as new collateral may be added to this solution given the rapidly evolving situation. This can be verified on the main Content hub page.

Microsoft Sentinel queries

Microsoft Sentinel customers can use the following detection queries to look for this activity:

• Possible exploitation of Apache Log4j component detected

This hunting query looks for possible attempts to exploit a remote code execution vulnerability in the Log4j component of Apache. Attackers may attempt to launch arbitrary code by passing specific commands to a server, which are then logged and executed by the Log4j component.

• Cryptocurrency miners EXECVE

This query hunts through EXECVE syslog data generated by AUOMS to find instances of cryptocurrency miners being downloaded. It returns a table of suspicious command lines.

• Azure WAF Log4j CVE-2021-44228 hunting

This hunting query looks in Azure Web Application Firewall data to find possible exploitation attempts for CVE-2021-44228 involving Log4j vulnerability.

• Log4j vulnerability exploit aka Log4Shell IP IOC

This hunting query identifies a match across various data feeds for IP IOCs related to the Log4j exploit described in CVE-2021-44228.

• Suspicious shell script detected

This hunting query helps detect post-compromise suspicious shell scripts that attackers use for downloading and executing malicious files. This technique is often used by attackers and was recently used to exploit the vulnerability in Log4j component of Apache to evade detection and stay persistent or for more exploitation in the network.

• Azure WAF matching for CVE-2021-44228 Log4j vulnerability

This query alerts on a positive pattern match by Azure WAF for CVE-2021-44228 Log4j exploitation attempt. If possible, it then decodes the malicious command for further analysis.

• Suspicious Base64 download activity detected

This hunting query helps detect suspicious encoded Base64 obfuscated scripts that attackers use to encode payloads for downloading and executing malicious files. This technique is often used by attackers and was recently used to the Log4j vulnerability in order to evade detection and stay persistent in the network.

• Linux security-related process termination activity detected

This query alerts on attempts to terminate processes related to security monitoring. Attackers often try to terminate such processes post-compromise as seen recently to exploit the CVE-2021-44228 vulnerability.

• Suspicious manipulation of firewall detected via Syslog data

This query uses syslog data to alert on any suspicious manipulation of firewall to evade defenses. Attackers often perform such operations as seen recently to exploit the CVE-2021-44228 vulnerability for C2 communications or exfiltration.

• User agent search for Log4j exploitation attempt

This query uses various log sources having user agent data to look for CVE-2021-44228 exploitation attempt based on user agent pattern.

• Network connections to LDAP port for CVE-2021-44228 vulnerability

This hunting query looks for connection to LDAP port to find possible exploitation attempts for CVE-2021-44228.

• Linux toolkit detected

This query uses syslog data to alert on any attack toolkits associated with massive scanning or exploitation attempts against a known vulnerability

• Container miner activity

This query uses syslog data to alert on possible artifacts associated with containers running images related to digital cryptocurrency mining.

• Network connection to new external LDAP server

This query looks for outbound network connections using the LDAP protocol to external IP addresses, where that IP address has not had an LDAP network connection to it in the 14 days preceding the query timeframe. This could indicate someone exploiting a vulnerability such as CVE-2021-44228 to trigger the connection to a malicious LDAP server.

Azure Firewall Premium 

Customers using Azure Firewall Premium have enhanced protection from the Log4j RCE CVE-2021-44228 vulnerability and exploit. Azure Firewall premium IDPS (Intrusion Detection and Prevention System) provides IDPS inspection for all east-west traffic and outbound traffic to internet. The vulnerability rulesets are continuously updated and include CVE-2021-44228 vulnerability for different scenarios including UDP, TCP, HTTP/S protocols since December 10th, 2021. Below screenshot shows all the scenarios which are actively mitigated by Azure Firewall Premium.

Recommendation: Customers are recommended to configure Azure Firewall Premium with both IDPS Alert & Deny mode and TLS inspection enabled for proactive protection against CVE-2021-44228 exploit.  

Figure 23. Azure Firewall Premium portal

Customers using Azure Firewall Standard can migrate to Premium by following these directions. Customers new to Azure Firewall premium can learn more about Firewall Premium.

Azure Web Application Firewall (WAF)

In response to this threat, Azure Web Application Firewall (WAF) has updated Default Rule Set (DRS) versions 1.0/1.1 available for Azure Front Door global deployments, and OWASP ModSecurity Core Rule Set (CRS) version 3.0/3.1 available for Azure Application Gateway V2 regional deployments.

To help detect and mitigate the Log2Shell vulnerability by inspecting requests’ headers, URI, and body, we have released the following:

• For Azure Front Door deployments, we have updated the rule 944240 “Remote Command Execution” under Managed Rules
• For Azure Application Gateway V2 regional deployments, we have introduced a new rule Known-CVEs/800100 in the rule group Known-CVEs under Managed Rules

These rules are already enabled by default in block mode for all existing WAF Default Rule Set (DRS) 1.0/1.1 and OWASP ModSecurity Core Rule Set (CRS) 3.0/3.1 configurations. Customers using WAF Managed Rules would have already received enhanced protection for Log4j 2 vulnerabilities (CVE-2021-44228 and CVE-2021-45046); no additional action is needed.

Recommendation: Customers are recommended to enable WAF policy with Default Rule Set 1.0/1.1 on their Front Door deployments, or with OWASP ModSecurity Core Rule Set (CRS) versions 3.0/3.1 on Application Gateway V2 to immediately enable protection from this threat, if not already enabled. For customers who have already enabled DRS 1.0/1.1 or CRS 3.0/3.1, no action is needed. We will continue to monitor threat patterns and modify the above rule in response to emerging attack patterns as required.

Figure 24. Remote Code Execution rule for Default Rule Set (DRS) versions 1.0/1.1 

Figure 25. Remote Code Execution rule for OWASP ModSecurity Core Rule Set (CRS) version 3.1

Note: The above protection is also available on Default Rule Set (DRS) 2.0 preview version and OWASP ModSecurity Core Rule Set (CRS) 3.2 preview version, which are available on Azure Front Door Premium and Azure Application Gateway V2 respectively. Customers using Azure CDN Standard from Microsoft can also turn on the above protection by enabling DRS 1.0.

More information about Managed Rules and Default Rule Set (DRS) on Azure Web Application Firewall can be found here. More information about Managed Rules and OWASP ModSecurity Core Rule Set (CRS) on Azure Web Application Firewall can be found here.

Indicators of compromise (IOCs)

Microsoft Threat Intelligence Center (MSTIC) has provided a list of IOCs related to this attack and will update them with new indicators as they are discovered: https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Sample Data/Feeds/Log4j_IOC_List.csv

Microsoft will continue to monitor this dynamic situation and will update this blog as new threat intelligence and detections/mitigations become available.

Revision history

[01/21/2022] – Threat and vulnerability management can now discover vulnerable Log4j libraries, including Log4j files and other files containing Log4j, packaged into Uber-JAR files.

[01/19/2022] New information about an unrelated vulnerability we discovered while investigating Log4j attacks

[01/11/2022] New threat and vulnerability management capabilities to apply mitigation directly from the portal, as well as new advanced hunting queries

[01/10/2022] Added new information about a China-based ransomware operator targeting internet-facing systems and deploying the NightSky ransomware

[01/07/2022] Added a new rule group in Azure Web Application Firewall (WAF)

[12/27/2021] New capabilities in threat and vulnerability management including a new advanced hunting schema and support for Linux, which requires updating the Microsoft Defender for Linux client; new Microsoft Defender for Containers solution.

[12/22/2021] Added new protections across Microsoft 365 Defender, including Microsoft Defender for Office 365.

[12/21/2021] Added a note on testing services and assumed benign activity and additional guidance to use the Need help? button in the Microsoft 365 Defender portal.

[12/17/2021] New updates to observed activity, including more information about limited ransomware attacks and additional payloads; additional updates to protections from Microsoft 365 Defender and Azure Web Application Firewall (WAF), and new Microsoft Sentinel queries.

[12/16/2021] New Microsoft Sentinel solution and additional Microsoft Defender for Endpoint detections.

[12/15/2021] Details about ransomware attacks on non-Microsoft hosted Minecraft servers, as well as updates to product guidance, including threat and vulnerability management.

[12/14/2021] New insights about multiple threat actors taking advantage of this vulnerability, including nation-state actors and access brokers linked to ransomware.

The post Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability appeared first on Microsoft Security Blog.

Attack Simulation Training helps mitigate phishing risk

Microsoft has been working hard to understand these types of attacks and create solutions that help prevent, detect, and remediate vulnerability at the most basic point of attack: the user. Attack Simulation Training is one of those solutions. Attack Simulation Training is included in Microsoft Defender for Office 365 Plan 2 and E5 offerings and provides a behavior-based solution to mitigate phishing risk across your organization. It provides the necessary tools to run intelligent simulations and measure users for a baseline awareness of phishing risk, provide actionable insights and recommendations to remediate risk with hyper-targeted training designed to change behavior, and then measure behavioral progress against that benchmark through repeated simulation. This all happens straight from the Microsoft 365 Defender portal.

Attack Simulation Training was released as part of Microsoft Defender for Office 365 to ensure customers had a complete prevent, detect, investigate, and respond solution. Other offerings may only provide a portion of these capabilities. Microsoft Defender for Office 365 offers essential threat investigation and response capabilities to keep malicious communication from reaching users’ inboxes, and Attack Simulation Training provides the ability to test where vulnerabilities lie in your organization and reduce your phish risk score by educating users with a vast library of trainings. Together, both Microsoft Defender for Office 365 and Attack Simulation Training can prevent a future data compromise saving your organization time and unexpected costs.

Through Attack Simulation Training’s intelligent automation, you can target your simulations by setting custom criteria and creating tailored payloads to fit your business. Additionally, you can leverage hundreds of premade email payloads in the template library that were modeled on real phishing attempts. After you run simulations, you’ll get several training options of content by Terranova Security that includes a variety of tailored courses, micro learnings, and nano learnings available in over 20 different languages. If you haven’t already, try Attack Simulation Training and learn how to set up a new phish simulation in this two-part blog series.

Learn more

At Microsoft, we keep our customers top of mind when making product investment decisions. Since we announced Attack Simulation Training at Ignite in 2020, we have made significant investments to ensure our customers have the best email simulation and training platform for their businesses. Two key investment areas that the product team recently made were:

1. The ability for customers to access all the data that they have through Graph API reads. Learn more in our Tech Community blog post.
2. The ability for organizations to customize anything on the landing page and make it their own, including adding their own branding. Read our blog post here.

You can also read more about Attack Simulation Training’s new regional availability and access all the latest product updates in the Attack Simulation Training blog series.

Watch our overview video of Attack Simulation Training to get a better feel of the user interface and some of its key reporting and insights capabilities.

Try Attack Simulation Training straight from the Microsoft 365 Defender portal and learn how to get started today!

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.

¹HAFNIUM targeting Exchange Servers with 0-day exploits, Microsoft Threat Intelligence Center (MSTIC), Microsoft 365 Defender Threat Intelligence Team, Microsoft 365 Security, Microsoft. 2 March 2021.

²New sophisticated email-based attack from NOBELIUM, Microsoft Threat Intelligence Center (MSTIC), Microsoft 365 Defender Threat Intelligence Team, Microsoft. 27 May 2021.

The post Protect against phishing with Attack Simulation Training in Microsoft Defender for Office 365 appeared first on Microsoft Security Blog.

The aims of nation-state cyber actors—largely espionage and disruption—remain consistent, along with their most reliable tactics and techniques: credential harvesting, malware, and VPN exploits. However, a common theme this year among the actors originating from China, Russia, North Korea, and Iran has been increased targeting of IT service providers as a way of exploiting downstream customers.¹

Earlier this month, we published the 2021 Microsoft Digital Defense Report (MDDR), which provides more in-depth findings about Microsoft’s tracking of nation-state threat groups, including information on the most heavily targeted sectors and countries, specific threat actors, attack methods, and more. This blog captures the high-level themes from the MDDR, and we encourage you to download the full report for additional details.

Government agencies and non-governmental organizations are favored targets

Whenever an organization or individual account holder is targeted or compromised by observed nation-state activities, Microsoft delivers a nation-state notification (NSN) directly to that customer to give them the information they need to investigate the activity. Over the past three years, we’ve delivered over 20,500 NSNs. According to the analysis of the actor activity behind these NSNs, nation-state attacks in the past year have largely focused on operational objectives of espionage and intelligence collection rather than destructive attacks.

“Nation-state activity spans nearly every industry sector and geographic region. In other words, protections against these tactics are critical for every organization and individual.”—2021 Microsoft Digital Defense Report.

The Microsoft Threat Intelligence Center (MSTIC) and the Microsoft Digital Crimes Unit (DCU) have observed that nearly 80 percent of nation-state attacks were directed against government agencies, think tanks, and non-government organizations (NGOs). The nation-state groups we refer to as NOBELIUM, NICKEL, THALLIUM, and PHOSPHORUS were the most active against the government sector, targeting mostly government entities involved in international affairs.

Figure 1: Sectors targeted by nation-state attacks (July 2020 to June 2021).

Russia-based cyber attackers in particular have increasingly set their sights on government targets. Year-on-year comparisons of NSN data depict a marked increase in successful compromises, from a 21 percent success rate between July 2019 and June 2020, up to 32 percent since July 2020. In turn, the percentage of government organizations targeted by Russian threat actors exploded from roughly 3 percent last year, to 53 percent since July 2020 (see figure 3).

Most-targeted countries

The United States remained the most highly targeted country in the past year. Russia-based NOBELIUM also heavily targeted Ukraine, particularly focusing on government interests involved in rallying against a build-up of Russian troops along Ukraine’s border—driving the number of Ukrainian customers impacted from 6 last year to more than 1,200 this year. This past year also saw a near quadrupling in the targeting of Israeli entities, driven exclusively by Iranian actors as tensions escalated between the two countries.

Figure 2: Countries most targeted (July 2020 to June 2021).

Microsoft identifies nation-state activities by chemical element names, some of which are shown in the table below, along with their countries of origin. This small sample of the total nation-state actors tracked by Microsoft represents several of the most active in the last year.

Figure 3: Reference map for nation-state actors.

Volume versus precision

Rates of successful compromises varied widely among threat groups this year. Some, such as North Korea-based THALLIUM, had a low rate of successful compromise likely because their common tactic of large-scale spear-phishing campaigns has become easier to detect and deter as users become increasingly aware of these lures and organizations use security solutions to detect them more effectively. Russia-based NOBELIUM, in contrast, had more successful compromises as a result of their more targeted attack against software supply chains coupled with more high-volume password spray campaigns in pursuit of credential theft. Nation-state actors appear to be increasing the scale of these blunt attacks in an attempt to evade detection and improve their chances of a successful breach. The first fiscal quarter of 2020 (July to September) saw a proportionally higher compromise rate; not necessarily because threat actors were more successful, but because we saw fewer high-volume campaigns during this time.

Figure 4: Average rates of compromise (all tactics, July 2020 to June 2021).

Snapshot: Nation-state activity

Russia

Russia-based NOBELIUM proved how insidious software supply chain attacks can be with its devastating compromise of the SolarWinds Orion software update.² Although the group limited its follow-up exploitation to approximately 100 organizations, its backdoor malware was pushed to roughly 18,000 entities worldwide. In other incidents, NOBELIUM has employed password spray and phishing attacks to compromise third-party providers and facilitate future compromises. This threat actor targeted cloud solution providers (CSPs) and leveraged the backdoor to steal a Mimecast private key.³ Get the full account from world-class defenders on what it took to respond to the most advanced nation-state attack in history by watching the Decoding NOBELIUM docuseries.

China

Chinese nation-state threat actors have been targeting the United States political landscape for insight into policy shifts. In early March 2021, Microsoft blogged about HAFNIUM and the detection of multiple zero-day exploits used to attack on-premises versions of Microsoft Exchange Server. HAFNIUM operates primarily from leased virtual private servers in the United States and targets entities across a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs.

Iran

Iran continued its streak of destructive cyberattacks against regional adversaries, including a string of ransomware attacks against Israeli entities. Iran-linked threat actor RUBIDIUM has been implicated in the Pay2Key⁴ and N3tw0rm⁵ ransomware campaigns that targeted Israel in late 2020 and early 2021. A common element in Iranian nation-state cyberattacks was the targeting of Israeli logistics companies involved in maritime transportation. Despite Tehran’s less aggressive approach toward the United States in the wake of last year’s election, United States entities remained Iranian threat actors’ top target, comprising nearly half of the NSNs Microsoft delivered to cloud-service customers.

North Korea

Just over half the NSNs Microsoft issued were for North Korea-based state actors during the last three months of 2020. The majority of the North Korean targeting was directed at consumer account targets, based on the likelihood of obtaining non-publicly available diplomatic or geopolitical intelligence. As Microsoft reported in November 2020,  ZINC and CERIUM targeted pharmaceutical companies and vaccine researchers in several countries, probably to speed up North Korea’s own vaccine research. North Korea also continued to target financial companies with the intent of stealing cryptocurrency and intellectual property.⁶

Private sector actors supply the tools

Though not nation-state actors themselves, private sector offensive actors (PSOAs) create and sell malicious cyber technologies to nation-state buyers. PSOA tools have been observed targeting dissidents, human rights defenders, journalists, and other private citizens. In December 2020, Microsoft’s efforts to protect our customers led us to file an amicus brief in support of WhatsApp’s case against Israel-based NSO Group Technologies.⁷ The brief asks the court to reject NSO Group’s position that it’s not responsible for the use of its surveillance and espionage products by governments. Microsoft also worked with Citizen Lab to disable malware used by Israel-based PSOA, SOURGUM (aka Candiru), which created malware and zero-day exploits (fixed in CVE-2021-31979 and CVE-2021-33771) as a part of a hacking-as-a-service package sold to government agencies and other malicious actors.

Comprehensive protection starts with individuals

One thing is clear: nation-state actors are well-funded and employ techniques of tremendous breadth and sophistication. More than other adversaries, nation-state attackers will also target individuals specifically for access to their connections, communications, and information. These attackers are constantly refining their tactics and techniques; therefore, defense-in-depth strategies should include educating employees on how to avoid being targeted themselves. Most importantly, applying Zero Trust principles across corporate resources helps secure today’s mobile workforce—protecting people, devices, applications, and data no matter their location or the scale of threats faced.

Learn more

For a deep dive into our latest information on nation-state threats, download the 2021 Microsoft Digital Defense Report and watch the Decoding NOBELIUM docuseries. Also, look for more blog posts providing information for each themed week of Cybersecurity Awareness Month 2021. Read our latest posts:

• #BeCyberSmart: When we learn together, we’re more secure together
• How cyberattacks are changing according to new Microsoft Digital Defense Report
• Get career advice from 7 inspiring leaders in cybersecurity
• Defenders wanted—building the new cybersecurity professionals

Be sure to visit our Cybersecurity Awareness Month page for links to additional resources and information on protecting your organization year-round. Do your part. #BeCyberSmart

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.

¹Awareness Briefing: Chinese Cyber Activity Targeting Managed Service Providers, Cybersecurity Infrastructure Security Agency.

²A ‘Worst Nightmare’ Cyberattack: The Untold Story Of The SolarWinds Hack, Monika Estatieva, NPR. 16 April 2021.

³Mimecast attributes supply chain attack to SolarWinds’ hackers, David Jones, Cybersecurity Dive. 14 January 2021.

⁴Pay2Key Ransomware Joins the Threat Landscape, Tomas Meskauskas, Security Boulevard. 30 November 2020.

⁵N3TW0RM ransomware emerges in wave of cyberattacks in Israel, Lawrence Abrams, Bleeping Computer. 2 May 2021.

⁶North Korean hackers charged in massive cryptocurrency theft scheme, Dan Mangan, CNBC. 17 February 2021.

⁷Google, Cisco and VMware join Microsoft to oppose NSO Group in WhatsApp spyware case, Zack Whittaker, Tech Crunch. 21 December 2020.

The post Microsoft Digital Defense Report shares new insights on nation-state attacks appeared first on Microsoft Security Blog.

As businesses begin reimagining their future in a post-pandemic world, most are pivoting to a digital-first approach to take full advantage of technological innovation (much of which was adopted in haste). The pandemic has accelerated three existing trends and the tension between them: how to remain relevant against a backdrop of consumer and market demands, how to react and respond to evolving cyber threats, and how to do this reliably while reducing complexity and cost.

Becoming a resilient organization requires collaboration between business and security leaders and a lifecycle approach to continuous improvement.

Figure 1. The cyclical stages of an incident.

In this blog, we delve deeper into specific themes in recent cyberattack trends—how and why they work so effectively—and strategies to mitigate them.

On-premises vs. cloud security

As we’ve seen from the progression of headline-grabbing attacks over the course of this blog series, today’s attackers have choices. They can remain on-premises and have a better chance of lingering unseen in the complexity of multiple generations of legacy technology, or they can elevate privileges and move to the cloud, where there’s a higher risk of detection. In the most recent nation-state attack, HAFNIUM took the path of least resistance and targeted organizations through on-premises Microsoft Exchange Servers, leveraging a zero-day exploit to gain backdoor access to data centers. After Microsoft released critical out-of-band updates, attackers were quick to seek out and compromise unpatched servers in a race to take advantage of the situation before those doors were closed.

The Exchange attack illustrates challenges faced by companies in managing a complex hybrid of on-premises and cloud that spans many generations of technology. For many organizations, it can be a costly operation to upgrade systems; so, security teams are often asked to protect both old and new technology at the same time. Organizations need to simplify the management of this complex mix because attackers are always looking for vulnerabilities. The good news is that cloud security is no longer just for cloud resources; it’s extending to cover on-premises resources, up to and including the 50 to 100-year-old operational technology (OT) equipment that’s controlled by computer technology retrofitted 30 to 50 years ago.

Your security team can reduce risk by prioritizing the cloud as the preferred source of security technology. This will simplify adoption, reduce maintenance overhead, ensure the latest innovations and capabilities, and provide unified visibility and control across multiple generations of technology. No longer are we just referring to cloud security, but rather security delivered from the cloud.

Ransomware

Criminal organizations are increasingly relying on cybercrime as a high-reward, low-risk (illicit) line of business. However, it’s the evolution of human-operated ransomware that’s now driving the business need to address longstanding security hygiene and maintenance issues. Ransomware’s evolution can be traced to WannaCry and NotPetya malware, which fused large-scale compromise techniques with an encryption payload that demanded ransom payments in exchange for a decryption key. Sometime around June 2019, the new generation of human-operated ransomware started infecting systems, expanding into an enterprise-scale operation that blends targeted attacks and extortion.

What makes human-operated ransomware so dangerous? Unlike most cyber threats, these are not preprogrammed attacks. Human attackers know the weaknesses in your networks and how to exploit them. Attacks are multistage and opportunistic—they might gain access via remote desktop protocol (RDP) brute force or through banking trojans, then decide which networks are most profitable. Like nation-state attacks, these breaches can have dwell times lasting from minutes to months. Human operators may also deliver other malicious payloads, steal credentials, or exfiltrate data. Some known human-operated ransomware campaigns that Microsoft actively monitors include REvil, Samas, Bitpaymer, and Ryuk.

Figure 2: Human-operated ransomware—attack paths.

Human-operated ransomware is an extortion model that can use any one of multiple attack vectors. These attacks are often highly damaging and disruptive to an organization because of the combination of:

1. Broad access to business-critical assets: Attackers rapidly gain broad enterprise access and control through credential theft.
2. Disrupt business operations: The extortion business model requires inflicting the maximum pain on the organization (while still allowing recovery) in order to make paying the ransom attractive.

By denying access to business-critical data and systems across the enterprise, the attackers are more likely to profit, and organizations are more likely to suffer significant or material impact.

In the same way COVID-19 has shifted industry perceptions regarding bring-your-own-device (BYOD) policies and remote work, human-operated ransomware is poised to trigger seismic shifts in cybersecurity. Organizations who fail to prepare for these evolving threats face the prospect of performing mass restores of systems and data or paying the ransom (not recommended).

This is particularly true if they have any of these commonly held (and dangerous) false beliefs:

• Attackers aren’t interested in us because we’re just: a small organization, don’t have secrets, not a government, or other seemingly relevant characteristics.
• We are safe because we have firewalls.
• A password is good enough for admins; so multifactor authentication (MFA) can be deferred.
• Attackers won’t find unpatched VPNs and operating systems; so, maintenance can be deferred.
• We don’t apply security updates to internal systems like domain controllers to avoid impacting availability and performance.
• Security operations (SecOps) can manually write every alert and respond using a SIEM and a firewall; so, modernization with high-quality XDR detections and SOAR can be deferred.

If your organization is targeted, we strongly discourage paying any ransom, since this will incentivize future attacks. Also, there’s no guarantee that payment will get you the promised decryption key, or even that the attackers won’t sell your data on the dark web anyway. For a specific plan of how to address ransomware, see our downloadable Ransomware recommendations PowerPoint.

On the upside, having a business continuity and disaster recovery (BCDR) solution can provide a crucial safety net. Datto’s Global Ransomware Report 2020 indicates that three-out-of-four managed service providers (MSPs) report that clients with BCDR solutions recovered from a ransomware attack within 24 hours. However, just having a BCDR plan is not enough; you need an immutable backup that cannot be corrupted or deleted as attackers try to corrupt these backups.

This control needs to be implemented effectively across all generations of technology, including on-premises and in the cloud. Information protection and file encryption can also make data unreadable, even if exfiltrated.

Insider threats

Many data leaks can be attributed to accidents by insiders, but the risk posed by deliberate internal threats is on the rise as well—68 percent of organizations feel “moderately to extremely vulnerable” to all kinds of insider attacks. The same percentage confirms that insider attacks are becoming more frequent. Anyone who has access to an organization’s confidential data, IT, or network resources is a potential risk, whether they intend to do harm or not. This could include employees, consultants, vendors, former employees, business partners, or even a board member.

Recent examples include a former Amazon finance manager charged in a $1.4 million insider trading scheme, a Shopify data breach carried out by two employees, and an insider attack at Stradis Healthcare carried out by the former vice president of finance that “disrupted the delivery of personal protective equipment in the middle of a global pandemic.” Deliberate insider threats straddle both the physical and digital workspace, but organizations can protect themselves by looking for signs, including:

Digital warning signs

• Accessing data not associated with their job function.
• Using unauthorized storage devices.
• Network crawling and searches for sensitive data.
• Data hoarding or copying sensitive files.
• Emailing sensitive data outside the organization.

Behavioral warning signs

• Attempts to bypass security.
• Frequently in the office during off-hours.
• Displays disgruntled behavior.
• Violates corporate policies.
• Discusses resigning or new opportunities.

The key to preventing insider threats is to detect a violation before it happens. This means being empathetic to your organization’s changing environment and managing potential stressors that could lead to aberrant behavior. Being cognizant of employee wellbeing is not only in the best interests of your staff, it also drastically reduces the occurrence of insider threats for your organization. Microsoft invests in mitigating both accidental and deliberate insider threats with insider risk management, policy tips, and more.

Overcoming analyst fatigue

As the dust settles after the double-impact of the Nobelium and Hafnium attacks, we’re returning to a “normal baseline” of steadily increasing impact, volume, and sophistication of attacks. This lack of relief hits security professionals hardest, particularly analysts in security operations responding to these incidents.

The talented security professionals who silently bear the burden of attackers’ profit models often experience a high likelihood of burnout. According to PsyberResilience, the list of reasons for burnout among security professionals is long: fear of letting the organization down by missing that one threat amongst thousands every day; exhausting work schedules; fatigue from trying to keep up with new threats and technologies; the emotional toll of facing down criminals and witnessing their lack of morality.

Security teams need real help, and they need to feel supported and connected to the mission. Here are a few tips that can go a long way:

• Show your appreciation: The first minimum step for business leaders is to thank these hardworking people and get a basic understanding of what it’s like to experience these attacks from the ground level. Just as CEOs and business leaders should take time out to meet the people who make business operations work (like factory workers, truck drivers, nurses, doctors, cooks, engineers, and scientists), they should also do the same with security operations personnel to show the importance of the work to keep the organization safe every day.
• Enable automation and orchestration: This is critical to removing redundant, repetitive workflows or steps that burn up work hours and burn out employees. Azure Sentinel and Microsoft 365 Defender automate investigation and remediation tasks for many incidents, reducing the burden of repetitive work on analysts. Different security solutions in your enterprise need to see and share threat intelligence, driving a unified response across on-premises and multi-cloud environments.
• Bring in help: Many companies find it difficult to recruit and retain security professionals, especially organizations that have a smaller security team. Supplementing your team with experts from service providers can help you bring in top talent for the limited times you need them or help scale the experts you have by shifting high-volume frontline analyst work to the service provider.
• Take a collaborative approach: Reach out to peers in other industries to learn about their challenges. How do hospitals secure their patient data? How is cybersecurity done in retail operations, airlines, or government offices? Looking into different verticals might offer some new ideas and inspiration. An army of interconnected defenders provides more clarity and oversight than any single organization can maintain. For more technical information about how this works, learn about the community-based approach to information security.

Augmented intelligence and deepfakes

Using machine learning and automation has proven to be an incredible tool for defenders to detect and respond to threats faster. However, attackers also have access to similar technology and are leveraging this to their advantage. In another example of the cyber and physical worlds coming together, cybercriminals were able to create a near-perfect impersonation of a chief executive’s voice using deepfake technology—tricking the company into transferring $243,000 to their bank account. Attackers combined machine learning and AI with social engineering to convince people to move the money.

While still rare, AI and machine learning attacks like this are becoming more common. Attackers can make deepfake using public recordings of their target from earnings calls, interviews, and speeches, mimicking their mannerisms and using the technology as a kind of mask. Despite the advanced technology required for one of these attacks, the defense may be refreshingly straightforward and non-technical—if in doubt, call the person back. Using a secondary authentication for high-value transactions can also provide an additional secure step in the approval process, making it difficult for attackers to anticipate and fake out all of the channels at once.

With the use of AI and machine learning becoming more prolific in the defender’s kit bag, cybercriminals have also taken to attacking and poisoning the algorithms that are used to detect anomalies; often flooding the algorithm with data to skew results or generate false positives. In short, the human intelligence layer remains critical to providing contextual awareness and understanding of new cyber threats, helping to decipher the evolving tactics and techniques designed to evade detection.

Stay tuned

The next post in this series will focus on how your organization can pull all these concepts together into a security strategy that integrates with your business priorities, risk frameworks, and processes.

If you want to read ahead, you can check out the secure methodology in the cloud adoption framework.

Learn more

Read the previous blogs in this series:

• Becoming resilient by understanding cybersecurity risks: Part 1
• Becoming resilient by understanding cybersecurity risks: Part 2
• Becoming resilient by understanding cybersecurity risks: Part 3—a security pro’s perspective

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 Becoming resilient by understanding cybersecurity risks: Part 4—navigating current threats appeared first on Microsoft Security Blog.

Microsoft Defender for Endpoint received the highest possible scores in the control, data security, and mobile security criteria, as well as in the Zero Trust framework alignment and security community involvement criteria. Forrester also noted our “impact on endpoint is also notably low when actively running on the endpoint, and that the number of reported false positives by customers is also the lowest in this evaluation.”

As Vasu Jakkal, Corporate Vice President of Marketing for Security, Compliance, and Identity, states in her blog, we are operating in the most complex cybersecurity landscape we’ve ever seen and security has never been more important. It’s clearer than ever that a Zero Trust approach is critical to success. Our continued investments in extending Microsoft Defender for Endpoint’s industry-leading capabilities across non-Windows platforms, such as macOS, Linux, Android, and iOS, help customers get visibility into all endpoints accessing corporate data and apply the right controls necessary to minimize their growing attack surface. Our strengths in threat detection and integrated XDR approach across endpoints, email and collaboration, identities, and cloud apps further enable security teams’ ability to enable a true Zero Trust strategy.

Also critical to all of our success is the need to share and contribute to the security community so that all can be equipped to strengthen defenses and respond to attacks such as what we’ve seen with web shell attacks, NOBELIUM (Solorigate), and HAFNIUM. As we have seen in recent months, with attacks becoming more coordinated and sophisticated, community collaboration and sharing can help us all take the steps needed for a safer world.

Our continued leadership in security is due in part to the close partnership we have with customers who give us continuous feedback in the product development process. We are grateful for their continued trust in us and are committed to delivering innovative security capabilities that help them secure their organizations.

Microsoft Defender for Endpoint is seamlessly built into Microsoft 365 Defender, our solution offering XDR capabilities for identities, endpoints, cloud apps, email, and documents. Microsoft 365 Defender delivers intelligent, automated, and integrated security in a unified security operations (SecOps) experience, with detailed threat analytics and insights, unified threat hunting, and rapid detection and automation across domains—detecting and stopping attacks anywhere in the kill chain and eliminating persistent threats.

Our mission is to empower defenders with the best security capabilities in the industry so that you can focus on what’s important: preventing and remediating threats.

You can download The Forrester Wave™: Endpoint Security Software as a Service, Q2 2021 complimentary report to get more details about our position as a Leader. We thank our customers and partners for being on this journey with us.

Learn more

Microsoft Defender for Endpoint is an industry-leading, cloud-powered endpoint security solution offering vulnerability management, endpoint protection, endpoint detection and response, and mobile threat defense. With our solution, threats are no match. If you are not yet taking advantage of Microsoft’s unrivaled threat optics and proven capabilities, sign up for a free trial of Microsoft Defender for Endpoint today.

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 Forrester Wave™: Endpoint Security Software as a Service, Q2 2021, Chris Sherman, May 13, 2021.

This graphic was published by Forrester Research as part of a larger research document and should be evaluated in the context of the entire document. The Forrester document is available upon request here.

The post Microsoft is a Leader in the 2021 Forrester Endpoint Security Software as a Service Wave appeared first on Microsoft Security Blog.

Hackers launch an average of 50 million password attacks every day—579 per second. Phishing attacks have increased. Firmware attacks are on the rise, and ransomware has become incredibly problematic. And while Microsoft intercepted and thwarted a record-breaking 30 billion email threats last year, our work is never done.

We are now actively tracking 40 plus active nation-state actors and over 140 threat groups representing 20 countries—that number used to be a handful.

We are also rapidly delivering innovation to meet the needs of a changing landscape and you can read more about our latest product updates for RSA in a blog I published today.

Security continues to be a number one priority for our customers, especially as many companies around the world are looking to transition from remote work to hybrid. To truly meet this challenge, defenders across the industry must come together for an end-to-end, Zero Trust security approach that covers the entire technology ecosystem. Because today, digital transformation cannot happen without security transformation.

The future of work is hybrid: Here’s what we can do

Even as many people start to transition back to the office, we expect a future where hybrid work is the norm. Forrester predicts that once people have settled into their new work patterns post-pandemic, we will still see a 300 percent increase in employees working remotely from pre-pandemic levels. According to our own Work Trend Index, The Next Great Disruption is Hybrid Work—Are We Ready?, 46 percent of people plan to move because they can now work remotely.

People are working on corporate networks and home networks and moving fluidly between business and personal activity online thanks to technologies intertwined with both aspects of our daily routines. The network is changing with employees’ home networks and devices are now part of the corporate network. What this means for organizations is that the network is suddenly without firm borders.

Our own approach

My friend and colleague Bret Arsenault, Microsoft’s Chief Information Security Officer, had the mammoth task of transitioning Microsoft and its 160,000 plus employees to remote work in March 2020 and has created our technology plan to transition to hybrid work.

Bret’s approach to solving this has been to foster a culture where security is everyone’s job. Just today, new guidance went out on a few areas:

• Keeping devices healthy and managed: All devices that need access to corporate resources must be managed to seamlessly keep your device secure and protected from phishing and malicious websites.
• Making security everyone’s job: We will offer new training, opportunities to provide feedback, and a new virtual security summit to ensure our employees are empowered and equipped to be more secure.
• Securing home offices: We will continue to build and offer resources and guidelines for employees that will work remotely either part or full time.
• Building for Zero Trust: We are asking our developers to build with a Zero Trust mentality.

While we have been remote, and as part of our Zero Trust approach, we have also been moving employees off the corporate network. An internet-first approach reduces exposure and gives employees a consistent experience whether they are at home or in the office.

We believe that security is a team sport and that when we share what we’re learning, we can all make the world a safer place. So we are sharing Bret’s guidance with our customers and partners. These specific steps will be the first of many in ensuring our hybrid workforce is as secure as possible.

There are other practical things that we will continue to focus on, and every business should consider as we move into hybrid work.

Identity is more important than ever: Use the tools you likely already have to protect it

Through NOBELIUM and other recent attacks, a clear theme has emerged—identity is the battleground for attacks of the future. We know weak passwords, password spraying, and phishing are the entry point for the vast majority of attacks. As our own CISO, Bret Arsenault, likes to say, “hackers don’t break in, they log in.”

In building a defense for our new threat landscape, the first thing every business should do is examine the tools they already have.

A great example of this is multifactor authentication (MFA). MFA is a defense that our customers have available to them, yet when looking at our own customer data, only 18 percent have it turned on. Any customer with a commercial service subscription—Azure or Microsoft 365—can turn on MFA at no additional cost.

We saw a significant jump in usage when the pandemic began. And when that happened, we saw a significant decrease in aggregate compromises—people thought they were activating to protect only remote access, but MFA protects the entire network.

We work with many kinds of organizations of all sizes—for some, implementing MFA is as easy as flipping the switch. But we understand and empathize that for others it’s much more complex. We’re actively working to make MFA rollout easier and more seamless for our customers, as well as ensuring that the end-user experience is as frictionless and friendly as possible. We are dedicated to working alongside our customers to make everyone more secure. We’ve introduced a number of programs to drive MFA adoption—from the introduction of security defaults to giving customers an entire toolset for internal communications.

Embrace a Zero Trust mindset

In a world where identity is the new battleground, adopting a Zero Trust strategy is no longer an option, it’s a new business imperative. People and organizations need to have trust in the technologies that bring them together. The term Zero Trust may feel like the opposite of that, but when you assume breach and provide the least privileged access necessary, it actually empowers employees with the flexibility and freedom they want.

The hybrid world is largely perimeterless, so wrapping protections around identity and devices is critical. As part of Zero Trust, we also think the future is passwordless and we will start to see that transition this year.

In fact, to help our customers on their Zero Trust journey we are excited to roll out a new Zero Trust assessment tool today that can help companies understand where they are currently and where they need to go.

For a deeper look at the imperatives around Zero Trust and how Microsoft is reimagining the concept of identity for a perimeterless world, read Joy Chik’s blog, 5 identity priorities for 2021—strengthening security for the hybrid work era and beyond, from Microsoft Ignite.

Take advantage of more robust security in the cloud

The benefits of the cloud for a remote or hybrid workforce are plentiful. Business-critical information can be accessed over the network, making it easy to have workers in any location.

Over the next 6 to 12 months, we will see rapid migration to the cloud, as companies recover from 2020 and implement new infrastructure. In a recent survey of our Microsoft Intelligent Security Association (MISA) partners, 90 percent reported that customers have accelerated their move to the cloud due to the pandemic.

Having a strong cloud posture also provides a level of security that most companies just couldn’t achieve on their own. And we learned from NOBELIUM that the vast majority of attacks originated on-premises, while attacks via the cloud were largely unsuccessful.

Invest in people and skills—and focus on diversity

We know that attackers exploit not just our digital holes, but the holes in our defender teams. Right now, we have two big problems: a shortage of cybersecurity professionals and a lack of diversity within teams. In the coming year, attackers will find these gaps and take advantage.

There is an estimated shortfall of 3.5 million security professionals this year—91 percent of our MISA partners report more demand than supply for cybersecurity professionals. This shortage can mean not only unfilled positions but also too much work on the shoulders of existing teams.

How do we solve this? We build the workforce of the future. We teach, train, and arm new defenders. After all, anyone can be a superhero of cybersecurity. It just takes passion and purpose—and some skilling.

I firmly believe anyone can be a defender, and with the proper training programs, we can all work together to build a cybersecurity workforce that reflects our planet. We must build diverse teams that reflect the many viewpoints of people globally, including the same demographics as the attackers themselves, to meet the security and privacy challenges of our time.

That’s why we’re pleased to offer new skilling programs and certifications across security, compliance, and identity. There are programs available for all levels of expertise, no matter where a defender is on their journey.

Fortunately, in a future where remote work is more common, the world is our oyster in terms of cultivating new and diverse talent. No longer constrained by physical office locations, it’s an exciting time to find the next generation of defenders and help them develop.

What’s next

We’re emerging from a year that has altered the world forever. It changed the way we live and work, brought new challenges in cybersecurity, and reminded all of us that there is no playbook for change.

But where there’s uncertainty, there is also the power to shape the world in positive and profound ways. At the heart of security and privacy protection is the freedom to imagine, plan, empower, and inspire.

As security professionals, it is within our superpowers to help people and organizations feel safe and be safe—to help them persist in the face of adversity with optimism, empathy, and peace of mind.

Learn more

Learn more about Microsoft’s approach to securing hybrid work, including context from our CISO Bret Arsenault, as well as a link to his new podcast Security Unlocked.

You can also assess your Zero Trust maturity stage to determine where your organization is and how to move to the next stage.

To learn more about Microsoft security solutions and how to optimize your Zero Trust strategy, 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 Securing a new world of hybrid work: What to know and what to do appeared first on Microsoft Security Blog.

As organizations recover from this incident, we continue to publish guidance and share threat intelligence to help detect and evict threat actors from affected environments. Today, we are sharing intelligence about what some attackers did after exploiting the vulnerable servers, ranging from ransomware to data exfiltration and deployment of various second-stage payloads. This blog covers:

• Threat intelligence and technical details about known attacks, including components and attack paths, that defenders can use to investigate whether on-premises Exchange servers were compromised before they were patched and to comprehensively respond to and remediate these threats if they see them in their environments.
• Detection and automatic remediation built into Microsoft Defender Antivirus and how investigation and remediation capabilities in solutions like Microsoft Defender for Endpoint can help responders perform additional hunting and remediate threats.

Although the overall numbers of ransomware have remained extremely small to this point, it is important to remember that these threats show how quickly attackers can pivot their campaigns to take advantage of newly disclosed vulnerabilities and target unpatched systems, demonstrating how critical it is for organizations to apply security updates as soon as possible. We strongly urge organizations to identify and update vulnerable on-premises Exchange servers, and to follow mitigation and investigation guidance that we have collected and continue to update here: https://aka.ms/ExchangeVulns.

Mitigating post-exploitation activities

The first known attacks leveraging the Exchange Server vulnerabilities were by the nation-state actor HAFNIUM, which we detailed in this blog. In the three weeks after the Exchange server vulnerabilities were disclosed and the security updates were released, Microsoft saw numerous other attackers adopting the exploit into their toolkits. Attackers are known to rapidly work to reverse engineer patches and develop exploits. In the case of a remote code execution (RCE) vulnerability, the rewards are high for attackers who can gain access before an organization patches, as patching a system does not necessarily remove the access of the attacker.

Figure 1. The Exchange Server exploit chain

In our investigation of the on-premises Exchange Server attacks , we saw systems being affected by multiple threats. Many of the compromised systems have not yet received a secondary action, such as human-operated ransomware attacks or data exfiltration, indicating attackers could be establishing and keeping their access for potential later actions. These actions might involve performing follow-on attacks via persistence on Exchange servers they have already compromised, or using credentials and data stolen during these attacks to compromise networks through other entry vectors.

Attackers who included the exploit in their toolkits, whether through modifying public proof of concept exploits or their own research, capitalized on their window of opportunity to gain access to as many systems as they could. Some attackers were advanced enough to remove other attackers from the systems and use multiple persistence points to maintain access to a network.

We have built protections against these threats into Microsoft security solutions. Refer to the Appendix for a list of indicators of compromise, detection details, and advanced hunting queries. We have also provided additional tools and investigation and remediation guidance here: https://aka.ms/exchange-customer-guidance.

While performing a full investigation on systems is recommended, the following themes are common in many of the attacks. These are prevailing threat trends that Microsoft has been monitoring, and existing solutions and recommendations for prevention and mitigation apply:

• Web shells – As of this writing, many of the unpatched systems we observed had multiple web shells on them. Microsoft has been tracking the rise of web shell attacks for the past few years, ensuring our products detect these threats and providing remediation guidance for customers. For more info on web shells, read Web shell attacks continue to rise. We have also published guidance on web shell threat hunting with Azure Sentinel.
• Human-operated ransomware – Ransomware attacks pose some of the biggest security risks for organizations today, and attackers behind these attacks were quick to take advantage of the on-premises Exchange Server vulnerabilities. Successfully exploiting the vulnerabilities gives attackers the ability to launch human-operated ransomware campaigns, a trend that Microsoft has been closely monitoring. For more information about human-operated ransomware attacks, including Microsoft solutions and guidance for improving defenses, read: Human-operated ransomware attacks.
• Credential theft – While credential theft is not the immediate goal of some of these attacks, access to Exchange servers allowed attackers to access and potentially steal credentials present on the system. Attackers can use these stolen credentials for follow-on attacks later, so organizations need to prioritize identifying and remediating impacted identities. For more information, read best practices for building credential hygiene.

In the following sections, we share our analysis of known post-compromise activities associated with exploitation of the Exchange server vulnerabilities because it is helpful to understand these TTPs, in order to defend against other actors using similar tactics or tools. While levels of disruptive post-compromise activity like ransomware may be limited at the time of this writing, Microsoft will continue to track this space and share information with the community. It’s important to note that with some post-compromise techniques, attackers may gain highly privileged persistent access, but many of the impactful subsequent attacker activities can be mitigated by practicing the principle of least privilege and mitigating lateral movement.

DoejoCrypt ransomware

DoejoCrypt was the first ransomware to appear to take advantage of the vulnerabilities, starting to encrypt in limited numbers shortly after the patches were released. Ransomware attackers often use multiple tools and exploits to gain initial access, including purchasing access through a broker or “reseller” who sells access to systems they have already compromised. The DoejoCrypt attacks start with a variant of the Chopper web shell being deployed to the Exchange server post-exploitation.

The web shell writes a batch file to C:\Windows\Temp\xx.bat. Found on all systems that received the DoejoCrypt ransomware payload, this batch file performs a backup of the Security Account Manager (SAM) database and the System and Security registry hives, allowing the attackers later access to passwords of local users on the system and, more critically, in the LSA Secrets portion of the registry, where passwords for services and scheduled tasks are stored.

Figure 2. xx.bat

Given configurations that administrators typically use on Exchange servers, many of the compromised systems are likely to have had at least one service or scheduled task configured with a highly privileged account to perform actions like backups. As service account credentials are not frequently changed, this could provide a great advantage to an attacker even if they lose their initial web shell access due to an antivirus detection, as the account can be used to elevate privileges later, which is why we strongly recommend operating under the principle of least privileged access.

The batch file saves the registry hives to a semi-unique location, C:\windows\temp\debugsms, assembles them into a CAB file for exfiltration, and then cleans up the folders from the system. The file also enables Windows Remote Management and sets up an HTTP listener, indicating the attacker might take advantage of the internet-facing nature of an Exchange Server and use this method for later access if other tools are removed.

Figure 3. xx.bat actions

The xx.bat file has been run on many more systems than have been ransomed by the DoejoCrypt attacker, meaning that, while not all systems have moved to the ransom stage, the attacker has gained access to multiple credentials. On systems where the attacker moved to the ransom stage, we saw reconnaissance commands being run via the same web shell that dopped the xx.bat file (in this instance, a version of Chopper):

Figure 4. DoejoCrypt recon command

After these commands are completed, the web shell drops a new payload to C:\Windows\Help which, like in many human-operated ransomware campaigns, leads to the attack framework Cobalt Strike. In observed instances, the downloaded payload is shellcode with the file name new443.exe or Direct_Load.exe. When run, this payload injects itself into notepad.exe and reaches out to a C2 to download Cobalt Strike shellcode.

Figure 5. DoejoCrypt ransomware attack chain

During the hands-on-keyboard stage of the attack, a new payload is downloaded to C:\Windows\Help with names like s1.exe and s2.exe. This payload is the DoejoCrypt ransomware, which uses a .CRYPT extension for the newly encrypted files and a very basic readme.txt ransom note. In some instances, the time between xx.bat being dropped and a ransomware payload running was under half an hour.

Figure 6. DoejoCrypt ransom note

While the DoejoCrypt payload is the most visible outcome of the attackers’ actions, the access to credentials they have gained could serve them for future campaigns if organizations do not reset credentials on compromised systems. An additional overlapping activity observed on systems where xx.bat was present and the attackers were able to get Domain Administrator rights was the running of scripts to snapshot Active Directory with ntdsutil—an action that, if executed successfully, could give the attackers access to all the passwords in Active Directory from a single compromised system.

Lemon Duck botnet

Cryptocurrency miners were some of the first payloads we observed being dropped by attackers from the post-exploit web shells. In the first few days after the security updates were released, we observed multiple cryptocurrency miner campaigns, which had been previously targeting SharePoint servers, add Exchange Server exploitation to their repertoire. Most of these coin miners were variations on XMRig miners, and many arrived via a multi-featured implant with the capability to download new payloads or even move laterally.

Lemon Duck, a known cryptocurrency botnet named for a variable in its code, dove into the Exchange exploit action, adopting different exploit styles and choosing to use a fileless/web shell-less option of direct PowerShell commands from w3wp (the IIS worker process) for some attacks. While still maintaining their normal email-based campaigns, the Lemon Duck operators compromised numerous Exchange servers and moved in the direction of being more of a malware loader than a simple miner.

Using a form of the attack that allows direct execution of commands versus dropping a web shell, the Lemon Duck operators ran standard Invoke Expression commands to download a payload. Having used the same C2 and download servers for some time, the operators applied a varied degree of obfuscation to their commands on execution.

Fig 7. Example executions of Lemon Duck payload downloads

The Lemon Duck payload is an encoded and obfuscated PowerShell script. It first removes various security products from the system, then creates scheduled tasks and WMI Event subscription for persistence. A second script is downloaded to attempt to evade Microsoft Defender Antivirus, abusing their administrative access to run the Set-MPPreference command to disable real-time monitoring (a tactic that Microsoft Defender Tamper protection blocks) and add scanning exclusions for the C:\ drive and the PowerShell process.

Figure 8. Lemon Duck payloads

One randomly named scheduled task connects to a C2 every hour to download a new payload, which includes various lateral movement and credential theft tools. The operators were seen to download RATs and information stealers, including Ramnit payloads.

Figure 9. Lemon Duck post-exploitation activities

In some instances, the operators took advantage of having compromised mail servers to access mailboxes and send emails containing the Lemon Duck payload using various colorful email subjects.

Figure 10. Email subjects of possibly malicious emails

Figure 11. Attachment variables

In one notable example, the Lemon Duck operators compromised a system that already had xx.bat and a web shell. After establishing persistence on the system in a non-web shell method, the Lemon Duck operators were observed cleaning up other attackers’ presence on the system and mitigating the CVE-2021-26855 (SSRF) vulnerability using a legitimate cleanup script that they hosted on their own malicious server. This action prevents further exploitation of the server and removes web shells, giving Lemon Duck exclusive access to the compromised server. This stresses the need to fully investigate systems that were exposed, even if they have been fully patched and mitigated, per traditional incident response process.

Pydomer ransomware

While DoejoCrypt was a new ransomware payload, the access gained by attackers via the on-premises Exchange Server vulnerabilities will likely become part of the complex cybercriminal economy where additional ransomware operators and affiliates take advantage of it. The first existing ransomware family to capitalize on the vulnerabilities was Pydomer. This ransomware family was previously seen using vulnerabilities in attacks, notably taking advantage of Pulse Secure VPN vulnerabilities, for which Pulse Secure has released security patches, to steal credentials and perform ransomware attacks.

In this campaign, the operators scanned and mass-compromised unpatched Exchange Servers to drop a web shell. They started later than some other attackers, with many compromises occurring between March 18 and March 20, a window when fewer unpatched systems were available. They then dropped a web shell, with a notable file name format: “Chack[Word][Country abbreviation]”:

Figure 12. Example web shell names observed being used by the Pydomer attackers

These web shells were observed on around 1,500 systems, not all of which moved to the ransomware stage. The attackers then used their web shell to dump a test.bat batch file that performed a similar function in the attack chain to the xx.bat of the DoejoCrypt operators and allowed them to perform a dump of the LSASS process.

Figure 13. Pydomer post-exploitation activities

This access alone would be valuable to attackers for later attacks, similar to the credentials gained during their use of Pulse Secure VPN vulnerabilities. The highly privileged credentials gained from an Exchange system are likely to contain domain administrator accounts and service accounts with backup privileges, meaning these attackers could perform ransomware and exfiltration actions against the networks they compromised long after the Exchange Server is patched and even enter via different means.

On systems where the attackers did move to second-stage ransomware operations, they utilized a Python script compiled to an executable and the Python cryptography libraries to encrypt files. The attackers then executed a PowerShell script via their web shell that acts as a downloader and distribution mechanism for the ransomware.

Figure 14. PowerShell downloader and spreader used to get the Pydomer payload

The script fetches a payload from a site hosted on a domain generation algorithm (DGA) domain, and attempts to spread the payload throughout the network, first attempting to spread the payload over WMI using Invoke-WMIMethod to attempt to connect to systems, and falling back to PowerShell remoting with Enter-PSSession if that fails. The script is run within the context of the web shell, which in most instances is Local System, so this lateral movement strategy is unlikely to work except in organizations that are running highly insecure and unrecommended configurations like having computer objects in highly privileged groups.

The Pydomer ransomware is a Python script compiled to an executable and uses the Python cryptography libraries to encrypt files. The ransomware encrypts the files and appends a random extension, and then drops a ransom note named decrypt_file.TxT.

Figure 15. Pydomer ransom note

Interestingly, the attackers seem to have deployed a non-encryption extortion strategy. Following well-known ransomware groups like Maze and Egregor which leaked data for pay, the Pydomer hackers dropped an alternative readme.txt onto systems without encrypting files. This option might have been semi-automated on their part or a side effect of a failure in their encryption process, as some of the systems they accessed were test systems that showed no data exfiltration. The note should be taken seriously if encountered, as the attackers had full access to systems and were likely able to exfiltrate data.

Figure 16. Pydomer extortion readme.txt

Credential theft, turf wars, and dogged persistence

If a server is not running in a least-privilege configuration, credential theft could provide a significant return on investment for an attacker beyond their initial access to email and data. Many organizations have backup agent software and scheduled tasks running on these systems with domain admin-level permissions. For these organizations, the attackers might be able to harvest highly privileged credentials without lateral movement, for example, using the COM services DLL as a living-off-the-land binary to perform a dump of the LSASS process:

Figure 17. Use of COM services DLL to dump LSASS process

The number of observed credential theft attacks, combined with high privilege of accounts often given to Exchange servers, means that these attacks could continue to impact organizations that don’t fully remediate after a compromise even after patches have been applied. While the observed ransomware attempts were small-scale or had errors, there is still the possibility of more skillful groups utilizing credentials gained in these attacks for later attacks.

Attackers also used their access to perform extensive reconnaissance using built-in Exchange commandlets and dsquery to exfiltrate information about network configurations, user information, and email assets.

While Lemon Duck operators might have had the boldest method for removing other attackers from the systems they compromised, they were not the only attacker to do so. Others were observed cleaning up .aspx and .bat files to remove other attackers, and even rebuilding the WMI database by deleting .mof files and restarting the service. As the window on unpatched machines closes, attackers showed increased interest in maintaining the access to the systems they exploited. By utilizing “malwareless” persistence mechanisms like enabling RDP, installing Shadow IT tools, and adding new local administrator accounts, the attackers are hoping to evade incident response efforts that might focus exclusively on web shells, AV scans, and patching.

Defending against exploits and post-compromise activities

Attackers exploit the on-premises Exchange Server vulnerabilities in combination to bypass authentication and gain the ability to write files and run malicious code. The best and most complete remediation for these vulnerabilities is to update to a supported Cumulative Update and to install all security updates. Comprehensive mitigation guidance can be found here: https://aka.ms/ExchangeVulns.

As seen in the post-exploitation attacks discussed in this blog, the paths that attackers can take after successfully exploiting the vulnerabilities are varied and wide-ranging. If you have determined or have reason to suspect that these threats are present on your network, here are immediate steps you can take:

• Investigate exposed Exchange servers for compromise, regardless of their current patch status.
• Look for web shells via our guidance and run a full AV scan using the Exchange On-Premises Mitigation Tool.
• Investigate Local Users and Groups, even non-administrative users for changes, and ensure all users require a password for sign-in. New user account creations (represented by Event ID 4720) during the time the system was vulnerable might indicate a malicious user creation.
• Reset and randomize local administrator passwords with a tool like LAPS if you are not already doing so.
• Look for changes to the RDP, firewall, WMI subscriptions, and Windows Remote Management (WinRM) configuration of the system that might have been configured by the attacker to allow persistence.
• Look for Event ID 1102 to determine if attackers cleared event logs, an activity that attackers perform with exe in an attempt to hide their tracks.
• Look for new persistence mechanisms such as unexpected services, scheduled tasks, and startup items.
• Look for Shadow IT tools that attackers might have installed for persistence, such as non-Microsoft RDP and remote access clients.
• Check mailbox-level email forwarding settings (both ForwardingAddress and ForwardingSMTPAddress attributes), check mailbox inbox rules (which might be used to forward email externally), and check Exchange Transport rules that you might not recognize.

While our response tools check for and remove known web shells and attack tools, performing a full investigation of these systems is recommended. For comprehensive investigation and mitigation guidance and tools, see https://aka.ms/exchange-customer-guidance.

Additionally, here are best practices for building credential hygiene and practicing the principle of least privilege:

• Follow guidance to run Exchange in least-privilege configuration: https://adsecurity.org/?p=4119.
• Ensure service accounts and scheduled tasks run with the least privileges they need. Avoid widely privileged groups like domain admins and backup operators and prefer accounts with access to just the systems they need.
• Randomize local administrator passwords to prevent lateral movement with tools like LAPS.
• Ensure administrators practice good administration habits like Privileged Admin Workstations.
• Prevent privileged accounts like domain admins from signing into member servers and workstations using Group Policy to limit credential exposure and lateral movement.

Appendix

Microsoft Defender for Endpoint detection details

Antivirus                                                                                                                                   

Microsoft Defender Antivirus detects exploitation behavior with these detections:

• Behavior:Win32/Exmann
• Behavior:Win32/IISExchgSpawnEMS
• Exploit:ASP/CVE-2021-27065
• Exploit:Script/Exmann
• Trojan:Win32/IISExchgSpawnCMD
• Behavior:Win32/IISExchgDropWebshell

Web shells are detected as:

• Backdoor:JS/Webshell
• Backdoor:PHP/Chopper
• Backdoor:ASP/Chopper
• Backdoor:MSIL/Chopper
• Trojan:JS/Chopper
• Trojan:Win32/Chopper
• Behavior:Win32/WebShellTerminal

Ransomware payloads and associated files are detected as:

• Trojan:BAT/Wenam – xx.bat behaviors
• Ransom:Win32/DoejoCrypt – DoejoCrypt ransomware
• Trojan:PowerShell/Redearps – PowerShell spreader in Pydomer attacks
• Ransom:Win64/Pydomer – Pydomer ransomware

Lemon Duck malware is detected as:

• Trojan:PowerShell/LemonDuck
• Trojan:Win32/LemonDuck

Some of the credential theft techniques highlighted in this report are detected as:

• Behavior:Win32/DumpLsass
• Behavior:Win32/RegistryExfil

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate threat activity on your network:

• Suspicious Exchange UM process creation
• Suspicious Exchange UM file creation
• Suspicious w3wp.exe activity in Exchange
• Possible exploitation of Exchange Server vulnerabilities
• Possible IIS web shell
• Possible web shell installation
• Web shells associated with Exchange Server vulnerabilities
• Network traffic associated with Exchange Server exploitation

Alerts with the following titles in the security center can indicate threat activity on your network specific to the DoejoCrypt and Pydomer ransomware campaign:

• DoejoCrypt ransomware
• Pydomer ransomware
• Pydomer download site

Alerts with the following titles in the security center can indicate threat activity on your network specific to the Lemon Duck botnet:

• LemonDuck Malware
• LemonDuck botnet C2 domain activity

The following behavioral alerts might also indicate threat activity associated with this threat:

• Possible web shell installation
• A suspicious web script was created
• Suspicious processes indicative of a web shell
• Suspicious file attribute change
• Suspicious PowerShell command line
• Possible IIS Web Shell
• Process memory dump
• A malicious PowerShell Cmdlet was invoked on the machine
• WDigest configuration change
• Sensitive information lookup
• Suspicious registry export

Advanced hunting

To locate possible exploitation activities in Microsoft Defender for Endpoint, run the following queries.

Processes run by the IIS worker process

Look for processes executed by the IIS worker process

// Broadly search for processes executed by the IIS worker process. Further investigation should be performed on any devices where the created process is indicative of reconnaissance
DeviceProcessEvents
| where InitiatingProcessFileName == 'w3wp.exe'
| where InitiatingProcessCommandLine contains "MSExchange"
| where FileName !in~ ("csc.exe","cvtres.exe","conhost.exe","OleConverter.exe","wermgr.exe","WerFault.exe","TranscodingService.exe")
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Search for PowerShell spawned from the IIS worker process, observed most frequently in Lemon Duck with Base64 encoding to obfuscate C2 domains

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where InitiatingProcessFileName =~ "w3wp.exe"
| where InitiatingProcessCommandLine contains "MSExchange"
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Tampering

Search for Lemon Duck tampering with Microsoft Defender Antivirus

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("Set-MpPreference", "DisableRealtimeMonitoring", "Add-MpPreference", "ExclusionProcess")
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Batch script actions

Search for batch scripts performing credential theft, as observed in DoejoCrypt infections

DeviceProcessEvents
| where InitiatingProcessFileName == "cmd.exe"
| where InitiatingProcessCommandLine has ".bat" and InitiatingProcessCommandLine has @"C:\Windows\Temp"
| where ProcessCommandLine has "reg save"
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Look for evidence of batch script execution that leads to credential dumping

// Search for batch script execution, leading to credential dumping using rundll32 and the COM Services DLL, dsquery, and makecab use
DeviceProcessEvents
| where InitiatingProcessFileName =~ "cmd.exe"
| where InitiatingProcessCommandLine has ".bat" and InitiatingProcessCommandLine has @"\inetpub\wwwroot\aspnet_client\"
| where InitiatingProcessParentFileName has "w3wp"
| where FileName != "conhost.exe"
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Suspicious files dropped under an aspnet_client folder

Look for dropped suspicious files like web shells and other components

// Search for suspicious files, including but not limited to batch scripts and web shells, dropped under the file path C:\inetpub\wwwroot\aspnet_client\
DeviceFileEvents
| where InitiatingProcessFileName == "w3wp.exe"
| where FolderPath has "\\aspnet_client\\"
| where InitiatingProcessCommandLine contains "MSExchange"
| project FileName, FolderPath, InitiatingProcessCommandLine, DeviceId, Timestamp

Checking for persistence on systems that have been suspected as compromised

Search for creations of new local accounts

DeviceProcessEvents
| where FileName == "net.exe"
| where ProcessCommandLine has_all ("user", "add")
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Search for installation events that were used to download ScreenConnect for persistence

Note that this query may be noisy and is not necessarily indicative of malicious activity alone.

DeviceProcessEvents
| where FileName =~ "msiexec.exe"
| where ProcessCommandLine has @"C:\Windows\Temp\"
| parse-where kind=regex flags=i ProcessCommandLine with @"C:\\Windows\\Temp\\" filename:string @".msi"
| project filename, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Hunting for credential theft

Search for logon events related to services and scheduled tasks on devices that may be Exchange servers. The results of this query should be used to verify whether any of these users have privileged roles that might have enabled further persistence.

let devices =
DeviceProcessEvents
| where InitiatingProcessFileName == "w3wp.exe" and InitiatingProcessCommandLine contains "MSExchange"
| distinct DeviceId;
//
DeviceLogonEvents
| where DeviceId in (devices)
| where LogonType in ("Batch", "Service")
| project AccountName, AccountDomain, LogonType, DeviceId, Timestamp

Search for WDigest registry key modification, which allows for the LSASS process to store plaintext passwords.

DeviceRegistryEvents
| where RegistryValueName == "UseLogonCredential"
| where RegistryKey has "WDigest" and RegistryValueData == "1"
| project PreviousRegistryValueData, RegistryValueData, RegistryKey, RegistryValueName, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Search for the COM services DLL being executed by rundll32, which can be used to dump LSASS memory.

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("rundll32.exe", "comsvcs.dll")
| project FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Search for Security Account Manager (SAM) or SECURITY databases being saved, from which credentials can later be extracted.

DeviceProcessEvents
| where FileName == "reg.exe"
| where ProcessCommandLine has "save" and ProcessCommandLine has_any ("hklm\\security", "hklm\\sam")
| project InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Indicators

Selected indicators from attacks are included here, the threats may utilize files and network indicators not represented here.

Files (SHA-256)

The following are file hashes for some of the web shells observed during attacks:

• 201e4e9910dcdc8c4ffad84b60b328978db8848d265c0b9ba8473cf65dcd0c41
• 2f0bc81c2ea269643cae307239124d1b6479847867b1adfe9ae712a1d5ef135e
• 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
• 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
• 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
• 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
• 8e90ed33c7ee82c0b64078ea36ec95f7420ba435c693b3b3dd728b494abf7dfc
• a291305f181e24fe7194154b4cd355ccb039d5765709c80999e392efec69c90a
• b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
• dd29e8d47dde124c7d14e614e03ccaab3ecaa50e0a0bef985ed59e98928bc13d

DoejoCrypt associated hashes:

• 027119161d11ba87acc908a1d284b93a6bcafccc012e52ce390ecb9cd745bf27
• 10bce0ff6597f347c3cca8363b7c81a8bff52d2ff81245cd1e66a6e11aeb25da
• 2b9838da7edb0decd32b086e47a31e8f5733b5981ad8247a2f9508e232589bff
• 904fbea2cd68383f32c5bc630d2227601dc52f94790fe7a6a7b6d44bfd904ff3
• bf53b637683f9cbf92b0dd6c97742787adfbc12497811d458177fdeeae9ec748
• e044d9f2d0f1260c3f4a543a1e67f33fcac265be114a1b135fd575b860d2b8c6
• fdec933ca1dd1387d970eeea32ce5d1f87940dfb6a403ab5fc149813726cbd65
• feb3e6d30ba573ba23f3bd1291ca173b7879706d1fe039c34d53a4fdcdf33ede

Lemon Duck associated hashes:

• 0993cc228a74381773a3bb0aa36a736f5c41075fa3201bdef4215a8704e582fc
• 3df23c003d62c35bd6da90df12826c1d3fdd94029bf52449ba3d89920110d5ec
• 4f0b9c0482595eee6d9ece0705867b2aae9e4ff68210f32b7425caca763723b9
• 56101ab0881a6a34513a949afb5a204cad06fd1034f37d6791f3ab31486ba56c
• 69ce57932c3be3374e8843602df1c93e1af622fc53f3f1d9b0a75b66230a1e2e
• 737752588f32e4c1d8d20231d7ec553a1bd4a0a090b06b2a1835efa08f9707c4
• 893ddf0de722f345b675fd1ade93ee1de6f1cad034004f9165a696a4a4758c3e
• 9cf63310788e97f6e08598309cbbf19960162123e344df017b066ca8fcbed719
• 9f2fe33b1c7230ec583d7f6ad3135abcc41b5330fa5b468b1c998380d20916cd
• a70931ebb1ce4f4e7d331141ad9eba8f16f98da1b079021eeba875aff4aeaa85
• d8b5eaae03098bead91ff620656b9cfc569e5ac1befd0f55aee4cdb39e832b09
• db093418921aae00187ae5dc6ed141c83614e6a4ec33b7bd5262b7be0e9df2cd
• dc612f5c0b115b5a13bdb9e86f89c5bfe232e5eb76a07c3c0a6d949f80af89fd
• f517526fc57eb33edb832920b1678d52ad1c5cf9c707859551fe065727587501
• f8d388f502403f63a95c9879c806e6799efff609001701eed409a8d33e55da2f
• fbeefca700f84373509fd729579ad7ea0dabdfe25848f44b2fbf61bf7f909df0

Pydomer associated hashes:

• 7e07b6addf2f0d26eb17f4a1be1cba11ca8779b0677cedc30dbebef77ccba382
• 866b1f5c5edd9f01c5ba84d02e94ae7c1f9b2196af380eed1917e8fc21acbbdc
• 910fbfa8ef4ad7183c1b5bdd3c9fd1380e617ca0042b428873c48f71ddc857db
• a387c3c5776ee1b61018eeb3408fa7fa7490915146078d65b95621315e8b4287
• b9dbdf11da3630f464b8daace88e11c374a642e5082850e9f10a1b09d69ff04f
• c25a5c14269c990c94a4a20443c4eb266318200e4d7927c163e0eaec4ede780a
• c4aa94c73a50b2deca0401f97e4202337e522be3df629b3ef91e706488b64908

Network indicators

Domains abused by Lemon Duck:

• down[.]sqlnetcat[.]com
• t[.]sqlnetcat[.]com
• t[.]netcatkit[.]com

Pydomer DGA network indicators:

• uiiuui[.]com/search/*
• yuuuuu43[.]com/vpn-service/*
• yuuuuu44[.]com/vpn-service/*
• yuuuuu46[.]com/search/*

The post Analyzing attacks taking advantage of the Exchange Server vulnerabilities appeared first on Microsoft Security Blog.

Update [03/15/2021]: Microsoft released a new one-click mitigation tool, the Microsoft Exchange On-Premises Mitigation Tool, to help customers who do not have dedicated security or IT teams to apply security updates for Microsoft Exchange Server. 

Update [03/08/2021]: Microsoft continues to see multiple actors taking advantage of unpatched systems to attack organizations with on-premises Exchange Server. To aid defenders in investigating these attacks where Microsoft security products and tooling may not be deployed, we are releasing a feed of observed indicators of compromise (IOCs). The feed of malware hashes and known malicious file paths observed in related attacks is available in both JSON and CSV formats at the below GitHub links. This information is being shared as TLP:WHITE: CSV format | JSON format

Update [03/05/2021]: Microsoft sees increased use of these vulnerabilities in attacks targeting unpatched systems by multiple malicious actors beyond HAFNIUM. To aid customers in investigating these attacks, Microsoft Security Response Center (MSRC) has provided additional resources, including new mitigation guidance: Microsoft Exchange Server Vulnerabilities Mitigations – March 2021

Update [03/04/2021]: The Exchange Server team released a script for checking HAFNIUM indicators of compromise (IOCs). See Scan Exchange log files for indicators of compromise.

Microsoft has detected multiple 0-day exploits being used to attack on-premises versions of Microsoft Exchange Server in limited and targeted attacks. In the attacks observed, the threat actor used these vulnerabilities to access on-premises Exchange servers which enabled access to email accounts, and allowed installation of additional malware to facilitate long-term access to victim environments. Microsoft Threat Intelligence Center (MSTIC) attributes this campaign with high confidence to HAFNIUM, a group assessed to be state-sponsored and operating out of China, based on observed victimology, tactics and procedures.

The vulnerabilities recently being exploited were CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065, all of which were addressed in today’s Microsoft Security Response Center (MSRC) release – Multiple Security Updates Released for Exchange Server. We strongly urge customers to update on-premises systems immediately. Exchange Online is not affected. We have established a resource center that is constantly updated as more information becomes available at https://aka.ms/ExchangeVulns.

We are sharing this information with our customers and the security community to emphasize the critical nature of these vulnerabilities and the importance of patching all affected systems immediately to protect against these exploits and prevent future abuse across the ecosystem. This blog also continues our mission to shine a light on malicious actors and elevate awareness of the sophisticated tactics and techniques used to target our customers. The related IOCs, Azure Sentinel advanced hunting queries, and Microsoft Defender for Endpoint product detections and queries shared in this blog will help SOCs proactively hunt for related activity in their environments and elevate any alerts for remediation.

Microsoft would like to thank our industry colleagues at Volexity and Dubex for reporting different parts of the attack chain and their collaboration in the investigation. Volexity has also published a blog post with their analysis. It is this level of proactive communication and intelligence sharing that allows the community to come together to get ahead of attacks before they spread and improve security for all.

Who is HAFNIUM?

HAFNIUM primarily targets entities in the United States across a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs.

HAFNIUM has previously compromised victims by exploiting vulnerabilities in internet-facing servers, and has used legitimate open-source frameworks, like Covenant, for command and control. Once they’ve gained access to a victim network, HAFNIUM typically exfiltrates data to file sharing sites like MEGA.

In campaigns unrelated to these vulnerabilities, Microsoft has observed HAFNIUM interacting with victim Office 365 tenants. While they are often unsuccessful in compromising customer accounts, this reconnaissance activity helps the adversary identify more details about their targets’ environments.

HAFNIUM operates primarily from leased virtual private servers (VPS) in the United States.

Technical details

Microsoft is providing the following details to help our customers understand the techniques used by HAFNIUM to exploit these vulnerabilities and enable more effective defense against any future attacks against unpatched systems.

CVE-2021-26855 is a server-side request forgery (SSRF) vulnerability in Exchange which allowed the attacker to send arbitrary HTTP requests and authenticate as the Exchange server.

CVE-2021-26857 is an insecure deserialization vulnerability in the Unified Messaging service. Insecure deserialization is where untrusted user-controllable data is deserialized by a program. Exploiting this vulnerability gave HAFNIUM the ability to run code as SYSTEM on the Exchange server. This requires administrator permission or another vulnerability to exploit.

CVE-2021-26858 is a post-authentication arbitrary file write vulnerability in Exchange. If HAFNIUM could authenticate with the Exchange server then they could use this vulnerability to write a file to any path on the server. They could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate admin’s credentials.

CVE-2021-27065 is a post-authentication arbitrary file write vulnerability in Exchange. If HAFNIUM could authenticate with the Exchange server then they could use this vulnerability to write a file to any path on the server. They could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate admin’s credentials.

Attack details

After exploiting these vulnerabilities to gain initial access, HAFNIUM operators deployed web shells on the compromised server. Web shells potentially allow attackers to steal data and perform additional malicious actions that lead to further compromise. One example of a web shell deployed by HAFNIUM, written in ASP, is below:

Following web shell deployment, HAFNIUM operators performed the following post-exploitation activity:

• Using Procdump to dump the LSASS process memory:

• Using 7-Zip to compress stolen data into ZIP files for exfiltration:

• Adding and using Exchange PowerShell snap-ins to export mailbox data:

• Using the Nishang Invoke-PowerShellTcpOneLine reverse shell:

• Downloading PowerCat from GitHub, then using it to open a connection to a remote server:

HAFNIUM operators were also able to download the Exchange offline address book from compromised systems, which contains information about an organization and its users.

Our blog, Defending Exchange servers under attack, offers advice for improving defenses against Exchange server compromise. Customers can also find additional guidance about web shell attacks in our blog Web shell attacks continue to rise.

Can I determine if I have been compromised by this activity?

The below sections provide indicators of compromise (IOCs), detection guidance, and advanced hunting queries to help customers investigate this activity using Exchange server logs, Azure Sentinel, Microsoft Defender for Endpoint, and Microsoft 365 Defender. We encourage our customers to conduct investigations and implement proactive detections to identify possible prior campaigns and prevent future campaigns that may target their systems.

Check patch levels of Exchange Server

The Microsoft Exchange Server team has published a blog post on these new Security Updates providing a script to get a quick inventory of the patch-level status of on-premises Exchange servers and answer some basic questions around installation of these patches.

Scan Exchange log files for indicators of compromise

The Exchange Server team has created a script to run a check for HAFNIUM IOCs to address performance and memory concerns. That script is available here: https://github.com/microsoft/CSS-Exchange/tree/main/Security.

• CVE-2021-26855 exploitation can be detected via the following Exchange HttpProxy logs:
  • These logs are located in the following directory: %PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\HttpProxy
  • Exploitation can be identified by searching for log entries where the AuthenticatedUser is empty and the AnchorMailbox contains the pattern of ServerInfo~*/*
    • Here is an example PowerShell command to find these log entries:

Import-Csv -Path (Get-ChildItem -Recurse -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy" -Filter '*.log').FullName | Where-Object { $_.AnchorMailbox -like 'ServerInfo~*/*' -or $_.BackEndCookie -like 'Server~*/*~*'} | select DateTime, AnchorMailbox, UrlStem, RoutingHint, ErrorCode, TargetServerVersion, BackEndCookie, GenericInfo, GenericErrors, UrlHost, Protocol, Method, RoutingType, AuthenticationType, ServerHostName, HttpStatus, BackEndStatus, UserAgent

• • If activity is detected, the logs specific to the application specified in the AnchorMailbox path can be used to help determine what actions were taken.
    • These logs are located in the %PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging directory.
• CVE-2021-26858 exploitation can be detected via the Exchange log files:
  • C:\Program Files\Microsoft\Exchange Server\V15\Logging\OABGeneratorLog
  • Files should only be downloaded to the %PROGRAMFILES%\Microsoft\Exchange Server\V15\ClientAccess\OAB\Temp directory
    • In case of exploitation, files are downloaded to other directories (UNC or local paths)
  • Windows command to search for potential exploitation:

findstr /snip /c:"Download failed and temporary file" "%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\OABGeneratorLog\*.log"

• CVE-2021-26857 exploitation can be detected via the Windows Application event logs
  • Exploitation of this deserialization bug will create Application events with the following properties:
    • Source: MSExchange Unified Messaging
    • EntryType: Error
    • Event Message Contains: System.InvalidCastException
  • Following is PowerShell command to query the Application Event Log for these log entries:

Get-EventLog -LogName Application -Source "MSExchange Unified Messaging" -EntryType Error | Where-Object { $_.Message -like "*System.InvalidCastException*" }

• CVE-2021-27065 exploitation can be detected via the following Exchange log files:
  • C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server

All Set-<AppName>VirtualDirectory properties should never contain script. InternalUrl and ExternalUrl should only be valid Uris.

• • Following is a PowerShell command to search for potential exploitation:

Select-String -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\ECP\Server\*.log" -Pattern 'Set-.+VirtualDirectory'

Host IOCs

Microsoft is releasing a feed of observed indicators of compromise (IOCs) in related attacks. This feed is available in both CSV and JSON formats. This information is being shared as TLP:WHITE.

Hashes

Web shell hashes

• b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
• 097549cf7d0f76f0d99edf8b2d91c60977fd6a96e4b8c3c94b0b1733dc026d3e
• 2b6f1ebb2208e93ade4a6424555d6a8341fd6d9f60c25e44afe11008f5c1aad1
• 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
• 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
• 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
• 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
• 1631a90eb5395c4e19c7dbcbf611bbe6444ff312eb7937e286e4637cb9e72944

Paths

We observed web shells in the following paths:

• C:\inetpub\wwwroot\aspnet_client\
• C:\inetpub\wwwroot\aspnet_client\system_web\
• In Microsoft Exchange Server installation paths such as:
  • %PROGRAMFILES%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\
  • C:\Exchange\FrontEnd\HttpProxy\owa\auth\

The web shells we detected had the following file names:

• web.aspx
• help.aspx
• document.aspx
• errorEE.aspx
• errorEEE.aspx
• errorEW.aspx
• errorFF.aspx
• healthcheck.aspx
• aspnet_www.aspx
• aspnet_client.aspx
• xx.aspx
• shell.aspx
• aspnet_iisstart.aspx
• one.aspx

 Check for suspicious .zip, .rar, and .7z files in C:\ProgramData\, which may indicate possible data exfiltration.

Customers should monitor these paths for LSASS dumps:

• C:\windows\temp\
• C:\root\

Tools

• Procdump
• Nishang
• PowerCat

Many of the following detections are for post-breach techniques used by HAFNIUM. So while these help detect some of the specific current attacks that Microsoft has observed it remains very important to apply the recently released updates for CVE-2021-26855, CVE-2021-26857, CVE-2021-27065 and CVE-2021-26858.

Microsoft Defender Antivirus detections

Please note that some of these detections are generic detections and not unique to this campaign or these exploits.

• Exploit:Script/Exmann.A!dha
• Behavior:Win32/Exmann.A
• Backdoor:ASP/SecChecker.A
• Backdoor:JS/Webshell (not unique)
• Trojan:JS/Chopper!dha (not unique)
• Behavior:Win32/DumpLsass.A!attk (not unique)
• Backdoor:HTML/TwoFaceVar.B (not unique)

Microsoft Defender for Endpoint detections

• Suspicious Exchange UM process creation
• Suspicious Exchange UM file creation
• Possible web shell installation (not unique)
• Process memory dump (not unique)

Azure Sentinel detections

• HAFNIUM Suspicious Exchange Request
• HAFNIUM UM Service writing suspicious file
• HAFNIUM New UM Service Child Process
• HAFNIUM Suspicious UM Service Errors
• HAFNIUM Suspicious File Downloads

Advanced hunting queries

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 and Azure Sentinel:

Microsoft Defender for Endpoint advanced hunting queries

Microsoft 365 Defender customers can find related hunting queries below or at this GitHub location: https://github.com/microsoft/Microsoft-365-Defender-Hunting-Queries/

Additional queries and information are available via Threat Analytics portal for Microsoft Defender customers.

UMWorkerProcess.exe in Exchange creating abnormal content

Look for Microsoft Exchange Server’s Unified Messaging service creating non-standard content on disk, which could indicate web shells or other malicious content, suggesting exploitation of CVE-2021-26858 vulnerability:

DeviceFileEvents | where InitiatingProcessFileName == "UMWorkerProcess.exe" | where FileName != "CacheCleanup.bin" | where FileName !endswith ".txt" | where FileName !endswith ".LOG" | where FileName !endswith ".cfg" | where FileName != "cleanup.bin"

UMWorkerProcess.exe spawning

Look for Microsoft Exchange Server’s Unified Messaging service spawning abnormal subprocesses, suggesting exploitation of CVE-2021-26857 vulnerability:

DeviceProcessEvents | where InitiatingProcessFileName == "UMWorkerProcess.exe" | where FileName != "wermgr.exe" | where FileName != "WerFault.exe"

Please note excessive spawning of wermgr.exe and WerFault.exe could be an indicator of compromise due to the service crashing during deserialization.

Azure Sentinel advanced hunting queries

Azure Sentinel customers can find a Sentinel query containing these indicators in the Azure Sentinel Portal or at this GitHub location: https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/.

Look for Nishang Invoke-PowerShellTcpOneLine in Windows Event Logging:

SecurityEvent  | where EventID == 4688  | where Process has_any ("powershell.exe", "PowerShell_ISE.exe")  | where CommandLine has "$client = New-Object System.Net.Sockets.TCPClient"

Look for downloads of PowerCat in cmd and Powershell command line logging in Windows Event Logs:

SecurityEvent  | where EventID == 4688  | where Process has_any ("cmd.exe", "powershell.exe", "PowerShell_ISE.exe")  | where CommandLine has "https://raw.githubusercontent.com/besimorhino/powercat/master/powercat.ps1"

Look for Exchange PowerShell Snapin being loaded. This can be used to export mailbox data, subsequent command lines should be inspected to verify usage:

SecurityEvent  | where EventID == 4688  | where Process has_any ("cmd.exe", "powershell.exe", "PowerShell_ISE.exe")  | where isnotempty(CommandLine)  | where CommandLine contains "Add-PSSnapin Microsoft.Exchange.Powershell.Snapin"  | summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Computer, Account, CommandLine

The post HAFNIUM targeting Exchange Servers with 0-day exploits appeared first on Microsoft Security Blog.