Überwachung von TLS-Zertifikatstransparenzprotokollen

Was macht Überwachung von TLS-Zertifikatstransparenzprotokollen?

Verwendungszweck

• Überwachung eigener Domains auf unbefugte oder unerwartete Zertifikatsausstellungen durch unbekannte Zertifizierungsstellen
• Entdecken von Subdomains und versteckten Diensten durch in öffentlichen CT-Logs protokollierte Zertifikate
• Erkennung von Phishing-Infrastruktur, die Zertifikate mit ähnlich aussehenden Domains verwendet (Typosquatting, Homograph-Angriffe)
• Prüfung der Einhaltung der Richtlinien von Zertifizierungsstellen durch Überprüfung, ob alle ausgestellten Zertifikate wie von Browserrichtlinien gefordert in CT-Logs erscheinen
• Aufbau einer kontinuierlichen Zertifikatsüberwachung in eine Sicherheitsoperations-Pipeline mit Alarmierung bei neuen Ausstellungen

Nicht verwenden für Angriffe oder Störungen von Zertifizierungsstellen, zum Scraping von CT-Logs unter Verletzung von Ratenbegrenzungen oder Nutzungsbedingungen oder als alleinige Methode zur Subdomain-Enumeration ohne Bestätigung durch DNS-Überprüfung.

Voraussetzungen

• Python 3.10+ mit den Bibliotheken requests, cryptography und pyOpenSSL
• Netzwerkzugriff auf crt.sh (HTTPS) und öffentliche CT-Log-Server
• Eine Liste der zu überwachenden Domains (eigene Domains, Markenvarianten, Typosquat-Kandidaten)
• SMTP-Anmeldedaten oder Webhook-URL für Alarmierung bei neuen Zertifikatsentdeckungen
• Grundlegendes Verständnis der X.509-Zertifikatsstruktur und der TLS-Zertifikatskettenvalidierung

Arbeitsablauf

Schritt 1: Domain-Inventur und Basislinie

Erstellen Sie das anfängliche Zertifikatsinventar für die überwachten Domains:

• Überwachungsumfang definieren: Listen Sie alle eigenen Root-Domains, eingetragenen Markennamen und bekannten Tochtergesellschaften auf. Fügen Sie Wildcard-Muster (%.example.com) für eine umfassende Subdomain-Abdeckung hinzu.
• Historische Zertifikate von crt.sh abfragen: Verwenden Sie die crt.sh JSON-API, um alle bekannten Zertifikate für jede Domain abzurufen. Der API-Endpunkt https://crt.sh/?q=%.example.com&output=json gibt Zertifikate zurück, die dem Wildcard-Muster entsprechen, mit Feldern wie issuer_ca_id, issuer_name, common_name, name_value, not_before, not_after und serial_number.
• Basisdatenbank aufbauen: Speichern Sie die anfängliche Zertifikatsmenge in einer lokalen SQLite-Datenbank mit Spalten für Zertifikats-ID, Domain, Aussteller, Gültigkeitsdaten, SANs (Subject Alternative Names) und Zeitstempel der ersten Sichtung. Diese Basislinie verhindert Alarme für bereits bekannte Zertifikate.
• Autorisierte Zertifizierungsstellen identifizieren: Extrahieren Sie aus der Basislinie die Menge der Zertifizierungsstellen, die legitimerweise Zertifikate für Ihre Domains ausgestellt haben. Jede zukünftige Ausstellung durch eine nicht in dieser Menge enthaltene Zertifizierungsstelle löst einen Alarm mit hoher Priorität aus.
• Subdomains kartieren: Extrahieren Sie alle eindeutigen Subdomains aus dem Feld name_value aller Zertifikate, um ein anfängliches Subdomain-Inventar zu erstellen.

Schritt 2: Kontinuierliche CT-Log-Überwachung

Richten Sie eine fortlaufende Überwachung auf neue Zertifikatsausstellungen ein:

