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 d2lang.com)

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:11.34.58.78 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 messaging.microsoft.com. 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.

 1;; QUESTION SECTION:
 2;messaging.microsoft.com. IN NS
 3
 4;; ANSWER SECTION:
 5messaging.microsoft.com. 3012 IN NS ns2-gtm.glbdns.o365filtering.com.
 6messaging.microsoft.com. 3012 IN NS ns1-gtm.glbdns.o365filtering.com.
 7
 8;; QUESTION SECTION:
 9;messaging.microsoft.com. IN NS
10
11;; ANSWER SECTION:
12messaging.microsoft.com. 3334 IN NS ns2-gtm.glbdns.o365filtering.com.
13messaging.microsoft.com. 3334 IN NS ns1-gtm.glbnds.o365filtering.com. <-------👀

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 microsoft.com.ar, microsoft.com.py, and microsoft.com.uy. The previous resolutions can be seen below

 1dig +short MX microsoft.com.uy
 25 maila.tpar.com.ar.
 38 mailb.tpar.com.ar.
 410 mail.microsoft.com.uy.
 5
 6dig +short MX microsoft.com.ar
 710 mx1.sdp.com.ar.
 82 mailb.tpar.com.ar.
 91 maila.tpar.com.ar.
10
11dig +short MX microsoft.com.py
122 mailb.tpar.com.ar.
131 maila.tpar.com.ar.

Figure 2: How microsoft.com.ar appeared before we reported the issue (image created with d2lang.com)

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.

1dig +short MX microsoft.com.uy
210 mail.microsoft.com.uy.
3
4dig +short MX microsoft.com.ar
5<none>
6dig +short MX microsoft.com.py
7<none>

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

Acknowledgements

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.