2026-10-06 · RESEARCH · Das Team von Offensive Technology

Wie Certificate-Transparency-Logs interne Subdomains preisgeben

Geben Certificate-Transparency-Logs interne Hostnames preis? Ja, regelmäßig. Wir haben die öffentlichen CT-Logs für 702 Top-Domains über crt.sh ausgewertet, denselben kostenlosen Lookup, den jeder ausführen kann, und festgestellt: 65.5% haben mindestens einen intern wirkenden Hostname geloggt: a dev., staging., vpn., admin., jira., oder einen Namen im Stil von vault., der mit an Sicherheit grenzender Wahrscheinlichkeit für Mitarbeiter und nicht für das öffentliche Internet bestimmt war. Kein einziger Host wurde gescannt, aufgelöst oder kontaktiert, um diesen Wert zu ermitteln. CT ist ein öffentliches, Append-only-Logbuch jedes Zertifikats, das jemals von einer öffentlichen CA ausgestellt wurde. Ein Name muss nur ein einziges öffentlich vertrauenswürdiges Zertifikat erhalten, um zu einem dauerhaften, durchsuchbaren Datensatz zu werden. Das ist der erste Schritt eines Angreifers, bevor überhaupt ein Scan beginnt. Und die meisten Unternehmen geben ihre internen Namenskonventionen völlig kostenlos preis.

Warum ein öffentliches Log privat wirkende Namen leakt

Certificate Transparency existiert aus gutem Grund: Es verhindert, dass eine CA heimlich und fälschlicherweise ein Zertifikat für eine Domain ausstellt, für die sie es nicht sollte, da jedes ausgestellte Zertifikat für den Domaininhaber und die Öffentlichkeit sichtbar wird. Chrome und andere Browser fordern das CT-Logging von öffentlich vertrauenswürdigen CAs seit 2018 gemäß RFC 6962. Das ist ein echter Sicherheitsgewinn für das gesamte Ökosystem. Der Nebeneffekt: CT protokolliert auch den Hostname selbst, und dieser Hostname ist oft der aufschlussreichste Teil des Datensatzes.

Interne Systeme erhalten öffentliche Zertifikate aus einem ganz pragmatischen Grund: Niemand möchte eine Browserwarnung sehen, wenn Mitarbeiter das VPN-Portal oder die interne Jira-Instanz öffnen, selbst wenn das DNS für diesen Namen nur im Unternehmensnetzwerk oder über einen VPN-Tunnel auflöst. Also erhält der Name ein echtes Zertifikat von Let's Encrypt, DigiCert oder einer anderen öffentlichen CA, genau wie eine öffentlich erreichbare Website. Das Zertifikat erfüllt unauffällig seinen Zweck. Der Nebeneffekt: vpn.example.com oder staging-admin.example.com ist nun dauerhaft für jeden einsehbar, der CT über ein kostenloses Tool wie crt.sh nach example.com abfragt, ganz ohne Interaktion mit der eigentlichen Infrastruktur von example.com.

Die Daten: Was 702 Top-Domains protokollieren

Wir haben crt.sh für eine Stichprobe der Tranco-Top-Sites-Liste abgefragt (Liste 94Y82), Domain für Domain mit Caching und Backoff, um den Dienst zu schonen. Anschließend haben wir das erste DNS-Label jedes protokollierten Namens anhand von neun Kategorien typischer interner Namenskonventionen klassifiziert: Remote Access, Auth/Identity, Non-Production, DevOps/CI, interne Kollaboration, Observability, Admin/Management, Secrets/Infrastruktur und explizit interne Namen. 702 der 1,000 angefragten Domains lieferten vollständige Daten; 660 wiesen überhaupt eine CT-Historie auf. Die Ergebnisse pro Domain wurden für den Durchlauf ausschließlich im Arbeitsspeicher gehalten und nie gespeichert, sodass hier keine konkreten Unternehmen genannt werden. Es handelt sich um Prozentwerte der Gesamtstichprobe, nicht um eine Namensliste.

Non-Production-Namen dominieren: 58.8% der Domains haben einen dev., staging., test. oder ähnlichen Namen geloggt. Das ist der am wenigsten überraschende Befund und für sich genommen der harmloseste, denn die Benennung einer Staging-Umgebung ist keine Schwachstelle. Interessanter ist, wie weit unten in der Liste die wirklich gefährlichen Kategorien auftauchen. 20.4% haben einen Secrets- oder infrastrukturnahen Namen geloggt wie vault., consul. oder k8s., und 21.8% haben einen Remote-Access-Namen geloggt wie vpn. oder citrix. Das sind genau die Kategorien, bei denen der Name dem Angreifer unmittelbar verrät, nach welchen bekannten CVEs für ein bestimmtes Produkt er suchen muss.