• crt.sh regelmäßig abfragen: Fragen Sie die crt.sh-API in regelmäßigen Abständen (alle 15-60 Minuten) nach neuen Zertifikaten ab. Verwenden Sie den Parameter exclude=expired, um sich auf derzeit gültige Zertifikate zu konzentrieren. Vergleichen Sie die Ergebnisse mit der Basisdatenbank, um neue Einträge zu identifizieren.
• Zertifikatsdetails parsen: Extrahieren Sie für jedes neue Zertifikat die vollständige SAN-Liste, die Ausstellerkette, den Gültigkeitszeitraum, den Schlüsseltyp und die Schlüsselgröße, die SCT-Details (Signed Certificate Timestamp) des CT-Logs und den Zertifikatsfingerabdruck (SHA-256).
• Precertificates erkennen: CT-Logs enthalten Precertificates (vergiftete Zertifikate, die vor der endgültigen Ausstellung eingereicht wurden). Verfolgen Sie diese als Frühwarnungen, da sie darauf hinweisen, dass ein Zertifikat kurz vor der Ausstellung steht, aber möglicherweise noch nicht aktiv ist.
• Signed Tree Heads (STH) von CT-Logs überwachen: Für fortgeschrittene Überwachung fragen Sie CT-Log-Server direkt ab, um den neuesten STH abzurufen und Konsistenznachweise zwischen aufeinanderfolgenden Tree Heads zu überprüfen. Eine Inkonsistenz deutet auf Fehlverhalten des Logs (Split-View-Angriff) hin.
• Ratenbegrenzung beachten: Respektieren Sie die Ratenbegrenzungen von crt.sh, indem Sie Abfragen zeitlich abstimmen und Antworten zwischenspeichern. Implementieren Sie exponentielles Backoff bei HTTP-429-Antworten. Erwägen Sie bei hohem Überwachungsvolumen die direkte Abfrage der PostgreSQL-Schnittstelle von crt.sh unter crt.sh:5432.
• Atom/RSS-Feed-Alternative: Abonnieren Sie den Atom-Feed von crt.sh für eine schlankere Überwachung: https://crt.sh/atom?q=%25.example.com bietet Echtzeitbenachrichtigungen über neue Logeinträge.

Schritt 3: Subdomain-Erkennung mittels CT-Daten

Extrahieren und validieren Sie in Zertifikatstransparenzdaten gefundene Subdomains:

• Wildcard-Erweiterung: Zertifikate mit Wildcard-SANs (*.dev.example.com) offenbaren die Existenz von Subdomains, die möglicherweise nicht in DNS-Zonendateien enthalten sind. Zeichnen Sie die übergeordnete Domain als Ziel für die weitere Aufzählung auf.
• Historische Zertifikatsanalyse: Fragen Sie crt.sh ohne den Parameter exclude=expired ab, um Subdomains aus abgelaufenen Zertifikaten zu finden, die möglicherweise noch im DNS aufgelöst werden. Diese repräsentieren historische Infrastruktur, die anfällig für Subdomain-Übernahmen sein könnte.
• DNS-Validierung: Führen Sie für jede entdeckte Subdomain eine DNS-Auflösung (A, AAAA, CNAME-Einträge) durch, um festzustellen, ob die Subdomain derzeit aktiv ist. Gleichen Sie die Ergebnisse mit bekannten IP-Bereichen ab, um Schatten-IT oder unbefugte Dienste zu identifizieren.
• Typosquat-Erkennung: Generieren Sie Permutationen der überwachten Domain (Bitsquatting, Homograph, Einfügung, Auslassung, Transposition, Tastatur-angrenzende Ersetzung) und fragen Sie CT-Logs nach Zertifikaten ab, die für diese Variationen ausgestellt wurden. Zertifikate für Typosquat-Domains deuten stark auf Phishing-Infrastruktur hin.
• Deduplizierung und Anreicherung: Normalisieren Sie entdeckte Subdomains (Kleinschreibung, entfernen Sie nachgestellte Punkte), deduplizieren Sie sie und reichern Sie sie mit WHOIS-Daten, IP-Geolokalisierung und HTTP-Antwortheadern an, um die Untersuchung zu priorisieren.

Schritt 4: Alarmierung bei Zertifikatsausstellung

Konfigurieren Sie Alarmierungsregeln für sicherheitsrelevante Zertifikatsereignisse:

