The Subdomain You Forgot About
Somewhere on your domain, there's a subdomain you don't remember. staging-old.yourdomain.com from a launch three years ago. jenkins.yourdomain.com from when DevOps was a one-person team. oauth-test.yourdomain.com from the SSO migration that never finished. They still resolve. They still serve content. And every penetration tester, bug bounty hunter, and opportunistic attacker can find them in five seconds.
The reason isn't that someone leaked your DNS zone. It's that the moment you issued a TLS certificate for those subdomains — usually via Let's Encrypt's automated process — they were logged in Certificate Transparency logs: append-only, public, queryable, permanent. The same mechanism designed to make CA misbehavior detectable also makes your forgotten subdomains discoverable.
This guide walks through how Certificate Transparency works, why it's both a critical defensive control and an attacker's first reconnaissance step, and how to use it to find what's already exposed before someone else does.
You can run a CT-log subdomain search against any domain right now using our free Subdomain Finder — no signup, runs entirely in your browser via crt.sh.
What Certificate Transparency Actually Does
Certificate Transparency (CT) is a system, mandated by every major browser, that requires every publicly-trusted TLS certificate to be logged in at least two append-only public logs before it's trusted. The original goal was defensive: catch CAs issuing certificates for domains they shouldn't (a 2011 incident with DigiNotar issuing certs for Google to Iranian intelligence was the proximate cause). If a CA mis-issues a cert, it shows up in CT logs and the legitimate domain owner can detect it.
The mechanics are roughly: when a CA issues a cert, it submits the cert to multiple CT log servers operated by Google, Cloudflare, DigiCert, and others. Each log returns a Signed Certificate Timestamp (SCT) proving the log accepted it. Browsers refuse to trust certificates without SCTs from a sufficient number of qualified logs. The logs themselves are append-only — entries cannot be removed or modified after acceptance — which means once a cert is logged, it's logged forever.
This is genuinely good for the open web. Domain owners can monitor CT logs for unauthorized certificate issuance against their domains and detect compromise within minutes. Browsers can detect rogue CAs. Researchers can analyze cert ecosystems at scale.
The side effect: every Subject Alternative Name on every certificate is now public. SANs are how a single cert covers multiple hostnames — your wildcard *.example.com cert lists exactly which subdomains it was issued for. Your individual api.example.com cert announces "api.example.com exists." Every staging, every dev environment, every internal tool that ever needed HTTPS now has its hostname in CT logs forever.
Querying CT Logs in Practice
The most common interface is crt.sh, a free public service operated by Sectigo that mirrors and indexes CT logs. You query crt.sh by domain, it returns every certificate (and every Subject Alternative Name) it has on record. The JSON API is the same one our Subdomain Finder uses:
GET https://crt.sh/?q=example.com&output=jsonThe response is an array of certificate entries:
[
{
"issuer_name": "C=US, O=Let's Encrypt, CN=R3",
"common_name": "api.example.com",
"name_value": "api.example.com\nauth.example.com\nstaging.example.com",
"not_before": "2024-09-15T08:30:00",
"not_after": "2024-12-14T08:30:00",
"id": 14829380123
},
...
]Each entry's name_value is the newline-separated list of hostnames that certificate covered. Pull every name_value from every entry, dedupe, filter to entries actually under your target domain, and you have a complete list of every subdomain ever issued a certificate. For most domains the list is dozens to hundreds of entries.
Other CT log search interfaces exist (Censys, SecurityTrails, Spyse, Google's CT log search), some with richer querying and some with paid tiers. crt.sh is free, doesn't require auth, and has CORS enabled — which is why it's the source for our browser-based tool.
What an Attacker Sees in CT Logs
A focused recon session against any domain starts with the same query you just learned. The output is gold for an attacker because it tells them:
Forgotten infrastructure. jenkins-old.yourdomain.com, staging-2019.yourdomain.com, oauth-poc.yourdomain.com. Subdomains that were spun up for projects, given a Let's Encrypt cert, and never decommissioned. The DNS is still there, the cert was issued, the service is probably still running an outdated version of whatever it was running three years ago.
Internal tools accidentally on the public internet. Many teams run internal-only tools (Jenkins, Grafana, Kibana, internal admin panels) and assume "no one knows the URL = secure." CT logs publish the URL. Combine with a port scan and the attacker has a target.
SaaS integrations they can attack. shop.yourdomain.com → CNAME → store.shopify.com, docs.yourdomain.com → CNAME → readthedocs.io, app.yourdomain.com → CNAME → custom-domain.netlify.app. Each tells the attacker which third-party service to target. Subdomain takeover risk is highest when the third-party account has been deprovisioned but the CNAME still exists.
Naming conventions. Once they see app-prod-1.yourdomain.com and app-staging-1.yourdomain.com in CT, they'll guess app-dev-1, app-test-1, app-qa-1 and try those even if they're not in CT (no cert needed for HTTP-only).
Migrations and infrastructure changes. If your CT history shows certs issued by Heroku-managed wildcards in 2022 and DigiCert wildcards in 2024, you migrated off Heroku in 2023. That's intel an attacker can use for social engineering ("Hi, I'm from your old Heroku account team, we need to verify…").
None of this is a vulnerability in CT. CT is doing exactly what it was designed to do. The exposure is a side effect of having a public PKI. Your job is to make sure nothing in CT is a surprise to you.
The Real Risks: Subdomain Takeover and Shadow Infrastructure
Two specific risks make CT-log subdomain enumeration more than a curiosity.
Subdomain takeover. When a subdomain points (via CNAME) at a third-party service that no longer claims that hostname, an attacker can register the hostname on the platform and serve content under your domain. Common patterns:
shop.yourdomain.com → your-old-store.shopify.com— Shopify account cancelled, store name now claimabledocs.yourdomain.com → your-old-docs.readthedocs.io— Read the Docs account closed, project name reusablecdn.yourdomain.com → cdn-bucket.s3.amazonaws.com— S3 bucket deleted, bucket name available for re-creationapi.yourdomain.com → your-app.herokuapp.com— Heroku app deprovisioned, app name now free
The pattern: discover via CT logs, check whether the CNAME target is still claimed, register the hostname on the platform, serve attacker content under the victim's domain. Subdomain takeover lets attackers send phishing emails from your domain (with valid SPF/DKIM if you've authorized the platform), bypass Content Security Policy whitelists, and exfiltrate user sessions via cookies scoped to your domain. Mitre tracks this as a documented attack pattern and there are weekly reports of it succeeding against major brands.
Shadow infrastructure. Forgotten servers, expired auto-renewals on dev environments, abandoned proof-of-concept apps that still resolve. These are the assets that fail every security control you've put in place: they don't get patched (no one knows they exist), they don't get monitored (not in any inventory), they don't follow your password policy (last touched in 2021 by someone who's since left). Attackers love them because the success-to-effort ratio is enormous — one outdated WordPress install on a forgotten subdomain is more useful than a year of Burp Suite work against your hardened production stack.
What to Do With a CT Log Subdomain List
Run our free Subdomain Finder against your primary domain. You'll likely get a list of 20-200 unique hostnames depending on your organization's size. Then for each entry, do the work attackers won't do:
1. Resolve every subdomain. Run DNS A and CNAME queries on each. Anything that doesn't resolve is fine (DNS was removed). Anything that resolves to an IP you don't recognize, or a CNAME pointing at a third-party service, needs investigation.
2. For each CNAME, verify the target is still claimed. Visit the CNAME target in a browser. If you get a "no such app" / "domain not found" / "404 nothing here" error from the third-party platform, that's a subdomain takeover risk. Re-claim the hostname on the platform or delete the CNAME.
3. For each resolving subdomain you don't recognize, investigate. What's running there? When was the cert last renewed? Is the service patched? Is it supposed to exist?
4. Decommission what you don't need. Every subdomain that exists is attack surface. The smallest attack surface is the one you don't have. Remove DNS records for retired services. Cancel Let's Encrypt auto-renewal on subdomains you don't use anymore.
5. For everything you keep, document why. Subdomain inventory should be deliberate, not accidental. If you can't explain what a subdomain is for, you probably don't need it.
Beyond CT: When This Tool Isn't Enough
Certificate Transparency only tells you about subdomains that have ever had a publicly-trusted certificate. There are several common cases where a subdomain exists but won't appear in CT:
- HTTP-only services. No cert, no CT entry. (You should be running HTTPS everywhere, but reality is messier.)
- Internal-only DNS. Subdomains that resolve only inside your VPN or only via internal DNS won't appear. CT only sees publicly-issued certs.
- Private CA-issued certs. If you run an internal CA (some enterprises do), those certs aren't in public CT logs.
- Wildcard-only setups. If
*.example.comcovers everything and individual subdomain certs aren't issued, you'll see the wildcard but not which specific subdomains exist behind it.
For full coverage, combine CT-based discovery with active enumeration: DNS brute-forcing with a wordlist (tools like subfinder, amass, sublist3r), zone transfer attempts (rare but occasionally productive), search engine scraping (Google's site:yourdomain.com), and passive sources like Project Sonar's DNS datasets. Each method finds subdomains the others miss.
The CT-log approach is the highest-confidence starting point — every hostname returned definitely existed at one point because someone issued a real certificate for it — but it's the floor of your subdomain inventory, not the ceiling.
Continuous Monitoring: Why a One-Time Scan Isn't Enough
You ran the scan, you decommissioned the dead subdomains, you fixed the takeovers. Two weeks later, your DevOps team spins up new-staging.yourdomain.com and Let's Encrypt issues a cert. It hits CT logs within minutes. You don't know it exists.
That's the gap between one-time scanning and continuous monitoring. The right answer for production environments is a system that watches CT logs in real time and alerts you on every new certificate issued for any of your domains. Two reasons:
Asset visibility. Every new subdomain is a new attack surface. Knowing about it within minutes (rather than discovering it on next quarter's pen test) is the difference between catching a misconfiguration before it matters and explaining a breach to your board.
Unauthorized issuance detection. If a cert appears for a hostname you didn't authorize — issued by a CA you don't use, for a subdomain you've never had — that's a strong signal of registrar account compromise, CI/CD pipeline hijack, or rogue insider. CT monitoring is one of the highest-signal early warning systems available.
FortWatch monitors CT logs continuously for every domain you own and alerts you the moment a new certificate is issued for any subdomain. It's combined with continuous DNS monitoring (which catches subdomain takeover risk on existing CNAMEs), so you're covered both for "new things appearing" and "existing things changing." Start free and add your first domain in two minutes.
For a one-time check right now, our free Subdomain Finder queries crt.sh directly from your browser. No signup, no rate limits, no data sent to FortWatch. Run it against your domain — you'll likely find at least one subdomain you'd forgotten about.
The Subdomain Audit Checklist
Use this against every domain you own — primary, marketing, acquired company domains, the lot.
- Run a CT-log subdomain enumeration. Use our free tool or
curl 'https://crt.sh/?q=yourdomain.com&output=json'. - Resolve every result. Identify which subdomains still respond to DNS queries.
- Investigate every CNAME pointing at a third-party platform. Verify the target is still under your control.
- Identify what each resolving subdomain serves. If you can't explain it, investigate.
- Decommission dead subdomains. Remove DNS records for retired services.
- Document the live ones. Maintain a deliberate subdomain inventory.
- Set up continuous CT log monitoring so the next new subdomain doesn't go unnoticed for months.
Run step 1 now with the free Subdomain Finder. The rest is your weekend project.