Domain names are some of the most highly-prized assets for brands today. The trust placed in an authoritative domain name can lend organizations valuable legitimacy and support brand reputation. The problem? An attacker with a computer and a few minutes to spare can impersonate that domain over email, putting an organization’s hard-won reputation in danger.
Email impersonation attacks have disastrous consequences for enterprises. Whether it’s the threat of severe financial loss, the leakage of sensitive data, or of deep damage to brands and reputations, the risks to businesses of impersonation and spoofing are ever-present, and growing by the day.
The most worrying thing for cybersecurity leaders is that attackers do not have to execute especially difficult or sophisticated techniques for their cyberattacks to have an outsize impact on organizations. This blog will cover some of the simple methodologies cybercriminals are employing to impersonate domain names – a powerful impersonation technique that is used by attackers all over the world to target enterprises. (Read our previous blog in this series, on display name impersonation, here.)
If you’re interested in learning how criminals infiltrate enterprise networks and extract money, data and credentials from organizations around the world, just read through this guide to domain impersonation attacks and how they impact email security.
Let’s begin with what a domain actually does. It all starts with IP addresses, which are numeric codes used to identify network activity on individual computers. Domains were originally developed as a way of making IP addresses easier to remember and identify.
Today, domain names are used to define ownership of particular properties on the internet, like websites and email addresses. Domains can be purchased and registered using a hosting site or registrar. (More on the different parts of domains, and their vulnerabilities, later). By registering a domain, individuals and companies can be sure that when someone visits the domain www.tessian.com, or sends an email to [email protected], they will be interacting or communicating with Tessian.
Or can they? If only it was that simple.
Attackers penetrating organizations’ defenses by spoofing emails (i.e, forging an email by modifying the email address from which the email appears to have been sent) is a growing threat. Even as awareness of the threat grows, though, there are several ways for attackers to take advantage of lax enforcement of the protocols that govern domain identification.
In 2000, SPF became the first protocol that allowed domain owners to specify which IP addresses could send email from a given domain. Recent years have seen growing adoption of newer authentication protocols, first DKIM (DomainKeys Identified Mail) and later DMARC (Domain-based Message Authentication, Reporting & Conformance).
DKIM is a complex authentication protocol that uses cryptographic encryption to give each email sent from a domain a “signature”. The most recent protocol to have become a widely-accepted standard is DMARC. DMARC gives organizations that have already set up SPF and DKIM an extra level of security. DMARC validates that both SPF and DKIM authentications have completed successfully, and also lets senders tell other email providers what to do with emails that fail authentication.
However, all is not as rosy as it seems. Key structural problems with authentication mean that it is very easy for malicious actors to work around protocols. First among these difficulties is the scale of adoption. As of 2019, roughly 80% of large enterprises have “no DMARC policy in place.”
Because authentication protocols are in the public domain, it’s easy for attackers to identify which firms do or do not have policies in place. As Tessian’s Laura Brooks previously wrote in a blog on DMARC:
DMARC’s settings let sending domains tell recipients to quarantine, block or passively monitor any emails that fail SPF and/or DKIM authentication (ie, the emails that could be spoofing the sending domain). But having DMARC set up doesn’t necessarily afford enterprises the flexibility they need.
Let’s use the example of a big bank that works with several different law firms. As is the case in many industries, relationships between banks and their professional services suppliers are often disclosed in press releases and other media coverage. It is very simple for an attacker to find out whether any of the bank’s legal partners have failed to configure DMARC correctly. The attacker would then be free to spoof these law firms’ domains and target the bank, knowing that any communications would be likely to reach their intended targets given the flaws in many traditional Secure Email Gateway (SEG) products.
For businesses whose DMARC policies aren’t set to block or quarantine messages, emails that fail DMARC checks will still be delivered to their intended recipients. This threatens email security. But many businesses simply can’t risk missing important and legitimate communications by using DMARC’s quarantine or block settings.
The only way the bank’s – or any other organization’s – email infrastructure can be truly secure is for all third party suppliers and partners to also have DMARC configured to reject or quarantine non-compliant emails. Working within these unrealistic conditions, the only way to reliably identify impersonations is to focus on behavioral and relationship patterns within email communications – something legacy security companies do not offer.
While there are still such fundamental gaps in the security infrastructure of global businesses, this leaves enterprises vulnerable to many of the same issues that plague employees and security leaders – DMARC or no DMARC.
Impersonating an organization’s domain in a spear phishing email is just one way for attackers to get past organizations’ defenses. But what domain impersonations do attackers rely on? There are three main kinds of domain impersonation that are regularly exploited in cybercriminal scams.
Before selecting a top-level domain, organizations usually stipulate which root domain they want to represent them. Put simply, this is the “branded” part of a web address – the “tessian” in tessian.com. However, even owning a root domain does not prevent impersonations. Attackers may substitute characters in the root domain (see the image below, where an “l” has been turned into a “1”), or even by using characters from other alphabets. The Cyrillic alphabet’s “а” looks identical to an English “a” but will not be treated as such by a computer.
Another strategy might be to register a domain that appears to be an “extension” of the targeted company’s regular root domain. Using dashes, for example, attackers can give the appearance of a functional subdomain that could easily trick a busy or distracted employee. At Tessian, we’ve registered the root domain to demonstrate the value of defending against these kinds of impersonations. Otherwise, attackers could add “company” subdomains to the root domain and easily create a convincing impersonation.
Top-level domains are the parts of web addresses that follow root domain names. Some of the most widely-known are .com, .net, .org, and so on. In recent years, many more top-level domains have come to market. Individuals and organizations can register domains using extensions like .work, .finance or even .pizza. The example below shows a potential domain impersonation where an attacker has registered the .io domain. If the organization in question has not configured DMARC, the name of the organization being impersonated can be absolutely identical to the “genuine” brand name.
Just because a brand might own the .com and .co.uk top-level domains doesn’t mean it automatically owns all possible alternatives. Attackers thereby have more opportunities than ever to register and impersonate “legitimate” root domains with new top-level domains. Finding and registering a top-level domain that ties in with the purpose of the organization in question – .finance might work for a bank, for instance – gives attackers a simple way to impersonate that company and target its employees, customers or suppliers.
Subdomains can be employed to distinguish different services from one another within an overarching website structure. They are separated from the main root domain with periods. If you’ve ever visited an online property with a prefix like , you’ll have interacted with a subdomain.
Using subdomains also raises the likelihood of confusing which domain constitutes the original “root”. A good example might be the address <[email protected]>. The root domain, , is positioned directly before the .com top-level domain. Here, “tessian” is a subdomain, but as it appears first and potentially looks legitimate, the address could be convincing to an employee.
As with root domains, owning a domain name does not prevent malicious actors from deploying authentic-looking subdomains. Registering , for instance, might give attackers a legitimate-seeming but separate domain by which to impersonate employees and third parties affiliated with the company in question.
A cunning example of subdomain impersonation is shown in the below example. Here, someone impersonating a third party supplier has used subdomains to break a legitimate company’s brand name into two, creating the domain.
The bottom line of all this? Effectively, anyone in control of an email server can dupe recipients into thinking a fraudulent email is legitimate, easily bypassing SEGs and other security protocols. In many ways, email attacks have never been easier.
It might seem alarming that impersonating a domain is so easy to accomplish. The reason impersonations are so surprisingly simple is down to deficiencies in the legacy email security services many organizations employ to defend against them. Attackers know all about the flaws and loopholes in SPF, DKIM and DMARC, and about the ways in which domain registrations can be exploited. These email threats are not going away.
Organizations need to move away from network and endpoint security frameworks and embrace technologies that tackle the heart of the issue: the impersonation itself. Tessian Defender takes into account factors like an email’s language, and the historic relationship between the email’s sender and receiver, in order to judge whether an email could be the product of an impersonation.
If Tessian judges that an impersonation is taking place, real-time contextual notifications are placed within the email client, warning the employee that something looks fishy. The final decision on whether or not to proceed as normal is down to the employee.
Tessian learns and adapts to threats by focusing on people’s behaviors and relationships, preventing advanced impersonation spear phishing attacks and other forms of security risk like data exfiltration and data breaches caused by human error. Speak to an expert and learn more here.
