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