2026-10-06 · RESEARCH · Het Offensive Technology-team

Hoe Certificate Transparency-logs interne subdomeinen lekken

Lekt Certificate Transparency interne hostnames? Ja, routinematig. We hebben de openbare CT-logs voor 702 topdomeinen via crt.sh geanalyseerd, dezelfde gratis zoekopdracht die iedereen kan uitvoeren, en ontdekten dat 65.5% minstens één intern ogende hostname heeft gelogd: a dev., staging., vpn., admin., jira., of vault.-achtige naam die vrijwel zeker bedoeld was voor medewerkers, niet voor het openbare internet. Er is geen enkele host gescand, geresolved of benaderd om dit cijfer te verkrijgen. CT is een openbaar, append-only log van elk certificaat dat een publieke CA ooit heeft uitgegeven, en een naam hoeft slechts één publiek vertrouwd certificaat te ontvangen om een permanent, doorzoekbaar gegeven te worden. Dit is de eerste stap van een aanvaller voordat er ook maar gescand wordt, en de meeste organisaties geven hun interne naamgevingsconventie gratis weg.

Waarom een openbaar log privé ogende namen lekt

Certificate Transparency bestaat met een goede reden: het voorkomt dat een CA stilletjes een onterecht certificaat uitgeeft voor een domein waar het niet voor bedoeld is, omdat elk uitgegeven certificaat zichtbaar wordt voor de domeineigenaar en het publiek. Chrome en andere browsers vereisen sinds 2018 CT-logging van publiek vertrouwde CA's onder RFC 6962. Dat is een echte beveiligingswinst voor het ecosysteem. Het neveneffect is dat CT ook de hostname zelf logt, en de hostname is vaak het meest onthullende deel van het record.

Interne systemen krijgen publieke certificaten om een alledaagse, banale reden: niemand wil een browserwaarschuwing wanneer medewerkers het VPN-portaal of de interne Jira-omgeving openen, zelfs als DNS voor die naam alleen resolvet op het bedrijfsnetwerk of via een VPN-tunnel. Dus krijgt de naam een echt certificaat van Let's Encrypt, DigiCert of een andere publieke CA, net zoals een publiek toegankelijke site dat zou krijgen. Het certificaat doet stilletjes zijn werk. Het neveneffect is dat vpn.example.com of staging-admin.example.com nu permanent leesbaar is voor iedereen die CT raadpleegt voor example.com, via een gratis tool zoals crt.sh, zonder enige interactie met de eigen infrastructuur van example.com.

De data: wat 702 topdomeinen loggen

We hebben crt.sh geraadpleegd voor een steekproef uit de Tranco top-sites-lijst (lijst 94Y82), domein voor domein met caching en backoff om de dienst niet te overbelasten, en classificeerden het eerste DNS-label van elke gelogde naam op basis van negen categorieën van conventionele interne naamgeving: remote access, auth/identity, niet-productie, devops/CI, interne samenwerking, observability, admin/management, secrets/infrastructure en expliciet interne namen. 702 van de 1.000 opgevraagde domeinen werden succesvol verwerkt; 660 hadden überhaupt een CT-geschiedenis. Resultaten per domein werden tijdens de run alleen in het geheugen bewaard en nooit opgeslagen, dus niets hier noemt een specifieke organisatie. Dit zijn populatiepercentages, geen lijst.

Niet-productienamen domineren: 58.8% van de domeinen heeft een dev., staging., test. of vergelijkbare naam gelogd. Dat is de minst verrassende bevinding en op zichzelf de minst gevaarlijke, het noemen van een staging-omgeving is geen kwetsbaarheid. Interessanter is hoe ver in de lijst de gevaarlijke categorieën voorkomen. 20.4% heeft een naam gelogd gerelateerd aan secrets of infrastructuur zoals vault., consul. of k8s., en 21.8% heeft een remote-access-naam gelogd zoals vpn. of citrix. Dat zijn de categorieën waarin de naam zelf een aanvaller precies vertelt naar welk product gezocht moet worden voor een bekende CVE.

