Exchange

Hafnium and Exchange mitigation and remediation

11 Comments

Last week Microsoft discovered a zero-day vulnerability for Exchange (which was initially detected by security companies last January) and an urgent patch was released. Unfortunately this patch is only available for recent versions of Exchange 2019 and Exchange 2016 and the last version of Exchange 2013. If you have an older version of Exchange running you have to bring it to the latest Cumulative Update first and then deploy the Security Update.

There are some mitigation rules available though:

  • Exchange server that are not available on the Internet are much less vulnerable (ok, this is an open door, I know). I have two customers that have their Exchange servers available only via a VPN connection. This works well from a security perspective.
  • Similar to the previous bullet, Exchange hybrid servers should not be publicly available, only Exchange Online must be able to access the Exchange on-premises servers. URL’s and IP ranges can be found on https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide.
  • Microsoft also posted a number of mitigation rules on the Microsoft Security Response Center Blog. These mitigation rules are temporary though and should only be used until the Exchange servers are fully patched. Mitigation rules are an IIS Re-Write Rule, disabling UM services and disable OAB en ECP Application Pool.

Microsoft has published a script (Test-ProxyLogon.ps1) on GitHub that can be used to check your Exchange servers if they are compromised. This script can be found on CSS-Exchange/Security at main · microsoft/CSS-Exchange · GitHub.

When you run the script it will show in seconds if something is found:

Too bad that this is a production Exchange 2016 server that was compromised.

At this moment I would recommend to turn off and remove the Exchange server and rebuild it using the /Mode:RecoverServer option of the Exchange setup application. This is documented in my next blog Rebuild your server (after HAFNIUM infection. When other (better or easier) recommendations are published I’ll update this blog.

Last updated: March 10, 2021

11 thoughts on “Hafnium and Exchange mitigation and remediation”

  1. Pingback: Attack on Exchange Servers Gives Impetus to Move Email to the Cloud

  2. Hi Jaap, We’re in the same situation. I’m about to recover our Exchange 2016 using the -recoverserver option. I am however still in the dark on how to recover the mailbox database afterwards: the database was located on the default path (C:\Program Files\Microsoft\Exchange Server\V15\Mailbox). Do I just recover this directory from backup and place it in the fresh server? How does the recovery process of the database work exactly? Can’t find any tutorials about this…
    Thx.

    Like

    Reply

    1. Hi Thomas,

      you use the existing backup/restore to restore the mailbox database after the recovery. What you also can do is dismount the old database (on the infected server) and store it somewhere safe. After the recovery you can just copy this .EDB file to the new recovered server on the same location and mount it. I have not checked, but I’m pretty sure when using the /RecoverServer option a new Mailbox database will not be created so you should be good here. I don’t know if there are any tutorials for this specific scenario.

      Like

      Reply

      1. Hi Jaap, thx. for your reply. Just for my understanding : when you say ‘use the existing backup/restore…’, you mean that I use my backupsoftware (Veeam) to recover files from backup and restore them to the same location on the fresh server? thx.

        Like

  3. Ok thx. And would I then need to select a recover-option or will exchange automatically find the database and mount it?

    Like

    Reply

    1. You still need to use the setup /recoverserver option when recovering the server. That won’t change. Veeam will restore to its known destination (I guess) so Exchange will automatically know the files are there. Remember that all this is stored in Active Directory and all these settings are used during recovery setup.

      Like

      Reply

  4. Hi Jaap, this week I got the same message after running Test-ProxyLogon on a not fully patched Exchange 2019 server. But suspicious activity doesn’t exactly mean that the server is compromised right?

    I decided to run the EOMT script, which can be found here: https://github.com/microsoft/CSS-Exchange/tree/main/Security#important-note-regarding-microsoft-safety-scanner
    This script remediates the server when it’s vulnerable by installing and configuring the IIS URL Rewrite Module. Then, it performs a quick scan with the Microsoft Safety Scanner. This quick scan reported that no known threats were found so no remediation of compromises were needed. I installed CU9 (which contains the March 2021 security updates) and the latest Windows Updates, and all looks fine.

    Do you have any experience with the EOMT script and does this make you reconsider your statement regarding rebuilding the server? I also do wonder if you started using any other script/tool/procedure in order to scan/remediate an Exchange server in the meantime?

    Like

    Reply

    1. It’s a difficult question, what is suspicious activity? It can be an IT team trying to figure out what’s wrong, but it can also be a hacker that was not successful. Last week I had a security breach, we found 6 compromised servers (no Exchange). CERT involved, blue team and red team. They did more research, we have to force migration off of the 6 servers and turn them off, including domain controllers. But 6 other servers showed ‘suspicious activity’ and with some remediation they were declared ‘clean’ by CERT. Personally I would have rebuilt those servers.
      When it comes to Exchange, it depends a bit of what kind of suspicious activity is found, but my preference would still be to rebuild the servers (but I have done this before, so I know what to expect when rebuilding)

      Like

      Reply