Reference Brand protection

Using Certificate Transparency Logs to Catch Phishing Early

Every SSL certificate issued is recorded in a public ledger. If you know where to look, you can detect phishing infrastructure before it goes live.

April 1, 2026 · 7 min read

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 — to catch CAs issuing certificates they shouldn't — but it's 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. 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. 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. 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. 4

    <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.

  5. 5

    <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.