Protecting against Dangling DNS hijacking is more than good hygiene

May 29, 2024 by StrikeReady Labs5 minutes

As Sinatra famously sang, if you can make it here, you can make it anywhere. The “here”, of course, was the Big Apple Tech, and the “you” was software vulnerabilities. The gist being that if a security issue impacts large enterprises like Microsoft, other companies should take note, and run a sanity check on their own DNS infrastructure.

But perhaps we’re stretching the analogy too far and getting ahead of ourselves.

There are many forms of DNS hijacking, ranging in sophistication from “attacker with a wrench at your Registrar” to “Dan Kaminsky”. “Dangling DNS” hijacks refer to an erroneous CNAME, NS, MX, or (less commonly) an A/AAAA DNS record. In most cases, Dangling DNS misconfigurations are not a security issue! However, If the stars align in a specific error combination, these domains can be taken over by an enterprising researcher, or worse, an attacker. Here’s how it works:


Figure 1: Common causes for Dangling DNS hijacks (image created with

Example 1: The domain NS.EXAMPLE2.COM could expire, but because EXAMPLE still resolves, you may not notice. An attacker could re-register EXAMPLE2, and then could opportunistically provide the wrong responses for any record type (MX, CNAME, AAAA, etc.)

Example 2:MAILHANDLER2.EXAMPEL.COM may have never existed, and a typo was introduced at deployment time. This is not terribly rare, and we’ll highlight a current example of that below. Because by definition these are failover mechanisms, the setup will appear to work normally.

Example 3: may have been a typo, or generally point to an IP address that may be dynamic or “get-a-ble” by an attacker. A good example of this is a recent article by Sekoia: Unplugging PlugX: Sinkholing the PlugX USB worm botnet. It can be difficult, but not impossible, for attackers to grab specific IP addresses.

Example 4: Dangling CNAME records, such as for DEFUNCTMARKETINGCOMPANY.COM are the most common form of vulnerability. In this case, EXAMPLE.COM had a real business relationship with DEFUNCTMARKETINGCOMPANY, but it later terminated. That subdomain may be able to be re-assigned to the attacker, if they can convince DEFUNCTMARKETINGCOMPANY that their company name is also EXAMPLE. If the domain itself expires, it could also just be registered by the attacker, and then they could host malicious content that seems to be hosted by MARKETING.EXAMPLE.COM

To be clear, Dangling DNS != exploitable DNS. Below we can see an NS request and response for Although it is a perfect illustration of “Example 2” above — a simple typo of “glbdns → glbnds” — that does not make it exploitable. The underlying problem that results in these two queries being sporadically different is left as an exercise for the reader.

 2; IN NS
 4;; ANSWER SECTION: 3012 IN NS 3012 IN NS
 9; IN NS
11;; ANSWER SECTION: 3334 IN NS 3334 IN NS <-------👀

In the case of Microsoft, we noticed that parts of some MX records for certain Microsoft cctld domains did not exist anymore, so we simply registered them. The domains were,, and The previous resolutions can be seen below

 1dig +short MX
 6dig +short MX
11dig +short MX


Figure 2: How appeared before we reported the issue (image created with

After registering the missing domain, one could imagine the flood of inbounds. Typically, MX hijacks (or hijinx!) are only good for intercepting inbound email, because outbound mail uses a separate infrastructure. With the advent of SPF and DKIM, spoofing outbound mail can be difficult, since the MX record does not overrule a lack of appropriate TXT. However, in this case, since the target is also an outbound mail provider, we decided to see how far we could take it, within the bounds of acceptable researcher behavior. In our case, we were able to create teams accounts, share content from onedrive, and cause mail to be sent that would pass SPF/DKIM, due to how this specific spoof worked.


Figure 3: Onedrive will send the mail out directly through the “share” function



Figure 4: Showing SPF/DKIM checks “PASS”



Figure 5: Showing the ability for Teams to confirm who you are to the target

After we notified Microsoft, they addressed the issue, and the MX records now look like this:
1dig +short MX
4dig +short MX
6dig +short MX

StrikeReady helps customers detect configuration issues such as Dangling DNS, by partnering with domain intelligence providers like SilentPush. Customers can scan their infrastructure that we discover, or they can scan related infrastructure to understand third-party risk.


Figure 6: Along with Deep/Darkweb scanning, we also help detect Dangling DNS for Attack Surface Monitoring, coming Q2 '24


Figure 7: Other domains can be scanned, up to your quota limits from the partner

Disclosure timeline:

Mar 20, 2024 disclosed to MSRC

May 28, 2024 public release


The authors would like to thank MSRC for their collaboration on confirming and fixing the stated issues. Please get in touch at if you have further corrections or would like to collaborate on research in the future.