Blog: OPSEC

OpSec. Expanding your search: Hunting domains

Tony Gee 02 Sep 2021

In the last few blogs I have introduced OSINT and OpSec, talked about leaky images and using Google Dorks and how to use those techniques specifically to examine your own corporate OpSec. One of the most important aspects is to understand how wide your target expands.

Many companies own multiple domains, commonly following the same or similar brand names, but sometimes completely unrelated brand names. Each of these may have their own subdomains. Companies may have merged or acquired other companies and brands, some of these could be independent operations or folded into the main corporate identity. Identifying these is key. So how do we do that?

WHOIS records

My initial steps to identify other domains is with WHOIS, this records who registered the domain and is searchable allowing you to find the registrant name. Using that it is possible to pivot to the domains registered by that name.

So how does it work in practice?

There is any number of WHOIS services, but the ones I find most useful are:

  • https://www.whoxy.com
  • https://tools.whoisxmlapi.com

The reason these are my favourites is for their historical WHOIS and reverse WHOIS capabilities.

Historical WHOIS

For many years WHOIS records were public but individuals had the right to use domain privacy services to protect their personal privacy, this offer was not extended to businesses. In reality this offer was rarely taken up by individuals due to the additional costs.

Also, occasionally companies would protect their privacy if using a domain management service. However, in practice WHOIS information was readily available. Then GDPR required companies serving EU resident customers to protect the information by default and at no cost and so rather than having complex systems for different regions, the registrars just switched all records to private records unless it was explicitly declared it was a business and then in practice some still protected it anyway.

What can we do to get around this? Look at historical records.

Whoxy is less comprehensive when it comes to historical records, showing only key changes, but offers it for free or for a very small price using the API if you want it.

Using Porsche.com as an example we can see it was registered in 1996 and has redacted information (although in this case the company is shown).

What I like about whoxy.com is you can see the history of the key changes on the same page and can pivot using the key information such as registrant name, company name, email address and location.

We can see that the privacy for this domain was enacted on the 12th December 2018, a few months after the EU GDPR rules came in to effect in May 2018.

Reverse WHOIS

However, we can see any data before that, and that allows us to pivot to other find domains. The email address is usually the most reliable, but the owner and company can also be useful. Depending on the number of other domains found I may well check all. In this case we can see roughly 6,692 domains registered by [email protected]

The pivot is really just a reverse WHOIS look up, from that we can see what other domains are registered, when they were registered and when they will expire:

The Whoxy webservice limits the amount that can be found, usually to under 100 domains without using the API.

Whoisxmlapi is a good option too. It can reveal more history and find all domains, with the option to export to CSV. The free version has it’s limitations though. Registering will give you some additional trial credits, allowing you to see the entire history. In this case there are 26 changes.

The reverse WHOIS allows for searching both historic and current records, which can then be downloaded in CSV for importing into other tools.

Subdomain enumeration

Armed with these domains what can you do? The next step is enumerating the subdomains. There are a ton of tools available, some web, some terminal apps, some browser apps.

To get a quick initial overview of a single domain I typically start with the excellent securitytrails.com. Using the pentestpartners.com domain as an example we can see the subdomains we host.

Each of these can be clicked on to view the IP address of the server hosting the subdomain. From this IP we can pivot back to domain enumeration by seeing what domains and subdomains share the same IP address.

In our case we use Cloudflare in front of our website to protect it from large spikes of traffic when some of our research gets picked up worldwide.

However, from the IP we can pivot back to domain enumeration by seeing what domains and subdomains share the same IP address. In our case as we are behind Cloudflare we will see other Cloudflare clients.

We can see the list of domains sorted by Alexa rank. We have some way to go to get to Perez Hilton’s rank!

Your results may vary, and its highly likely you will find other domains or subdomains hosted on the same IP.

Another tool for sub domain enumeration is the excellent Amass from OWASP. This will try multiple techniques to recover subdomains, including DNS, Webscraping, TLS certificates, 3rd party APIs and web archives depending on how you configure it.

Another excellent option is to use certificate transparency logs, these log every TLS certificate issued to domains, these will commonly include numerous common names and alternative names. This can allow you to find subdomains that make use of the particular certificate. There are lots of places to check this, including Amass as detailed above, but also censys.io and crt.sh.

Again using our domain, we can see certificates issued for multiple subdomains

At this point we can do further DNS lookups and find the IP addresses hosting these services and then use Shodan to find open ports, etc. but what if we wanted to do something slightly different.

Further Pivoting

I really like certificate logs as they allow you to quickly collect the certificate serial number. Which we can use to pivot further into the networks the company use.

We have talked extensively about using Shodan for finding ships, sat coms and numerous other things. Shodan can also be used to find servers who make use of the TLS certificates.

Using the ssl.cert.serial: query its easy to find the underlying servers supporting the domains and subdomains that use that certificate.

Examining the pentestpartners.com certificate on crt.sh we can see it is from GoDaddy and has serial number: 2743166423553142286

Using the shodan query “ssl.cert.serial:2743166423553142286” we can see 12 servers that use that certificate

This can then lead you on to other domains, other services including services without a DNS name or with domain names you may not have identified with the reverse WHOIS steps.

I have used this technique to find internal domain names, internal certificate authority servers, servers with no DNS record or no public DNS record, VPN servers, critically vulnerable services with ports open you really shouldn’t expose and a multitude of other services the organisation had attempted to obscure in one way or another.

Make sure when you are performing corporate OpSec that you look at all the other domains registered and then hunt subdomains on those domains to really understand what is being leaked.

Fixing it

Fixing this issue is hard, the information being disclosed needs to be disclosed in order for the internet to work. However, you can limit the pivot points.

  • When registering new domains use domain privacy even as a company.
  • Make sure to update all of your existing domains to make it harder to find the data (though not impossible).
  • Use unique certificates for each service, don’t reuse the same certificate with different subdomains (LetsEncrypt for the win!).
  • Don’t include internal domain names in public certificates.
  • Don’t use internal CA generated certificates on public services.
  • Use VPNs to keep most services behind a secure access point.
  • Fundamentally… only expose publicly what you want found.

Conclusion

The fundamental fact of running public facing services is that by their nature they are public facing, that means people can and will find them. However, that doesn’t mean we can’t make it hard for them.

Knowing what you are exposing is critical to understanding the threats you might face and how you can make it harder for attackers to find you. OpSec investigations can take time so make sure you allow yourself time to do this task.

Resources

Read more about OpSec in Red Teaming here.

If you’d like any help, do reach out, I’d happily give you some pointers: @_tonygee_.