Microsoft Defender Antivirus is using this integration to detect and block XLM-based malware, and we encourage other antivirus products to use this open interface to gain better visibility and improve protections against these threats.

XLM macros is a legacy macro language that was made available to Microsoft Excel in 1992, prior to the introduction of Visual Basic for Applications (VBA) in 1993. While more rudimentary than VBA, XLM is powerful enough to provide interoperability with the operating system, and many organizations and users continue to use its functionality for legitimate purposes. Cybercriminals know this, and they have been abusing XLM macros, increasingly more frequently, to call Win32 APIs and run shell commands.

The AMSI instrumentation for VBA has been providing deep visibility into the runtime behavior of VBA macros. Its release in 2018 effectively removed the armor that macro-obfuscation equipped malware with, exposing malicious code to improved levels of scrutiny. Naturally, threat actors like those behind Trickbot, Zloader, and Ursnif have looked elsewhere for features to abuse and operate under the radar of security solutions, and they found a suitable alternative in XLM.

Like VBA and many other scripting languages abused by malware, XLM code can be obfuscated relatively easily to conceal the real intent of the macro. For example, attackers can hide URLs or file names of executable files from static inspection through simple strings manipulations. Attackers also take advantage of the way macro code persists within the Excel document—while VBA macros are stored in a dedicated OLE stream (and hence can be easily located and extracted), XLM macros do not exist as a separate, well-defined entity. Rather, each XLM macro statement is a formula within a cell. Extracting a whole XLM macro can become a cumbersome task, requiring a cell-by-cell inspection of the whole document.

Figure 1. Sample malicious XLM macro

In addition, while formulas are typically executed downwards starting from the top, with XLM the macro content can be quite spread out, thanks to control flow statements like RUN, CALL, or GOTO, which allow the switching of execution flow from one column to another. This feature, together with obfuscation, has been abused by attackers to craft documents that could evade static analysis.

AMSI instrumentation for Excel 4.0 (XLM) macros

AMSI is an open interface that allows any application to request the scanning of any data at any time. In a nutshell, this technology provides applications the capability to interface with the installed antivirus solution in order to inspect and scan potentially dangerous data (e.g., a file downloaded from a remote location, or data generated dynamically by an application). Microsoft already utilizes this technology in various applications to detect malicious macros, script-based malware, and other threats:

• Office VBA macros
• JScript
• VBScript
• PowerShell
• WMI
• Dynamically loaded .NET assemblies
• MSHTA/Jscript9

The data provided by AMSI is leveraged extensively by Microsoft Defender for Endpoint. It provides important data for machine learning models that process billions of signals every day to identify and block malicious behaviors. The XLM instrumentation is similar to the implementation in VBA and other scripting engines that integrate with AMSI:

Figure 2. AMSI instrumentation for XLM

The XLM language allows a user to write programs that call native runtime functions, as well as external Win32 APIs. In both cases, the interfaces that dispatch the calls to these functions are intercepted and directed to an internal logger. The logger component stores the intercepted functions in text format within a circular buffer. When certain dangerous functions are called, for example the runtime function EXEC or the Win32 API ShellExecute, XLM halts the macro execution and invokes AMSI to request a synchronous scan of the circular buffer containing the functions logged up to that point. Such dangerous functions are called “trigger functions”. If the antivirus identifies the macro as malware, the execution of the macro is aborted and Excel is safely terminated, blocking the attack and preventing the malicious macro from doing any damage. Otherwise, the user experience continues seamlessly.

It’s important to observe that the interception of XLM function calls happens at runtime. This means that the logger component always registers the true behavior of all functions and associated parameters, which may contain URLs, file names, and other important IOCs, regardless of the obfuscation used by the malware.

The following is an example of an XLM macro found in a malicious document:

Figure 3. Sample XLM macro

This malicious macro consists of a series of commands (e.g., RUN, REGISTER, IF, etc.) with related parameters specified by references to other cells. For example, the token $CA$1889 passed to the first function RUN indicates that the string provided as parameter for this function is in the cell at column CA and row 1889.

This is only one of the many ways that XLM-based malware can obfuscate code. Detecting this macro is challenging because it doesn’t expose any suspicious strings or behavior. This is where the power of AMSI comes into play: the instrumentation allows XLM to inspect functions when they are invoked, so that all their parameters have already been de-obfuscated. As a result, the above macro produces a log that looks like the following:

Figure 4. Sample log

The XLM engine determines that the dangerous function ShellExecuteA is being invoked, and subsequently places the macro execution on hold and passes the macro behavioral log to AMSI for scanning. The antivirus now has visibility into a behavioral log that completely exposes all of the data including, API names, URLs, and file names. The log makes it easy to conclude that this macro is trying to download and execute a DLL payload via the tool Rundll32.

Case study: ZLoader campaign

ZLoader is a malware family that has been actively perpetrating financial theft for several years. Like many of its peers, ZLoader operates via aggressive campaigns that rely on social engineering and the abuse of Office documents spread via email.

We have been monitoring the activity of this threat and observed that in the last year the attackers shifted to XLM as their infection vector of choice. The Excel documents have a typical lure message to trick the user into clicking “Enable Content” to allow the macro code to run.

