Before You Send a Single Packet: CT Logs Gave Us 79 Subdomains in 12 Seconds

What Certificate Transparency Is — and Why It Exists

Every SSL/TLS certificate issued by a publicly-trusted Certificate Authority must be logged in a Certificate Transparency log — an append-only, publicly-accessible database — within 24 hours of issuance. This was mandated by the CA/Browser Forum and enforced by Chrome since 2018 after a series of high-profile mis-issuance incidents (DigiNotar 2011, Symantec 2017) revealed that Certificate Authorities were issuing fraudulent certificates for major domains without detection.

CT logging solves this by making every certificate issuance transparent. If a CA issues a certificate for google.com that Google didn't request, it will appear in a public log. Anyone monitoring those logs can detect it within hours.

The side effect: every subdomain that has ever had a publicly-trusted certificate is permanently discoverable by anyone with internet access. No authentication. No cost. No noise on the target's network. Just a query to a public database.

crt.sh is the most widely used CT log aggregator — a PostgreSQL database maintained by Sectigo that indexes all major CT logs. SecurityClaw's ct_search.py skill queries the crt.sh API.

The Numbers

What We Actually Found

The Full Environment Ladder — Before a Single Scan

Superdrug's CT logs revealed their complete environment naming convention — the kind of infrastructure map that normally takes days of active enumeration:

• hyve-staging.superdrug.com — staging server on Hyve hosting (2017–2018)
• pharmacy-uat.superdrug.com / www.pharmacy-uat.superdrug.com — pharmacy User Acceptance Testing environment
• www-etst.superdrug.com, www-euat.superdrug.com, www-pre.superdrug.com, www-tst.superdrug.com, www-uat.superdrug.com, www-prd.superdrug.com — the full environment ladder: external test → external UAT → pre-prod → test → UAT → production
• uat-appcms.superdrug.com, pre-appcms.superdrug.com — CMS staging and pre-production

Why does this matter? UAT and staging environments frequently have weaker security controls than production: older software versions, weaker authentication, debug modes enabled, test credentials in code. Knowing they exist — and their exact naming convention — is the starting point for the most productive attack surface assessment. We knew where to look before we looked.

Active Services — The High-Value Targets

Several active services were immediately identifiable from certificate context:

• onlinepharmacy.superdrug.com — the NHS pharmacy platform (our primary bug bounty research target, handling prescription and patient data)
• preview.onlinepharmacy.superdrug.com — preview environment for the pharmacy platform
• onlinedoctor.superdrug.com — online doctor consultation service (2013–present)
• healthclinics.superdrug.com with a wildcard *.healthclinics.superdrug.com — health clinics infrastructure
• dare.superdrug.com / dareapp.superdrug.com — the DARE health app
• appcms.superdrug.com — app content management system
• opticians.superdrug.com, support.opticians.superdrug.com — optical service
• email.superdrug.com — email infrastructure

The pharmacy platform appearing immediately in CT log results was significant — it's a service handling prescription medication data and patient health information, which makes it a high-value target in any authorised security assessment. CT logs surfaced it on day one.

Third-Party Vendor Relationships — The Unexpected Intelligence

This is where Certificate Transparency gets particularly interesting. SSL certificates can contain Subject Alternative Names (SANs) — additional domain names bundled into a single certificate. When multiple unrelated domains appear in the same certificate, it often reveals vendor or hosting relationships.

In Superdrug's CT log output, two relationships appeared:

• dareapp.superdrug.com was bundled in the same certificate as www.pugpig.com (2017–2018). Pugpig is a mobile publishing platform. This single certificate SAN reveals that Superdrug's DARE app was built on Pugpig's platform — information that wasn't publicly disclosed anywhere else. For a pentester, Pugpig is now a third-party to investigate for shared infrastructure vulnerabilities or supply chain exposure.
• Multiple certificates showed aswatson.eu bundled with www.superdrug.com — confirming AS Watson Group ownership of the Superdrug brand through certificate infrastructure evidence, independent of any public company records.

CA Issuer Analysis — The Unexpected Flag

The distribution of Certificate Authorities that issued certificates for Superdrug's subdomains tells a second story about their infrastructure:

The cPanel CA figure stands out. cPanel is a web hosting control panel primarily used in shared hosting environments. 76 certificates from cPanel's CA on a UK retailer of Superdrug's scale suggests that some portion of their infrastructure — likely historical or departmental — runs on shared hosting rather than dedicated cloud infrastructure.

Shared hosting is a priority target in any security assessment. Shared hosting environments typically have weaker isolation between tenants, shared file system access in some configurations, and more limited network-level hardening than dedicated cloud. If Superdrug's stack includes shared hosting nodes, that's where an attacker looks next.

