DMARC - Protecting Your Infrastructure and Users from Phishing Attacks
Technical measures have been standardized to make phishing attacks less successful, Sven Krohlas from BFK explains – they just need to be implemented.
Phishing has been a constant threat to digital infrastructure over the last few decades. It does not simply attack users, who lose data or money due to phishing campaigns, but even worse: Phishing attacks the users' trust in digital services and infrastructure. Industry sectors most commonly targeted are SAAS and webmail, payment services, financial institutions, eCommerce/retail, and telecommunication companies. The damage ranges from a few hundred Euros up to several million in targeted cases for every single successful attack. Each success allows the attackers to create even more advanced threats.
The most common way to distribute phishing links is via email. Other attack vectors – like fake advertisements – exist, but are relatively uncommon. The success of email is based on its open and decentralized structure, which on the one hand allows new participants to join the ecosystem quickly, but on the other hand creates opportunities for bad actors. Traditionally, there is no reliable way to verify that an email message is really composed by the person it claims to originate from. The email community realized this and changed the situation by creating new standards, which allow sender authentication: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC).
SPF specifies which hosts are allowed to send email for a domain. This authentication method is limited by indirect mail flows like email forwards. To make it also work reliably for those cases, additional processing steps are required at the forwarding host. DKIM cryptographically signs emails, which makes it robust to various kinds of indirect mail flows that do not change the message itself. However, it lacks a policy providing the receiver with a recommendation on what to do, if the signature check fails.
DMARC combines both technologies by checking SPF and DKIM for the user-visible sender domain and giving the recipient policy advice on how to handle unsuccessful authenticity checks. Combined with the latest extension - Authenticated Received Chain (ARC) - it handles all kinds of mail flows, even message modifying mail flows, like some traditionally configured mailing lists. In other words: It has the potential not to break traditional use cases.
Up-ramping your phishing protection
Three mechanisms of DMARC allow this technology to be ramped up, while they reduce the risk of collateral damage to a minimum. First, DMARC allows a domain owner to request reports about individual submission failures and aggregated summaries for a domain.
This means that problems can be detected early and without any negative impact on email deliverability. It is the two other mechanisms which permit the success of the first one: The DMARC policy and the proportion of messages that should be handled according to these principles. Both can be set by the domain owner. The policy option ranges from none, which tells the receiver to ignore failures, to quarantine them (which proposes the removal of messages to the spam folder), or to reject them, if the DMARC check returns a negative result.
Costs on the sender side are limited to setting up standard email technologies and monitoring incoming DMARC reports. Those provide additional insight into current phishing threats and can easily be outsourced to a service provider who takes care of the phishing sites' takedown. Setting DMARC up can be harder than expected due to many uncontrolled mail flows from various departments, which need to be identified and adjusted to be DMARC-compliant. This problem can be overcome with DMARC reporting, which also helps to avoid additional harm. ARC needs to be implemented on forwarding and receiving hosts, but not on the senders' side. According to many companies which have implemented the system for their brands, the pros include a reduction in financial damage and the costs of support caused by phishing, as well as a better domain reputation for email deliverability.
DMARC does not solve all issues that allow phishing with current email technologies. It only protects exactly the domain it has been configured for. So-called cousin, typo, or look-alike domains are not covered by DMARC. These are domains that look similar to the real one, but are nonetheless not associated with it. Examples for "mybrand.com" would be domains like mybrand-service.com, nybrand.com or rnybrand.com. To combat these, other measures, like monitoring domain registrations and spam traps for such similarities, have to be implemented.
Instead of creating new domains of a single brand every now and then, users should have the chance to get accustomed to utilizing exactly one known domain. Specific marketing campaigns could make use of subdomains like "summerdeals.mybrand.com". All these measures will also improve brand reputation. A further problem is, for instance, CEO fraud. This attack vector makes use of various methods which are much more targeted – often using insider information like company-internal wordings or knowledge about the absence of employees – to gain trust or generate a pressure situation for the victims.
However, despite these limits, DMARC forces attackers to use less successful deception tactics for general phishing campaigns. Because, by now, most large mail providers worldwide route emails with DMARC failures to the spam folder or even have a policy of rejecting outright all such phishing attempts, and users are more likely to detect these fraudulent messages.
Quarterly APWG phishing reports: https://antiphishing.org/trendsreports/
DMARC RFC: https://tools.ietf.org/html/rfc7489
ARC RFC: http://arc-spec.org/
Sven Krohlas is an email expert and security consultant at BFK edv-consulting GmbH in Karlsruhe, Germany.
Please note: The opinions expressed in Industry Insights published by dotmagazine are the author’s own and do not reflect the view of the publisher, eco – Association of the Internet Industry.