Detecting Brand Impersonation with Certificate Transparency Logs

What Certificate Transparency is and why it exists

Certificate Transparency is an open framework, defined in RFC 6962, that requires Certificate Authorities to publish every TLS certificate they issue to public, append-only logs. The logs are cryptographically verifiable: once a certificate is recorded, it cannot be removed or altered without detection.

CT exists because the certificate ecosystem used to be opaque. A misissued or fraudulent certificate could go unnoticed for months. CT made issuance auditable in the open. Browsers enforce it: Chrome and Safari require certificates to carry Signed Certificate Timestamps (SCTs) — proof of inclusion in qualifying logs — or they refuse to trust the connection.

The side effect is the part that matters for brand protection. To get the padlock, an attacker has to log their certificate. That means the moment they provision TLS for a lookalike domain, they tell the world.

Why CT is an early-warning signal for impersonation

A phishing operation follows a predictable sequence: register a lookalike domain, stand up hosting, obtain a certificate so the browser padlock appears, then deploy the kit and send the lures.

The certificate almost always comes early. It is frequently free — Let's Encrypt issues at no cost in seconds — so there is no reason for an attacker to delay it. And because of CT enforcement, that issuance is published to the logs within minutes to a few hours.

That gives defenders a window. You can see secure-acmebank-login.com get a certificate before a single phishing email reaches an inbox.

The certificate is logged before the phish goes live — the earliest reliable signal you get. But raw keyword matching against the logs drowns you in benign certificates, so the signal is only useful once the noise is suppressed.

How to monitor CT: crt.sh and Certstream

Two free tools cover most of the ground.

crt.sh, operated by Sectigo, is a searchable index of CT logs with a web UI, a JSON API, and direct Postgres access. You query for your brand and its variations in the certificate Subject and Subject Alternative Names (SANs) — the latter is where most hostnames actually live. The % characters are SQL-style wildcards:

https://crt.sh/?q=%25acmebank%25

The same query as JSON, suitable for a scheduled poll:

https://crt.sh/?q=%25acmebank%25&output=json

That returns an array of certificate records — issuer, name_value (the dnsNames), and not_before timestamps you can use to catch newly issued certs.

Certstream is the other approach: a real-time firehose that aggregates the CT logs and streams every new certificate as it is issued. Instead of polling crt.sh on a schedule, you subscribe to the stream and filter each record against your watchlist as it arrives. For continuous monitoring, streaming catches issuance faster and avoids hammering crt.sh with repeated queries.

Commercial monitors wrap these same sources with retention, alerting, and deduplication, but the underlying signal is identical — it is all CT.

The false-positive problem (this is the hard part)

Here is where naive monitoring falls apart. Search the logs for a substring of your brand and you will be buried.

A query for acmebank returns certificates for:

• Your own production and staging infrastructure
• CDN and edge certificates (Cloudflare, Fastly, Akamai) carrying your hostnames
• SaaS vendors who legitimately put your brand in a SAN — support desks, status pages, marketing tools
• Wildcard certificates (*.acmebank-partners.com) that match broadly
• Subdomain certs for internal services that never face customers

The overwhelming majority of matches are benign. If your alerting fires on every keyword hit, analysts stop reading the alerts within a week — and the one certificate that actually mattered is buried in the same inbox as four hundred that did not.

Suppressing that noise is the real work, and it is not a keyword filter. It requires:

• Permutation logic that distinguishes a genuine lookalike (acmebank-secure.com, acmeb4nk.com) from your own legitimate naming.
• Homoglyph and typo matching to catch acmebɑnk.com (Cyrillic or Latin substitutions) and acemebank.com that a substring search misses entirely.
• Scoring that weighs how close the match is, who issued the cert, how the domain was registered, and whether it resolves — so each candidate gets a confidence level instead of a binary alert.

This is why a substring search is a starting point, not a detection system. The value is in deciding what to ignore.

Combining CT with DNS, registration, and permutations

A certificate alone tells you a domain exists. To know whether it is a live threat, enrich it.

1. DNS resolution. Does the domain resolve to an IP? A certificate with no A record is dormant — lower priority. One that resolves to hosting you have seen used for phishing is urgent.
2. MX records. A domain with mail-handling records can send email. A lookalike that is mail-capable is a credential-phishing or BEC risk, not just a spoofed web page.
3. Domain age. Cross-reference registration data. A certificate on a domain registered yesterday is a far stronger signal than one on a domain that has existed for three years.
4. Permutation set. Generate your brand's plausible variations up front — typos, homoglyphs, combosquats, alternate TLDs — and match CT records against that set rather than a single keyword. This is what turns substring noise into ranked candidates.

Each signal is weak alone. Stacked, they separate the handful of certificates that warrant action from the thousands that do not.

Setting up CT monitoring: a checklist

1. Build your permutation set — the brand plus realistic typos, homoglyphs, combosquats, and alternate TLDs. This drives everything downstream.
2. Pick an ingestion method: scheduled crt.sh JSON polling for periodic sweeps, or a Certstream subscription for real-time coverage.
3. Match each certificate's Subject and SAN entries against the permutation set, not a bare keyword.
4. Enrich every candidate with DNS resolution, MX presence, issuer, and domain-registration age.
5. Score and rank. Suppress your own infrastructure, known CDNs, and trusted vendors automatically.
6. Route only high-confidence candidates to human review — and capture evidence (the certificate record, screenshots, DNS state) at the moment of detection, before the attacker tears it down.

From signal to takedown

Brandfence ingests certificate-transparency logs, DNS, and new registrations, matches them against your brand's permutation set, suppresses the benign majority, and routes confirmed impersonations to evidence-backed, human-reviewed takedown. Get a free brand exposure report.