Individuele voorvoegsels vertellen hetzelfde verhaal op een gedetailleerder niveau. Hier zijn de twaalf meest voorkomende labels die we vonden, naar aandeel binnen de steekproef van 702 domeinen:

De vpn. prefix staat alleen al op 12.8% van de gehele steekproef, wat betekent dat ongeveer een op de acht van de drukste domeinen op internet de wereld, via een openbaar log dat ze zelf nooit hebben hoeven aanraken, heeft laten weten dat ze een specifiek remote-access-product op een specifieke naam draaien. Combineer dat met de version-fingerprinting die mogelijk is zodra een hostname resolvet, en een aanvaller is van nul kennis naar een geprioriteerde doelwittenlijst gegaan zonder ook maar één pakket naar het doelwit te sturen.

Het blijft zelden bij één naam

Het lekken is niet gelijkmatig verdeeld over één naam per domein. Van de 460 domeinen die iets lekten, lekten 113 een naam uit precies één categorie, maar de rest lekte tegelijkertijd over meerdere categorieën: 65 domeinen raakten drie categorieën, 42 raakten er zes en 22 domeinen lekten een naam in alle negen categorieën die we bijhielden. Zodra een organisatie de gewoonte heeft om interne tools echte publieke certificaten te geven, blijkt die gewoonte vaak consistent te gelden voor elke interne tool die ze draaien, niet slechts één. Voor een aanvaller is een domein dat breed lekt waardevoller dan een domein dat één enkele naam lekt, omdat het ontwikkel-, authenticatie- en beheerinfrastructuur in één query in kaart brengt.

Hoe je je eigen domein controleert

Dit kost minder dan een minuut en vereist geen andere tool dan een browser of curl, omdat je hetzelfde openbare register leest als wij.

• Doorzoek crt.sh rechtstreeks. Open https://crt.sh/?q=%25.yourdomain.com&output=json en bekijk elke hostname die terugkomt. Dat is alles wat CT ooit voor je domein heeft gelogd, inclusief namen die jaren geleden zijn uitgegeven voor servers die mogelijk al lang zijn ontmanteld.
• Grep de uitvoer op intern ogende labels. Zoek specifiek naar de voorvoegsels in de bovenstaande tabel: dev, test, staging, admin, auth, vpn, internal, vault, jenkins, gitlab, grafana en nauwe varianten daarvan. Alles wat overeenkomt is permanent openbaar, ongeacht of het momenteel resolvet.
• Beschouw elke match als reeds bekend bij een aanvaller. Je kunt een certificaat niet met terugwerkende kracht uit het log verwijderen. De enige optie is aannemen dat de naam openbaar is, zorgen dat de service erachter niet leunt op obscurity, en deze gepatcht en beveiligd houden met toegangscontrole zoals elk ander publiek toegankelijk asset, want voor een aanvaller die CT leest, is het dat al.

Wat dit niet bewijst

Eerlijke kanttekeningen, want een cijfer zonder nuances is marketing.

• Een gelogde naam is geen bewijs van een actieve, bereikbare of kwetsbare service. We hebben alleen hostnametekst in CT vergeleken, niets anders. We hebben geen enkele naam geresolved, geen verbinding gemaakt met een host en niet getest of de service erachter nog bestaat. Sommige van deze namen verwijzen naar ontmantelde infrastructuur, andere verwijzen naar helemaal niets.
• Het is een steekproef van 702 domeinen, niet het hele internet. De top-sites van Tranco neigen naar grote, gevestigde organisaties met voldoende infrastructuur om überhaupt dev- en staging-omgevingen te hebben. Een andere rangschikkingsmethodiek of een bredere steekproef zou de exacte percentages verschuiven.
• Het is een momentopname. Deze cijfers beschrijven de status van CT op het moment van onze meting op 24 juli 2026. Organisaties voegen continu interne hostnames toe en faseren ze uit, waardoor de exacte cijfers in de loop van de tijd verschuiven, zelfs als het onderliggende gedrag dat niet doet.
• Prefix-matching is heuristisch, niet sluitend. Een label zoals admin is meestal een intern beheerpaneel, maar kan af en toe een legitieme, publiek toegankelijke productnaam zijn. We hebben de categorielijst geoptimaliseerd voor conventionele naamgeving, niet voor perfecte precisie, dus beschouw de percentages als een sterk signaal en niet als een exacte inventarisatie.
• Dit meet de blootstelling van een naam, niet de exploiteerbaarheid. Weten dat vpn.example.com bestaat is verkenning, geen inbreuk. Wat het een aanvaller oplevert, is een geprioriteerde lijst met minimale inspanning van wat als volgende moet worden onderzocht.

