(Note: This is a fiction story, the characters and situations are not real, the only real thing is the technical part, which is based on a mixture of work done, experiences of other colleagues and research carried out. with the same technical dose but with less narrative, you can consult the video of the talk that the author gave at the 11th STIC Conference of the CCN-CERT here )
On the previous article we left off with our views on the mail server of the Organization, a Microsoft Exchange 2010. The first thing we can do is ask Systems to do a message tracking of the email, using a graphical tool (although we can also do it by console) to locate the history of a high level email within Exchange.
First attempt, and the email still does not appear. We repeat the addresses and the Systems technician repeats the search without success. The email must necessarily be there, so we ask him to search again the whole day… and we finally find it, 14 minutes later than when it should have been sent.
Apparently the Organization has not implemented its time synchronization strategy well, and we have a 14 minute drift between the Exchange server and the clients (mental note: insist on the need to deploy an NTP server as soon as possible), but at last we have located the email. The screenshot sent by Systems would be something similar to this one (for confidentiality issues we cannot put any of the originals):
The most interesting thing about the message tracking is that it allows us to extract the ItemEntryId, which within Exchange constitutes a unique identifier that allows searching in the EventHistoryDB, an internal Exchange table that comprehensively gathers ALL the activity of the life cycle of an email (from when the message is created, including when it has been saved as a draft, or with what medium it has been sent). Exchange by default only saves this information for 7 days, but in this case we have plenty of time, so we can extract all the information we need.
We extract the ItemEntryId, and we ask System Team to extract all the relevant information. In this case we do not have a graphical tool and they have to use a bit of Powershell:
The result should be something like this:
With an entry for each activity of the mailbox in question. In our case, a text file of about 50Mb (the user clearly sent emails). Unfortunately, our search for the ItemEntryId returns a NULL again as a response. The thing begins to take a somewhat unpleasant look: the email is not on the user’s computer, nor do we find it in the Exchange.
We must begin to seriously consider the possibility that the attackers have compromised the Exchange since it is part of their repertoire of TTP (Techniques, Tactics and Procedures). If they have done so, the incident will have a critical impact: attackers can read all of the Organization’s emails, as well as capture all access passwords (which are usually those of the Windows domain). And … what better way to exfiltrate information than by a simple and “innocent” email?
However, before considering “burning” the mail server of the Organization (with a considerable number of mailboxes) we need to find solid and conclusive evidence, which forces us to exhaust all possible avenues of investigation.
In the first place, we can check if the user’s mailbox has the audit enabled, which would allow us to check in detail the possible accesses. The command in Powershell would be very similar to this:
… and the results are negative (the audit consumes system resources, being deactivated by default for all mailboxes).
If we do not have an audit, we will not be able to control mailbox delegations which is quite common in corporate environments when one person needs to access another’s mailbox (or they have shared generic mailboxes). However, another call to Systems confirms that this user’s mailbox does not have delegations, so another door that we close in our investigation.
We have one option left: to recover the full mailbox of the Exchange user. Although we think that we have full access to our data in the desktop or mobile client, in reality Exchange keeps a good amount of extra information, being our objective a special folder: the Recoverable Elements.
This folder performs the functions of trash, and ALL the emails that are deleted are stored in that folder for 14 days or until that folder has a size of 30Gb (whichever comes first). Therefore, in a corporate environment in which clients have mailboxes synchronized via MAPI (essential to be able to access mail from OWA or mobile phones), if the user deletes an email in his desktop client the change will be reflected in his mailbox … but the mail will go to this folder. Additionally, this folder is inaccessible by the user (and probably, could not have been manipulated by the attackers unless they have compromised the entire Exchange).
It is later than 10pm, but Maria agrees that the incident has maximum priority, so we call the user and ask for his permission to export his user mailbox (we insist: although the security policy of the Organization can authorize the monitoring of emails, it is always better to inform and request consent to be scrupulously compliant with the rights to the privacy of users).
The user is totally cooperative and provides us with this authorization, so we speak with Systems for the complete export of the user’s mailbox, something that is done in Powershell with this command:
The export gives us the full mailbox that we can load again in Kernel Outlook PST Viewer. A quick search gives us a joy: the mail is in the Recoverable Items folder! We finally have a solid clue to what may be happening. If we review the mail carefully we will find several interesting data:
- The email has been deleted (logically, it is in the Recoverable Elements folder). If the user did not do it, someone must have erased it by force.
- We can locate the original document, used to generate the malicious document, a few days before in the user’s mailbox.
- The signature of the malicious email is slightly different from the original (the job posts are not complete, and an image in the signature is missing).
- The email has been written in English (when the default language of the Organization is Spanish).
It is past midnight and we have no more direct lines of investigation. Everything seems to point to the fact that the attackers have compromised the Exchange of the Organization, so tomorrow we will have to start analyzing the four servers that make up the mail cluster. We leave the Autopsy working on the forensic image and we retire until tomorrow.
The analysis will continue, but in the next chapter…
