Introduction
In the digital world, conducting an open-source intelligence (OSINT) assessment against your organization is an important part of securing your online assets. By understanding the intelligence that can be discovered by an adversary, you are able to better prepare against cyber threats.
Reconnaissance is the first step in every attacker’s playbook.
Root Domain Records
Let’s start with analyzing an organization’s root domain. In this context, a root domain is just an organization’s primary domain, suffixed by a TLD.
For example, the root domain for Shadowscape is: shadowscape.io
Organizations oftentimes expose copious amounts of information in just their root domain records. Let’s take a look at the TXT records for an example domain: attck.me
These records alone tell us a ton about our target organization.
Let’s break some of these records down:
1password-site-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This appears to be a 1Password site verification record. Oftentimes, when verifying that you own a domain through a specific service, that service will require you to add a “domain verification record”. These types of records can vary from service to service.
By doing a quick Google search, we can see that this record is specifically added for businesses that want to monitor which employees have been impacted by data breaches. (Source)
Additionally, 1Password mentions on their support page that they are using “haveibeenpwned.com” as the source for these data breach detections. This is incredibly relevant to an attacker, as they might have access to a data breach that has yet to be indexed by “haveibeenpwned.com”.
For example, let’s assume that an attacker has just downloaded a brand new data breach that includes:
ceo@attck.me:MySuperSecurePassword123By checking “haveibeenpwned.com” for this information, we can see that these records have not yet been indexed. There is a good chance that relevant parties (in this case, the CEO) have not been notified of this data breach and subsequently not had a chance to update their password.
If this is the case, using the password found via the new data breach may be a viable way to gain initial access.
atlassian-domain-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
This record appears to be an Atlassian domain verification record, serving a similar function to the previous record. This indicates that this organization might be a current Atlassian customer, which could be useful for social engineering exercises.
google-site-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
This record appears to be similar to the previous 2 records, a mechanism for proving domain ownership. This indicates that this organization might be a current Google Workspaces customer, which could be useful for social engineering exercises.
v=spf1 include:_spf.google.com include:amazonses.com -all
This is known as an SPF record. SPF is an email authentication method to detect forging sender addresses during email delivery. Specifically, it ensures that any mail received from a specific sender was sent from a valid IP address. In this record, attck.me is using include: to pull in a list of IP addresses allowed to send mail.
Understanding how SPF works is outside the scope of this post. However, we can still glean some insight into our target’s technical stack based on this record.
In this example, the AWS SES inclusion is particularly interesting. If an attacker is able to deduce that attck.me is an AWS customer, it gives them much better guidance on narrowing their attack surface reconnaissance. For example, an attacker may search for publicly available S3 buckets that are tied to their target.
Another set of records that may be useful for reconnaissance is the MX records.
By looking at the MX records of a domain, we can see what email provider attck.me is using.
In this example, it looks like attck.me is using Gmail as their email provider. This helps confirm our earlier suspicion about attck.me being a Google Workspace customer. An attacker might also find this information useful when crafting social engineering attacks.
Subdomain Records
Let’s move on to the really fun stuff.
Subdomains are domains that are prefixed on the root domain. These are typically used to organize online assets that an organization owns.
For example, let’s assume that the company “Acme Inc.” owns an FTP server with the IP address 1.2.3.4. They might have an A record for their FTP server that has the name: ftp.acmeinc.com which points to 1.2.3.4.
Finding subdomains for an organization is incredibly valuable to an attacker, as they are able to quickly enumerate their target’s attack surface. However, subdomains can be a bit tricky to find. There is no way to directly “query” a list of an organization’s subdomain records. (Without making some noise, and potentially breaking the law).
Let’s take a look at some different methods used to find subdomains.
SSL Certificates
SSL certificates are used to secure online communications. They are commonly used in the HTTPS protocol to encrypt communication between your machine and a website. This is used by organizations to protect themselves & customers against “man-in-the-middle” attacks.
Notably, SSL certificates use something called the “Common Name” to represent the server name protected by the SSL certificate. The certificate is valid only if the requested hostname matches the certificate’s common name. You can learn more about this here. This means, if an organization is using HTTPS to secure a service that lives on a subdomain, the SSL certificate will often include the subdomain as the “Common Name”.
Let’s take a look at how we can use this in practice.
Censys Search is a tool developed by Censys that automatically scans the internet and catalogs information about different hosts & certificates. It lives at: https://search.censys.io.
Let’s run a “Certificate” search against shadowscape.io
In this example, the 3rd SSL certificate on the page contains: community.shadowscape.io
Let’s do some more digging on that domain:
We can see that the domain has a single A record pointing to: 209.87.159.65. With reverse DNS, we can see the PTR record points to: saashost-6699537.us-midwest-1.nxcli.net.
There are a variety of other sites for this purpose such as crt.sh. I recommend doing your own research, and cross-referencing the results.
Brute Force
Subdomains can also be found via brute force as well. This process involves the use of a tool along with a wordlist to query common subdomains. There are a variety of tools to accomplish this task, such as dnscan & dnsrecon.
Zone Transfers
Another method used to find subdomains is by attempting a DNS zone transfer.
A DNS zone transfer is a process in which a DNS server (called the primary server) transfers a copy of a DNS zone to another DNS server (called the secondary server). This process is used to ensure that the secondary server has a current and accurate copy of the DNS zone, which it can then use to respond to DNS queries from clients.
A DNS zone will contain all of the subdomains & records for the zone that was requested. However, many DNS hosting providers will have this functionality disabled.
If you want to test this method out, be sure it is on a domain that you control. Even requesting a DNS zone transfer on a domain that you do not own is considered illegal in the US.
Conclusion
As you can see, conducting DNS reconnaissance against your organization is a great way to gain visibility into your own attack surface. Additionally, you may discover that an adversary may be able to see more information than you might have anticipated. Thanks for reading!