In the previous article we verified that a series of emails had been sent from the MINAF CEO’s account to the CFO, and through social engineering a series of unauthorized transfers had been made. We are at a point in the investigation where we want to know more about those emails, and for this we have to go to the low-level database of Exchange: EventHistoryDB.
EventHistoryDB is a database that collects with minute detail the entire life cycle of an email in Exchange. Thanks to EventHistoryDB we can know such granular details as:
- When an email was written.
- When it was sent.
- Whether or not it was read by the recipient, and when.
- If the mail was moved to a folder.
- If the email was answered.
- If the mail was sent to the trash, or even if it was deleted from it.
Unfortunately, not everything is perfect in the EventHistoryDB. It is only accessible via Powershell (no nice graphical interfaces), and only the last 7 days are saved by default. However, in this case the MINAF has reacted very quickly and this has allowed us to enter comfortably within that time frame, so it is possible to fully recover the records for the two affected users.
To see what an EventHistoryDB record looks like, here is a sample:
We are mainly interested in 4 fields:
- ItemEntryID: An identifier of the message that appears in MessageTracking, and that serves as a relationship between both sources of information.
- EventName: Indicates the action taken on the message (in this case, that it has been modified).
- ClientCategory: the type of client that performed the operation (MOMT = Outlook Client).
- DocumentId: Unique identifier of an email within EventHistoryDB (ItemEntryID is not 100% unique, so we need to resort to DocumentId).
We take as evidence two important messages from MessageTracking: the first message supposedly sent by the attackers, and the message sent by CFO Alfonso Ferrán, that CEO Abelardo Alcázar claims not to have read.
We extract the metadata and create this file (we have eliminated the “-” because that is the format in which they are recorded in EventHistoryDB):
The first thing we do is a basic grep to verify that we have the correct ItemEntryID. As everybody is expecting… the command returns nothing. It is not the first time that EventHistoryDB format “makes our day”… but this time we are ready.
A less of the file shows that it contains binary characters (something that grep does not usually like AT ALL), so we do a very simple conversion with type, and repeat the operation, managing to locate our ItemEntryID elegantly:
If we take the first occurrence, we see a very curious thing:
Looking at the creation date of the event, we see that it was created at 15:56:07 UTC+0. But we know that the mail was sent at 16:02:10 UTC+0, so… what’s going on here?
Very simple: as mentioned, EventHistoryDB obsessively saves the ENTIRE mail life cycle. What see at 15:56:07 is the CREATION of the email message: when the attacker clicks on “New Mail.” Yes, that’s how comprehensive EventHistoryDB is…
If we search for our chosen time, we verify that the mail had indeed been received by the Exchange:
Once located the mail we want to examine, the easiest thing to do is usually to collect the DocumentId and search for it again in the entire file (in some circumstances, the ItemEntryID can change, but the DocumentId always remains constant).
If we examine all the transitions of DocumentId 14386, we find two very interesting:
If we look at the EventName (the action made), it is ObjectMoved. This is when we recommend you to learn new swearwords, because a very curious thing happens: EventHistoryDB has an EventName named “ObjectDeleted“, which in effect serves to indicate that an email has been deleted… but from the sending queue, not from a mailbox.
The EventName used to delete an email is, as you can imagine… ObjectMoved. Exchange’s explanation for this funny name dance is that deleting an email is “moving” it to the Trash. With that little piece of information in mind, we see these events from another perspective and understand what they mean.
What we see with the first ObjetcMoved is the movement of the mail sent by the attackers to the trash, and the second ObjectMoved constitutes the permanent deletion of the mail when emptying the trash. If we check the rest of the messages in the conversation, we see that the same has happened to each and every one of them.
Why have the attackers deleted these emails so drastically? Very simple: all devices are synchronized with Exchange, so any mail would end up reaching CEO Abelardo Alcázar’s smartphone and he would end up reading it sooner or later. But if the attackers delete the mail from Exchange, that same synchronization deletes it in the terminal. In short, what the attackers are doing is erasing their tracks to avoid detection and save time.
If we look at the email sent by the CFO Alfonso Ferrán (the one the CEO Abelardo Alcázar claims he never read), we see that something similar happens:
We verify that the mail was accessed by the attackers. A few seconds later, it suffers the same fate as the previous emails:
If we look closely, we can see that not even 20 seconds have passed since the mail arrived to CEO Abelardo Alcázar’s mailbox, the attackers read it, found that it was harmful to them, and removed it from the inbox without any consideration.
What does this tell us? That the attackers were constantly and thoroughly monitoring the mailbox of the CEO, “censoring” any mail that might endanger their attack. In other words, the attackers knew exactly what they were doing, and they executed the attack perfectly.
Only one detail remains to be revealed about EventHistoryDB: the source of all these actions. Reviewing the events, we see that they were carried out through OWA (Outlook Web Access), the Exchange webmail. Fortunately, we have a good amount of CAS logs (which also records the actions performed through OWA), so we have material to work on… in the following article.