The Honest Assessment: What CT Logs Miss

Transparency matters in security tooling. Here's the complete picture:

What CT logs find reliably:

• Every subdomain that has ever had a publicly-trusted SSL/TLS certificate
• Historical infrastructure — even subdomains decommissioned years ago
• Environment naming conventions, even when specific environments are offline
• Third-party vendor relationships embedded in certificate SANs
• Infrastructure diversity — which cloud providers and CDNs host which services

What CT logs miss:

• HTTP-only services — no TLS certificate = invisible to CT logs. Any internal or legacy service running plain HTTP won't appear.
• Private PKI subdomains — certificates issued by internal CAs that are never submitted to public CT logs won't appear.
• Very recent certificates — CT log propagation takes minutes to hours; brand-new certificates may have a brief visibility delay.
• DNS-only subdomains — a subdomain that exists in DNS but has never had a certificate won't appear.

For a security-conscious company like Superdrug, the gap is likely small. Almost every internet-facing service they run handles HTTPS traffic, which requires a certificate. Our estimate is that CT logs cover 85–90% of their external attack surface — the 10–15% gap is worth filling with DNS brute-forcing and passive DNS history, but CT logs get you most of the way there in 12 seconds.

Why This Is Step Zero in Every Assessment

CT log analysis should be the first thing any security assessor does. Three reasons:

1. Zero noise. No alerts triggered, no WAF blocks, no rate limits hit. You can run CT log analysis before formal authorisation paperwork is finalised without any legal or operational ambiguity.
2. Historical data. CT logs show what was there, not just what is there. A staging server decommissioned last year might still have the same codebase on a slightly different IP. CT logs tell you to look for it.
3. Instant attack surface map. 79 subdomains in 12.57 seconds. A human-driven DNS enumeration session for a major retailer would take hours and likely miss the historical subdomains entirely.

In SecurityClaw's authorised Superdrug research, we spent weeks working up to onlinepharmacy.superdrug.com as a high-value target. CT logs would have shown it — with NHS pharmacy context visible in the certificate metadata — on day one.

The Tool — How to Run It

# Discover subdomains passively — zero noise
python3 ct_search.py superdrug.com --output subdomains

# Full intelligence report (CAs, dates, SANs, issuer analysis)
python3 ct_search.py superdrug.com

# Pipe directly to nmap for live host discovery
python3 ct_search.py example.com --output subdomains | \
  nmap -iL - -p 80,443 --open -oN ct_live_hosts.txt

# Pipe to nuclei for vulnerability scanning on discovered subdomains
python3 ct_search.py example.com --output subdomains | \
  nuclei -l - -t exposures/

The --output subdomains flag strips all metadata and returns one subdomain per line — ready to pipe directly into any active scanning tool. This is the bridge between passive recon and active testing: 12 seconds of zero-noise enumeration feeding directly into targeted scans against only the hosts that have confirmed historical existence.

For anyone building out a professional bug bounty workflow, Real-World Bug Hunting by Peter Yaworski covers the full recon-to-report workflow that CT log analysis fits into — including how to triage 79 subdomains into a prioritised testing list.

SecurityClaw Scorecard: Passive Recon Category Opens

D10 opens a new capability category — passive reconnaissance — on the SecurityClaw platform. Before this, every SecurityClaw demo involved active interaction with a target: sending packets, sending requests, submitting payloads. D10 is the first campaign where SecurityClaw gathered actionable intelligence without touching the target's network at all.

The PASS determination is straightforward: we asked "how much of Superdrug's external attack surface can you map without touching their network?" and the tool returned 79 subdomains, 1,499 certificates, and 12+ years of infrastructure history in 12.57 seconds. The answer to the question is "nearly all of it."

The passive recon category will grow. Upcoming campaigns will cover DNS history analysis, Shodan passive indexing, and GitHub dork-based organisation enumeration — each one a tool that answers meaningful security questions without leaving a trace. For teams building their own recon capability, The Web Application Hacker's Handbook provides the foundational methodology that all of these techniques plug into.

What This Means for Defenders

If your organisation owns public internet-facing domains, everything above applies to your infrastructure too. Your CT logs are publicly available right now. An attacker can query them in 12 seconds before they've sent a single packet to your network.

The practical implication: your external attack surface assessment should start with your own CT log output. python3 ct_search.py yourdomain.com will show you exactly what an attacker sees — the staging servers you forgot about, the vendor relationships in your certificate SANs, the cPanel CA certificates that shouldn't be there.

If the results surprise you, that's the point. Fix the surprises before the attacker finds them. For a structured approach to processing this kind of attack surface data, Penetration Testing by Georgia Weidman is the practical handbook that covers what to do with this information once you have it.