The UK’s National Cyber Security Centre (NCSC) reported that in the past year, it has stopped 140,000 phishing attacks and taken down more than 190,000 fraudulent websites. In its second annual report on the Active Cyber Defence (ACD) program, the NCSC details how its use of Synthetic DMARC has stopped sophisticated phishing operations, including one in which hackers used a gov.uk domain to impersonate an airline organization.
While this approach of synthesising DMARC records has proven to be effective in stopping spoof email campaigns so far, the NCSC’s report also describes it as “an evil hacky kludge,” adding that more needs to be done to express policy ownership in domain hierarchies.
Here, we address the shortfalls of DMARC and email authentication records, and consider what more can be done to stop strong-form impersonation attacks.
95% of all attacks on enterprise networks are the result of successful spear phishing, which often involves an attacker directly impersonating the email domain of the receiver. For example, any attacker could send an email from your business email domain to an employee at your business, and the recipient would have no way to validate the sender’s authenticity in the absence of authentication records.
SPF and DKIM are email authentication records that, in short, allow email clients to validate the domain name of an inbound email. DMARC enables organizations to specify how the client responds to emails that fail SPF or DKIM checks (generally reject, quarantine, or no action.) SPF, DKIM, and DMARC are essential for preventing direct impersonation of your organization’s email domain.
All email domains – especially those of trusted brands – are at risk of direct domain impersonation, regardless of past threat activity.
However, DMARC has its downsides. And while the NCSC has encouraged more UK businesses and government agencies to adopt DMARC, the report doesn’t shy away from bringing these shortfalls to light.
The NCSC report states that “for any enterprise of a decent size, implementing DMARC is often a long process” and that “implementing DMARC is a lot harder than people will have you think.”
Strict DMARC policies can, if misconfigured, block the delivery of real, legitimate emails. As a result, the ACD recommends organizations take time to digest DMARC reports and investigate the nuances of their mail infrastructure, before gradually moving to a more protective DMARC policy. Unfortunately, this process takes many organizations well over a year.
DMARC, SPF, and DKIM records are inherently public information – they need to be so that receiving mail clients can authenticate a sender’s domain. Attackers can see not only if your organization has a DMARC policy, but also how strictly you have configured it.
Before trying to impersonate your email domain directly, a sophisticated attacker will check if you have a strict DMARC policy in place. If you do, the attacker can still carry out an advanced spear phishing attack.
For example, DMARC doesn’t protect against indirect impersonation, or domains that are similar to yours (e.g. @tassian.com, @tessian.outbound.com, @tessian.email). There are thousands of ways an attacker can make a new domain look similar enough to your domain to fool members of your organization. These new, legitimate domains are unprotected by DMARC.
Perhaps because of DMARC’s public nature and the vulnerability of indirect impersonation, ACD data has yet to establish a causal link between increased DMARC adoption and decreased phishing.
Configuring DMARC and other email authentication records are necessary measures for preventing attackers from directly impersonating your organization’s email domain. Unfortunately, a high percentage of the emails your employees receive likely come from the domains of other organizations, such as partners, vendors, customers, and government bodies.
Given that other organizations are unlikely to have authentication records in place, employees remain vulnerable to direct impersonation of their external contacts. Email authentication records and policies, then, are only a small piece of the puzzle for protecting your organization against spear phishing attacks.
Impersonation is a difficult problem to solve. To accurately detect it, you need to understand what is being impersonated. You need to be able to answer the question, “for this user, at this point in time, given this context, is the sender really who they say they are?” Tessian Defender uses stateful machine learning models to analyze historical email data and understand relationship context, which means we can automatically detect the impersonation of both internal and external parties.