Author: Dave Mitchell and Adam Casella
The DNS landscape was forever changed in the fall of 2013 when ICANN approved over a thousand new gTLDs (generic top-level domains). Although this was a giant step forward “to foster diversity, encourage competition, and enhance the utility of the DNS,”1 it also opened the door to a new set of security risks for organizations with internal domains on those new gTLDs. After ICANN’s approval, the chance of selecting an internal or private domain name that collides with a publicly registered domain name became a real security risk. When an organization’s internal domain becomes publicly registered by a third party, that organization’s internal DNS lookups, and by extension, the mapping of its private infrastructure, would be sent to that third-party. This kind of information is a treasure map for attackers.
For over a decade, malicious actors have snapped up and registered internal domains, which are often lookalike domains to those of legitimate organizations. By registering a domain that is used by an organization internally, a bad actor can perform DNS adversary-in-the-middle (AitM) attacks, phish for confidential data, or exploit a known or unknown software vulnerability. This article will describe how this nefarious activity could occur, ways to mitigate it, and how Infoblox security products can help protect your organization.
Figure 1: Simplified illustration of a company asset accidentally looking up an internal corporate domain that has become hosted externally and controlled by a threat actor
Organizations may not be fully aware of their level of risk from these kinds of AitM attacks because: 1) Active Directory (AD) and general local DNS access are frequently taken for granted and assumed to “just work,” and 2) often, their internal domains like company[.]inc were chosen many years ago, long before the gTLD expansion. (ICANN is attempting to rectify this overlap by reserving TLD namespaces for private use.2) Moreover, the de-centralization of modern zero-trust network architectures also adds to the variety of risks an organization faces when its internal domains become publicly available. Table 1 below offers a list of top-level domains (TLDs) commonly used for internal domains, and whether they have become approved by ICANN as a gTLD.
| Common Internal TLD | gTLD Registered |
|---|---|
| .ad | Yes |
| .corp | No |
| .dev | Yes |
| .inc | Yes |
| .internal | No |
| .intranet | No |
| .lan | No |
| .llc | Yes |
| .local | No |
| No | |
| .network | Yes |
| .office | Yes |
| .private | No |
Table 1: Commonly used local TLDs within enterprises
Back when everyone was in the office five days a week and had inbound VPN access, the enforcement points for defining local domains were clear: configure local domains at the DNS resolver/AD layer and on the VPN concentrators. But as the perimeter has dissolved with the adoption of zero-trust networking and employees moved to accessing most resources over their web browser, the risks have increased.
DNS is complicated and has a large attack surface that is difficult to protect. Here are some of the most common areas where the risk of an external domain collision, leaked DNS queries, and by extension, mapping of private infrastructure are greatest:
- Split-Brain DNS
- VPN and Remote Access Technologies
- Browser Auto-Completion
- Email Systems (MX Records)
- SSL/TLS Certificates
- Service Discovery Protocols (mDNS, DNS-SD)
- External DNS Cache Poisoning
- Public Cloud Services
- Third-Party SaaS Integrations
- IoT Devices
Without going into the details of how all the above threats work, the key takeaway is that IT administrators should identify each of their internal domains and determine whether they are able to be (or already are) registered externally. If the domains are not yet registered publicly, IT admins can protect against leakage by acquiring and sinkholing them to public domains they own.
If you find that any of your internal domains are registered externally, attempt to acquire them via a domain broker or direct purchase. While organizations have become accustomed to registering lookalikes to prevent brand impersonation, owning their internal-turned-public domains is significantly more important from a security and risk perspective.
In some cases, you may not be able to obtain the public domain and require another way to protect your organization against DNS leaks. Infoblox Threat Defense offers the ability to use a custom list to set up a sinkhole policy that will block internal domains from recursing to authoritative DNS servers, which could potentially be owned by a malicious actor. Setting up this kind of sinkhole policy will prevent recursive lookups to an upstream authoritative DNS server on any devices that use Threat Defense Cloud.
Footnotes
- ICANN gTLD guidebook from 2012: https://newgtlds.icann.org/sites/default/files/guidebook-full-04jun12-en.pdf
- https://www.icann.org/en/announcements/details/icann-seeks-feedback-on-proposed-top-level-domain-string-for-private-use-24-01-2024-en
