Was passiert
Google meldete am 6. Oktober 2026, dass Angreifer drei Länder-Domains gehackt haben: .gh (Ghana), .sl (Sierra Leone) und .as (Amerikanisch-Samoa). Über die kompromittierten DNS-Systeme dieser Country-Code Top-Level Domains (ccTLDs) gelang es den Angreifern, HTTPS-Zertifikate für mehrere Google-Domains auszustellen. Die genaue Anzahl der ausgestellten Zertifikate und alle betroffenen Domains nannte Google in der öffentlichen Mitteilung nicht.
Die Zertifikate wurden über Certificate-Authority-Mechanismen ausgestellt, die bei der Validierung auf kompromittierte DNS-Records vertrauten. Das ist ein klassisches Angriffsmuster: Wer den DNS kontrolliert, kann dem Certificate-Validation-System vorgaukeln, dass er berechtigt ist, ein Zertifikat für fast jeden Domain-Namen zu erhalten. Besonders kritisch ist die Tatsache, dass diese Zertifikate für Google-Domains gelten — eines der prominentesten Unternehmen der Welt.
Die direkten Systeme von Google selbst wurden nicht kompromittiert. Das Problem liegt nicht bei Google, sondern bei den Registry-Betreibern der drei betroffenen Länder-Domains. Diese sind verantwortlich für die DNS-Infrastruktur ihrer ccTLDs und für die Sicherheit der Nameserver. Ein Angreifer, der auf diese Systeme Zugriff erhält, kann beliebige DNS-Einträge ändern oder erstellen — und damit Zertifikats-Validierungen täuschen.
Google reagierte, indem es die betroffenen Zertifikate in seine Certificate-Transparenz-Logs aufnahm und die Zertifikats-Invalidierung veranlasste. Das bedeutet, dass moderne Browser und Systeme diese Zertifikate als ungültig behandeln. Allerdings dauerte diese Benachrichtigung Zeit — zwischen Ausstellung und öffentlicher Bekanntgabe lagen potenziell Tage oder Wochen, in denen die gefälschten Zertifikate in Umlauf waren.
Die betroffenen Registry-Betreiber für .gh, .sl und .as müssen nun untersuchen, wie Angreifer administrative Zugriff erhalten haben. Es geht hier um einen grundlegenden Sicherheitsbruch in der Infrastruktur, die das Internet zusammenhält.
Einordnung
Das Angriffsmuster ist nicht neu, aber sein Ausmaß ist bemerkenswert. DNS-basierte Zertifikats-Anschaffung wurde bereits bei anderen Registries angegriffen — etwa 2015 bei .tn (Tunesien) und mehrfach bei verschiedenen Registraren. Der zugrundeliegende Mechanismus ist simpel, aber wirksam: Certificate-Authorities (CAs) nutzen DNS-Abfragen, um zu prüfen, ob derjenige, der ein Zertifikat fordert, auch die Domain kontrolliert. Der Standard ACME (Automated Certificate Management Environment) setzt genau darauf — DNS-Challenge ist eine von mehreren Validierungsmethoden.
Das Problem ist, dass Registry-Operatoren weltweit unterschiedliche Sicherheitsstandards erfüllen. Während große, wohlfinanzierte Registries wie .de oder .com kontinuierlich in Sicherheit investieren, haben kleinere Registry-Betreiber oft begrenzte Ressourcen. Angreifer nutzen genau diese Unterschiede aus. Ein Hack bei einer kleinen Registry kann Sicherheitsauswirkungen haben, die weltweit wirken.
Google-Domains sind ein besonders hohes Ziel, weil sie hohes Vertrauen genießen. Ein gefälschtes Google-Zertifikat könnte für Phishing, Malware-Verbreitung oder Man-in-the-Middle-Attacken missbraucht werden. Angreifer könnten so täuschend echt aussehende Google-Seiten betreiben und Nutzer um Anmeldedaten, Zahlungsinformationen oder Verifikationscodes bringen.
Die Abhängigkeit von DNS für die Zertifikats-Validierung ist systemeigen und lässt sich nicht einfach ersetzen. Allerdings hat die Certificate-Transparency-Requirement der letzten Jahre dazu geführt, dass solche gefälschten Zertifikate schneller entdeckt werden als früher. Google und andere große Webservices nutzen HPKP (HTTP Public Key Pinning) oder ähnliche Techniken, um zusätzliche Validierungsebenen einzubauen. Für kleinere Anbieter ist dieser Schutz oft nicht praktikabel.
Was das bedeutet
Diese Vorfälle zeigen, dass die Sicherheit der globalen Zertifikatsinfrastruktur nur so stark ist wie ihr schwächstes Glied. Ein Hack bei einer kleinen, wenig bekannten Registry kann massive Auswirkungen auf vertrauenswürdige Brands haben. Das zentralisierte, DNS-basierte Validierungsmodell ist nun mehr als 20 Jahre alt und hat sich bewährt, aber es erzeugt genau diese Abhängigkeiten.
Für Organisationen bedeutet das konkret: Wer sich auf HTTPS und Zertifikate als Vertrauensanker verlässt, sollte zusätzliche Verifizierungsmechanismen einsetzen — etwa DNSSEC für die DNS-Sicherheit selbst, Certificate-Pinning für kritische Domains oder sogar Zero-Trust-Modelle, die nicht nur auf TLS vertrauen. Einzelne Nutzer sollten wissen, dass selbst grüne Schlösser und HTTPS nicht garantieren, dass sie auf der echten Seite sind, wenn Zertifikate kompromittiert sind — der Browser kann das nicht unterscheiden. Verdächtige Anfragen von angeblich vertrauenswürdigen Diensten sollten durch sekundäre Kanäle verifiziert werden, etwa über offizielle Telefonnummern oder verifizierte Social-Media-Accounts.
