Email Forensics; 1. The Gathering
This blog post series explains the basic evaluation of email headers, body, and various types of attachments.
Parts of this Email Forensics Series:
- The Gathering (You Are Here)
- Headers and Body (To Be Published)
- Attachments (To Be Published)
In the first part of the series, we examine methods of how potential cyber threats, specifically email payloads, are passed from recipient to analysts and how it affects forensic investigations.
Let’s set a scene. An email is delivered to Alice’s mailbox. Unsure about the legitimacy or the contents of the mail, Alice becomes suspicious. Reporting the incident, she asks how should she proceed.
Access to the email server is limited and Alice does not have any “report this email” button installed in Outlook.
Therefore, Alice’s options to get an email to us are the following:
Forward the email
The forwarded email has no headers.
If our reply to Alice would be to forward a suspicious email to us, there will be no headers to investigate. Forwarded email is comprised of the email body and attachments, but it’s wrapped in a new envelope (header). Data about the original envelope and its path\route through the network are lost.
Although original headers are crucial for comprehensive forensics. At the end of the article, I will show that headers are not always necessary for basic triage.
Export email from Outlook
Email saved from Outlook has only part of the headers.
Here comes the tricky part; even if we ask Alice to save email from Outlook to (shared) disk or to drag & drop attaching the spurious email to another email, we will not get all the headers.
The reason is, that email is saved not as plaintext according to RFC 5322 but as an Outlook native object. This object has only a defined set of headers and all the rest is dropped.
Let’s compare original headers of the email received from GMail with the same email but saved to disk:
Multiple common headers are kept, like all transport headers ‘Received’, but we lost all the ‘X-Headers’, all authorization and signature headers, and important ‘Return-Path’ header.
Forward and copy headers to the body
Less convenient but works even for web clients.
Headers are copied from Outlook’s view to the body of the forwarded email. This approach required Alice to copy headers from her suspicious email to the forwarded email body.
As a result, all original headers are preserved in the body and the original body and attachments are forwarded as attachments or multi-parts.
Forensics without headers
In this scenario, a suspicious email was already forwarded and we need to work with what we have. Our task is to evaluate if this email is legitimate or not. The email was forwarded for analysis from the free email service, hotmail.com and it looks as follows:
Email is the call for action from a personal account on domain blockchain[.]org. As headers are not available we cannot directly evaluate if the sender was spoofed. We do know that email was successfully delivered to the Hotmail email box, indicating that SPF verification didn’t fail. Almost all email servers are dropping an email with failed SPF and we can suppose that Hotmail would do the same. Potential blind spots are the senders without an SPF entry. A common setup of email servers is to accept such an email but flag it as spam in the user’s mailbox.
Digging domain information, we discovered that there is no email server (MX entry) associated, therefore no SPF entry as well.
As the domain is not configured to serve email communication, we can consider received email as clearly spoofed.
Moving forward, the link from the action button points to file /jd2r9e/xi3f2o.php hosted on domain merotheatre[.]com. The random name of the path indicates an effort to avoid pattern matching by security software.
To verify that the sending domain might be just another victim in this malicious campaign, we will open the Tor browser and check the content.
Hosting account is already suppressed therefore we need to dig in Google Seach Cache.
The payload was served from the PWNed Theatre Management site based in Nepal.
We can conclude, even without available headers, that email was spoofed and contains a link to the payload on the compromised web server.
The End of part n.1
