Das Wichtigste in Kürze
Wer das DNS Ihrer Domain kontrolliert, bekommt ein echtes, browservertrauenswürdiges Zertifikat dafür. Am 6. Oktober 2026 meldete das Chrome-Sicherheitsteam von Google, dass Angreifer die Länder-Registries von Ghana (.gh), Sierra Leone (.sl) und Amerikanisch-Samoa (.as) gekapert, autoritative DNS-Einträge geändert und gültige HTTPS-Zertifikate für mehrere Google-Domains sowie für weitere Organisationen erhalten hatten.
Laut Google wurden die eigenen Systeme nicht kompromittiert, und die Zertifizierungsstellen haben sich offenbar regelkonform verhalten. Chrome blockiert die Zertifikate. Die Lehre für alle anderen liegt in dem Teil des Stacks, den kaum ein Team ansieht: Registries, Registrare und die DNS- und Zertifikatsautomatisierung hinter Ihrer Cloud-Umgebung.
Wie kamen Angreifer an echte Zertifikate für Google-Domains?
Bevor eine Zertifizierungsstelle ein HTTPS-Zertifikat ausstellt, prüft sie, ob der Antragsteller die Domain kontrolliert. Ein gängiges Verfahren verlangt, einen DNS-Eintrag mit einem Zufallswert zu veröffentlichen. Wer das autoritative DNS der Domain bearbeiten kann, besteht diese Prüfung. Genau das ist der Sinn der Domain-Validierung – und zugleich ihre Schwachstelle.
In diesem Fall griffen die Angreifer nicht Google an. Sie setzten eine Ebene höher an, bei den Systemen, die drei Länder-Top-Level-Domains betreiben. Mit dieser Kontrolle schrieben sie das autoritative DNS für Domains unter .gh, .sl und .as um, darunter Googles lokale Domains für diese Länder, und beantragten dann Zertifikate, denen jeder Browser vertraut. The Register und BleepingComputer weisen darauf hin, dass Google weder die ausstellenden CAs noch die weiteren betroffenen Unternehmen genannt hat.
Wie haben Google und Chrome reagiert?
Google nahm die gefälschten Zertifikate für eigene Dienste in die CRLSets auf – den Mechanismus, mit dem Chrome Zertifikate im Notfall schnell sperrt – und ließ sie von den ausstellenden CAs widerrufen, damit auch andere Browser und Clients geschützt sind. Anschließend durchsuchte Google die öffentlichen Certificate-Transparency-Logs, fand Zertifikate weiterer Organisationen, die zur selben Kampagne zu gehören scheinen, sperrte auch diese in Chrome und informierte Betroffene, soweit möglich. Chrome-Nutzer müssen laut Google nichts tun.
Der wichtige Vorbehalt stammt von Google selbst: Weil DNS-Hijacks komplex sind, kann das Unternehmen nicht zusichern, jede betroffene Domain gefunden zu haben. Inhaber von Domains unter den drei Endungen und alle, deren Marke eine Länderdomain bei einer kleinen Registry hält, sollten ihre Zertifikatshistorie selbst prüfen, statt auf eine Benachrichtigung zu warten.
Was das für Software-Teams in den USA und der EU bedeutet
Erstens: Ihr TLS-Vertrauen ist nur so stark wie die schwächste Registry, von der Sie abhängen. Viele Unternehmen registrieren Länderdomains für Marketing, Markenschutz oder lokale Shops und vergessen sie danach. Diese Domains liegen oft bei kleinen Registries und Resellern, deren Sicherheit nie bewertet wurde. Ein Hijack dort kann ein gültiges Zertifikat für eine Domain erzeugen, die Ihre Kunden kennen.
Zweitens: CAA-Einträge sind keine optionale Hygiene mehr. Ein Certification-Authority-Authorization-Eintrag legt fest, welche CAs für Ihre Domain ausstellen dürfen. Google empfiehlt ausdrücklich strikte CAA-Einträge, die die Ausstellung zusätzlich auf Ihre eigenen ACME-Konten und Validierungsmethoden beschränken. Wer Ihr DNS vollständig kontrolliert, kann den Eintrag zwar umschreiben – für alle anderen werden die Wege aber enger, und eine Ausstellung über eine unerwartete CA oder ein fremdes Konto scheitert standardmäßig.
Drittens: Certificate-Transparency-Monitoring macht aus einem stillen Angriff einen Alarm. Jedes öffentlich vertrauenswürdige Zertifikat wird protokolliert. Über diese Logs hat Google die weiteren Opfer gefunden, und es ist der schnellste Weg, ein unerwartetes Zertifikat zu sehen, bevor es gegen Ihre Nutzer eingesetzt wird. Für EU-Unternehmen unter NIS2 oder DORA und für US-Firmen mit SOC-2-Pflichten oder Sicherheitsfragebögen von Kunden ist „Wir überwachen CT für unsere Domains“ eine leicht nachweisbare Kontrolle.
Was bedeutet das für Unternehmen im DACH-Raum?
Die eigenen Kerndomains unter .de, .at und .ch liegen bei großen, etablierten Registries – das eigentliche Risiko für DACH-Unternehmen steckt in den Rändern des Portfolios. Mittelständler mit Exportgeschäft halten oft Dutzende Länderdomains für Vertriebsgesellschaften, Messen oder Markenschutz, nicht selten über Agenturen oder lokale Partner registriert. Genau diese Domains kennt die IT häufig nicht, und genau dort liegen die kleinen Registries, die jetzt angegriffen wurden. Ein Zertifikat für die Länderdomain einer bekannten deutschen Marke reicht für glaubwürdiges Phishing gegen Kunden und Händler in diesem Markt.
Regulatorisch passt das Thema direkt in die NIS2-Pflichten: Die Richtlinie verlangt Risikomanagement für die Lieferkette, und DNS-Dienste sowie Registrare zählen ausdrücklich dazu. Für Finanzunternehmen unter DORA gilt Ähnliches für IKT-Drittdienstleister. Praktisch heißt das: das Domain-Portfolio inklusive Registrar und Registry ins Asset- und Dienstleisterregister aufnehmen, DNSSEC und CAA als technische Maßnahme dokumentieren und CT-Monitoring als laufende Kontrolle nachweisen. Wer in Deutschland, Österreich und der Schweiz Kunden mit hohem Sicherheitsanspruch bedient, sollte diese Nachweise ohnehin im nächsten Audit vorlegen können.
Was sollten Teams diese Woche prüfen?
- Jede eigene Domain inventarisieren. Auch Länderdomains, Kampagnendomains und alles, was Agenturen in Ihrem Namen registriert haben. Registry und Registrar je Domain notieren.
- Certificate-Transparency-Logs durchsuchen. Nach Zertifikaten suchen, die seit Mitte September 2026 ausgestellt wurden und die Sie nicht beantragt haben, und danach laufende CT-Alarme für das gesamte Portfolio einrichten.
- Strikte CAA-Einträge veröffentlichen. Nur die CAs zulassen, die Sie tatsächlich nutzen, und – wo die CA es unterstützt – die Ausstellung an Ihr ACME-Konto und die bevorzugte Validierungsmethode binden.
- Schutzfunktionen bei Registrar und Registry aktivieren. Registry Lock nutzen, wo verfügbar, DNSSEC einschalten, MFA für Registrar-Konten erzwingen und Zugriffsrechte prüfen.
- Verwaiste Domains stilllegen oder bündeln. Eine Domain, die niemand beobachtet, bemerkt auch niemand, wenn sie gekapert wird. Über einen gut verwalteten Registrar weiterleiten oder bewusst aufgeben.
Häufige Fragen
Was ist mit den Domains unter .gh, .sl und .as passiert?
Angreifer kompromittierten die Systeme, mit denen die Länder-Registries von Ghana (.gh), Sierra Leone (.sl) und Amerikanisch-Samoa (.as) betrieben werden, schrieben autoritative DNS-Einträge für Domains unter diesen Endungen um und nutzten diese Kontrolle, um gültige HTTPS-Zertifikate zu erhalten. Google legte die Vorfälle am 6. Oktober 2026 offen.
Wurden Googles eigene Systeme kompromittiert?
Nein. Laut Google wurden die eigenen Systeme nicht kompromittiert. Die Angreifer kontrollierten auf Registry-Ebene das DNS für Googles Länderdomains wie google.com.gh – das genügte, um die Domain-Validierung der Zertifizierungsstellen zu bestehen.
Haben die Zertifizierungsstellen Fehler gemacht?
Google hat nach eigenen Angaben keinen Grund zur Annahme, dass die ausstellenden CAs unsachgemäß gehandelt haben. Die Domain-Validierung belegt, wer das DNS einer Domain in diesem Moment kontrolliert, nicht wem sie rechtlich gehört. Ein Hijack auf Registry-Ebene hebelt sie daher konstruktionsbedingt aus.
Müssen Chrome-Nutzer etwas tun?
Nein. Google hat die identifizierten Zertifikate in Chrome über CRLSets blockiert und sie von den ausstellenden CAs widerrufen lassen, was auch Nutzer anderer Browser und Clients schützt. Zertifikate weiterer betroffener Organisationen, die Google über Certificate-Transparency-Logs fand, wurden ebenfalls blockiert.
Was sollte unser Unternehmen jetzt tun?
Strikte CAA-Einträge veröffentlichen, die nur Ihre tatsächlich genutzten CAs nennen und die Ausstellung wo möglich an Ihr eigenes ACME-Konto und Ihre Validierungsmethoden binden. Certificate-Transparency-Logs für jede eigene Domain überwachen, auch für Länderdomains. Sicherheitsfunktionen bei Registrar und Registry wie Registry Lock und DNSSEC prüfen und dokumentieren.
Quellen
Google — Chrome’s response to recent ccTLD registry hijacks
BleepingComputer — Hackers hijack Google domains after breaching ccTLD registries
The Register — Attackers hijacked top-level domains, minted fake security certs for Google and other orgs
SecurityWeek — Google domains impacted by recent ccTLD hijacks