Let’s take a brief look at what Ransomware is before moving on to an Exchange Server infected with Ransomware:
Ransomware is a form of malicious software (or malware) that, once it's taken over your computer, either a desktop or server, it threatens you with harm, usually by denying you access to your data. The attacker demands a ransom from the victim, promising — not always truthfully — to restore access to the data upon payment.
Users are shown instructions for how to pay a fee to get the decryption key. The costs can range from a few hundred dollars to thousands. Some ransomware encrypts files on the machine, where other forms of Ransomware encrypt the entire machine making it useless.
What happens when my Exchange Server is infected with Ransomware?
There are a couple of things you need to do if you suspect that the Exchange server is infected:
Let’s expand on the above a bit. As hectic as it might sound, you do need to isolate the machine that is infected. Yes, it means Exchange will be down (if it is a standalone server) and if the server is part of a DAG you could run on the 2nd, 3rd of 4th copy depending on how big your DAG is. If it is a case of a single server, you will need to check if the C:\ drive has been encrypted and how badly. This all depends on the kind of Ransomware that has reached the server.
The next step would be to see what other Servers on your network have been compromised and take action like the one we mentioned above to isolate the machine. Unfortunately, business might not meet SLA due to the amount of downtime and recovery of the data.
With some forms of Malware, they leave some form of trace behind, like a user account was compromised and they were able to gain access to the server and then create a new account for themselves that has full administrative rights or new folders are created on the server. A common one is the Intel folder where the executable is dropped and then launched.
If you can get access to the location where the Exchange databases are sitting, then ensure you get a copy of the data off the machine before it is encrypted. It’s easier said than done as your Exchange databases can be huge and this will take quite a while to copy across.
The “bad” option is having to pay. Yes the demands for decrypting the data can be financially straining in a sense that they could demand 100 bitcoin etc., and if your currency exchange rate is high you are looking at millions to get that “decrypt key” but it is no guarantee that they will release it to you after paying. It is big gamble paying unfortunately.
Another thing you can look at is using Stellar Phoenix Exchange Recovery to get into the .EDB file, depending on the fact you can get to the directory or not. If you have a backup in place then the Stellar Phoenix tool and open the. EDB file and extract the data. This tool can save you a lot of time extracting the data to Office 365 or to .PST files etc., there are many options while you rebuild your exchange server.
Lastly, if you want to recover exchange from the setup, then you would need to use the recovery switch to do so. Here is a small example of how this is done:
You can use the “New-MailboxRestoreRequest” cmdlet to extract data from a recovery database. After extraction, the data can then be exported to a folder or merged into an existing mailbox. Recovery databases enable you to recover data from a backup or copy of a database without disturbing user access to current data.
If you have a good backup of the database before the infection occurred you could use that database to do the recovery if the current one is encrypted.
Quick overview of the recovery process:
Command to run:
Restoring a Mailbox:
Restore the source mailbox with the MailboxGUID <guid> on mailbox database database1 to the target mailbox
Command for running the mailbox restore request:
Restoring the Content:
Restore the content of the source mailbox with the DisplayName of User2 on mailbox database DB1. This is just a high level overview of the process.