What is CT?

Certificate Transparency (CT) is an experimental IETF standard. The goal of CT is to allow the public to audit which certificates were created by Certificate Authorities (CA). TLS has a weakness that comes from the large list of CAs that your browser implicitly trusts. If any of those CAs were to maliciously create a new certificate for a domain, your browser would trust it. CT adds benefits to TLS certificate trust: Companies can monitor who is creating certificates for the domains they own. It also allows browsers to verify that the certificate for a given domain is in the public log record.

How can CT logs benefit Red Teams, Pentesters, and Bug Bounty Hunters?

These logs end up being a gold mine of information for penetration testers and Red Teams. I’m not the first to use this, people have been using this technique for years to gain OSINT on targets. When you start to experiment with searching on some of the web based CT log web sites, you’ll quickly realized this is an information leak by design.

After copying and pasting from the search results, I knew this wasn’t going to scale. Some companies have thousands of domains that show up, so I knew I needed to automate this. I also noticed that some domains either didn’t resolve or were only accessible from the inside networks (internal IP space, or DNS ‘view’ for BIND server prevented a resposne).

It goes without saying that these logs can help you find more targets, that might not have seen many eyes. Making it easier to get a bug bounty award. In my experience CT logs provide more sub domains than a google dork with site:domain.com .

ct-exposer

Instead of googling to see if a tool existed to search CT logs for unknown subdomains, I decided to make my own. In addition to querying and creating a sub domain list, I also wanted to do DNS queries on the domains to see which ones had records configured. When companies have one or two thousand subdomains in CT logs, it can take a little while to resolve them one at a time. To speed this up I used gevents, which sped things up nicely. I’ve seen 2k resolutions get processed in about a second or two. I added the ability to export the ip addresses into a masscan input format to help automate tasks that take place after you’ve located IPs to investigate.

Interesting things I’ve learned during this project

Symantec’s CT log searching tool has a bug. If you search for a domain with it, and then hit their ‘export as csv’ endpoint, it will not give the correct response. The csv will be filled with spam domains that do not include the domain you’re looking for, but with hits that look like: domain-requested.com.something.spammer.net . This I guess would be useful for companies who want to track down phishing sites, but was unhelpful for anyone else. The web page table did have the correct information though, but that is a pain to scrape. It was also very slow to reply with search results.

While doing testing of the gevents portion of my code, I noticed that responses from my DNS servers would come back in batches of 36 or 50. It would pause a couple of seconds, before the next similarly sized responses came in. At first I thought it was my code, and then I looked into linux being the problem, but then after trying on another network the resolution of 1000 domains would complete in a second or two. It seems my ISP is rate limiting DNS traffic.

I also noticed that a lot of companies have leaked domains that can only be accessed on their internal networks. Sometimes I even saw internal only 192.168.0.0 addresses coming back. This can be very helpful for internal server side request forgery (SSRF) targets, or pivoting once you get inside of the network.

GitHub

I’ve posted ct-exposer on my GitHub. If you have any feedback or suggestions, please contact me.

Example output