"F" Is for Forensic: Exchange Server Investigations

Forensics have come a long way. Formerly the domain of medical examiners and police crime labs, we now have all sorts of forensic occupations. Forensic accountants analyze financial records of companies to gather evidence of crime; forensic engineers recreate situations such as bridge collapses to figure out what happened. Forensics have become a mainstay of popular culture, leading to widespread public familiarity with some aspects of forensic science. Law enforcement professionals have a phrase for this phenomenon, "the CSI effect," referring to the tendency of amateurs to have inappropriately high expectations for crime solving because of what they see on TV shows such as the popular CSI: Crime Scene Investigation.

Sadly, the CSI effect is alive and well when it comes to Exchange Server organizations. There are several common circumstances where Exchange data collection might be required, such as recovering mailbox data of users who have left a company, performing internal investigations, and capturing data pursuant to subpoenas or other legal demands. These circumstances each have somewhat different characteristics:

If you're recovering a former employee's mailbox, your interest is typically just in getting the mail data; metadata such as read/unread status isn't as important, and there's usually no legal requirement to preserve a chain of custody.
For internal company investigations, the goal is usually to copy some data from a target mailbox without the target becoming aware of it. Sometimes you need a way to search multiple mailboxes and export the results, again without tipping off the targets or changing any data.
For responding to subpoenas or other legal or regulatory demands, you typically need a way to gather all the requested data without altering anything, as well as proving that you retrieved all the data you were asked for. These requests frequently require cross-mailbox searching.

Interestingly, the most commonly used Exchange forensic tool is (drum roll, please) the venerable Exchange Server Mailbox Merge Wizard, commonly known as ExMerge. This utility has the virtue of being very well understood in the Exchange community, and it provides a fairly robust way to move mailbox data and metadata into a PST file. Its logging options are adequate, provided you increase logging above the default level. It doesn't offer any way to search mailboxes, though, which makes it hard to be sure you’ve captured all the content required for your collection.

The Exchange Server 2007 Move-Mailbox cmdlet through Exchange Management Shell solves the search problem by offering a way to search multiple mailboxes for content, then extract matching messages to a PST file. This method solves the most common problems of the three cases listed above. As a bonus, Move-Mailbox is both faster and more robust than the ExMerge engine, and you can use it even if you don't have any Exchange 2007 servers deployed. To do so, you need to install the Exchange 2007 management tools on a workstation (not on your Exchange 2003 servers!) with the Exchange 2007 prerequisites, including Windows PowerShell 1.0 and the .NET Framework 2.0.

The larger question is what best practices are appropriate for performing forensic collections on Exchange servers. There are lots of best practices for conventional forensic data recoveries using tools such as Guidance Software's EnCase eDiscovery. However, many Exchange administrators don't know the common rules of computer forensics, and many of the people who do know those rules don't know much about Exchange. I'm interested in hearing what has, and hasn't, worked well for you during forensic collections—drop me a note at probichaux@windowsITpro.com to let me know, and I'll summarize the results in a future column.

End of Article