Veelgestelde vragen

Kunnen aanvallers Certificate Transparency-logs gebruiken om subdomeinen te vinden?

Ja. Elk certificaat dat een publieke CA uitgeeft, wordt gelogd onder RFC 6962, en iedereen kan die logs gratis doorzoeken via crt.sh. In onze steekproef van 702 domeinen had 65.5% van de organisaties op deze manier minstens één intern ogende hostname gelogd, zonder enige interactie met hun infrastructuur.

Kunnen CT-logs interne hostnames onthullen die nooit bedoeld waren om openbaar te zijn?

Ja. Een naam heeft slechts één publiek vertrouwd certificaat nodig, vaak uitgegeven zodat medewerkers geen browserwaarschuwing te zien krijgen, om een permanent openbaar gegeven te worden. De server erachter hoeft niet via internet bereikbaar te zijn om de naam zelf te laten lekken.

Welke informatie wordt blootgesteld in het Subject Alternative Name-veld van een certificaat?

Het SAN-veld bevat elke hostname die een certificaat dekt. Eén enkel multi-domeincertificaat kan tientallen namen tegelijk blootstellen, die allemaal doorzoekbaar zijn in CT zodra het certificaat wordt uitgegeven.

Hoe ontdek ik subdomeinen met behulp van crt.sh?

Zoek op https://crt.sh/?q=%25.yourdomain.com&output=json. Dit retourneert elk gelogd certificaat voor je domein en subdomeinen, inclusief certificaten die zijn uitgegeven voor servers die mogelijk niet meer bestaan. Het is een passieve, read-only lookup in een openbaar log, dezelfde methode die we hier hebben gebruikt.

Voorkomt een wildcard-certificaat dat subdomeinen in CT-logs verschijnen?

Een wildcard-certificaat voor *.example.com logt alleen de wildcard-string en verbergt het specifieke subdomeinlabel. Maar zodra één service een eigen, uniek benoemd certificaat krijgt, wordt die naam gelogd, zelfs als al het andere achter een wildcard zit.

Hoe kan ik voorkomen dat interne hostnames lekken naar Certificate Transparency?

Gebruik een private, interne CA voor namen die nooit openbaar mogen worden, aangezien alleen publieke CA's moeten loggen naar CT. Geef de voorkeur aan wildcard-certificaten boven uniek benoemde leaf-certificaten waar je architectuur dit toestaat, en beschouw alles wat al in CT staat als permanent bekend.

Zijn private of interne certificaatautoriteiten vrijgesteld van Certificate Transparency-logging?

Ja. CT-logging is verplicht voor publiek vertrouwde CA's, niet voor certificaten in het algemeen. Een certificaat van je eigen interne CA, dat alleen wordt vertrouwd door je beheerde apparaten, hoeft nooit in een openbaar CT-log terecht te komen.

Gerelateerde artikelen

• Wat kunnen aanvallers daadwerkelijk zien van je bedrijf? De bredere attack surface-vraag waar dit bericht een deel van beantwoordt.
• Hoe lang duurt het voordat een certificaat in CT verschijnt? Zelfde crt.sh-hoek, de vraag over timing in plaats van over naamgeving.
• Is Certificate Transparency al post-quantum? Een andere laag van hetzelfde openbare log-ecosysteem, de checkpoint-ondertekeningslaag in plaats van de certificaatinhoud.