This post is a write-up of the “This can’t be real” challenge I created for the iHack CTF at HackFest, I was lucky to be part of the MalwareTheFlag team that created 9 challenges for this event. The other write-ups can be found at Max’s blog and Kaido’s blog.
Description:
Phishing attacks can bypass different email filters and settings by crafting custom headers and spoofing information. The idea is the user reads the email and find the anomalies in the headers, once he spots the problem he will easily decode the string and get the URL to the flag. The provided description of the challenge was
One of our customers says he has been waiting for months for a huge prize he won, but he’s afraid he might have been scammed and lost all his credit cards. He told us he got the following email with detailed information about the prize. Do you think you can find if he is going to get his money back?
The attached file was You Won a billion $$$!!.eml
Analysis
Eml files are exported emails that can be loaded into any email client. A quick look at the email only reveals some broken links and a suspicious description from a “Shark Lottery” company ;)
As there is nothing else we can see at first look, we only have one thing left to do: checking the headers and source of the email. This can be done either by opening the EML file with a text editor or by loading the email file on an email client such as Outlook and then hitting the “view source” option over the email, this may vary between email clients, but a quick google search will get you detailed guides.
Looking at email headers can be a little bit overwhelming the first time, especially if you look at them in plain text. A useful tool that might help detecting and analyzing headers can be https://mxtoolbox.com/EmailHeaders.aspx. After pasting the headers and clicking the “Analyze Header” button we get a warning about some DMARC errors.
The warning describes problems with the SPF and DKIM headers, where both fail to authenticate and provide a correct alignment. DKIM and SPF headers are an authentication mechanism used by an email server to protect senders and recipients from impersonation and spoofing, DKIM stands for Domain Keys Identified Mail and adds a signature header that can be validated by the inbound server using the DKIM key stored in the TXT DNS record of the original outbound server, if the values match the message is authentic, otherwise the message might have been forged or altered. An authentic DKIM header should contain the following values:
v: Version - the version of DKIM standard used
a: Algorithm - contains the cryptographic algorithm used to create the hash
c: Canonicalization - define characteristics like allowed whitespaces allowed or not.
s: Selector - the identifier or selector of the key to be requested
d: Domain - domain that is signed the message
h: Headers - SMTP headers included in the hash
i: Identity - signer or sender
b: Signature - Signature in base64 format
On the other hand, SPF which stands for Sender Policy Framework is also an authentication mechanism but works slightly differently. A domain administrator sets an SPF record on the domain configuration, defining the authorized server to send emails on behalf of the domain. When a new email arrives to the inbound server, the server checks ether the “Return-Path” or “From” header to extract the domain, resolve the SPF record on that domain, and then compare it to the outbound server. If the IP is not marked as authorized on the SPF record, the server can either block the message or flag it as malicious/spam.
Now that we know a little bit more about these headers, we might want to look at our email headers to see why MXToolBox marked them with problems.
The DKIM-Signature header has a suspicious structure as it only contains a value “F” which is not in the standard. Decoding the base64 value of “F” reveals the flag along with the message:
this is not a real DKIM header right? :)
mtf{trust_n0_3m41L}
