The Cert That Named It: Certificate Transparency as Attack Surface
The challenge
Caldera Freight has one application its security team is certain is not on the internet. It has no public DNS record anyone remembers creating, it is not linked from the website, it is not in any search index, and the README says in plain words that it is internal only. You have been asked to check that claim from the outside, with nothing but public records. There is a way in, and it is not a wordlist. Every time a certificate is issued for a name, that name is written to a public, permanent, append-only log, and nobody at Caldera was thinking about that log the day they bundled two hosts onto one certificate to save themselves a renewal. Work through the records, discard the names that are dead or that belong to someone else, and submit the internal hostname that is actually live on the public internet.
What you'll learn
- Use Certificate Transparency as a primary source for subdomain discovery
- Read subject alternative names rather than the common name alone
- Separate a live certificate from a live host using DNS
- Discard names that resolve into RFC 1918 space as unreachable
- Use netblock ownership to tell your assets from a vendor's
Skills tested
Prerequisites
- What a TLS certificate and a subdomain are
- Reading dig output and an NXDOMAIN response
How it works
Certificate Transparency was built to catch misissued certificates, and it does. The side effect is that it is also a permanent, public, append-only index of hostnames, contributed to by every certificate authority, for free, with no way to withdraw an entry. If a name has ever had a certificate, the name is public, whatever the DNS zone or the README says.
The habit this exercise trains is reading the whole certificate. A certificate has a subject and a list of subject alternative names, and modern clients ignore the common name entirely: the SAN list is what is actually validated. Record id 9501338 is issued for status.caldera.example, and buried third in its SAN list is ops-console.caldera.example. Scan the CN column and the console is invisible. The changelog tells you why it is there: ticket OPS-4471 renewed the console in the same batch as the status page, because it was one less renewal to remember.
Discovery is not the finish line, because a certificate proves that a name existed, not that a host answers. vpn.caldera.example has the newest certificate of the whole set, issued the day before the appliance was retired, and it is NXDOMAIN. That gap between certificate and reality is exactly why the elimination pass matters.
Two more filters finish it. internal.caldera.example resolves to 10.40.7.15, RFC 1918 space that is not routable from the internet, so the name leaks but the host does not. status and uptime CNAME onto 203.0.113.77, which the netblock record assigns to a hosting vendor, not to Caldera. Reachable, but not Caldera's asset and not Caldera's problem.
One address is left inside Caldera's own assignment, answering on 443 with a login form. The README describes an intention that the infrastructure never enforced.
Common mistakes
- Reading only the CN line. The console never appears as a subject, only as the third alternative name on a neighbour's certificate.
- Answering vpn.caldera.example. Newest certificate in the set, and NXDOMAIN. A certificate outlives the host.
- Answering internal.caldera.example. It resolves, but into RFC 1918 space you cannot route to.
- Answering status or uptime. Both point at a vendor netblock that Caldera does not own.
- Guessing admin or portal. Both are NXDOMAIN, and the changelog says admin was never provisioned.
How to defend against it
You cannot unpublish a Certificate Transparency entry, so the control is to plan around the log rather than hope nobody reads it.
- Never bundle an internal host onto a public certificate to save a renewal. Automate renewal instead, so convenience stops being a reason.
- Use a private certificate authority for internal names, or issue for a name that is only meaningful inside the network.
- Monitor Certificate Transparency for your own domains and alert on any name that was not expected. The same log that finds this for an attacker finds it for you first.
- Stop treating obscurity as a control. Put the console behind the VPN or an identity-aware proxy so that knowing the name buys nothing.
- Reconcile DNS against the asset inventory on a schedule. Retire records and certificates together, and remember that the reverse case, a retired record with a live certificate, is the one that misleads defenders.