Figure 5. Malicious Excel file used in Zloader campaign

A closer look at the document reveals an Excel sheet with an obscure-looking name. That sheet embeds XLM macro formulas, which are stored several rows down to make the sheet look empty. Furthermore, the macro formulas are spread out and obfuscated, hindering static analysis and raising more challenges for identifying intent.

Figure 6. Malicious XLM macro used in ZLoader campaign

Executing and debugging the macro with Excel is not very straightforward either. The macro has long loops that are used to decode and run further obfuscated macro formulas, and the Excel’s debugger doesn’t have the ability to control the execution in a granular way in order to skip loops and break on specific formulas.

However, when this macro runs with the AMSI instrumentation enabled, it produces up to three different logs that are passed to AMSI. The first two look like the following:

Figure 7. Log produced when ZLoader’s XLM macro is run

The image only shows the final part of the log where the interesting activity shows up. We can see that the macro is issuing a new EXEC statement to run a .vbs file via explorer.exe. This EXEC statement causes the execution of the VBScript named EW2H.vbs, which has been decoded and saved to disk by the macro prior to the EXEC line. The VBScript then tries to download and run a binary payload. The macro attempts to do this twice, hence this log (with minor variations) is passed to AMSI twice.

If the above steps fail, the macro resorts to downloading the payload directly, producing the following log for AMSI:

Figure 8. Log produced when ZLoader’s XLM macro is run

The macro defines two URLs, then downloads their content with the API URLDownloadToFileA, and finally invokes the API ShellExecuteA to launch the downloaded payload (the file jxi09.txt) via rundll32.exe. We can infer from this line that the payload is a DLL.

All three logs offer plenty of opportunities to detect malicious behavior and also allow the easy extraction of relevant IOCs like URLs, file names, etc. The initial XLM code in the Excel document is completely obfuscated and contains no usable information, making it tricky to issue static detections that are both effective and durable. With the dynamic nature of AMSI, the runtime behavior can be observed in cleartext, even with obfuscation. Detections based on the logs passed to AMSI also have the advantage of being more robust and generic in nature.

Availability

Runtime inspection of XLM macros is now available in Microsoft Excel and can be used by antivirus solutions like Microsoft Defender Antivirus that are registered as an AMSI provider on the device. This feature is included as an addition to the existing AMSI integration with Office. It’s enabled by default on the February Current Channel and Monthly Enterprise Channel for Microsoft 365 subscription users.

In its default configuration, XLM macros are scanned at runtime via AMSI, except in the following scenarios:

• Files opened while macro security settings are set to “Enable all macros”
• Files opened from a trusted location
• Files that are trusted documents

Administrators can now use the existing Microsoft 365 applications policy control to configure when both XLM and VBA macros are scanned at runtime via AMSI. Get the latest group policy template files.

AMSI improves security for all

AMSI provides deep and dynamic visibility into the runtime behaviors of macros and other scripts to expose threats that hide malicious intent behind obfuscation, junk control flow statements, and many other tricks. Microsoft Defender Antivirus, the built-in antivirus solution on Windows 10, has been leveraging AMSI to uncover a wide range of threats, from common malware to sophisticated attacks. The recent AMSI instrumentation in XLM directly tackles the rise of malware campaigns that abuse this feature. Because AMSI is an open interface, other antivirus solutions can leverage the same visibility to improve protections against threats. Security vendors can learn how to leverage AMSI in their antivirus products here.

At Microsoft, we take full advantage of signals from AMSI. The data generated by AMSI is not only useful for immediate client antimalware detections, but also provides rich signals for Microsoft Defender for Endpoint. In our blog post about AMSI for VBA, we described how these signals are ingested by multiple layers of cloud-based machine learning classifiers and are combined with all other signals. The result is an enhanced protection layer that learns to recognize and block new and unknown threats in real-time.

Figure 9. Example of detection from Microsoft Defender Antivirus based on data inspected by AMSI

Figure 10: Notification from Microsoft Excel after AMSI reported malware detection

Figure 11: Example of Microsoft Defender for Endpoint alert for detection of XLM malware

The visibility provided by AMSI leads to significant improvements in generic and resilient signatures that can stop waves of obfuscated and mutated variants of threats. AMSI-driven protection adds to an extensive multi-layer protection stack in Microsoft Defender for Endpoint, which also includes attack surface reduction, network protection, behavior monitoring and other technologies that protect against macro malware and other similar script-based threats.

The AMSI-enriched visibility provided by Microsoft Defender for Endpoint is further amplified across Microsoft 365 Defender, such that XLM macro threats are detected and blocked on various entry vectors. The orchestration of signal-sharing and coordinated defense in Microsoft 365 ensures that, for example, Microsoft Defender for Office 365 blocks macro malware distributed via email, which is the most common delivery methods for these threats.

Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

Giulia Biagini, Office 365 Threat Research Team

Auston Wallace, Microsoft 365 Security Team

Andrea Lelli, Microsoft 365 Defender Research Team

The post XLM + AMSI: New runtime defense against Excel 4.0 macro malware 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.