Multiple agencies from the US government recently co-authored a joint cybersecurity advisory on North Korean threat actors abusing weak DMARC (DNS Domain-based Message Authentication, Reporting, and Conformance) records for spear phishing. The report included real examples of phishing emails and redacted headers that show us a glimpse of how the abuse might have taken place, including the effective bypass of the other two email security controls, SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).
Email Security Mechanisms, Explained Like I’m Five
Email security controls have always been a complicated and contentious topic, so here’s a simple summary. The three mechanisms to test if an email is spoofed are SPF, DKIM and DMARC. This is what they do:
- SPF specifies rules on which IP addresses can send emails on behalf of a domain
- DKIM specifies public keys that are used to validate cryptographic signatures of emails
- DMARC specifies what to do and where to report when domains in the “From” email address do not align with domains in the “MailFrom” header based on SPF and DKIM checks
SPF and DKIM are bouncers at the door that check whether your ID is real. DMARC checks if the person on the ID card matches who you are and decides what to do if someone shows up with a fraudulent ID. Without DMARC, someone else can walk in using your ID.
All three of these checks are defined through DNS records. If they are not specified, the emails can’t be checked, but the mail server can still choose to receive the email, put it in spam, or take some other action. Specifying those records will help the receiving email server decide what to do with each email.
North Korean Hackers
The joint cybersecurity advisory stated that North Korean hackers have been able to bypass SPF and DKIM checks by picking targets that didn’t have DMARC enabled. Since the domains of the spoofed email senders had weak DMARC records (set to p=none), those organizations were successfully impersonated in legitimate-looking spear phishing attacks.
Using Compromised Email to Bypass SPF and DKIM
It’s a bit difficult to tell exactly what’s going on in the above screenshot because the email headers were heavily redacted in the report, but we can take an educated guess.
It looks like there are four email addresses/accounts involved:
- The legitimate university email account (the sender’s email account)
- Expert’s receiving email (the target victim)
- Email address of the legitimate think tank staff (the spoofed email)
- Spoofed account of legitimate think tank staff (the attacker controlled email account impersonating the think tank staff), in the Reply-To header
Let’s clarify each of these email account’s relationship with the attacker. The first email, the legitimate university email account, is most likely compromised by the attacker, either via credential theft, malware, or internal network access. That’s why the email could originate from the university’s email server, passing the SPF and DKIM checks for the sending domain. It’s also possible that a web service connected to the university’s email infrastructure was abused to send arbitrary emails from a vulnerable or malicious PHP script, as shown by the X-PHP-Script header.
The expert receiving email address is the intended victim and recipient of this spear phishing attack. The email address of the legitimate think tank staff is impersonated by the attacker (it could be thought of as the “attack vector”). The attacker has no access to either of those email accounts.
Finally, the spoofed account of the legitimate think tank staff is the only email address that the attacker actually controls and operates; it could be a personal email account, or an email address with a domain that looks like the impersonated think tank organization. The domain of this email account (which is in the From header) does not match the domain of the MailFrom header, which causes a DMARC failure; however, nothing is done about it since the DMARC policy as shown in the message header is p=none which means do nothing. Because of this, the phishing email will likely arrive directly into the recipient’s inbox.
Using Shared MTAs to Bypass SPF
In the second example email, the headers only show a passed SPF check. The interesting thing is the use of a shared MTA (Mail Transfer Agent), which can be shown by a reverse lookup of the IP address 35.89.44.36 (omta37.uswest2.a.cloudfilter.net). A quick search reveals many frustrated web hosting users that have stumbled upon email delivery issues because their hosting provider sends outbound emails via the fleet of MTAs under a.cloudfilter.net, and some answers even advise they add it to their SPF record to fix the issue.
Be it compromised or shared, it looks like the MailFrom header is always different from the From header anyway, meaning the defense mechanism should be on the DMARC level. Without DMARC, SPF and DKIM controls are trivially bypassed.
The Common Thread: Bad Reply-To
Minor typos in the email, unsure if intentional or not (highlighted in pink)
The emails are mostly well-written, there are some grammatical errors that could have been written by a native English speaker in a rush. Both emails were quite long and contained some thoughtful content that would be relevant to the target audience.
The common thread is that the Reply-To headers are always spoofed emails. Since the attacker can only send emails from the spoofed addresses but not receive them (as they have no access to those inboxes), they must use similar-looking emails (via lookalike domains) or shared personal email providers to receive back any communication. In one case, they even openly stated that their corporate account will be disabled soon and that they will need to use their personal email addresses to communicate.
Weak DMARC Records in Other Organizations are the Attacker’s Weapon
The organization that needs to improve their DMARC records in this case is the owner of the spoofed sender domains (the legitimate think tank as well as the news media outlet). The unique nature of this threat lies in the fact that the vulnerable organization acts as a third-party enabling attacks on others. Typically, the vulnerable party is also the recipient of the exploit. Even if your organization has properly configured DMARC, it remains susceptible to receiving phishing emails from domains where DMARC is misconfigured.
Mitigation: How To Fix DMARC and Friends
Despite being the most effective security control for thwarting email spoofing, DMARC (RFC-7489) is often ignored because it was introduced much later than SPF and DKIM. SPF and DKIM can both be bypassed via abuse of shared or compromised infrastructure that will happily send and sign emails for attackers as shown above, allowing them to send phishing emails with spoofed From addresses.
DMARC records are DNS TXT records in the _dmarc subdomain; for example, example.com‘s DMARC TXT record would be at _dmarc.example.com. There are three policies that can be specified:
- p=none tells the receiver not to alter how they treat the messages (do nothing), which should only be used for testing purposes during initial deployment of DMARC;
- p=quarantine tells the receiver to treat them as possible spam, which usually puts them in the spam folder;
- p=reject tells the receiver to drop the messages completely
The DMARC DNS TXT record should be configured as “v=DMARC1; p=quarantine;” or “v=DMARC1; p=reject;”, along with any additional reporting directives (for example, if you use a vendor for DMARC reporting). This ensures that messages from your domain failing DMARC checks are either marked as spam or rejected.
It’s important to note that SPF and DKIM should also be implemented for DMARC to be effective, since it is SPF and DKIM that authenticates the MailFrom header domains via IP address and signature checking. Best practices recommend using a soft fail (such as a record ending in “~all”) for an SPF record when using DMARC and DKIM, instead of a hard fail (such as “-all”). A hard fail could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing happens; this is a common configuration for operators that implemented SPF first before DMARC was considered. When using DMARC, SPF soft and hard fail has identical security, but using a hard fail increases the risk of undeliverable email.
