Many modern websites employ an automatic issuance and renewal of TLS certificates. For enterprises, there are DigiCert services. For everyone else, there are free services such as Let’s Encrypt and ZeroSSL.

There is a flaw in a way that deployment of TLS certificates might be set up. It allows anyone to discover all domain names used by the same server. Sometimes, even when there is no HTTPS there!

In this article, I describe a new technique for discovering domain names. Afterward, I show how to use it in threat intelligence, penetration testing, and bug bounty.

Quick Overview

Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of TLS certificates. It creates a system of public logs that seek to record all certificates issued by publicly trusted certificate authorities (CAs).

To search through CT logs, Crt.sh or Censys services are usually used. Censys also adds certificates from the scan results to the database.

It’s already known that by looking through CT logs it’s possible to discover obscure subdomains or to discover brand-new domains with CMS installation scripts available.

There is much more to it. Sometimes the following or equivalent configuration is set up on the server:

# /etc/crontab
37 13 */10 * * certbot renew --post-hook "systemctl reload nginx"

This configuration means that certificates for all the server’s domains are renewed in the same time. Therefore, by a time-correlation attack on certificate transparency, we can discover all these domains!

Let’s see how this can be applied in practice!

A Real Case Scenario. Let’s Encrypt

A month ago, I tried to download dnSpy, and I discovered a malicious dnSpy website. I sent several abuse reports, and I was able to block it in just 2 hours:

I found quite a lot of information about the threat actors who created this website online. For example, there is an article in Bleeping Computer and detailed research from Colin Cowie.

In short, a person or a group of people create malicious websites mimicking legitimate ones. The websites distribute infected software, both commercial and open source. Affected software includes, but is not limited to Burp Suite, Minecraft, Tor Browser, dnSpy, OBS Studio, CPU-Z, Notepad++, MinGW, Cygwin, and XAMPP.

I wasn’t willing to put up with the fact that someone trojans cool open source projects like OBS Studio or MinGW, and I decided to take matters into my own hands.

Long Story Short

I sent more than 20 abuse reports, and I was able to shut down a lot of infrastructure of the threat actors:

It isn’t easy to confront these threat actors. They purchase domains on different registrars using different accounts. Next, they use an individual account for each domain on Cloudflare to proxy all traffic to the destination server. Finally, they wait for some time before putting malicious content on the site, or they hide it under long URLs.

Some of the domains controlled by the threat actors are known from Twitter: cpu-z[.]org, gpu-z[.]org, blackhattools[.]net, obsproject[.]app, notepadd[.]net, codenote[.]org, minecraftfree[.]net, minecraft-java[.]com, apachefriends[.]co, ...

The question is how to discover other domains of the threat actors. Other domains may have nothing in common, and each of them would refer to Cloudflare.

This is where our time-correlation attack on certificate transparency comes into play.

Take a look at one of the certificates to the known domain cpu-z[.]net, used by the threat actors:

This certificate has the validity start field equal to 2022-07-23 13:59:54.

Let’s utilize the parsed.validity.start filter to look for certificates that were issued a few seconds later:

Here it is! We just discovered a domain that wasn’t known before!

Let’s open a website with this domain:

This is exactly what we were looking for! Earlier I was able to disclose the real IP address of cpu-z[.]org. This IP address belonged to Hawk Host, and after my abuse report to them, all websites of the threat actors on Hawk Host started to show this exact page.

This proves that we discovered a domain managed by the same threat actors.

A few pages later a domain blazefiles[.]net can be found, which distributed infected Adobe products. It also displays the same Hawk Host page.

There are a lot more domains used by these threat actors, so let’s just move on.

Why did the technique work?

The threat actors set up their websites by software such as Plesk, cPanel, or CyberPanel. It was automatically issuing and renewing trusted certificates for all websites, even though these certificates were never needed.

If we try to search for cpu-z[.]org certificates, we would see a bunch of not-needed certificates issued by the hosting servers:

All of these certificates can be dug up from certificate transparency logs, and correlated with other certificates by their timestamps.

DigiCert and Other CAs

DigiCert services are used by large companies for the automatic issuance of TLS certificates.

The validity field of DigiCert certificates doesn’t contain the time when the certificate was issued. The same is true for some other certificate authorities, for example, ZeroSSL.

However, if we look at crt.sh’s representation of transparency logs, we would see that crt.sh IDs of certificates owned by the same company may go quite close to each other:

This means that when a CA doesn’t include the exact issuing time to certificates, the certificates issued close in time can be discovered by their positions in certificate transparency logs.

Additionally, you may find two types of certificates in the logs: precertificates and leaf certificates. If you have access to the leaf certificate, you can take a look at the signed certificate timestamp (SCT) filed in it:

The SCT field should always contain a timestamp, even when the time in the validity field is 00:00:00.

What’s Next

Probably, some kind of tooling or a service is needed to help with discovering domains by this technique.

The ways to correlate domains that may be utilized:

• Analyzing certificates with close timestamps in the issuance field
• Analyzing certificates with close timestamps in the SCT field
• Analyzing certificates that come close to each other in CT logs
• Analyzing time periods between known certificates
• Analyzing certificates issued after a round period of time from the known timestamps
• Getting an intersection for sets of certificates issued close in time regarding the known timestamps
• The same, but for sets of certificates that come close to each other in CT logs
• Grabbing CT logs in real time and timestamping the certificates on our own

Regarding mitigation, regularly inspect CT logs for your domains. You may discover not only domains affected by attacks on CT but also certificates issued by threat actors attacking your infrastructure.