Even With The Best Email Spoofing Defences in The World, HMRC is Spoofed

In September 2017, Trustwave identified a scam campaign that pretended to come from HMRC. The bad actors registered the cousin domain ‘hmirc-gov.co.uk‘ and sent emails to unsuspecting UK citizens with the subject “VAT Return Query.” The message body warns the recipient that there was an error with their online VAT return as detailed in the attachment. The extra tricky part is that there was no attachment included with the message. What appeared to be an attachment was actually an embedded HTML image with a link to a Microsoft OneDrive location. A user clicking on the “attachment” would download a file named “VAT RETURN QUERY.ZIP” from OneDrive which in turn contains a file called “VAT Return Query.pdf.jar” This Jar file contains the Java RAT malware jRAT which is a popular remote administration tool widely used by bad actors. But HMRC claims to have the most advanced email spoofing protection. How did this happen?

The best email defenses are the ones that prevent the malicious emails from ever reaching the intended recipients. Big data algorithms are successful at limiting traditional attacks where the same email is sent to millions of people. This type of SPAM is pretty obvious when viewed in aggregate and it is rare to find it in your inbox these days. But there are a lot of phishers out there spending a lot of time finding ways around these big data driven defences. Sending emails to smaller groups of people is one way that might work since it starts to look like legitimate email traffic between trusted sender and recipient. The automated tools will likely catch the email if it comes from a suspicious domain (e.g. @J8eZY5FzPJ.net) so the bad actors want to impersonate a legitimate domain. They are able to make the email look however they want, it is simple to make it appear to come from a legitimate domain like your bank, or the tax office. If you can’t trust the email what can you do?

HRMC famously implemented Domain-based Message Authentication, Reporting and Conformance (DMARC) in 2016 after several years of preparation and experimentation. In the first year, they reduced the number of spoofed emails by 300 million! At this point, it is almost impossible for the criminals to send an email from the official HRMC domain. And yet in 2017, the bad actors were distributing jRAT malware under the guise of VAT refund issues at the HRMC. How did they accomplish this? DMARC is very effective at validating emails from legitimate domains, but it cannot defend against cousin domains which look similar enough to the legitimate domain to fool people. To understand this limitation, one must first understand how DMARC works. And to understand DMARC, one must understand SPF and DKIM.

Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) were implemented to provide a way for email recipients to distinguish between legitimate and spoofed emails. The SPF record is defined by the authorized owner of a domain and identifies email servers that are authorized to send email on behalf of that domain. Phishers shouldn’t have access to these authorized email servers so if the recipient’s email system checks the SPF record and compares it against the IP address noted in the message it can identify spoofed messages. Unfortunately, there are situations where SPF might also block legitimate emails messages. For example, if you forward an email message, the IP address of the email server is changed and it would fail the SPF record check — although it is not a malicious message. Similarly, if the authorized sender hasn’t implemented SPF protection, the recipient has no SPF record to validate against. For this reason, few recipients will automatically block ALL messages that fail the SPF validation. So it is an incomplete solution.

In addition to SPF, authorized senders can leverage DomainKeys Identified Mail (DKIM) to mark their email as legitimate. With DKIM, the sender digitally signs the message which allows the recipient to verify that the message came from an authorized sender — slightly different than SPF which is validating the specific, authorized email server. As with SPF, DKIM implementations are not complete, so recipients cannot rely solely on DKIM certificates to distinguish legitimate from unwanted email. They become one more piece of information for the automated tools to make decisions with but not a comprehensive tool.

Due to inconsistent implementations of SPF and DKIM, authorized senders and recipients have been slow to completely rely on these tools. Authorized senders do not know how well the configurations are working to protect their brand from spoofing, and recipients don’t know how many legitimate emails are being dropped by their filtering tools. Domain-based Message Authentication, Reporting and Conformance (DMARC) is intended to address these shortcomings. With DMARC enabled, the authorized sender is able to provide direction to recipients on how to deal with the message when it is received. For example, if the sender has implemented SPF, the DMARC record can instruct recipients’ email filters to drop any message that doesn’t pass SPF validation. In addition, the DMARC framework provides feedback to authorized senders identifying attempts to spoof their email domain.

From the HMRC example, we see that DMARC is very effective for protecting legitimate email domains, but it still doesn’t address the threat of cousin domains that can fool unsuspecting recipients.

Even with the latest DMARC protections in place to validate emails from HMRC’s legitimate domain, the criminals were able to fool people with emails from a domain that looks very similar to the legitimate one — to a human. It is impractical to pre-authorize all email senders since email is the most common way of introduction for new companies so we need to receive an initial email to determine we wish to trust the recipient. We expect our automated tools to allow the trustworthy emails to get through and block the unwanted emails — but we don’t always know the difference ourselves until we receive the message. As good as the tools are, they will never be 100% so we will always have to rely on the human recipient for that last line of defence.