A Quick Look at Exchange Forensics

3 short lessons learned from a real-world situation

The news lately has been full of stories about computer-based surveillance, espionage, and other topics seemingly right out of a Tom Clancy (or John Le Carré) novel. I refuse on principle to use the "cyber-" prefix to refer to these topics (look up the Wikipedia definition of “cybernetics” and you’ll see why), but if you recognize the words “Flamer”, “Stuxnet”, or “CISA” you’ll know exactly what I’m talking about.

A growing number of enterprises—and their IT staffs—are becoming increasingly concerned about the range of threats posed by electronic attack. Couple that with the high incidence of business litigation, and the high regulatory barriers, present in the US and EU, and you’ll see why computer forensics is such a rapidly growing field.

One reason for this rapid growth is that there are relatively few standards for what “forensics” actually means. It can refer to extraction of data from a target system (usually in a way that preserves the data and ensures that it’s not accidentally or purposefully modified); analysis of data on a system to see what it, and its users, have been up to; analysis of network traffic, and a variety of other tasks. This broad spectrum means that it's difficult to tell whether a person, or company, has any particular expertise—anyone can claim to be a computer forensics expert. Several vendors, notably Guidance Software, which produces the EnCase computer investigation solution, offer certifications for their specific products, while industry organizations such as SANS offer more standardized certifications, but it can still be hard to tell what you’re getting when you retain a forensics consultant or try to get training yourself.

From an Exchange perspective, there aren’t really any solid definitions either. I’ve heard people refer to simple operations such as copying a mailbox’s contents with ExMerge, as forensic recoveries, as well as more complex actions such as reconstructing a timeline of communications based on message tracking and SMTP logs. In general, though, I tend to think of Exchange forensics as about an equal mix of recovering data that’s been accidentally or deliberately deleted and analyzing data to tell you something about what’s going on.

Case in point: Recently a company that's very concerned with protecting itself against advanced persistent threats (APTs), malware that gathers data and then stealthily exfiltrates it from the network, contacted me. They had seen an unusual spike in outbound network traffic to a particular IP address and wanted help identifying the source.

In this particular case, the company’s own logs showed about 2GB worth of data sent from the Exchange server to this IP address in the middle of the night. I suspected that it might be mailbox sync activity, so that’s what I looked at first.

It would have been great if Exchange had a cmdlet or report that would show the volume of data sent to a particular user. It does have IIS logs, which provide a decent outline of connections made with protocols that run through IIS.

Examining the logs netted us the target IP address, which turned out to belong to an AT&T DSL customer in the Bay Area. Reviewing the IIS logs indicated that the server had logged a large number of HTTP requests from that IP during the time period in question—and the IIS logs also told us which user account was doing the requesting.

The clincher: the IIS user agent strings indicated that the requests were coming from an iPad. Sure enough, one of the company’s engineers had just bought a new iPad that day and was syncing his mailbox to it, causing the unusual spike in overnight traffic.

I admit that this case isn’t a very exciting example of Exchange forensics; it would have been way more interesting if we’d caught a spy or uncovered a conspiracy, or even done anything involving stored mail. It does, however, illustrate a few things:

  • If you don’t have good monitoring in place, you will have no idea when something unusual is happening on your network. APTs have to have some way to exfiltrate the data they steal from your network, so watching for unusual traffic patterns is a very useful way to get a degree of warning.
  • Having said that, many unusual-looking circumstances have reasonable explanations.
  • Having IIS logging enabled before you need it is key. Without those logs, it would have been much more difficult to figure out exactly what was going on. There’s a whole industry that revolves around log consolidation, analysis, and archiving, but even the basic logging features in Windows and Exchange can provide surprisingly useful data if you enable them.

Recovering message data after it’s been deleted, and preserving it along the way, is way more interesting, so that’s what I’m going to talk about in the next UPDATE.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.