Die Wiederherstellung nach Domain-Hijacking ist mit der Reparatur des DNS nicht abgeschlossen. Prüfen Sie Certificate Transparency auf unerwartete Zertifikate, beantragen Sie bei der ausstellenden Zertifizierungsstelle den Widerruf unberechtigter Zertifikate, stellen Sie eine restriktive Ausstellungsrichtlinie wieder her und benennen Sie einen Verantwortlichen für die weitere Überwachung. Eine funktionierende Website und eine Notfallsperre im Browser beantworten jeweils nur einen Teil der offenen Fragen.

Am 6. Oktober meldete Google Manipulationen am autoritativen DNS in den Namensräumen `.gh`, `.sl` und `.as`. Danach wurden unberechtigt Zertifikate für Google und andere Organisationen ausgestellt. Laut Google waren die eigenen Systeme nicht kompromittiert; der Bericht liefert auch keinen Grund, den ausstellenden Zertifizierungsstellen die Verantwortung zuzuschreiben. Chrome sperrte Zertifikate über CRLSets, während Google zugleich deren Widerruf mit den Ausstellern abstimmte. Dies ist Googles Darstellung des Vorfalls, keine vollständige öffentliche Rekonstruktion seiner Auswirkungen. [Googles Vorfallsbericht](https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks/).

## Was bleibt nach der DNS-Wiederherstellung offen?