• Alarm bei unbefugter Zertifizierungsstelle: Wird ausgelöst, wenn ein Zertifikat von einer Zertifizierungsstelle ausgestellt wird, die nicht in der Liste der autorisierten Zertifizierungsstellen enthalten ist. Dies ist der Alarm mit der höchsten Priorität, da er auf Domain-Hijacking, BGP-Hijacking zur Domain-Validierung oder eine kompromittierte Zertifizierungsstelle hinweisen kann.
• Alarm bei neuer Subdomain: Wird ausgelöst, wenn ein Zertifikat eine SAN mit einer bisher nicht gesehenen Subdomain enthält. Dies erfasst Schatten-IT-Bereitstellungen und unbefugte Dienste.
• Alarm bei Wildcard-Zertifikat: Wird bei jeder Ausstellung eines neuen Wildcard-Zertifikats ausgelöst, da Wildcard-Zertifikate bei Kompromittierung eine größere Auswirkung haben und ihre Ausstellung streng kontrolliert werden sollte.
• Anomalie bei kurzlebigen Zertifikaten: Alarmieren, wenn Zertifikate ungewöhnlich kurze Gültigkeitszeiträume (weniger als 24 Stunden) aufweisen, die vom normalen Zertifikatslebenszyklus der Organisation abweichen, da dies auf Missbrauch von Let's Encrypt oder automatisierte Phishing-Infrastruktur hindeuten kann.
• Ablaufwarnung: Alarmieren, wenn Zertifikate für kritische Dienste sich dem Ablaufdatum nähern (30, 14, 7 Tage), basierend auf dem Feld not_after aus den CT-Log-Daten.
• Alarmzustellung: Senden Sie Alarme per E-Mail (SMTP), Slack-Webhook, PagerDuty oder schreiben Sie sie in ein SIEM-kompatibles JSON-Logformat zur Integration in die bestehende Sicherheitsüberwachung.

Schritt 5: Überprüfung der CT-Log-Integrität und Berichterstellung

Überprüfen Sie die Log-Integrität und erstellen Sie Compliance-Nachweise:

• Signed Tree Head (STH)-Überwachung: Rufen Sie den neuesten STH von jedem überwachten CT-Log über den API-Endpunkt get-sth ab. Der STH enthält die Baumgröße und einen signierten Zeitstempel. Überprüfen Sie die Signatur mit dem öffentlichen Schlüssel des Logs.
• Überprüfung des Konsistenznachweises: Fordern Sie zwischen aufeinanderfolgenden STH-Abrufen einen Konsistenznachweis über get-sth-consistency an, um zu überprüfen, ob das Log nur Anhänge zulässt und keine Einträge geändert oder entfernt wurden.
• Zertifikatsinventarbericht: Erstellen Sie ein vollständiges Inventar aller für die überwachten Domains ausgestellten Zertifikate, gruppiert nach Aussteller, mit Gültigkeitsstatus und Schlüsselstärke-Metriken.
• Analyse der Zertifizierungsstellen-Vielfalt: Berichten Sie, wie viele verschiedene Zertifizierungsstellen Zertifikate für die Organisation ausstellen, und identifizieren Sie Konsolidierungsmöglichkeiten und Single Points of Failure.
• Compliance-Nachweise: Für Organisationen, die PCI-DSS, SOC 2 oder ähnlichen Rahmenwerken unterliegen, liefern CT-Überwachungsprotokolle Nachweise für das Zertifikatslebenszyklusmanagement und die Fähigkeit zur Erkennung unbefugter Ausstellungen.

Schlüsselkonzepte

