How to Detect Phishing Using Certificate Transparency (CT) Logs
Monitor CT logs to catch phishing domains the moment their SSL certificates are issued, hours before the phishing site goes live. Free queries, a monitoring setup, and triage steps.
Watch
Every TLS cert is logged publicly, so watching CT logs surfaces lookalikes before the attack.
TL;DR
- 1 Every TLS certificate issued by a public CA is recorded in append-only Certificate Transparency (CT) logs within minutes.
- 2 Monitoring CT logs for your brand string surfaces phishing infrastructure before the page goes live.
- 3 Free queries at crt.sh; production monitoring needs filtering against legitimate certs and continuous polling.
What it does
Every TLS certificate issued by a publicly-trusted Certificate Authority is recorded in append-only Certificate Transparency (CT) logs within minutes of issuance. CT was designed for accountability (catching CAs issuing certificates they shouldn't), but it has become the highest-signal early-warning channel for phishing infrastructure. When an attacker registers a lookalike and provisions HTTPS, the CT entry appears before the phishing page goes live.
Modern browsers require any certificate they trust to be CT-logged. Let's Encrypt, the CA most phishing operators use because it's free and automated, submits every certificate to multiple logs. So the moment an attacker requests <code>yourbrand-login.com</code>'s cert, you can see it in CT, usually several hours before the phishing campaign launches.
The catch: CT logs are firehoses. tens of millions of certificates per day across all logs. Filtering for your brand requires either manual queries against crt.sh (free, slow) or continuous monitoring with brand-string filters (PhishFence and similar tools). Without filtering the signal is unusable.
How it works
-
1
<strong>Search crt.sh for one-off lookups.</strong> <code>https://crt.sh/?q=%25yourbrand%25</code> returns every certificate ever issued for a domain containing the brand. Quick sanity check; not suitable for production monitoring.
-
2
<strong>Subscribe to a CT-monitoring service.</strong> PhishFence (and CertSpotter, Facebook's CT monitor) poll the public logs continuously, filter for brand strings, and alert on new entries. Critical for catching infrastructure during the few-hour window before a campaign launches.
-
3
<strong>Define your brand strings carefully.</strong> Too narrow (only exact <code>yourbrand.com</code>) and you miss <code>yourbrand-secure.com</code>; too broad (any 'yourbrand') and you drown in legitimate cert reissuances. Most monitors let you combine a brand string + a list of patterns + a list of legitimate domain allowlists.
-
4
<strong>Allowlist your own infrastructure first.</strong> Before turning on alerts, seed the monitor with your real domains, your CDN and SaaS subdomains, and any vendor that issues certs on your behalf. This is what keeps the alert channel quiet enough that a real lookalike cert stands out the same day it is issued.
-
5
<strong>Route alerts somewhere a human sees them within hours.</strong> The whole value of CT detection is the gap between certificate issuance and campaign launch. An alert that lands in a weekly digest wastes it; send new-certificate alerts to email, Slack, or a webhook that pages whoever handles takedowns.
-
6
<strong>Treat new entries as triage signals, not confirmed threats.</strong> Many newly-issued lookalike certs go onto parked domains, not phishing. Combine with HTTP / MX / threat-intel signals before escalating.
-
7
<strong>Use CT findings to anchor takedown reports.</strong> A registrar or hosting provider's abuse team takes a CT-evidenced complaint more seriously than a "we found this on a scan" report. CT proves the timeline.
Common pitfalls
-
<strong>Relying on crt.sh queries for production monitoring.</strong> Manual queries find threats after the fact. Continuous monitoring is the only way to act before the campaign launches.
-
<strong>Ignoring CT noise.</strong> A high-volume brand will see dozens of CT entries per day, most legitimate. Without auto-filtering against known-good domain lists, the signal-to-noise ratio is bad enough that real threats get buried.
-
<strong>Assuming all phishing uses CT-logged certs.</strong> An attacker who skips HTTPS (or uses a private CA, or self-signs) won't appear in CT. CT is one channel, not the only one.
-
<strong>Forgetting wildcard certs.</strong> A wildcard cert for <code>*.yourbrand-portal.com</code> covers all subdomains. The CT entry for the wildcard appears once; the per-subdomain phishing pages don't generate new CT entries.
Frequently asked questions
Can certificate transparency logs detect phishing?
Yes. Most phishing sites use HTTPS, and every certificate issued by a publicly-trusted CA is recorded in CT logs within minutes. Watching the logs for certificates containing your brand name surfaces phishing domains at certificate issuance, typically hours or days before the phishing page goes live and emails start landing.
How do I monitor CT logs for my domain?
For a one-off check, search crt.sh with a wildcard query like https://crt.sh/?q=%25yourbrand%25. For ongoing protection, use a CT monitoring service (PhishFence, CertSpotter, or a self-built poller) that continuously polls the public logs, filters entries against your brand strings, suppresses your own legitimate certificates, and alerts on anything new.
What is a certificate transparency log?
A certificate transparency (CT) log is a public, append-only ledger of TLS certificates. Certificate Authorities must submit every certificate they issue to CT logs for browsers to trust it. Entries cannot be edited or deleted, which makes the logs a reliable public record of exactly which certificates exist for which domains, and when they were issued.
How fast do new certificates appear in CT logs?
Usually within minutes of issuance. That is the detection window that matters: attackers typically request a certificate shortly before launching the phishing page, so a CT alert often arrives hours before the campaign starts, while traditional detection (user reports, blocklists) only triggers after victims are already being targeted.
Is crt.sh enough for phishing detection?
crt.sh is excellent for manual investigation but not for production monitoring. It is a search interface, not an alerting system: you only find threats when you remember to look. Continuous protection needs automated polling, brand-string filtering, an allowlist for your own certificates, and alert routing, which is what dedicated CT monitoring services provide.