Many admins are currently reporting a successful attack on their Exchange server. Many are finding evidence of unauthorized access or even an installed web shell. Many are now unsure what to do or how to proceed. Some are now implementing IIS rewrite rules or deactivating the UM services, for example, as recommended in this article from Microsoft:
However, there is something to note here: The article describes measures that can be taken if the available patch cannot be installed. The article assumes that the Exchange has not already been successfully attacked. The measures described are therefore "workarounds" for environments that cannot install the patch and have not yet been attacked. So if there are already indications that the Exchange server(s) have been attacked, the article linked above no longer applies.
So if you can already assume from the numerous available scripts, hints in the logs or strange .js / .aspx files in directories that the Exchange server has been successfully attacked, then you need to react quickly now. The child has already fallen into the well, a successfully installed webshell gives the attacker access to large parts of the network. Be aware that Exchange servers have extensive permissions in the Active Directory and the attacker may now have extensive access to the network via the web shell.
However, before embarking on a potentially lengthy analysis of the incident and attempting to undo the attack by deleting the files created or similar, for example, you could also consider a recovery installation of the Exchange server. After a recovery installation, you have a fresh installation of both the operating system and the Exchange Server. Only a few settings for the Exchange configuration have to be made again (e.g. receiving connectors). A recovery installation is also carried out very quickly, after about 2 - 3 hours the operating system including Exchange is restored. Another advantage: A current data backup is not required with this procedure.
Small warning: This article was written quite quickly and tested with Exchange 2019, so of course I can't recreate all environments here and can't go into every detail due to time constraints. If anything is unclear, please let me know and I can revise the article.
Take Exchange Server off the network immediately
If there are already indications that the Exchange server has been compromised, the server must be disconnected from the network immediately. Of course, this means downtime for the users, but it is now a matter of averting more damage. The Exchange server must therefore be disconnected from the network; in the case of a VM, you can deactivate the virtual network card in VMware or Hyper-V, for example. In the case of a physical server, the switch port can be deactivated or, if necessary, the network cables can be unplugged. The main thing is that the server is disconnected from the network. This prevents further damage in the first instance. If you don't want to "pull the cable" straight away, you must at least enable the ports and/or block access from the Internet to the Exchange server. Whichever option you choose, the other measures will require downtime (at least if you are not running a DAG).
Reset passwords
After the Exchange Server has been disconnected from the network, at least the passwords for the "Administrator" user and the user with which you administer Exchange are reset. So if you log in to the Exchange Server with the "Administrator" account (via RDP or EAC etc.), this password will now be changed. All other passwords for administrative users must also be changed. This is the minimum!
Save important settings
You can now start preparing the reinstallation of Exchange. The best way to do this is to back up a few important settings from the compromised server. It is best to go through the configuration of the server, many of the settings are saved in the Active Directory and will still be set accordingly after the reinstallation. However, you should always back up the settings of the virtual directories. Here, you must go through each directory once and save the values for internal and external URLs, as well as the settings for authentication:
The corresponding values can simply be copied into a TXT file, for example. The settings of the receive connectors are also important:
Save the corresponding settings here too.
Secure certificate
To make the reinstallation of the Exchange Server as easy as possible, it is best to save the current certificate. If you have only disconnected the Exchange Server from the Internet, you can still export the certificate via EAC:
If you have completely disconnected the server from the network, the certificate can be exported via MMC:
Save database
Before the database is backed up, the Exchange services must be stopped. The following command can be used to deactivate all Exchange services:
Get-Service *exchange* | Set-Service -StartupType Disabled
The Exchange services can then be stopped. Tip: Stopping the "Microsoft Exchange Active Directory Topology" service also stops most of the other Exchange services:
Now back up the Exchange databases. If the database(s) were saved on drives other than C:, you have an easy game here. In this case, nothing needs to be backed up. However, if the databases are saved on the C: drive, then all database files must first be copied to a safe location:
If the databases are saved on a separate drive, the data does not need to be backed up separately.
Reinstall server
The computer account of the Exchange Server is now reset in the Active Directory:
Important: The account is only reset, but NOT deleted.
After the account has been reset, the server is reinstalled.
If you have saved the databases on a different partition or drive, make sure that the data is not lost during the reinstallation. It is therefore better to check the settings twice.
The same operating system version that was previously in use must be used for the new installation. After installing the operating system, the new server is given the same name and the same IP as the old server, after which the new server is added to the Active Directory.
You should now have a fresh Windows installation with the same computer name, which has already been added to AD. Now Exchange is still missing.
Reinstall Exchange
The prerequisites for Exchange must first be installed on the fresh Windows server. The prerequisites for Exchange 2016 and 2019 can be found here:
After the required IIS roles, .NET framework and UCMA API have been installed, the Exchange restore can be started with the following command:
Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:RecoverServer
If Exchange was not installed in the default directory, the "TargetDir" parameter must also be specified:
Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:RecoverServer /TargetDir: "D:\Program Files\Exchange"
After some time, Exchange is installed again. The server should now be restarted.
Restore database
In order for the database to be restored, the restore must first be permitted; this is done with the following command in the Exchange Management Shell:
Get-MailboxDatabase -Server EX1 | Set-MailboxDatabase -AllowFileRestore $true
Now the entire folder with the database is copied from the old server back to its destination:
As soon as the data has been copied, the database can be mounted:
If the database was saved on a drive other than C:, the data is still available in the same location. Then make sure that the drive letters match. In this case, you should be able to mount the database directly.
To be on the safe side, you should now check whether all Exchange services have been started; if not all services are running, simply start them.
Restore the settings of the virtual directories
Logging on to Exchange via EAC is now possible again. You can now correct the settings of the virtual directories and set them back to the previous values:
As with the backup, you must go through each directory here.
Import certificate
The previously secured certificate can now be conveniently imported again via the Exchange Administrative Center and assigned to the services:
The path to the saved PFX file must be specified via UNC path:
The next step is to specify the server for the import:
Now the imported certificate only needs to be bound to the Exchange Services:
You can now release the users on Exchange again. At the same time, you should check all settings again and make any necessary adjustments. For example, now would be the time to configure the receive connectors again accordingly.