DNS reconnaissance is an important part of most external network penetration tests and Red Team operations. There are many areas of focus in DNS reconnaissance, but I thought it would be interesting to delve into the DNS TXT records that were created to verify domain name ownership. They are very common and can reveal useful information about the technologies and services used by the target company.
Domain name ownership verification process
When companies or individuals want to use online services related to their domain name, they need to verify the ownership of that domain name. This process is often referred to as “domain name verification” or “domain name validation”, depending on the service provider.
Here’s an outline of how this process typically works:
1. The company creates an account with the online service provider
2. The company provides the domain name to be verified to the online service provider
3. The online service provider sends an email containing a unique domain name verification token (text value) to the domain name contact registered with the company
4. The company then creates a DNS TXT record for their domain name containing the domain name verification token they received via email from the online service provider
5. The online service provider validates domain name ownership by performing a DNS query to verify that the TXT record containing the domain name authentication token has been created
6. In most cases, once the domain name authentication process is complete, the company can delete the DNS TXT record containing the domain name authentication token
Note that last step, this is really what everyone seems to forget to do, which is why simple DNS queries are so useful for getting insight into what online service providers are using.
Note: The domain name authentication process does not always require a DNS TXT entry. Some online service providers simply require you to upload a text file containing a domain name verification token to the domain name’s web site. For example, mywebsite.com/validation_… Google hacking is a handy way to do it if you know what you’re looking for, but for now let’s focus on DNS logging.
1 million domain name TXT record analysis
Our team has been collecting information about online service providers from DNS TXT records for years, but I’d like to have a broader understanding of what’s in them. So I set out on a journey to identify some trends in domain authentication tokens. ** Select domain name sample **
I started by just scraping the DNS TXT records of Alexa’s top 1 million websites. I used a slightly older list, but for those who want to repeat mining this information, Amazon has a service that you can go to aws.amazon.com/alexa-top-s…
Tool for querying TXT records
DNS TXT records can be easily found through nsLookup, Host, DIG, MassDNS, or high profile security tools like DnsRecon. I ended up using a basic PowerShell script to make all my DNS requests because PowerShell made me lazy. It was a bit slow, but it took less than a day to collect all the TXT records from 1 million sites.
Here is the basic collection script I used.
#Import list of domains Domains = gc c:\temp\domains.txt # Get TXT records for domains txtlist = Domains | ForEach-Object{ Resolve-DnsName -Type TXT _ -Verbose } # Filter out most spf records Results=Results = Results=txtlist | where type -like txt | select name,type,strings | ForEach-Object { myname=myname = myname=.name .strings | foreach { The object = New – object psobject object ∣ add – membernotepropertynameobject | add – member noteproperty name Object ∣ add – membernotepropertynamemyname object | add – member noteproperty txtstring I f (_ the if (I f (_ – notlike “v = SPF *”) { object } } } | Sort-Object name # Save results to CSV Results | Export-Csv -NoTypeInformation dnstxt-records.csv # Return results to console Results
Here is the advanced process I used after gathering the information:
1. Delete the remaining SPF records
2. Parse key-value pairs
Sort and group similar keys
4. Determine service providers through Google Hacking and document review
Remove keys that are completely unique and cannot easily be attributed to a particular service provider
6. Classify service providers
7. Determine the most common service provider category based on the count of domain name validation tokens
8. Determine the most commonly used service providers based on the count of domain name validation tokens
Five major service provider categories
After briefly analyzing DNS TXT records for nearly 1 million domain names, I created a list of the most common online service categories and providers that require domain name validation.
Here are the top five categories:
There are many other types of services, from caching services (such as Cloudflare) to security services (such as “Have I Been Pwned”), but the above category seems to be the most common. It’s worth noting that I deleted the SPF record because technically there is no domain name validation token in the SPF record. However, SPF records are another rich source of information that, if poorly managed, can lead to opportunities for email spoofing. Either way, they are beyond the scope of this blog.
Top 25 service providers
Here are the top 25 service providers I can fingerprint based on their domain name verification token (TXT record). However, I was able to provide about 130 properties in total.
Domain name authentication token fingerprint automation
To simplify the process, I wrote a PowerShell function called “resolve-dnsDomainValidationToken.” You can simply provide it with the domain name and it will scan the relevant DNS TXT records for known service providers based on the domain name validation token library I created. It currently supports parameters for a single domain name, a list of domain names, or a list of urls.
Resolve-dnsdomainvalidationtoken can be downloaded here.
Order sample
To give you an idea of what the command and output look like, I’ve provided an example below. The target domain is randomly selected from Alexa’s top 1 million domain names.
#Load Resolve-DnsDomainValidationToken into the PowerShell session IEX(New-Object System.Net.WebClient). DownloadString (” raw.githubusercontent.com/NetSPI/Powe…).
Run Resolve-DnsDomainValidationToken to collect and fingerprint TXT records Results = Resolve-DnsDomainValidationToken -Verbose -Domain adroll.com # View records in the console Results
For those who prefer not to view results on the console, there is also an out-of-GridView to view results.
#View record in the out-grid view $Results | Out-GridView
Finally, the command automatically creates two CSV files containing the results:
1. Dns_txt_records.csv contains all the TXT records found.
2. Dns_Txt_Records_Domain_Validation_Tokens. CSV contains the TXT records for fingerprint identification.
How can domain authentication tokens be used for evil?
Here are some examples of how we used domain name validation tokens in our penetration tests. Since penetration testers and red teams are restricted by law, I’ve also added some options that are only available to real-world attackers.
Penetration tester use cases
A. Services that support but do not use MFA for federated authentication: this is our most common use case. By examining the domain name authentication token, we were able to identify service providers that supported federated authentication associated with the company’s active directory deployment. In many cases, they are not configured with two-factor authentication. Common examples include Office 365, AWS, GSuite, and Github. Pro tip: Once you authenticate with Azure, you can quickly find other service provider targets that support federated or hosted authentication by resolving the service principal name. You can do this using Karl’s get-AzureDomaininfo. ps1 script.
B. Target hijacking by subdomain name: The domain name authentication token can display services that support subdomain names. Once the CNAME record is invalid, these services may be attacked. For information on common technologies, Patrick Hudak has a great blog post here.
C. Social engineering: When building phone and email phishing campaigns, a better understanding of the technologies and service providers used by organizations can be very useful
D. General maturity metrics: When reviewing the domain name validation tokens for all domain names owned by an organization to get an idea of their maturity level, you can begin to answer some basic questions such as:
Do they use a content delivery network (CDN) to distribute and protect their site content?
Do they use third party marketing and analytics? And if so, which third party? How are they configured?
Do they use a security-related service provider? What protection does the insurance provide?
Who do they use to issue SSL/TLS certificates? How are they used?
What email protection services do they use? What are those default configurations?
E. Analyzing the domain name verification token of a particular online service provider can yield additional insight. For example, many domain name authentication tokens are unique to a number that increases with each new customer. By analyzing the values of thousands of domain names, you can begin to infer things like the time of the service provider used by a particular client. Some validation tokens also include hashed and encrypted Base64 values that can be cracked offline to display some plaintext information.
F. A real-world attacker can also attempt to hack a service provider directly and then move horizontally to a specific company’s sites, data storage, and other servers. Shared hosting providers are a common example. Penetration testers and red team personnel cannot take advantage of these scenarios, but if you are a service provider, you should strive to enforce client isolation to help avoid opening these attack vectors to attackers.
conclusion
Analyzing domain name validation tokens found in DNS TXT records is far from a new concept, but I hope the fingerprint library in resolve-dnsDomainValidationToken will help save you some time during your next Red team, penetration test evaluation, or internal audit.