Einzelne Präfixe zeichnen dasselbe Bild mit höherer Detailschärfe. Hier sind die zwölf häufigsten Labels aus unserer Stichprobe von 702 Domains:

Das Präfix vpn. allein liegt bei 12.8% der gesamten Stichprobe. Das bedeutet, dass grob eine von acht der meistbesuchten Domains im Internet der Welt über ein öffentliches Log mitgeteilt hat, dass sie ein bestimmtes Remote-Access-Produkt unter einem bestimmten Namen betreibt, ohne dass sie dafür je kontaktiert werden musste. Kombiniert man das mit dem Versions-Fingerprinting, das möglich wird, sobald ein Hostname auflöst, hat ein Angreifer ohne ein einziges Paket an das Ziel gesendet zu haben eine priorisierte Angriffsliste aus dem Nichts erstellt.

Es bleibt selten bei einem einzigen Namen

Die Leaks verteilen sich nicht gleichmäßig auf einen Namen pro Domain. Von den 460 Domains, die überhaupt Daten preisgaben, leakteten 113 einen Namen aus genau einer Kategorie, der Rest jedoch über mehrere Kategorien hinweg: 65 Domains fielen in drei Kategorien, 42 in sechs, und 22 Domains wiesen Namen in allen neun erfassten Kategorien auf. Sobald sich in einem Unternehmen die Gewohnheit etabliert hat, internen Tools echte öffentliche Zertifikate auszustellen, betrifft das meist jedes interne Tool und nicht nur ein einzelnes. Für einen Angreifer ist eine Domain mit breitem Datenleak wertvoller als eine mit nur einem Namen, da sie Entwicklungs-, Authentifizierungs- und Administrationsinfrastruktur in einer einzigen Abfrage offenlegt.

So prüfen Sie Ihre eigene Domain

Das dauert unter einer Minute und erfordert außer einem Browser oder curl kein weiteres Tool, da Sie genau dieselben öffentlichen Datensätze lesen wie wir.

• crt.sh direkt abfragen. Öffnen Sie https://crt.sh/?q=%25.yourdomain.com&output=json und prüfen Sie alle zurückgegebenen Hostnames. Das ist alles, was CT jemals für Ihre Domain protokolliert hat, einschließlich Namen, die vor Jahren für längst stillgelegte Server ausgestellt wurden.
• Die Ausgabe nach intern wirkenden Labels filtern. Suchen Sie gezielt nach den Präfixen aus der obigen Tabelle: dev, test, staging, admin, auth, vpn, internal, vault, jenkins, gitlab, grafana und deren Varianten. Jeder Treffer ist dauerhaft öffentlich, unabhängig davon, ob er aktuell auflöst.
• Jeden Treffer als Angreifern bereits bekannt behandeln. Sie können ein Zertifikat nicht nachträglich aus dem Log entfernen. Die einzige sinnvolle Maßnahme ist anzunehmen, dass der Name öffentlich ist. Stellen Sie sicher, dass der Dienst dahinter nicht auf Security by Obscurity setzt, und patchen sowie sichern Sie ihn wie ein System mit direktem Internetzugang. Denn für einen Angreifer, der CT liest, ist er genau das.

Was dies nicht belegt

Transparente Grenzen, denn eine Zahl ohne Kontext ist reines Marketing.

• Ein geloggter Name ist kein Beweis für einen aktiven, erreichbaren oder verwundbaren Dienst. Wir haben lediglich Hostname-Strings in CT abgeglichen, sonst nichts. Wir haben keinen Namen aufgelöst, keine Verbindung zu einem Host aufgebaut und nicht geprüft, ob der Dienst dahinter noch existiert. Manche dieser Namen verweisen auf stillgelegte Infrastruktur, manche auf gar nichts mehr.
• Es ist eine Stichprobe von 702 Domains, nicht das gesamte Internet. Die Tranco-Top-Sites neigen zu großen, etablierten Unternehmen mit ausreichend Infrastruktur, um überhaupt Entwicklungs- und Staging-Umgebungen zu betreiben. Eine andere Ranking-Methodik oder eine breitere Stichprobe würde die exakten Prozentwerte verschieben.
• Es ist eine Momentaufnahme. Diese Zahlen spiegeln den Zustand von CT zum Zeitpunkt unseres Abrufs am 24. Juli 2026 wider. Unternehmen fügen kontinuierlich interne Hostnames hinzu oder mustern sie aus, daher verändern sich die genauen Werte im Laufe der Zeit, auch wenn das zugrunde liegende Verhalten gleich bleibt.
• Präfix-Matching ist eine Heuristik, keine absolute Gewissheit. Ein Label wie admin steht meist für ein internes Administrationspanel, kann vereinzelt aber auch ein legitimer öffentlicher Produktname sein. Wir haben die Kategorienliste auf gängige Namenskonventionen optimiert, nicht auf absolute Trennschärfe. Betrachten Sie die Prozentwerte daher als starkes Signal, nicht als exaktes Inventar.
• Dies misst die Exposition eines Namens, nicht seine Angreifbarkeit. Zu wissen, dass vpn.example.com existiert, ist Aufklärung, keine Kompromittierung. Ein Angreifer erhält dadurch jedoch eine priorisierte Liste lohnender Angriffsziele mit minimalem Aufwand.

