Last week, I received a frantic call from an on-site contact (contracted facility) who told me that e-mail seemed to be down. I’m sure I had a quizzical (maybe even scared) expression on my face because I wasn’t sure what “seemed to be down” meant. After an abysmal attempt at calming the contact down, I remotely accessed the network, right away noticing that the Exchange server’s response was very sluggish. Now I’m getting nervous; rebuilding Exchange servers isn’t much fun on a good day and a whole lot worse when it’s an unplanned activity.
Take a deep breath and think
Remote access wasn’t cutting it, so I decided to go to the facility. During the drive, I had time to settle down. I even laughed at myself, as I was trying to remember how Exmerge works, ultimately realizing that Exmerge was out of the question. I’d be rebuilding Exchange using the same computer, dahh. After arriving, I logged on the Exchange server locally, with the event logs being my first stop. The application log was full of red Xs, all referring to NDRs. That’s not good, because I check the event logs daily and normally they’re clean.
Next step, Exchange System Manager
I then opened Exchange System Manager. At first glance everything looked good. Next, I checked the queue. Oh my, there were over 9,000 outgoing messages in the queue, all from the postmaster. That’s also not good. I started to get a picture of what was going on, but how could it have happened? When I first set up the Exchange 2003 server five years ago I followed all the suggested guidelines. The server is up to date patch-wise and well-sheltered on the network.
I wanted to be sure about my hunch, so I went to DNSgoodies.com and used their Open Relay Check. Sure enough, the Exchange server was indeed acting as an open relay. Hmm, that doesn’t make sense. So, I opened Exchange System Manager once again to check the Relay Restrictions configuration and found it was set up as shown below:
According to Microsoft, this configuration should prevent the relay of e-mail by unauthorized users or servers. I started to have the sinking feeling that this Exchange server was compromised, but it didn’t make any sense. The server is well-protected in the classical sense, as shown in a simple Visio diagram of the network:
To further explain, the entire network is protected by Symantec Enterprise Edition anti-virus. Symantec System Center updates virus signatures daily and completely scans all networked computers nightly. As for notebooks, they are scanned immediately upon connection to the network. In addition, the network has IDScenter and Snort on the ISA server. Finally, all mobile devices (notebooks and smart phones) have software firewall applications, and the users are cautioned to not disable them.
Looking specifically at the Exchange server, it has Symantec’s Enterprise Edition client as well as Mail Security for Microsoft Exchange installed. Both Windows Defender and Malicious Software Removal Tool were up to date and scanning the Exchange server files automatically.
Needless to say, the on-site contact didn’t share my fascination with determining how the Exchange server got subverted, asking instead why couldn’t I just get it working again. I made mention of how important it was to understand the how and why of the attack process. Otherwise any resolution of the problem potentially would be short lived.
That didn’t cut it, and I was directed to get the e-mail flowing without delay. It kind of reminded me of Dune and the “spice of life” (one of my favorite movies), sorry, I digress. Having a computer compromised can mean many things, but in the case of e-mail servers it usually has to do with being rooted and under the control of a remote entity. Knowing that certainly didn’t give me any confidence that I’d be able to resolve this with anything less than a complete rebuild of the Exchange server.
Can a rootkit be removed?
I doubted it, but I thought it best to try. The following steps are how I went about trying to restore the Exchange server to normalcy:
- Ran a special scan using Windows Defender: No results
- Ran Malicious Software Removal Tool: No results
- Ran Windows Sysinternals Rootkit Revealer: No results
- Ran Trend Micro Rootkit Buster: No results
- Completely uninstalled AV client and reinstalled it locally. Next, I scanned the complete computer and guess what: Symantec found Backdoor.Rustock.B. This was the first indication of any malware. The AV client wasn’t able to remove it completely as it re-established itself after each quarantine.
- Went to Symantec’s Web site, hoping to find removal instructions for Backdoor.Rustock.B. Luckily, I found the exact process on the Rustock Removal page.
- Followed the steps and rebooted the server in normal mode.
The server appeared to be running at its normal pace. A check of Task Manager confirmed that. I next opened Exchange System Manager and checked the queue. To my relief, the queue was normal, as shown in the image below:
I’m sorry, but I was in shock. I didn’t expect to solve this issue with anything less than a total rebuild of the Exchange server. Almost immediately, user mailboxes started filling up, and sending e-mail was almost instantaneous. Being very skeptical, I closely monitored the server for several days; actually, I’m still monitoring it.
I’m very relieved but still perplexed as to how the infestation took place. I ran a complete scan on every computer on the network and that turned up nothing out of the ordinary. The firewall or IDS/IPS logs didn’t offer any help either.
This is the hard part: I’m not sure what I learned from this exercise. The network and Exchange server were using current best practices. Just to recap what that means, the following list is what most experts recommend to prevent rootkit infestation:
- Systems patched: There’s a WSUS server on the network, and it keeps every computer completely up to date. Secunia is running on the network as well, which informs me when other-than Windows applications or drivers need updating.
- Never run under Admin privileges: Since an Exchange server was compromised, the only time anyone has access to it is when administrative activities are required. So that’s a potential problem, except the server’s sole purpose is Exchange.
- Install security and AV tools: As I described earlier, the Exchange server had multiple applications running that supposedly would sound an alarm if any kind of malware was attempting to be installed.
I guess the real lesson that I learned (well re-learned) was that nothing is for sure. I was sure that this network would never get rooted. I was also sure of it being impossible to remove a polymorphic rootkit like Rustock. I was wrong on both counts.
As a small aside and to explain why I thought it would be impossible to remove Rustock, please check out this dialogue on the Windows Sysinternals forum. It’s quite amazing to follow the Rustock lineage and the increasing tenacity displayed by each new version, especially when the authors are fairly sure Rustock.D is in the wild and undetectable as of yet.
I consider myself very lucky. No doubt about it. I also know that we are playing some serious catch-up when it comes to keeping computer systems and networks secure from malware of this sophistication.