Wiederhergestellte DNS-Kontrolle macht ein bestehendes Zertifikat nicht ungültig. Certification Authority Authorization, kurz CAA, regelt, welche Stellen Zertifikate ausstellen dürfen. CAA regelt nicht, wie ein Client ein bereits ausgestelltes Zertifikat validiert. Eine Änderung dieser Richtlinie kann die Ausstellung nicht rückwirkend aufheben. [RFC 8659](https://www.rfc-editor.org/info/rfc8659/).

Ihre Website kann zum richtigen Server aufgelöst werden und ihr übliches Zertifikat ausliefern, während ein während der unberechtigten Kontrolle ausgestelltes Zertifikat weiterhin nicht widerrufen ist. Prüfen Sie Domain-Kontrolle und Zertifikatsstatus getrennt.

Beginnen Sie Ihre Wiederherstellungsdokumentation mit diesen Fragen:

| Frage zur Wiederherstellung | Aufzubewahrende Nachweise | Was damit offenbleibt |
| --- | --- | --- |
| Wer kontrolliert die Domain jetzt? | Antwort des Anbieters, erwartete Delegation und DNS-Beobachtungen | Ob unberechtigte Zertifikate weiter nutzbar sind |
| Welche Zertifikate sind ungeklärt? | CT-Einträge, abgeglichen mit Bereitstellungs- und Erneuerungsunterlagen | Ob diese Zertifikate bei Angriffen auf den Datenverkehr eingesetzt wurden |
| Was hat der Aussteller unternommen? | Widerrufsantrag, Antwort und Nachweise zum Zertifikatsstatus | Wie jeder einzelne Client diesen Status durchsetzt |
| Was haben Sie am Dienst geprüft? | Benannte Prüfungen, Zeitpunkt, Prüfstandort und Ergebnis | Aktivitäten außerhalb des geprüften Umfangs |
| Wer erledigt die restlichen Aufgaben? | Benannter Verantwortlicher und verlinkte Folgeaufgabe | Das Ergebnis noch ausstehender Arbeiten |

Dieselbe Unterscheidung gilt für [Meldungen zu offengelegten Zugangsdaten](/blog/leaked-credential-report-closure-checklist): Künftigen Zugriff zu verhindern und vergangene Aktivitäten zu verstehen sind zwei getrennte Entscheidungen.

## Gewinnen Sie die Kontrolle zurück und grenzen Sie den Untersuchungszeitraum ein

Arbeiten Sie mit den zuständigen Registraren, Registrys und DNS-Anbietern zusammen, um die Kontrolle zurückzugewinnen. Sichern Sie verfügbare Änderungsprotokolle und bestimmen Sie den zu untersuchenden Zeitraum, bevor routinemäßige Bereinigungen die Rekonstruktion erschweren.

Halten Sie fest, welche Ebene Ihrer Einschätzung nach betroffen war und welcher Anbieter die Wiederherstellung bestätigt hat. Ein kompromittiertes Registrar-Konto, veränderte autoritative Einträge und ein Vorfall auf Registry-Ebene können unterschiedliche Organisationen betreffen. Googles Bericht behandelt Manipulationen am autoritativen DNS in drei Namensräumen. [Googles Darstellung](https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks/).

Dokumentieren Sie für jede betroffene Domain die erwartete Delegation, den DNS-Anbieter und die davon abhängigen Dienste. Berücksichtigen Sie regionale Domains, Weiterleitungen und geparkte Domains. Auch eine Domain ohne aktive Website kann für Ihre Zertifikatsuntersuchung relevant sein. Google empfiehlt ausdrücklich, sämtliche eigenen Domains zu überwachen, einschließlich geparkter und regionaler Domains, und weist darauf hin, dass die Untersuchung betroffene Domains übersehen könnte. [Googles Hinweise für Domain-Inhaber](https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks/).

Begründen Sie den Untersuchungszeitraum. Wenn Sie den frühesten bestätigten unberechtigten Eingriff und einen vom Anbieter bestätigten Wiederherstellungszeitpunkt kennen, sichern Sie beide Angaben. Sind die Aufzeichnungen unvollständig, benennen Sie die unsichere Grenze. Ein bequem gewählter Zeitraum rund um die erste Warnung ist ein Ausgangspunkt, kein Beleg dafür, dass zuvor nichts geschehen ist.

## Finden Sie unerwartete Zertifikate in Certificate Transparency

Certificate Transparency, kurz CT, macht Zertifikate und Vorzertifikate in öffentlichen Protokollen sichtbar, denen nur neue Einträge hinzugefügt werden können. Überwachungsdienste prüfen diese Protokolle und können Abonnenten über gefundene Einträge informieren. CT liefert Nachweise zur Ausstellung, die Sie untersuchen können. Ein Protokolleintrag beweist weder das Abfangen von Datenverkehr noch Datendiebstahl. [So funktioniert CT](https://certificate.transparency.dev/howctworks/).

Suchen Sie die betroffene Domain in [crt.sh](https://crt.sh/), einer CT-Suche, auf die [Let's Encrypts Widerrufsanleitung](https://letsencrypt.org/docs/revoking/) verweist. Öffnen Sie relevante Ergebnisse und gleichen Sie die abgedeckten Namen, den Aussteller, die Gültigkeitsdaten und die Zeitstempel im Protokoll mit Ihrem Untersuchungszeitraum ab. Berücksichtigen Sie Zertifikats- und Protokollierungsdetails gemeinsam, statt den Beginn der Gültigkeit als genauen Ausstellungszeitpunkt zu behandeln.

Vergleichen Sie diese Ergebnisse mit Bereitstellungs- und Erneuerungsunterlagen. Fragen Sie den Dienstverantwortlichen, ob das jeweilige Zertifikat zu einer regulären Erneuerung, einem CDN oder einer anderen autorisierten Bereitstellung gehört. Laden Sie ungeklärte Zertifikate nach Möglichkeit herunter, damit der Aussteller dasselbe Artefakt untersuchen kann.

Sichern Sie für jedes ungeklärte Ergebnis einen kompakten Nachweis:

- Die vom Zertifikat abgedeckten Domainnamen, einschließlich der alternativen Namen im Feld Subject Alternative Name.
- Aussteller, Seriennummer und Zertifikatsfingerabdruck.
- Gültigkeitsdaten und die zugehörige Protokollreferenz.
- Ob der beobachtete Eintrag ein Zertifikat oder ein Vorzertifikat ist.
- Die Bereitstellungs- oder Erneuerungsunterlagen, mit denen Sie ihn abgeglichen haben.
- Die prüfende Person und ihre Schlussfolgerung.

**Unterscheiden Sie Vorzertifikate von Zertifikaten.** Ein Vorzertifikat dient dem CT-Protokollierungsverfahren und ist selbst kein nutzbares Serverzertifikat. Ein als Vorzertifikat gekennzeichnetes Ergebnis muss auch in Ihrer Eskalation und Meldung so bezeichnet bleiben. Machen Sie daraus keine Aussage, Sie hätten ein ausgeliefertes Zertifikat beobachtet. [CTs Erläuterung zu Vorzertifikaten](https://certificate.transparency.dev/howctworks/).

Die CT-Überwachung hat zeitliche Grenzen und erfasst nicht zwangsläufig alles. Im Protokollierungsverfahren gibt es eine maximale Verzögerung bis zur Aufnahme eines Eintrags; Ihr Überwachungsdienst sieht nur die Protokolle, die er prüft. Versprechen Sie keine sofortige Erkennung und behandeln Sie ausbleibende Warnungen nicht als vollständige Untersuchung. Das CT-Projekt veröffentlicht ein [Verzeichnis von Überwachungsdiensten](https://certificate.transparency.dev/monitors/). Ein Eintrag darin garantiert aber weder Vollständigkeit noch die Eignung für Ihre Anforderungen.

## Beantragen Sie den Widerruf bei der ausstellenden Zertifizierungsstelle

Melden Sie unberechtigte Ausstellungen der Zertifizierungsstelle, die das Zertifikat ausgestellt hat, und folgen Sie deren dokumentiertem Widerrufsverfahren. Die DNS-Wiederherstellung, ein Ersatzzertifikat und eine Notfallsperre im Browser sind getrennte Ereignisse. Keines davon ersetzt die Antwort des Ausstellers.

Senden Sie die gesammelten Kennungen und Nachweise, erläutern Sie die fehlende Berechtigung zur Ausstellung und bewahren Sie den Antrag sowie spätere Antworten auf. Enthält ein Zertifikat mehrere Namen, weisen Sie früh darauf hin. Möglicherweise benötigen Sie Unterstützung vom Aussteller. Gehen Sie nicht davon aus, dass die Kontrolle über eine einzelne Domain für das gewählte Verfahren genügt.

Let's Encrypt dokumentiert ein hilfreiches Beispiel: Nach Wiedererlangung der Domain-Kontrolle kann ein Inhaber über ein anderes autorisiertes Konto den Widerruf beantragen, indem er die Kontrolle über alle Kennungen im Zertifikat nachweist. Der Besitz des privaten Schlüssels des Angreifers ist also nicht die einzige Möglichkeit, die Berechtigung nachzuweisen. Dies ist das Verfahren von Let's Encrypt. Für Ihren Fall gelten die Anweisungen des tatsächlichen Ausstellers. [Let's Encrypts Dokumentation zum Widerruf](https://letsencrypt.org/docs/revoking/).

Verfolgen Sie jeden Antrag bis zu einem dokumentierten Ergebnis. „E-Mail an die CA gesendet“ beschreibt eine noch offene Aufgabe. Eine Antwort des Ausstellers und Nachweise zum Zertifikatsstatus erlauben eine belastbarere Aussage. Halten Sie fest, welches Zertifikat das Ergebnis betrifft. Eine Antwort zu einer Seriennummer darf nicht versehentlich mehrere ungeklärte Einträge erledigen.

### Was belegt eine Chrome-Sperre?

Chromes CRLSets ermöglichen Notfallsperren für Zertifikate und enthalten einen Teil der Widerrufe aus Listen der Zertifizierungsstellen. Sie sind keine vollständige Kopie aller Zertifikatswiderrufe. Google setzte Chrome-Sperren und die Abstimmung mit Zertifizierungsstellen als getrennte Maßnahmen ein. [Chromiums CRLSet-Dokumentation](https://www.chromium.org/Home/chromium-security/crlsets/), [Googles Reaktion auf den Vorfall](https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks/).

Google warnt, dass seine Eingriffe Nutzer anderer Browser nicht zuverlässig schützen. Wenn Sie das Verhalten von Browsern oder API-Clients prüfen, dokumentieren Sie die untersuchten Clients, Versionen oder Umgebungen, den Zeitpunkt und das beobachtete Ergebnis. Halten Sie diesen Prüfungsumfang von der Widerrufsantwort des Ausstellers getrennt.

## Stellen Sie CAA wieder her, ohne legitime Erneuerungen zu verhindern

CAA regelt die Zertifikatsausstellung. Prüfen Sie diese Regeln nach der DNS-Wiederherstellung. Sie kann unberechtigte Ausstellungen nicht verhindern, solange ein Angreifer die DNS-Richtlinie selbst kontrolliert, und sie kann bestehende Zertifikate nicht widerrufen. Google empfiehlt, restriktive CAA-Regeln mit unterstützten Bindungen an Konten und Validierungsmethoden wiederherzustellen. So lässt sich eine spätere Ausstellung auf Basis zwischengespeicherter Validierungsdaten begrenzen. [Googles Empfehlungen](https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks/).

Zwischengespeicherte Validierungsdaten sind relevant, weil mit dem Ende der unberechtigten DNS-Kontrolle nicht zwangsläufig jede währenddessen entstandene Ausstellungsmöglichkeit endet. Behandeln Sie die Prüfung als anbieterspezifische Konfigurationsaufgabe. Nehmen Sie nicht an, dass ein allgemeiner CAA-Eintrag diese Lücke schließt. Prüfen Sie, wie Ihr Aussteller die betreffenden Einschränkungen unterstützt.

RFC 8657 definiert zwei Parameter: `accounturi` bindet die Berechtigung an einen Konto-URI; `validationmethods` begrenzt die durch diesen Eintrag erlaubten Validierungsmethoden. Ihre Wirkung hängt von der ausdrücklichen Unterstützung durch die benannte Zertifizierungsstelle ab. Eine unbelegte Annahme zu einem der Parameter kann dazu führen, dass Ihre beabsichtigte Einschränkung nicht durchgesetzt wird. [RFC 8657](https://www.rfc-editor.org/info/rfc8657/).

Identifizieren Sie vor Änderungen an Produktionseinträgen Ihre legitimen Aussteller und die für die Produktion verwendeten Ausstellungskonten. Bestätigen Sie den genauen Konto-URI beim Aussteller oder im System zur Zertifikatsverwaltung. Die E-Mail-Adresse einer Person zur Anmeldung ersetzt diese Kontokennung nicht. Berücksichtigen Sie den Erneuerungsprozess ebenso wie die letzte manuelle Ausstellung, denn dafür können unterschiedliche Systeme zuständig sein.

Prüfen Sie die Richtlinie als Ganzes:

1. Bestätigen Sie, dass jeder benannte Aussteller die vorgesehenen Bindungen unterstützt.
2. Prüfen Sie den Konto-URI für die Produktion und die erlaubten Validierungsmethoden.
3. Prüfen Sie gegebenenfalls die Berechtigung für Wildcard-Zertifikate gesondert.
4. Untersuchen Sie Aliase, delegierte Namen und die Richtlinie für Subdomains.
5. Prüfen Sie jeden Berechtigungseintrag auf unbeabsichtigte alternative Freigaben.
6. Stellen Sie sicher, dass legitime Ausstellung und Erneuerung mit den vorgesehenen Einschränkungen weiter funktionieren.

Let's Encrypt dokumentiert die Unterstützung von Einschränkungen auf die Methoden `http-01`, `dns-01` und `tls-alpn-01` sowie von Bindungen an ACME-Konten. Die Stelle prüft CAA vor jeder Ausstellung und erklärt, dass sich die Berechtigungen mehrerer Einträge addieren. Die Dokumentation beschreibt außerdem abweichende Regeln für Subdomains und die CNAME-Auflösung. Nutzen Sie diese Angaben, wenn Let's Encrypt Ihr Aussteller ist. Gehen Sie nicht davon aus, dass alle Stellen identisch arbeiten. [Let's Encrypts CAA-Dokumentation](https://letsencrypt.org/docs/caa/).

Prüfen Sie diese additive Wirkung bewusst. Ein stark eingeschränkter Eintrag kann neben einer anderen Berechtigung stehen, die genau die eigentlich verbotene Ausstellung erlaubt. Nur den neuen Eintrag zu lesen genügt nicht. Prüfen Sie die wirksame Richtlinie für die vom Zertifikat abgedeckten Namen, einschließlich relevanter Delegationen und Aliase.

Dokumentieren Sie die betriebliche Prüfung zusammen mit der Konfigurationsänderung. Halten Sie fest, welches Zertifikat erfolgreich ausgestellt wurde, über welches Konto und welche Methode und welchen Erneuerungsprozess Sie geprüft haben. Prüfen Sie den Erneuerungsprozess, bevor Sie die Änderung freigeben, damit die Richtlinie Ihr nächstes legitimes Zertifikat nicht verhindert.

## Benennen Sie Verantwortliche für die Zertifikatsüberwachung aller Domains

Führen Sie die Überwachung nach der unmittelbaren Wiederherstellung fort. Benennen Sie einen Verantwortlichen, der Warnungen abgleichen und die ausstellende Stelle erreichen kann. Google empfiehlt die Überwachung sämtlicher eigener Domains, weil eine zentrale Reaktion betroffene Namen übersehen kann. [Googles Empfehlung zur Überwachung](https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks/).

Bestimmen Sie den Überwachungsumfang anhand Ihres Domain-Verzeichnisses statt anhand aktiver Websites. Berücksichtigen Sie regionale Marken, Weiterleitungen, geparkte Domains und an andere Teams delegierte Namen. Halten Sie für jede Domain den vorgesehenen Betreiber und den legitimen Ausstellungsprozess fest. So kann auch jemand eine neue Warnung bearbeiten, wenn die ursprünglich zuständige Person nicht verfügbar ist.

Legen Sie fest, wo Warnungen eingehen und was geschieht, wenn niemand reagiert. Für ein kleines Team können ein klar benannter Hauptverantwortlicher und eine Vertretung hilfreicher sein als ein ungelesenes gemeinsames Postfach. Der Ablauf sollte ermöglichen, den Eintrag zu sichern, den Dienstverantwortlichen zu kontaktieren und ungeklärte Ausstellungen zu eskalieren, ohne das Verfahren erst während eines Vorfalls zu erfinden.

Die Überwachung berechtigt nicht zu aktiven Tests gegen jedes Ziel, das mit einer Domain verbunden ist. Wenn Sie im Zuge der Untersuchung einen Dienst aktiv prüfen, klären Sie dessen Betreiber und Ihre Berechtigung. Unser [Leitfaden zum Umfang von Sicherheitsscans](/blog/security-scanning-asset-scope-authorization) erläutert, warum eine DNS-Verbindung allein keine Erlaubnis begründet.

## Bewahren Sie Wiederherstellungsnachweise bei der Meldung auf

Schließen Sie die Meldung anhand konkreter Ergebnisse ab: wiederhergestellte Kontrolle, geprüfte Zertifikatsnachweise, dokumentierte Ausstellerantworten, geprüfte Ausstellungsrichtlinie und zugewiesene Restaufgaben. Benennen Sie neben den Ergebnissen auch die Grenzen, damit eine andere Person die Entscheidung beurteilen kann, ohne die Untersuchung zu wiederholen.

Ein hilfreicher Abschlussvermerk könnte lauten: „Der Anbieter hat die wiederhergestellte Kontrolle über diese Domains bestätigt. Wir haben diese CT-Ergebnisse mit Bereitstellungsunterlagen abgeglichen und zwei ungeklärte Einträge an ihre Aussteller eskaliert. Deren Antworten sind hier verlinkt. Wir haben die angegebene CAA-Richtlinie und den Erneuerungsprozess geprüft. Unsere Client-Prüfungen umfassten diese Umgebungen; die separate Untersuchung der Aktivitäten bleibt diesem Verantwortlichen zugewiesen.“

Ersetzen Sie jeden Platzhalter durch Ihre tatsächlichen Nachweise, einschließlich ausstehender Ausstellerantworten und Lücken im Untersuchungszeitraum.

In Kit kann eine Sicherheitsmeldung einen benannten Verantwortlichen, belegende Anhänge, interne Notizen und verlinkte Anbieter- oder Behebungstickets enthalten. Ihr Verlauf führt Statusänderungen, Zuweisungen und Korrespondenz zusammen. In einem Postmortem können Sie die Ursache, Korrekturmaßnahmen und weitere Erkenntnisse festhalten. Verknüpfen Sie die technischen Wiederherstellungsarbeiten und ihre Ergebnisse mit dieser Meldung.

Damit hat Ihr Team einen Ort, an dem es die Übergabe und die Abschlussentscheidung prüfen kann. Sehen Sie sich [Kits Ablauf zur Bearbeitung von Sicherheitsmeldungen](/security) an und vergleichen Sie ihn mit Ihrem aktuellen Verfahren: Kann die nächste zuständige Person den Verantwortlichen erkennen, die Zertifikatsnachweise finden und sehen, welche Aussagen zur Wiederherstellung noch geprüft werden müssen?