Analyzing DNS TXT Records to Fingerprint Online Service Providers

DNS reconnaissance is an important part of most external network penetration tests and red team operations. Within DNS reconnaissance there are many areas of focus, but I thought it would be fun to dig into DNS TXT records that were created to verify domain ownership. They’re pretty common and can reveal useful information about the technologies and services being used by the target company.

In this blog I’ll walkthrough how domain validation typically works, review the results of my mini DNS research project, and share a PowerShell script that can be used to fingerprint online service providers via DNS TXT records. This should be useful to red teams and internal security teams looking for ways to reduce their internet facing footprint.

Below is an overview of the content if you want to skip ahead:

• Domain Ownership Validation Process
• Analyzing TXT Records for a Million Domains
• Top 5 Service Provider Categories
• Top 25 Service Providers
• Automating Domain Validation Token Fingerprinting
• How can domain validation tokens be used for evil?

Domain Ownership Validation Process

When companies or individuals want to use an online service that is tied to one of their domains, the ownership of that domain needs to be verified.  Depending on the service provider, the process is commonly referred to as “domain validation” or “domain verification”.

Below is an outline of how that process typically works:

1. The company creates an account with the online service provider.
2. The company provides the online service provider with the domain name that needs to be verified.
3. The online service provider sends an email containing a unique domain validation token (text value) to the company’s registered contact for the domain.
4. The company then creates a DNS TXT record for their domain containing the domain validation token they received via email from the online service provider.
5. The online service provider validates domain ownership by performing a DNS query to verify that the TXT record containing the domain validation token has been created.
6. In most cases, once the domain validation process is complete, the company can remove the DNS TXT record containing the domain validation token.

It’s really that last step that everyone seems to forget to do, and that’s why simple DNS queries can be so useful for gaining insight into what online service providers companies are using.

Note: The domain validation process doesn’t always require a DNS TXT entry.  Some online service providers simply request that you upload of a text file containing the domain validation token to the webroot of the domain’s website.  For example, https://mywebsite.com/validation_12345.txt.  Google dorking can be a handy way to find those instances if you know what you’re looking for, but for now let’s stay focused on DNS records.

Analyzing TXT Records for a Million Domains

Our team has been gleaning information about online service providers from DNS TXT records for years,  but I wanted a broader understanding of what was out there.  So began my journey to identify some domain validation token trends.

Choosing a Domain Sample

I started by simply grabbing DNS TXT records for the Alexa top 1 million sites.  I used a slightly older list, but for those looking to mine that information on a reoccurring basis, Amazon has a service you can use at https://aws.amazon.com/alexa-top-sites/.

Tools for Querying TXT Records

DNS TXT records can be easily viewed with tools like nslookup, host, dig, massdns, or security focused tools like dnsrecon .  I ended up using a basic PowerShell script to make all of the DNS requests, because PowerShell lets me be lazy. 😊  It was a bit slow, but it still took less than a day to collect all of the TXT records from 1 million sites.

Below is the basic collection script I used.

# Import list of domains
$Domains = gc c:tempdomains.txt

# Get TXT records for domains
$txtlist = $Domains |
ForEach-Object{
    Resolve-DnsName -Type TXT $_ -Verbose
}

# Filter out most spf records
$Results = $txtlist  | where type -like txt |  select name,type,strings | 
ForEach-Object {
    $myname = $_.name
    $_.strings | 
    foreach {
        
        $object = New-Object psobject
        $object | add-member noteproperty name $myname
        $object | add-member noteproperty txtstring $_
        if($_ -notlike "v=spf*")
        {
            $object
        }
    }
} | Sort-Object name

# Save results to CSV
$Results | Export-Csv -NoTypeInformation dnstxt-records.csv

# Return results to console
$Results

Quick and Dirty Analysis of Records

Below is the high level process I used after the information was collected:

1. Removed remaining SPF records
2. Parsed key value pairs
3. Sorted and grouped similar keys
4. Identified the service providers through Google dorking and documentation review
5. Removed keys that were completely unique and couldn’t be easily attributed to a specific service provider
6. Categorized the service providers
7. Identified most commonly used service provider categories based on domain validation token counts
8. Identified most commonly used service providers based on domain validation token counts

Top 5 Service Provider Categories

After briefly analyzing the DNS TXT records for approximately 1 million domains, I’ve created a list of the most common online service categories and providers that require domain validation.

Below are the top 5 categories:

There are many other types of services that range from caching services like Cloudflare to security services like “Have I Been Pwned”, but the categories above seem to be the most ubiquitous. It’s also worth noting that I removed SPF records, because technically there are not domain validation tokens.  However, SPF records are another rich source of information that could potentially lead to email spoofing opportunities if they aren’t managed well.  Either way, they were out of scope for this blog.

Top 25 Service Providers

Below are the top 25 service providers I was able to fingerprint based on their domain validation token (TXT record).  However, in total I was able to provide attribution for around 130.

Automating Domain Validation Token Fingerprinting

To streamline the process a little bit I’ve written a PowerShell function called “Resolve-DnsDomainValidationToken”.  You can simply provide it domains and it will scan the associated DNS TXT records for known service providers based on the library of domain validation tokens I created.  Currently it supports parameters for a single domain, a list of domains, or a list of URLs.

Resolve-DnsDomainValidationToken can be downloaded HERE.

Command Example

To give you an idea of what the commands and output look like I’ve provided an example below.  The target domain was randomly selected from the Alexa 1 Million list.

# Load Resolve-DnsDomainValidationToken into the PowerShell session
IEX(New-Object System.Net.WebClient).DownloadString("https://raw.githubusercontent.com/NetSPI/PowerShell/master/Resolve-DnsDomainValidationToken.ps1")

# Run Resolve-DnsDomainValidationToken to collect and fingerprint TXT records
$Results = Resolve-DnsDomainValidationToken -Verbose -Domain adroll.com  

# View records in the console
$Results

For those of you that don’t like starring at the console, the results can also be viewed using Out-GridView.

# View record in the out-grid view
$Results | Out-GridView

Finally, the command also automatically creates two csv files that contain the results:

1. Dns_Txt_Records.csv contains all TXT records found.
2. Dns_Txt_Records_Domain_Validation_Tokens.csv contains those TXT records that could fingerprinted.

How can Domain Validation Tokens be used for Evil?

Below are a few examples of how we’ve used domain validation tokens during penetration tests.  I’ve also added a few options only available to real-world attackers due to legal constraints placed on penetration testers and red teams.

Penetration Testers Use Cases

1. Services that Support Federated Authentication without MFA
   This is our most common use case. By reviewing domain validation tokens we have been able to identify service providers that support federated authentication associated with the company’s Active Directory deployment.  In many cases they aren’t configured with multi-factor authentication (MFA).  Common examples include Office 365, AWS, G Suite, and Github.

   Pro Tip: Once you’ve authenticated to Azure, you can quickly find additional service provider targets that support federated/managed authentication by parsing through the service principal names.  You can do that with Karl’s Get-AzureDomainInfo.ps1 script.

2. Subdomain Hijacking Targets
   The domain validation tokens could reveal services that support subdomain which can be attacked once the CNAME records go stale. For information on common techniques Patrik Hudak wrote a nice overview here.
3. Social Engineering Fuel
   Better understanding the technologies and service providers used by an organization can be useful when constructing phone and email phishing campaigns.
4. General Measurement of Maturity
   When reviewing domain validation tokens for all of the domains owned by an organization it’s possible to get a general understanding of their level of maturity, and you can start to answer some basic questions like:
   1. Do they use Content Distribution Networks (CDNs) to distribute and protect their website content?
   2. Do they user 3^rd party marketing and analytics? If so who? How are they configured?
   3. Do they use security related service providers? What coverage do those provide?
   4. Who are they using to issue their SSL/TLS certifications? How are they used?
   5. What mail protection services are they using? What are those default configurations?
5. Analyzing domain validation tokens for a specific online service provider can yield additional insights. For example,
   1. Many domain validation tokens are unique numeric values that are simply incremented for each new customer.  By analyzing the values over thousands of domains you can start to infer things like how long a specific client has been using the service provider.
   2. Some of the validation tokens also include hashes and encrypted base64 values that could potentially be cracked offline to reveal information.
6. Real-world attackers can also attempt to compromise service providers directly and then move laterally into a specific company’s site/data store/etc. Shared hosting providers are a common example. Penetration testers and red teams don’t get to take advantage of those types of scenarios, but if you’re a service provider you should be diligent about enforcing client isolation to help avoid opening those vectors up to attackers.

Wrap Up

Analyzing domain validation tokens found in DNS TXT records is far from a new concept, but I hope the library of fingerprints baked into Resolve-DnsDomainValidationToken will help save some time during your next red team, pentest,  or internal audit.  Good luck and hack responsibly!

Scott Sutherland