Even with the most advanced email protections in place and an entire government organization to support them, the bad actors were able to spoof Her Majesty’s Revenue and Customs (HMRC) emails to spread a Java-based remote administration tool to unsuspecting UK recipients.
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.
About the author: Steve Biswanger has over 20 years experience in Information Security consulting, and is a frequent speaker on risk, ICS and IoT topics. He is currently Director of Information Security for Encana, a North American oil & gas company and sits on the Board of Directors for the (ISC)2 Alberta Chapter.
Pierluigi Paganini is member of the ENISA (European Union Agency for Network and Information Security) Threat Landscape Stakeholder Group and Cyber G7 Group, he is also a Security Evangelist, Security Analyst and Freelance Writer.
Editor-in-Chief at "Cyber Defense Magazine", Pierluigi is a cyber security expert with over 20 years experience in the field, he is Certified Ethical Hacker at EC Council in London. The passion for writing and a strong belief that security is founded on sharing and awareness led Pierluigi to find the security blog "Security Affairs" recently named a Top National Security Resource for US.
Pierluigi is a member of the "The Hacker News" team and he is a writer for some major publications in the field such as Cyber War Zone, ICTTF, Infosec Island, Infosec Institute, The Hacker News Magazine and for many other Security magazines.
Author of the Books "The Deep Dark Web" and “Digital Virtual Currency and Bitcoin”.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.