Begriff	Definition
Certificate Transparency (CT)	Ein offenes Framework (RFC 6962), das Zertifizierungsstellen dazu verpflichtet, alle ausgestellten Zertifikate in öffentlich überprüfbaren, nur anhängbaren Protokollen zu protokollieren, sodass Domain-Inhaber unbefugte Ausstellungen erkennen können
Signed Certificate Timestamp (SCT)	Ein Versprechen eines CT-Logs, dass ein Zertifikat innerhalb der maximalen Zusammenführungsverzögerung (in der Regel 24 Stunden) in den Merkle-Baum aufgenommen wird; Browser benötigen SCTs von mehreren Logs, bevor sie einem Zertifikat vertrauen
Merkle-Baum	Die kryptografische Datenstruktur, die von CT-Logs verwendet wird, bei der Blattknoten Zertifikats-Hashes sind und Elternknoten Hashes ihrer Kinder sind, was effiziente Konsistenz- und Inklusionsnachweise ermöglicht
Precertificate	Ein Zertifikat, das vor der endgültigen Ausstellung an CT-Logs übermittelt wird, das eine Poison-Extension (OID 1.3.6.1.4.1.11129.2.4.3) enthält, die seine Verwendung für TLS verhindert, aber seinen Platz im Log reserviert
crt.sh	Ein kostenloser Webdienst von Sectigo, der Zertifikate aus allen wichtigen CT-Logs in einer durchsuchbaren PostgreSQL-Datenbank zusammenfasst und sowohl Web- als auch API-Zugriff bietet
Subdomain-Übernahme	Eine Sicherheitslücke, bei der ein DNS-Eintrag einer Subdomain auf einen stillgelegten Dienst (Cloud-Anbieter, CDN) verweist, den ein Angreifer übernehmen kann, auffindbar durch abgelaufene CT-Zertifikate
Maximale Zusammenführungsverzögerung (MMD)	Die maximale Zeit (in der Regel 24 Stunden), die ein CT-Log hat, um ein eingereichtes Zertifikat nach der Rückgabe eines SCT in seinen Merkle-Baum aufzunehmen
CAA-Eintrag	DNS Certification Authority Authorization-Eintrag, der angibt, welche Zertifizierungsstellen berechtigt sind, Zertifikate für eine Domain auszustellen; CT-Überwachung erkennt Verstöße gegen die CAA-Richtlinie

Werkzeuge und Systeme

• crt.sh: Primärer CT-Log-Aggregator mit JSON-API-Zugriff unter https://crt.sh/?q=<abfrage>&output=json mit Unterstützung für Wildcard-Abfragen, Identitätsfilterung und Zertifikatsdetailabruf
• ct-woodpecker: Open-Source-CT-Log-Überwachungstool von Let's Encrypt, das sich in Prometheus und Grafana für die operative Überwachung der Log-Gesundheit und -Konsistenz integrieren lässt
• certspotter: CT-Log-Monitor von SSLMate, der neu ausgestellte Zertifikate überwacht und Benachrichtigungen sendet; als gehosteter Dienst oder selbst gehostetes Tool verfügbar
• Google Argon / Xenon / Icarus: Von Google betriebene CT-Logs, die zu den am weitesten verbreiteten gehören und über die RFC 6962-API unter ihren jeweiligen Log-URLs abfragbar sind
• OpenSSL: Befehlszeilentool zum Parsen von Zertifikatsdetails, Überprüfen von Ketten und Extrahieren von SAN-Listen aus Zertifikaten, die durch CT-Überwachung abgerufen wurden

Häufige Szenarien

Szenario: Erkennung unbefugter Zertifikatsausstellung für ein Finanzdienstleistungsunternehmen

Kontext: Eine Bank überwacht ihre Hauptdomain (bank.example.com) und entdeckt über CT-Logs, dass ein Zertifikat von einer Zertifizierungsstelle ausgestellt wurde, die sie noch nie verwendet hat, das secure-login.bank.example.com abdeckt – eine Subdomain, die in ihrem DNS nicht existiert.

Vorgehen:

