Reconnaissance is the first phase of almost every targeted attack. Before an attacker tries to exploit anything, they map the terrain — find the subdomains, identify the services, look for soft spots. Traditionally, this required active probing: DNS brute-force, port scanning, crawling. All of which leaves traces in logs.
Certificate Transparency has changed that. An attacker can now build a detailed map of your external infrastructure without sending a single packet to any of your systems. They go to crt.sh, type your domain, and read the complete history of every certificate ever issued for your organisation. Completely passive. Zero noise in your logs. Takes about thirty seconds.
What they find shapes everything that follows.
The reconnaissance playbook — from a certificate perspective
Here is what a methodical attacker actually extracts from CT log data about a target organisation:
The complete subdomain map. Every subdomain that has ever had a publicly trusted certificate is in the logs. Not just the ones in DNS today — the historical ones too. This includes staging environments, development APIs, internal tools exposed accidentally, acquired company infrastructure that was never properly decommissioned, and services from projects that ended years ago but kept running on autopilot.
Infrastructure patterns. Certificate metadata reveals a lot about how an organisation operates. Certificates from a single managed CA suggest a centralised IT function with consistent processes. Certificates from a dozen different CAs — including free ones — suggest different teams operating independently, less consistent oversight, and likely less consistent security review. Both are useful signals to an attacker.
Cloud provider fingerprinting. Certificate SANs often include cloud-provider-specific domains alongside the organisation's own domains. app.yourdomain.com, app.yourdomain.azurewebsites.net in the same certificate tells an attacker you are running on Azure. This matters for targeting — different clouds have different default configurations, common misconfigurations, and known attack patterns.
Timing and activity patterns. The history of certificate issuance for a domain tells a story. A burst of new subdomains two years ago might correspond to a product launch or acquisition. A subdomain that has been quietly renewing its Let's Encrypt certificate every 90 days for three years — with no other changes — is a service nobody is actively managing. Old, unmanaged services are prime targets.
Organisational structure. Subdomain naming patterns often reflect internal team structure. api-payments.yourdomain.com, api-auth.yourdomain.com, api-reporting.yourdomain.com tells an attacker about your service architecture. This is useful for prioritising targets — payments services are more interesting than reporting services.
What attackers do with this information
The subdomain list from CT logs becomes the input for the next phase of reconnaissance. From there, a methodical attacker will:
- Resolve each subdomain to identify which are still active, which point to cloud services, and which are dangling DNS entries pointing at infrastructure that no longer exists (a class of vulnerability called subdomain takeover).
- Port scan the live hosts to identify which services are running and on which ports — looking for administrative interfaces, development ports left open, or services that should not be internet-facing.
- Check TLS configuration on each endpoint — looking for outdated protocol versions (TLS 1.0/1.1), weak cipher suites, missing security headers, and expired or soon-to-expire certificates that suggest neglect.
- Fingerprint the software stack — HTTP headers, error pages, and response patterns reveal what software is running and often what version, which can be cross-referenced against known CVEs.
- Prioritise targets based on what they find — services with old software, missing security headers, admin interfaces, or database ports exposed to the internet rise to the top of the list.
This entire process — from CT log query to prioritised target list — can be completed in a few hours by a single person with basic tooling. Automated scanning tools compress it to minutes.
The uncomfortable reality about your external surface
Most organisations have a significant gap between what they think is on their external attack surface and what is actually there. The assets they actively manage — the main website, the production API, the documented services — are usually reasonably well maintained. The gap is in everything else.
CT logs expose that gap ruthlessly. Every certificate ever issued for your domain is in there. Every forgotten staging environment. Every prototype that became a permanent service. Every third-party integration that was set up under your domain. Every subdomain from an acquisition five years ago that nobody properly cleaned up. Maintaining a current TLS certificate inventory is the starting point for understanding your true exposure.
The question is not whether attackers can find this. They can, and the cost to do so is negligible. The question is whether you have found it first — and whether you are managing it.
Seeing what attackers see — before they do
The practical response to this is to run the same reconnaissance against yourself, continuously, and use the results to manage your external surface proactively rather than reactively. CertControl's security probe automates exactly this process — querying CT logs, scanning live hosts, and surfacing prioritised findings.
This means:
- Querying CT logs for your domains to get a complete historical and current picture of what has been deployed under your name.
- Resolving and scanning those subdomains to determine what is currently live and what it is running.
- Reviewing TLS and security configuration on every live endpoint — not just the ones you know about.
- Tracking changes over time — new certificates mean new services, which should trigger review. Certificates that stop renewing may indicate services that were taken down, or they may indicate that automated renewal broke and a service is about to start serving expired certificate errors.
- Monitoring for new issuances in real time, so that new shadow IT or new infrastructure is visible immediately rather than discovered weeks later.
This is not a one-time exercise. Your external attack surface changes continuously. The goal is a system that keeps the picture current, surfaces new findings automatically, and alerts you when something changes. Certificate transparency monitoring is a key part of that real-time visibility layer.
How CertControl approaches this
CertControl's external attack surface scanner runs exactly this process — but automated, continuous, and with results surfaced in a structured dashboard rather than a pile of command-line output.
When you add a domain, the platform queries CT log aggregation for the complete historical record, resolves live subdomains, scans open ports, fingerprints services, checks TLS configuration, and cross-references findings against known CVEs. The result is a prioritised view of your external attack surface — ranked by real risk, not alphabetical order.
The attack path visualisation takes this further: showing how discovered subdomains, open ports, vulnerable services, and certificates connect into exploitable chains, so you can see which findings actually matter from an attacker's perspective rather than reviewing an undifferentiated list of issues.
Ongoing CT monitoring means the picture updates in real time. New certificates surface immediately. New services get reviewed. The gap between what you know about and what an attacker can find stays as small as possible.
Frequently asked questions
How do attackers use Certificate Transparency logs for recon?
They query a CT aggregator such as crt.sh for your domain and read every certificate ever issued, building a complete historical subdomain map passively — no packets sent to your systems and no traces in your logs.
What can a certificate reveal beyond subdomain names?
Certificate metadata exposes which CAs you use, cloud-provider fingerprints in the SANs, issuance timing that hints at launches or acquisitions, and naming patterns that reveal internal team and service structure.
Why are old, automatically renewing certificates a target signal?
A subdomain that has quietly renewed a 90-day certificate for years with no other changes usually means a service nobody is actively managing — unpatched and unmonitored, which makes it a prime target.
Can I stop attackers from reading my certificates in CT logs?
No. CT logging is mandatory for publicly trusted certificates and the logs are public and permanent. The defence is to run the same reconnaissance against yourself first and manage what it surfaces.
How do I see what attackers see?
Continuously query CT logs for your domains, resolve and scan the live subdomains, review TLS and security configuration on every endpoint, and monitor for new issuances so new infrastructure is visible immediately.