An Experiment With SaaS Enumeration Through DNS

The landscape of a traditional network has been changing for some time now, and gone are the days where your entire infrastructure is hosted by your organization. Many service offerings that used to provide on-premise solutions are moving strictly to the cloud, which provides a wider attack surface. I recently started down the road of seeing what SaaS offerings I could enumerate through publicly available information and discovered that through DNS alone you could gain some very valuable insight.

DNS TXT Records

The TXT records of a domain offers a plethora of information with respect to where organizations may keep their data, and service offerings they may utilize. It also seems to be the record I see discussed the least when people discuss DNS enumeration.

For those who may not know, a TXT record is a multi-purpose record which can be used for a wide variety of applications, perhaps most notably is verification of ownership of a domain, and informing other mail servers whether a sending mail server is authorized to send email for a specific domain with the use of Sender Policy Framework (SPF) records.

TXT records are unique in a number of ways, one of which is that unlike A and CNAME records which you need to brute-force, or guess, you can dump all TXT records with a single command nslookup -q=TXT <domain>.

TXT Records of Interest

  • SPF Records which state which IP’s and Domains can send email on behalf of the domain. If a domain allows, say Salesforce.com, to send emails claiming to come from their domain then we can safely assume there’s a strong possibility that domain is using a Salesforce offering.
  • Base64 encoded entries can represent Active Directory Federation Services challenges. Finding a string like this means that an org’s SaaS offerings might be federated with their Active Directory.
  • Domain Verification Records. A decent number of SaaS offerings require clients to verify ownership of their domain by creating a TXT record adhering to a pre-defined naming convention (ie. Microsoft’s is ms=msXXXXXXXX”

A TXT query for the rapid7.com domain. In the SPF record alone we can tell they appear to send emails from Google.com, Salesforce.com, mktomail.com and Outlook.com.

CNAME Records

CNAME records, or alias records, allow you to create a specific record for your domain and point it to another DNS record. An example might be an organization wanting to have both mail and smtp point to the same server, they could create a mail A record pointing to the IP address of their mail server, and create a CNAME record for smtp and simply point that to mail.

Where CNAME records become interesting for our purposes, is when they point to an external domain. If an organization has an autodiscover record pointing to a Microsoft domain,  there is a very good probability they’re using Microsoft for their email services.

A Records

A Records are the most widely utilized DNS record, and perhaps the easiest to understand. A records have a one-to-one mapping of a string to an IP address. An example would be pointing mail.domain.com to an IP address of xxx.xxx.xxx.xxx.

A Records are interesting for our purposes because we might be able to determine the enrolment in a SaaS offering by determining who who owns the IP address to which the record resolves. If a company has an autodiscover record that points to a Microsoft IP, it can likely be safely assumed that that organization is using Microsoft for hosted Exchange.

MX Records

Last, and certainly not least, are the MX, or Mail Exchange, records. These records tell other servers where to send email, so it’s an obvious choice for analysis for our purposes. MX Records are listed in order of priority, which tells other sending servers which addresses to try first.

If an organization has an MX Record pointing to an IP address owned by, lets say, Google then we know an organization is sending their emails through Google. They might only be using the MX as a filter, but the mail traverses through that MX record before reaching it’s destination.

Why Is This Useful Information?

Red Team

  • Identifying services we know the organization uses can be useful for Social Engineering, whether it be formatting phishing emails, spoofing email domains, etc.
  • Enumerate additional attack surface
  • Federated services might provide password spraying opportunities.

Blue Team

  • Help gain a full understanding of your potential attack surface.
  • Understand what the DNS information can provide those with malicious purposes

Caveats

I would be remise if I didn’t point out that all of this is based on a pretty wide set of assumptions. Just because a DNS record exists does not mean it’s current, or that an organization currently subscribes to a SaaS offering from that organization. In addition, many organizations (such as Google and Microsoft) provide a wide variety of product offerings that may leverage the same domain verification record. Seeing a google-site-verification might mean they are simply subscribed to Google Analytics, which is not as interesting as being subscribed to Gmail for business.

Enumeration as a Service

Armed with the above information I set about writing a script that would do this enumeration for me, and point out records of interest. I coded a script I call Enumeration as a Service, to query the DNS for a specified domain and highlight records that might indicate enrolment in a SaaS offering. This is just the beginning, and there’s lots of work to still be done but I would love to hear feedback an any domains I might have missed.

Find the code on My Github