Google: Sicherheitsvorfall
ccTLD-Hijacking ermöglichte unautorisierte HTTPS-Zertifikate für drei Domains.

Am 6. Oktober 2026 berichtete Googles Chrome Secure Web and Networking Team über eine Serie von DNS-Hijacking-Angriffen auf die ccTLD-Registries der Länderkennungen .gh (Ghana), .sl (Sierra Leone) und .as (Amerikanisch-Samoa). Die Angreifer manipulierten autoritäre DNS-Einträge auf Ebene der TLD-Registries selbst, ohne dabei Systeme von Google, betroffenen Organisationen oder den Zertifizierungsstellen (CAs) direkt zu kompromittieren.

Durch die Manipulation der autoritären DNS-Antworten konnten die Täter automatisierte Domain-Control-Validierungen (DCV) – etwa HTTP-01 oder DNS-01 – gegenüber öffentlichen CAs erfolgreich bestehen und so legitime, kryptografisch gültige HTTPS-Zertifikate für Google-Domains sowie Domains weiterer führender globaler Marken und weit verbreiteter Online-Dienste erschleichen. Die CAs handelten dabei regelkonform, da die manipulierten DNS-Antworten aus ihrer Sicht korrekte Validierungsnachweise lieferten.

Das Ausmaß des Vorfalls wurde zunächst über öffentliche Certificate-Transparency-Logs (CT-Logs) sichtbar. Analysen dieser Logs offenbarten, dass neben Google-Domains weitere Organisationen betroffen waren. Google blockierte die unautorisierten Zertifikate für eigene Domains umgehend über den Chrome-eigenen CRLSet-Mechanismus und arbeitete parallel mit den ausstellenden CAs zusammen, um eine vollständige Sperrung der Zertifikate zu erwirken – auch zum Schutz von Nutzern anderer Browser und Clients. Darüber hinaus wurden proaktiv auch Zertifikate weiterer betroffener Organisationen blockiert; diese wurden, soweit möglich, über den Vorfall informiert.

Google betonte, dass Chrome-Nutzer keinen Handlungsbedarf hatten. Domaininhaber mit Einträgen in .gh, .sl oder .as wurden aufgefordert, ihre CT-Log-Einträge auf unautorisierte Zertifikatausstellungen zu prüfen, restriktive CAA-Einträge mit ACME-Account-Bindings zu veröffentlichen sowie ein kontinuierliches Monitoring der Certificate-Transparency-Logs für ihr gesamtes Domain-Portfolio einzurichten.

Der Vorfall verdeutlicht, dass ein Angriff auf DNS-Infrastruktur auf Registry-Ebene klassische Perimeter-Sicherheitsmaßnahmen wie Firewalls, EDR-Systeme oder IAM vollständig unterlaufen kann, da der Vertrauensbruch außerhalb der Unternehmensnetzgrenze stattfindet. Browser-seitige Gegenmaßnahmen wie CRLSets bieten keinen vollständigen Schutz, insbesondere nicht für nicht-browserbasierte Clients, mobile Applikationen oder API-Gateways.