Breaking security controls using subdomain hijacking

Users obtain a domain name to establish a unique identity on the Internet. Domain names are not only used to serve names and addresses of computers and services but also to store security controls, such as SPF or CAA records. Many of the Internet protocols were designed at a time where built-in security was not a requirement. The IETF continues to standardize protocol extensions to address today’s security needs.

For some protocols security is added with controls stored in your domain names zone file. In order to have the desired effect, the pre-condition is of course that your domain name is secure. In other words, the security of your application that makes use of controls in DNS is only as secure as the security of your domain name.

Hijacking a domain name because of weak credentials at the registrar may get the job done but this is far from stealthy and will likely not last long. In many cases it is sufficient to hijack an abandoned subdomain. Taking over abandoned subdomains may be unnoticed by the owner for a very long period of time making it also very useful for targeted attacks.

Hijacking of an abandoned subdomain

Many organisations have a process on how employees can add a hostname or a subdomain to the company’s domain name. However, commonly they don’t have any process that cleans up hostnames or subdomains once they are not used anymore.

The simplest case of a subdomain hijack is to look for abandoned delegations (record type NS) or aliases (record type CNAME). In both cases, the authority of the owner name (the subdomain) is delegated to the DNS records target. In a DNS zone file such records could look as follows:

; ft.com NS delegation
update.ft.com. NS ns03.interelate.net.

; deutsche-bank.de CNAME alias
bildung.deutsche-bank.de. CNAME www. ahg-bildung.de.

To hijack the “update.ft.com” or “bildung.deutsche-bank.de” subdomain they must both point to a target where the domain name is not registered. An attacker then only needs to register the target domain name to also claim ownership of update.ft.com or bildung.deutsche-bank.de.

The small shop or restaurant across the street will very likely not have this problem. Their zone file only consists of a few records for mail and www in most cases. However, large organisations with thousands of records in their zone file very likely have many such abandoned records. With the ongoing trend to outsource IT services, organisations create delegations and alias records in their zone files more than ever.

Finding abandoned subdomains

If one of the authoritative name servers for the target domain name allows public zone transfer access, this is a mechanism typically used by name servers to keep the zone file synchronised, then one can simply download the whole zone file and test every record if it still resolves. However, very few name servers are configured in such a way.

There are other ways to get as many hostnames of a domain name as possible: For hostnames that have a TLS certificate, Certificate Transparency (CT) logs are a useful source. Internet wide scanning efforts such as by Censys.io could be another source. However, the most useful source of data is likely from Passive DNS replication systems. Passive DNS replication is a technology which constructs zone replicas without cooperation from zone administrators. It uses sensors on recursive name servers to log received responses.

Abusing abandoned subdomains

Having control over a subdomain of a targeted domain name can be used to setup up a phishing website or other fake content. To make it more effective, one can also request a TLS certificate for it. Remember, most TLS certificates are domain validated and controlling the subdomain lets you get a TLS certificate for it.

TLS certificates do not provide trust but encryption

Certificate authorities have started checking the domain names Certification Authority Authorization (CAA) record if it exists. This is a policy stored in the DNS zone file where the domain owner can limit which Certificate Authorities are allowed to issue certificates for it. However, if you control a subdomain you can publish a more specific CAA record on the subdomain itself. So, it does not restrict a subdomain owner from requesting a TLS certificate from any Certificate Authority.

; CAA policy
googleusercontent.com. IN CAA 0 issue "pki.goog"


The above example CAA policy for googleusercontent.com only allows the Google Trust Services certificate authority to issue certificates for the domain or any subdomain of googleusercontent.com unless a subdomain overwrites that policy.

Breaking anti mail spoofing protections

An organisation that registers a domain name and uses it for email communication does not by default prevent any other host on the Internet from abusing that domain name in spoofed email messages. Several IETF standards such as SPF, DKIM and DMARC help prevent email sender address spoofing. The policy (aka the control) of these standards is stored in the owner’s domain name.

To effectively prevent email sender address spoofing you would need to at least implement SPF and DMARC. Let’s quickly summarise how these standards work. Note, for operational flexibility we also recommend to implement DKIM (not discussed here any further).

The Sender Policy Framework (SPF) protocol can be used by a domain owner to explicitly authorise hosts that are allowed to use the domain name in the “MAIL FROM” (also called envelope from/return-path) part of a message. The SPF policy is typically stored in a TXT record type on the domain name e.g. deutsche-bank.de TXT:

deutsche-bank.de. IN TXT "v=spf1 ip4:160.83.0.0/16 ip4:129.35.231.144/28 -all"

It specifies that only the listed IP address ranges are allowed to send email messages with the sender domain name deutsche-bank.de in the “MAIL FROM”.

With DMARC (Domain Message Authentication Reporting & Conformance) you can publish a policy for your domain name that evaluates both SPF and DKIM. For SPF it provides the additional requirement that the envelope from domain needs to be in alignment with the header from domain. That’s exactly what we are looking for when we want to prevent sender address spoofing. Let’s look at the DMARC policy from deutsche-bank.de:

_dmarc.deutsche-bank.de. IN TXT "v=DMARC1; p=reject; rua=mailto:deutsche-bank@rua.agari.com; ruf=mailto:dmarc.reports@db.com; ri=3600"

The important part of the DMARC policy is the tag name “p” which defines the requested handling policy by the domain owner. It specifies that receiving mail server that evaluates this DMARC policy must reject messages, which are not in alignment with this policy.

A DMARC policy also defines implicit default options. Important regarding subdomain handling is that DMARC permits domain name alignment to be strict or relaxed (default). In strict mode, only an exact DNS domain match of the SPF-authenticated domain and the “Mail From” domain is considered to be in alignment with the DMARC policy. In relaxed mode, the SPF-authenticated domain can also belong to a subdomain. This behaviour is also well documented in the RFC standard (See RFC 7489, 10.4. Identifier Alignment Considerations).

Spoofing email sender addresses

Let’s look at the most common cases:

For domain names that do not use SPF, DKIM or DMARC no controls prevent any host on the Internet from abusing that domain name in spoofed email messages.

For domain names that only use an SPF policy, the attacker can use another envelope from address and spoof only the header from address to match the target organisation (See Picture 3 above). Some email clients may show both envelope from and header from address if the domain name does not match though.

For domain names that use both SPF and DMARC but with the default SPF-alignment mode relaxed, the attacker needs to hijack a subdomain of the target domain name first and then publish a SPF policy on this subdomain that includes the attackers host (See Picture 4 below).

The screenshot below shows a spoofed message created as shown in Picture 4 above. It is abusing the hijacked subdomain bildung.deutsche-bank.de to send a message to Google Mail. Google Mail validates both SPF and DMARC and proves that the attack worked.

Conclusion and Recommendations

Hijacking of subdomains is often possible against large zone files and these domain names are typically also the ones interesting to attack in the first place because they belong to large enterprises.

If you have a security control which relies on DNS, then it’s only as secure as your DNS. To prevent the attacks described we recommend that you regularly check your zone content for unresolvable hostname records. This github project contains a simple check script that can be used on your own zone files.

DNSSEC signing your domain name does also prevent some of the listed attacks (e.g. delegation hijack of update.ft.com) and is strongly recommended if you want to take DNS security seriously.