Back for week 2 of the Metaspike weekly CTF. This week we’ve been given an MSG file containing correspondence between two colleagues. I tried to do this one with entirely free tools again, but there’s a minor caveat that you do need access to Outlook to get the full MSG parsing experience.

Please let me know if there’s a way to do this without Outlook!

If you'd like to play along, the challenge has been archived here

I opened the email with Mailraider Pro, which worked fine for viewing the contents, attachment, and the email headers. Unfortunately, the limitation here is that the free tools that I’ve played with generally don’t show you the extended MAPI headers. In some instances they even truncate the headers, so YMMV.

The email is in .MSG format, which we know to be an OLE file. We can read more about the MSG format specification here. As we know it’s an OLE file, we can use OLE parsing tools, such as Didier Stevens oledump to extract out specific streams (it even has a specific MSG plugin). The downside of this is that we don’t necessarily know what the streams actually represent, which is why we want to use a tool that presents our the headers with their correct names.

Enter OutlookSpy. This add-on for Outlook will allow you to view the hidden secrets stored within .MSG files. What this means for our analysis is that we need to add the OutlookSpy add on (and enable it in Preferences), and then import the email into Outlook. It’s probably a good idea to create a new PST rather than merge it all into your actual Outlook, but for testing purposes whatever works. As an aside, Outlook for Mac seems to use EML files, and OutlookSpy only works on Windows, and as such I couldn’t do the exercise on my Mac. I’m not sure if the metadata is held elsewhere, but I didn’t spend too much time looking.

Once the email is loaded into Outlook, we can access all of the fun properties that we’ll use to answer the question. Pictured below is the “iMessage” window for the email of interesting.

Question 1

You are being asked to examine an email between two colleagues within the same corporation. The email contains an important business document known to have been created and maintained on a volume formatted with the NT File System (NTFS).
Based on your examination of the email, are the creation and last modification timestamps of the attachment more likely to be legitimate or fake

I spent a bit of time flicking through the headers to see what might be interesting here, but most of that is unrelated to the question at hand.

What I did find useful was this blog post by the challenge author, which walks through the process of getting at the relevant timestamps of the attachment. In the post, Arman explains that finding the complete granularity, and seeing it as all zeroes, is a good hint that the times have been forged.

The fields we’re looking for are PR_CREATION_TIME and PR_LAST_MODIFICATION_TIME to show the creation and modification time of the attachment.

Selecting both properties will show us the hex (which is great, because we verify it).

We can copy this hex value into Digital Detective’s DCode and see the FILETIME value with complete granularity.

Based on the fact that the timestamp ends in a series of zeroes we believe that the timestamps on the text file have been forged.

Question 2

Regardless of whether you believe it is legitimate or fake, what is the last modification timestamp you were able to find for the attachment in Part 1?
Enter the timestamp in UTC with 0.1 microsecond precision in the following format: yyyy-mm-dd hh:mm:ss.fffffff (e.g., 2005-11-20 13:17:48.1234567)

Since the question is asking for the last modification timestamp of the attachment we need to go to the PR_LAST_MODIFICATION_TIME field, which lists the timestamp as 2020-06-05 19:30:20.0000000 +00:00

I did load up the email into Nuix v8 and found that I could see the same timestamps, just without the granularity. Similarly, I saved the file out of the email directly (using Mailraider), and is preserved its timestamps. Viewing the file in FTK Imager showed me the same timestamps, just again, without the granularity.

Question 3

It is believed that the email you examined in Part 1 and Part 2 of this challenge was the last message in a conversation thread that comprises multiple messages. Based on the information available to you, when was the initial message in this conversation thread likely sent?
Enter the timestamp in UTC in the following format: yyyy-mm-dd hh:mm:ss (e.g., 2005-11-20 13:17:48)

I also found this excellent, and relevant, blogpost to help me find the answer. Although, re-reading it it says to take the thread index from the PR_CONVERSATION_INDEX MAPI header, rather than the email header pictured below.

Either way, after explaining the ins and outs of thread index parsing, Arman shares out a tool that conveniently does all the heavy lifting for us.

Based on the header timestamp, the initial message in this conversation thread was likely sent at 22/01/2020 23:17:41.2434944.

Question 4

Based on the information available to you, what is the maximum amount of time Vivian Alyse could have spent composing the final message in the thread that you examined? That is, time elapsed from the moment she pressed the “Reply” or “Forward” button, to the moment she hit “Send”. Assume that the following is true:

1. Vivian used Outlook to compose and send the message
2. All the computers invovled in the email conversation keep perfectly accurate time

Enter the duration in minutes rounding up. For example, enter 46 for 45 minutes and 31 seconds.

I have to admit that I started to approach this question completely wrong. I originally thought that maybe there was a clearly visible timestamp that was passed on in the MAPI headers that indicated when the email composition began. When sorting all the visible timestamps they pretty much all showed the same minute, so that wasn’t helpful.

Thankfully, the article that helped with the previous question had enough of a clue to help answer this one. If we look under Observations, the second point says that the Child Items found within the PR_CONVERSATION_INDEX/Thread Index are updated when the author of the email hits reply/forward. That is when the actual email is opened for composure.

What this means is that we need to get the time that the email was sent, and subtract is from the last Child Item timestamp.

To get this I had to find the PR_CLIENT_SUBMIT_TIME, which indicates when the email was sent (according to Adam, and Microsoft’s documentation).

In Question 3 we can see the timestamps recorded in the child items, and Child 2 is listed as 14/12/2020 21:57:34. Subtracting the two, and rounding up we get 2 minutes, which is the answer!

I liked this challenge a lot more than the last one because, even though it was a bit easier, I was able to read the articles and play with some stuff I hadn’t played with before. Overall, email analysis is a very niche topic that Arman has clearly spent a lot of time testing and documenting. Otherwise, there’s not a huge amount of information available (although Dave Cowen did an excellent series a little while ago). Most of the email analysis stuff relates to identify phishing, so good practice on forgery and fraud is hard to come by.

As an aside, John Hubbard has recently released a video on email header analysis that’s worth a watch.

Looking forward to week 3!