Blog

Initial phish

Protecting against Dangling DNS hijacking is more than good hygiene

StrikeReady Labs Research May 29, 2024 by Alex Lanstein

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:

Initial phish

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.
                

Dialog box that pops when the ELF is run

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.

Onedrive SPF/DKIM Teams

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  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.

Initial phish

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

Initial phish

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 the reviewers, as well as peer vendors, for their comments and corrections. Please get in touch at research@strikeready.com if you have corrections, or would like to collaborate on research.

Social Icon

Alex Lanstein

Chief Evangelist

Alex Lanstein is the Chief Evangelist at StrikeReady, running threat research and driving DFIR platform capabilities. Previously, Alex spent 15 years at FireEye, closing the loop between threat actor observations and product development.

Related posts

Armageddon is more than a Grammy-nominated album

Russian government hackers continue to leverage novel techniques for defeating automated analysis systems. In this blog, we examine a simple html trick for waiting for a user to jiggle the mouse before executing the malicious javascript.

June 24, 2024

Finding the unknown unknowns, part 1

This is the first article in a series about technical hunting wins that are attainable by all SOC teams.

April 20, 2024

Stealing your email with a .txt file

A blog that describes tracking a targeted threat actor using StrikeReady, passive dns, ssl certificates, and malware analysis.

January 17, 2024

See StrikeReady in Action

Request your StrikeReady demo today.