1. Der CT-Überwachungsagent erkennt ein neues Zertifikat von "FreeSSL CA" für secure-login.bank.example.com in den crt.sh-Ergebnissen, das nicht in der Liste der autorisierten Zertifizierungsstellen (DigiCert, Sectigo) enthalten ist
2. Der Alarm wird als unbefugte Zertifizierungsstelle + neue Subdomain ausgelöst und innerhalb von 15 Minuten nach dem CT-Log-Eintrag an das Sicherheitsteam eskalieren
3. Untersuchen Sie das Zertifikat: Extrahieren Sie den öffentlichen Schlüssel, prüfen Sie, ob die Domain über HTTP-01- oder DNS-01-Challenge validiert wurde, fragen Sie WHOIS nach der ausstellenden Organisation ab
4. Ein DNS-Lookup für secure-login.bank.example.com zeigt, dass es zu einer IP-Adresse in einem Hosting-Anbieter aufgelöst wird, der von der Bank nicht genutzt wird – dies bestätigt die Angreifer-Infrastruktur
5. Leiten Sie die Reaktion auf den Vorfall ein: Fordern Sie die Zertifikatswiderrufung von FreeSSL CA an, melden Sie einen Domain-Missbrauch, fügen Sie die IP zu Sperrlisten hinzu und benachrichtigen Sie das Anti-Phishing-Team
6. Implementieren Sie CAA-DNS-Einträge (bank.example.com. CAA 0 issue "digicert.com"), um unbefugten Zertifizierungsstellen die Ausstellung zukünftiger Zertifikate zu verhindern

Fallstricke:

• Nichtüberwachung von Wildcard-Mustern (%.bank.example.com) und Übersehen von Zertifikaten für Subdomains
• Ignorieren von Precertificates, die in CT-Logs vor der tatsächlichen Zertifikatsausstellung erscheinen, wodurch der Frühwarnvorteil verloren geht
• Unterlassene Überprüfung, ob CAA-Einträge nach einem Vorfall auf allen Domains korrekt konfiguriert sind
• Übermäßige Alarmierung bei legitimen Zertifikatsverlängerungen, weil die Basisdatenbank nach autorisierten Änderungen nicht aktualisiert wurde

Szenario: Angriffsflächenkartierung durch Subdomain-Erkennung mittels CT-Logs

Kontext: Ein Penetrationstester verwendet CT-Logs als erste Phase der externen Erkundung, um die internetfähigen Dienste der Zielorganisation vor dem aktiven Scannen zu kartieren.

Vorgehen:

1. Fragen Sie crt.sh nach %.target.com und allen bekannten Tochtergesellschafts-Domains ab und sammeln Sie 2.400 eindeutige Zertifikate, die 8 Jahre abdecken
2. Extrahieren Sie 347 eindeutige Subdomains aus den SAN-Feldern aller Zertifikate, einschließlich abgelaufener
3. Lösen Sie alle 347 Subdomains per DNS auf und finden Sie 189 derzeit aktive mit A/AAAA-Einträgen
4. Identifizieren Sie 12 Subdomains, die auf stillgelegte Cloud-Dienste verweisen (CNAME zu S3-Buckets, Azure-Endpunkte), die Kandidaten für eine Subdomain-Übernahme sind
5. Entdecken Sie staging-api.target.com und dev-portal.target.com, die nicht im dokumentierten Umfang des Ziels liegen, aber erreichbar sind und ältere Softwareversionen ausführen
6. Präsentieren Sie die Ergebnisse der Zielorganisation und zeigen Sie die Lücke zwischen ihrem bekannten Asset-Inventar und der aus CT abgeleiteten Angriffsfläche

Fallstricke:

• Annahme, dass alle über CT entdeckten Subdomains zum Umfang gehören, ohne dies mit dem Asset-Eigentümer zu bestätigen
• Nichtprüfung auf Wildcard-DNS-Antworten, die den Anschein erwecken, dass Subdomains existieren, wenn sie tatsächlich auf einen Catch-All aufgelöst werden
• Ausschließliches Verlassen auf CT-Daten ohne Abgleich mit passiven DNS-Datenbanken für eine vollständige Abdeckung

Ausgabeformat

## CT-Log-Überwachungsbericht

**Domain**: example.com
**Überwachungszeitraum**: 2026-03-01 bis 2026-03-19
**Insgesamt verfolgte Zertifikate**: 142
**Neue erkannte Zertifikate**: 7
**Generierte Alarme**: 2

### Alarm: Ausstellung durch unbefugte Zertifizierungsstelle
- **Schweregrad**: Kritisch
- **Zertifikats-CN**: secure-login.example.com
- **SANs**: secure-login.example.com, …

[Gekürzt für Übersetzung]