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.
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).
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:
37 13 */10 * * certbot renew --post-hook "systemctl reload nginx"
This configuration means that certificates for all the server’s domains are renewed at the same time. Therefore, we can discover all these domains by a time-correlation attack on certificate transparency!
Let’s see how it 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:
🧨 Be aware, dnSpy .NET Debugger / Assembly Editor has been trojaned again!— Arseniy Sharoglazov (@_mohemiv) July 8, 2022
In Google’s TOP 2, there was a malicious site maintained by threat actors, who also distributed infected CPU-Z, Notepad++, MinGW, and many more.
🎯 Thanks to NameSilo, the domain has been deactivated! pic.twitter.com/EdTlFjtN4B
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 domain
cpu-z[.]net, used by the threat actors:
This certificate has the validity start field equal to 2022-07-23 13:59:54.
Now, let’s utilize the parsed.validity.start filter to find certificates issued a few seconds later:
Here it is! We just discovered a domain that wasn’t known before!
Let’s open a website on 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, and not just a random malicious domain.
A few pages later a domain
blazefiles[.]net can be found. This domain was used to distribute infected Adobe products, and now it also shows the Hawk Host page.
There are much more domains of the threat actors that can be discovered by this technique. Thus, let’s just discuss why it works.
Why did the technique work?
The threat actors hosted their websites by software such as Plesk, cPanel, or CyberPanel. It was automatically issuing and renewing trusted certificates, and it was doing so simultaneously for all the websites.
If you try to search for the
cpu-z[.]org domain in crt.sh, you’d see a bunch of certificates:
Since the threat actors used Cloudflare, none of these certificates were ever needed.
However, we were able to utilize these non-Cloudflare certificates in the time-correlation attack and discover unknown domains of the threat actors.
DigiCert and Other CAs
DigiCert services are used by large companies for the automatic issuance of TLS certificates.
The time in the validity field of DigiCert certificates is always set to 00:00:00. The same is true for some other CAs, for example, ZeroSSL.
But if we look at crt.sh, we can see that crt.sh IDs of certificates owned by the same company may be placed quite close to each other:
Therefore, 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 CT 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.
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 regarding positions 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 someone attacking your infrastructure.