The Perils of Expired Domains: We're Reading Your Email

When we think about attack surfaces, historical thinking has thrown us at network services, web applications, APIs and other 'fuller stack' technology layers to review for high-impact weaknesses.

But, as real attackers, we look at organisations holistically and consider anything that is exposed to the Internet or could be abused from the Internet as part of an organisation's attack surface, ranging from vulnerabilities that might exist in third-party platforms, hosted container repositories to esoteric vulnerabilities in foundational 'glue' technology.

As part of the Adversary Sight engine that powers visibility within the watchTowr Platform - we collect troves of attack surface data about our clients, for continued and continuous review - providing the foundations of our ability to identify vulnerabilities that impact an organisation at any level.

Collecting huge amounts of data affords us the benefit of being able to perform analysis at scale, and find strange(r) things. Across our client base, we track more than 200,000 hostnames (domains and subdomains). When we review this many hostnames, the DNS data we handle is also significant.

For reasons unknown, MX records - the DNS record type that facilitates the safe and timely delivery of all the emails we don't read - became a short-lived focal point.

Across our client base, we see numerous configurations - typically configurations that I would affectionately bucket under the banner of "enterprises using enterprise technology" with significant clustering. The following are good examples;

• Mimecast
• Proofpoint
• Microsoft 365
• A spattering of Google Workspace
• etc

Once we tune this information out, through the power of magic, we're free to stare at those that don't fall into my aforementioned bucket - the "wild west" of configurations if you will. This is where we see an array of different organisations using a variety of providers, some big and some small - but generally, unusual.

Within the data set, we began to see combined configurations, as demonstrated in the example below:

$ dig affectedclientdomain.com MX

; <<>> DiG 9.10.6 <<>> affectedclientdomain.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18792
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;affectedclientdomain.com.			IN	MX

;; ANSWER SECTION:
affectedclientdomain.com.	3600	IN	MX	5 affectedclientd
omain-com.mail.protection.outlook.com.
affectedclientdomain.com.	3600	IN	MX	0 mx.legacydomain.com

While organisations had moved legacy domains and systems to their legitimate cloud email provider, we began to see a significant cluster that for reasons unknown had left untouched the original MX records (with their high delivery priority) - perhaps to avoid any potential disruption?

Historical research in this space has focused on top-level domains, but as we've seen in our brief review, the dangling MX record challenge is prolific across subdomains and typically undiscovered.

Across 15-20 years, third parties go out of business, your MSP changes, or perhaps your organisation decommissioned internal mail servers and left their dedicated domain names to expire.

Within our data, we saw specified MX records for domains and subdomains, where the specified priority mail server top-level hostname had expired and was available for registration. Email for these domains and subdomains were, as a result, effectively being delivered to the fallback MX record - which was usually the existing legitimate mail provider.

$ whois legacydomain.com
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

refer:        whois.verisign-grs.com

domain:       COM

organisation: VeriSign Global Registry Services
address:      12061 Bluemont Way
address:      Reston Virginia 20190
address:      United States

...
...
..

created:      1985-01-01
changed:      2017-10-05
source:       IANA

# whois.verisign-grs.com

No match for domain "LEGACYDOMAIN.COM".
>>> Last update of whois database: 2022-08-22T15:13:45Z <<<

This left the affected domains and subdomains open to a stark reality.

A sophisticated attacker (or, unsophisticated - we're talking about registering an $8/USD domain here) could leverage this to their advantage by following simple steps:

• Registering the expired mail server hostname (legacydomain.com in our example),
• Creating a DNS A record for the specified mail server hostname (mx.legacydomain.com in our example) and thus,  
• Specifying themselves as a primary or backup MX for the organisation in question.

These actions would allow said attacker to receive email for the affected domain/subdomain (affectedclientdomain.com in our example).

A superficial suggestion would be to suggest that your organisation comprehensively verify the accuracy of the MX records specified across your domains and subdomain estate, and ensure that the specified mail servers are indeed accurate - you will likely be surprised.

But, the reality is that in a large organisation with thousands of domains and subdomains, with domains expiring every week and DNS amendments being a regular occurrence - a simple 'check' is non-trivial, non-scalable, and likely needs to be performed on a regular basis.

We believe this is an interesting example of a high-impact vulnerability that would have a material impact on any organisation - but would likely not fall into the scope of your most recent penetration test.

At watchTowr, we believe continuous security testing is the future, enabling the rapid identification of holistic high-impact vulnerabilities that affect your organisation.

If you'd like to learn more about how the watchTowr Platform, our Attack Surface Management and Continuous Automated Red Teaming solution, can support your organisation, please get in touch.