Häufig gestellte Fragen

Können Angreifer Certificate-Transparency-Logs nutzen, um Subdomains zu finden?

Ja. Jedes von einer öffentlichen CA ausgestellte Zertifikat wird gemäß RFC 6962 protokolliert, und jeder kann diese Logs kostenlos über crt.sh durchsuchen. In unserer Stichprobe von 702 Domains hatten 65.5% der Unternehmen auf diese Weise mindestens einen intern wirkenden Hostname offengelegt, ganz ohne Interaktion mit deren Infrastruktur.

Können CT-Logs interne Hostnames aufdecken, die nie öffentlich sein sollten?

Ja. Ein Name benötigt nur ein einziges öffentlich vertrauenswürdiges Zertifikat, oft nur ausgestellt, damit Mitarbeiter keine Browserwarnung sehen, um zu einem dauerhaften öffentlichen Datensatz zu werden. Der Server dahinter muss nicht über das Internet erreichbar sein, damit der Name leakt.

Welche Informationen werden im Feld Subject Alternative Name eines Zertifikats offengelegt?

Das SAN-Feld listet jeden Hostname auf, für den ein Zertifikat gilt. Ein einzelnes Multi-Domain-Zertifikat kann dutzende Namen auf einmal offenlegen, die alle in CT durchsuchbar sind, sobald das Zertifikat ausgestellt wird.

Wie finde ich Subdomains mit crt.sh?

Fragen Sie https://crt.sh/?q=%25.yourdomain.com&output=json ab. Dies liefert jedes protokollierte Zertifikat für Ihre Domain und deren Subdomains zurück, einschließlich solcher, die für möglicherweise längst nicht mehr existierende Server ausgestellt wurden. Es ist ein passiver Read-Only-Lookup eines öffentlichen Logs, dieselbe Methode, die wir hier verwendet haben.

Verhindert ein Wildcard-Zertifikat, dass Subdomains in CT-Logs auftauchen?

Ein Wildcard-Zertifikat für *.example.com loggt nur den Wildcard-String selbst und verbirgt das spezifische Subdomain-Label. Sobald jedoch ein Dienst ein eigenes, dediziert benanntes Zertifikat erhält, wird dieser Name protokolliert, selbst wenn alles andere hinter einem Wildcard-Zertifikat liegt.

Wie kann ich verhindern, dass interne Hostnames in Certificate Transparency leaken?

Verwenden Sie eine private, interne CA für Namen, die niemals öffentlich sein sollten, da nur öffentliche CAs in CT protokollieren müssen. Bevorzugen Sie Wildcard-Zertifikate gegenüber eindeutig benannten Leaf-Zertifikaten, sofern Ihre Architektur dies zulässt, und behandeln Sie alles, was bereits in CT steht, als öffentlich bekannt.

Sind private oder interne Zertifizierungsstellen vom Certificate-Transparency-Logging ausgenommen?

Ja. Das CT-Logging ist eine Pflicht für öffentlich vertrauenswürdige CAs, nicht für Zertifikate im Allgemeinen. Ein Zertifikat Ihrer eigenen internen CA, dem nur Ihre verwalteten Geräte vertrauen, muss niemals in einem öffentlichen CT-Log auftauchen.

Weiterführende Artikel

• Was Angreifer tatsächlich über Ihr Unternehmen sehen können Die umfassendere Frage der externen Angriffsfläche, von der dieser Artikel einen Teilbereich beleuchtet.
• Wie lange dauert es, bis ein Zertifikat in CT auftaucht? Aus demselben crt.sh-Umfeld, hier steht der zeitliche Aspekt statt der Namensgebung im Fokus.
• Ist Certificate Transparency bereits Post-Quanten-sicher? Eine andere Ebene desselben Ökosystems öffentlicher Logs, die Checkpoint-Signierung statt des Zertifikatsinhalts.