Investigating and preventing Microsoft Exchange’s recent zero-day vulnerabilities

In this post we would like to help those who’s affected by the recent 0day vulnerabilities published by Microsoft in 2021/03 (alongside the required patches) concerning on-premise Exchange Servers.

To sum up the recent CVE numbers shown below:

  • CVE-2021-26855
  • CVE-2021-26857
  • CVE-2021-26858
  • CVE-2021-27065

An attacker can use them in a chained attack to get SYSTEM rights on the affected servers. Not too much POC codes are present currently, but it just needs time to contribute such codes through Github,Pastebin… or a ready MetaSploit module and not just APT and hacktivist groups, like HAFNIUM will utilize them but also script kiddies worldwide. According to the news the mentioned hacker group used to exfiltrate data and share via public platforms, but the vulnerabilities are making possible to run code remotely as well as a Ransomware code.

In this case if we see the first CVE, a server-side request forgery (SSRF) vulnerability that makes possible to authenticate as the Exchange server itself, it comes out that it needs a public OWA (Outlook Web App) service via port 443/TCP. Here the easiest ways to prevent any attempts are:

  • Restrict the source IP ranges/countries who can reach the OWA
  • Force the usage of a VPN to be able to use the OWA
  • Put an additional defense layer in front of the OWA e.g.: Web Application Firewall or an additional authentication layer like Reverse proxy authentication via AD and 2FA

This way the front entrance can be successfully defended, but it won’t help if the rest of the attack could happen internally via the usual way, like phishing attacks, malicious side-by download or anything that tricks the Layer 8 (human) to run the desired code.

After the initial access was gained the hacker usually doing post-exploitation activities in the hope of being able to make persistence. The example in this attack scenario is dumping LSASS process memory that holds the user credentials alongside placing a reverse shell as a backdoor. For this dozens of tools can be used like Procdump (from the Windows Sysinternals package),the old Mimikatz… etc, as well as for backdoor like, netcat, powercat, PowerShell Empire…

  • You can prevent the LSASS memory from dumping via set a registry key in Windows to enable protection
    • In the registry put a REG_DWORD key into HKLM\SYSTEM\CurrentControlSet\Control\Lsa and set the name to ‘RunAsPPL’ and the value to ‘1’.

(Keep in mind that this protection prevents any Debugger (and other process) to attach to this process so use it wisely in UAT or Development environments. The prevention is not working in 100% as the attacker can use vulnerable drivers to load into the kernel, but at least makes his/her job harder 😊 )

Almost in all standard Windows hacking scenario we found that the attacker using the command line and powershell to reach the goal. In the most cases we cannot disable powershell in the servers as many core process uses that, but we can place detection capability to monitor the command line activities.

For this it’s highly advices to enable Process creation logging and enable in addition the Command line auditing feature (It will give you one of the most useful Event ID in Windows Event logs, 4688). Check the source list for the actual configuration steps.

In this topic and in other hacking cases many time files has been created: droppers, shells, other executables…etc. As there is many indicators listen in Microsoft’s blog post, hashes also you may be curious about that. To complete the visibility and be able to track more IoC-s in your Windows environment install Sysmon from the Sysinternals package with a tailored config (example can be found in the sources list). This tool makes most hashes visible.

Basically now you have extended logging capabilities, so just forward the logs to a proper SIEM solution (like Splunk Enterprise or IBM QRadar) and set-up the alert rules based on the IoC-s.

Other things to check:

  • PowerShell History File located at: $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
  • File system to look for unknown/newly created .exe,.dmp and .ps1 files

Hope you will be able to apply patches in time before script kiddies awaken, but with this settings you can secure your environment a bit more, just don’t forget to check the logs and SIEM alerts regularly.

If you need help, please contact us!

Sources:

Microsoft says China-backed hackers are exploiting Exchange zero-days

https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing

https://github.com/SwiftOnSecurity/sysmon-config

Pin It on Pinterest