We’ve previously written a lot about DMARC, and despite the protocol having been in existence since 2011, it really did not enter into the spotlight as a mainstream email security solution until DHS jumped on the bandwagon late in 2018.
Perhaps the primary reason that the protocol had been relatively unknown to the masses is that many in the security community recognize that it serves only one purpose: to validate exact domains in order to prevent domain spoofing attacks. It is important to distinguish that DMARC does not protect against business email compromise (BEC) attack techniques other than exact domain spoofing.
Thus, popular BEC attacks, such as display name spoofing and domain impersonation, which occur far more frequently than exact domain spoofs, are immune to DMARC controls. As such, DMARC represents just one small piece to the very complex email security puzzle.
The Emergence of Brand Spoofing Propels Interest in DMARC
A complex type of email phishing, brand spoofing, is a technique used by cyber criminals to trick someone into performing a nefarious act. According to Verizon’s 2020 Data Breach Investigations Report (DBIR) 96% of all social attacks arrive via email.
Email threats in general date back to the early 2000s; everyone with a mailbox has received such messages. But the proliferation of advanced brand spoofing attacks is relatively new and not readily detectable by traditional email security tools, such as secure email gateways (SEGs). This has left many public and private sector organizations not just vulnerable to brand spoofs, but also unable to implement the phishing protection needed for mitigation, leaving humans as the only difference between detonation or neutralization.
In response to the growth of brand spoofing as an attack technique, organizations have begun to adopt DMARC as an outbound layer of email security to help authenticate senders, although a large percentage ~94% of domains remain unprotected by DMARC. According to TechRepublic 1 in 5 enterprises have DMARC setup with an enforcement policy
But the increased emphasis on DMARC has many in the cybersecurity community scratching their heads. That’s because DMARC does effectively nothing to help prevent, detect and respond to any type of social engineering techniques, such as spear-phishing, pretexting and whaling, nor does it protect against impersonation attacks, such as display name spoofing and cousin domains (e.g. domain look-alikes); all of which occur far more frequently than the expensive and time-consuming domain spoofing attacks that DMARC is designed to stop.
According to our research from earlier this year, exact domain spoofs and cousin domain spoofs only account for 2-3% of all email phishing attacks.
- Exact sender name impersonations (73.5%) - When an email is sent masquerading as coming from a trusted source, such as a colleague.
- Similar sender name impersonations (24%) - When an email is sent masquerading as coming from a trusted source, such as a colleague, with minor obfuscations.
- Look alike/cousin domain spoofing (2%) - When an email is sent from a similar domain, in which attackers register the domain to set the right authentication records in the DNS.
- Exact domain spoofs (.5%) - When an email is sent from a fraudulent domain that matches exactly to the spoofed brand’s domain.
In this three-part blog series, we’ll dissect and explore DMARC; emphasize what it is and what it isn’t, highlight its benefits and debunk some of the exaggerations propagating as a result of increased awareness and savvy vendor messaging.
Understanding the Acronyms – An Initial Overview of DMARC, SPF & DKIM
DMARC builds on the existing Simple Mail Transfer Protocol (SPF) and DomainKeys Identified Message (DKIM) compliance.
Here’s what you need to know:
- SPF works at the Simple Mail Transfer Protocol (SMTP) level.
When a message is received, it performs a basic check against the Domain Name System (DNS) to determine if the sending Internet protocol (IP) address is authorized to send emails.
- DKIM verifies the domain and where the email was sent from, instead of simply checking the IP address.
A public key is published in the senders DNS record, and a private key is assigned to all outbound messages.
When received, the keys are checked to make sure that they match, confirming that the message was sent by the domain and that it has not been tampered with in transit.
Rules can be set for received messages that, should an SPF or DKIM check fail, the message is automatically marked as Spam and not passed through the gateway and to the mailbox.
DMARC builds on SPF and DKIM with the aim to protect both senders and receivers by preventing phishers from performing direct domain name spoofing, such as firstname.lastname@example.org
An organization can indicate that all its messages are protected by SPF and/or DKIM and stipulate what should happen should an authentication fail – for example forward to a ‘spam’ folder or reject the message outright. In addition, the organization can ask that the receiver report messages that fail the DMARC Check.
The underlying responsibility of DMARC is policy enforcement. Therefore, if SPF and DKIM are not properly implemented by both sender and receiver, then DMARC cannot be effective at limiting domain spoofing attacks. With this in mind, spoofs of agency to agency communications within the U.S. government might be reduced through DMARC adoption, but communications to any private sectors organizations not adhering to DMARC remain vulnerable to all types of email phishing attacks. Just ask former Hilary Clinton campaign John Podesta, who fell victim to a complex nation-state spear-phishing campaign that DMARC would not have been prepared to stop.
In part two of this blog series, we’ll look at the interdependencies of SPF, DKIM and DMARC, explore the limitations and vulnerabilities of each, and identify the unintended consequences of DMARC adoption.
MARKET GUIDE FOR