Protecting your business and customers by monitoring certificate transparency logs
I built a lightweight application to help spot suspicious domains
Have you ever wondered what tools a scammer uses to impersonate a business online?
They don’t need much, but the tools they rely on can leave traces if you know where to look.
At a very high level, a scammer needs four things:
Source code
It’s easy enough to copy and paste customer-facing code from any browser’s developer tools and mimic the user interface of a business.
Somewhere to host the code
It has to run somewhere! Hosting on inexpensive services means they can keep running without raising too many red flags.
A similar looking domain
Something that looks legitimate enough to trick someone. For instance, take the domain acompany.com. Some similar looking domains might be the following:
acompnay.com - Swapped "a" & "n"
acompany.co - Changed top-level domain (TLD) from .com to .co
acompany.support - TLD used to fake a support pageTLS/SSL Certificate
A website can still run without a certificate, but the data sent between a customer and the host will be unencrypted.
Along with this, most browsers will warn users, like in the image below, if a website doesn’t have a certificate.
If their intent is to impersonate a business and scam people, they’re going to purchase a certificate to avoid suspicion.
Purchasing a TLS/SSL Certificate
To purchase a certificate they need to buy one from a trusted Certificate Authority (CA).
When a certificate is purchased, the CA logs the certificate and information associated with it, including the domain name.
These logs are called certificate transparency (CT) logs, and they’re publicly accessible.
How to protect your business and customers with CT log monitoring
If CT logs are publicly accessible, we can monitor them for domains that are similar to some predefined values.
I've done exactly that with an application I built called ct-log-monitor. The source code can be viewed here.
It does the following:
Fetches a list of CT logs.
Writes the name and URL of each CT log to a logbook.
Gets the number of certificates in each log and writes it to the logbook.
Gets all new certificates and the domain names associated with them.
Checks the domain name against a series of pre-defined values.
Writes any similar domains to a file for further inspection.
From here, you’d then need to inspect the suspicious domain. Tools like urlscan.io can be a great source to inspect domains safely.
If you do suspect the domain is malicious, you could then run a WHOIS lookup to find the registrar (the place the domain was purchased) or the hosting provider (where the code is running) and issue a takedown request.
Buy over build
No cybersecurity chat is complete without addressing whether you should buy a solution off the shelf or build it yourself.
Monitoring CT logs can be as simple or complex as you want it to be.
I’ve gone with the DIY approach because I’m a software engineer. But if you’re thinking about buying a feature-rich solution off the shelf, SSLMate’s Cert Spotter does a great job of monitoring suspicious domains using CT logs.
Monitoring CT logs won’t stop every scam, but it’s a proactive way to spot suspicious activity before it turns into a serious problem.
Think of it like a smoke alarm. It won’t put out the fire, but it might help you take action before your house goes up in flames.
The ct-log-monitor code is open source and up on GitHub if you want to fork it, play with it, or roll your own.
Cheers!