How to Use Certificate Transparency Logs to Map a Company's Attack Surface
• BizVuln Expert
Certificate Transparency logs are an underutilized goldmine for mapping external attack surfaces. This guide shows MSSPs and security teams how to leverage CT logs with the BizVuln platform to discover rogue subdomains, expired certificates, and shadow IT infrastructure before attackers do.
How to Use Certificate Transparency Logs to Map a Company's Attack Surface
In the modern cybersecurity landscape, the difference between a proactive defense and a reactive breach often comes down to one critical factor: visibility. For Managed Security Service Providers (MSSPs) and security consultants, understanding a client's true attack surface is no longer optional—it's existential.
Traditional reconnaissance methods—port scans, DNS brute-forcing, and WHOIS lookups—provide a snapshot, but they miss the dynamic, sprawling nature of modern cloud infrastructure. There is, however, a publicly auditable, legally mandated, and surprisingly underutilized data source that reveals the complete picture: Certificate Transparency (CT) Logs.
When integrated into a platform like BizVuln, CT logs transform from a niche cryptographic protocol into a powerful, automated attack surface mapping engine. This post will walk you through the methodology, the business value, and the practical steps to use CT logs for deep reconnaissance.
What Are Certificate Transparency Logs?
Before we dive into tactical use, it is essential to understand what CT logs are and why they exist. Certificate Transparency is an IETF standard (RFC 6962) designed to solve the fundamental problem of SSL/TLS certificate mis-issuance. Every time a Certificate Authority (CA) issues a certificate for a domain, they are required by major browsers (Chrome, Safari, Firefox) to append that certificate to a public, append-only log server.
These logs are essentially immutable ledgers. They contain the Subject Alternative Names (SANs)—the key field for our purposes—which list every domain and subdomain a certificate was issued for. This includes:
- Production domains (e.g.,
app.client.com) - Staging environments (e.g.,
dev.client.com) - Internal-facing services exposed inadvertently (e.g.,
vpn.client.com,gitlab.internal.client.com) - CDN endpoints
- Expired certificates that may still be in use
While the logs are public, consuming them at scale is noisy. That's where BizVuln's automated ingestion engine comes in, parsing millions of log entries to build a structured, deduplicated asset inventory.
Why CT Logs are the "Single Source of Truth" for External Attack Surface
Most organizations—and their MSSPs—suffer from institutional blind spots. A common scenario: a business acquires a startup, the startup's domains are loaded into a single certificate. Years later, that certificate expires, but the subdomain legacy-payments.company.com still points to an unpatched server. CT logs surface this.
Here is why CT logs outperform traditional reconnaissance:
| Method | Coverage | Recency | Hidden Assets? |
|---|---|---|---|
| DNS Brute-force | Low-Medium | Real-time | Rarely |
| Port Scanning | Medium | Real-time | Sometimes (non-standard ports) |
| WHOIS / RDAP | Very Low | Static | No |
| CT Logs (via BizVuln) | Very High | Near Real-time | Yes (Shadow IT, M&A remnants) |
The key insight is that a certificate must exist for a domain to be served over HTTPS. If a subdomain has a certificate, it is logged. This eliminates guesswork—you only see assets that are actually in use.
Step-by-Step: Using CT Logs with BizVuln for Attack Surface Mapping
The following methodology assumes you are using BizVuln's automated reconnaissance pipeline. We recommend running this as a recurring "Discovery Scan" for every client engagement.
Step 1: Seed with Root Domains
Begin with the obvious: the client's primary domain (e.g., acmecorp.com). BizVuln allows you to input a list of root domains. The engine then queries CT log aggregators (such as crt.sh, CertSpotter API) using wildcard patterns: %.acmecorp.com.
Pro Tip: Do not forget typosquatted domains and acquired subsidiaries. Add domains like acmecorp.net or acme-logistics.com if they were obtained via M&A.
Step 2: Harvest Subject Alternative Names (SANs)
This is the core of the operation. For each certificate returned, BizVuln extracts every SAN entry. A single wildcard certificate for *.acmecorp.com might list hundreds of subdomains that were explicitly issued across multiple certificates. The system aggregates these, removing duplicates from overlapping certificates.
Example output from a real-world scan of examplecorp.com:
app.examplecorp.comapi.examplecorp.comjenkins.examplecorp.com(← exposed CI/CD)admin-portal.staging.examplecorp.com(← staging environment)s3-bucket.examplecorp.com.s3-website-us-east-1.amazonaws.com(← cloud misconfiguration potential)test.examplecorp.com(← likely orphaned)
Step 3: Validate and Classify
Not every subdomain is accessible. BizVuln performs a HTTP(S) handshake check on each discovered asset. The system categorizes them:
- Live & Responding (200/301/302)
- Redirecting (moved to new domain)
- Dead / No Response (DNS resolves but no server listening)
- Certificate Expired (critical – indicates maintenance neglect)
This step separates signal from noise. You might find 500 subdomains, but only 200 are actually serving content. Prioritize those.
Step 4: Correlate with Third-Party Intelligence
BizVuln's strength lies in contextual enrichment. For each validated subdomain, the platform cross-references:
- Vulnerability databases (CVE mapping to software versions seen in HTTP headers or banners)
- Shodan / Censys integration for open ports and services
- Domain reputation (is the IP blacklisted? Associated with malware?)
- SSL/TLS configuration checks (weak cipher suites, expired certificates)
This turns a list of domains into a risk-scored attack surface map.
Step 5: Continuous Monitoring
Attack surfaces change daily. New subdomains appear, old certificates expire, and shadow IT projects spin up. Set BizVuln to re-scan CT logs weekly. The platform will generate a delta report showing:
- New assets added (new SANs in the last 7 days)
- Expired certificates (risk window increases)
- Removed assets (should this be decommissioned?)
Real-World Attack Scenarios Discovered via CT Logs
To illustrate the power of this method, here are three common findings from BizVuln's CT log analysis that directly led to critical vulnerability identification:
Scenario A: The Exposed Jenkins Server
Find: A CT log revealed jenkins.acmecorp.com with a valid certificate. BizVuln's banner grab detected Jenkins 2.235, which has a known RCE (CVE-2020-2187).
Impact: Unauthenticated command execution on a CI/CD server with access to production source code.
Remediation: The client was unaware this instance existed (a developer had spun it up on a cloud VM). Immediate isolation and patching.
Scenario B: Expired SSL on a Payment API
Find: payments-api.acmecorp.com had a certificate expired 45 days ago. BizVuln flagged it as "Critical" due to the tokenized payment data in transit.
Impact: All customer transactions were vulnerable to man-in-the-middle attacks due to broken trust.
Remediation: Certificate renewal within 4 hours. The incident led to a new procurement policy for auto-renewal.
Scenario C: Merged Company Infrastructure Leakage
Find: After AcmeCorp acquired "SmallBiz," BizVuln scanned smallbiz.com. CT logs revealed vpn.smallbiz.com and exchange.smallbiz.com (still active with original certificates).
Impact: The acquired company's VPN was still configured with default credentials. External attackers had a potential entry point into the parent's network.
Remediation: Forced migration to a unified VPN, revocation of old certificates.
Business Case: Why MSSPs Must Offer CT Log Reconnaissance
For MSSPs and security consultants, this capability directly translates into competitive advantage and revenue:
- Upsell Opportunity: A standard vulnerability scan might cost $X. A "CT Log Attack Surface Mapping" as a quarterly premium service differentiates your offering. Charge for the mapping, then upsell the remediation.
- Reduced Liability: When you can show a client the discovered "orphaned" subdomains that you remediated, you demonstrate proactive value. This reduces the risk of a client blaming you for a breach they didn't know they had.
- Compliance Automation: For PCI-DSS, HIPAA, or SOC2, you need to inventory all external-facing systems. CT logs provide an auditable trail of "this is what we know about." BizVuln can generate compliance-ready reports automatically.
Limitations and Ethical Considerations
No technique is perfect. CT logs have a time lag—it can take up to 24 hours for a new certificate to appear in publicly queriable logs. Also, wildcard certificates (*.acmecorp.com) do not list individual subdomains, so you must search for explicit certificates for specific subdomains to catch those.
Always work with authorization. Scanning a company's CT logs is entirely legal—the data is public. However, subsequent probing (port scanning, vulnerability testing) requires explicit written permission. BizVuln enforces scope agreements at the organization level to ensure your MSSP engagements remain ethical and within legal bounds.
Conclusion: CT Logs Are the Rosetta Stone of External Reconnaissance
Certificate Transparency Logs were created to prevent fraudulent certificates, but they have become the most comprehensive publicly available index of internet-facing infrastructure. For an MSSP using BizVuln, these logs are the starting point for every reconnaissance engagement.
By automating the extraction, validation, and enrichment of CT log data, you move from "reactive vulnerability scanning" to proactive attack surface management. You see what the attacker sees—often before they do. And in the world of cybersecurity, that visibility is the difference between a controlled engagement and a headline-making breach.
Start your next client engagement with a CT log scan in BizVuln. The hidden assets you find today could be the critical vulnerabilities you fix before they are weaponized tomorrow.