Are organizations giving more than they should?

There are several directions an organization can take when naming critical digital properties. A classic tactic is to use a common theme, such as animal names, planets, or colors. A technical director suggested name the database nodes after the characters “Game of Thrones (GoT)”. Taking this route creates an obscure naming system that would be difficult for others to guess.

However, we don’t always see companies implementing this tactic today, at least not when it comes to populating DNS records. It can be argued that with hundreds of domain and DNS records and other digital properties that an organization can own or manage, there can only be a limited number of animal names, dog breeds and GoT characters. Also, what if the employee who appointed the systems leaves the company without going through an appropriate rotation process? It would take some time to understand what these names refer to.

Switching to a more descriptive name

Many administrators use Web server names, locations, vendor names, and other descriptive naming systems. These names can be more difficult to remember and type, but you don’t have to guess what they’re used for. This naming mechanism is practical and scalable, two essential qualities to look for in a system.

While this strategy may be ideal for properties that are only accessible internally, applying the same tactic can be detrimental to publicly available data, such as the contents of DNS records.

Putting “Citrix” or “Linux” on your TXT record, for example, can cause malicious actors to check for vulnerabilities in those systems. Due to the DNS record values, attackers’ discovery efforts are shortened and their initial attack can be deployed earlier.

We have seen the same tendency for overly descriptive naming in all subdomains. Over 96,000 subdomains have been named after their cloud service providers, revealing some of the targets’ infrastructure to competitors and threat actors.

Examples of Descriptive DNS Record Content

We found several domains and subdomains with highly descriptive TXT values, such as “XenApp server 03 Citrix” and “Xen Citrix Test platform”. While this naming system is convenient for administrators, it could expose organizations to known and unknown vulnerabilities (zero days) related to these systems. Here is a screenshot of the reverse DNS lookup result:

We found a similar scenario for several organizations using Linux, which also has exploitable vulnerabilities:

To further analyze how often software and vendor names appeared in DNS records, we looked at DNS data feeds dated October 25-31, 2021, which contained a total of 1,048,576 records.

Three of these names refer to commonly used systems (Linux, Sharepoint and Fortinet). The other three are communication platforms that are generally part of shadow IT: Skype, Discord and Slack.

Implementing a naming system requires planning, regardless of the machines to which it will apply (database nodes, servers or DNS records). While selecting nondescript names can lead to greater operational complexities than naming properties as they are, here is a non-exhaustive list of term categories that probably reveal a bit too much about your digital infrastructure:

• Server names
• Names of software / IT infrastructure providers
• Names of Marketing Software Vendors
• Names of communication tools, such as chat applications
• Content Management System (CMS) Names

Please feel free to contact us if you would like to learn more about how the DNS intelligence of the WhoisXML API can help uncover the content of DNS records that are too descriptive to support attack surface management efforts.