Ein ungewöhnlicher Angriff hat Google und weitere Unternehmen getroffen, ohne dass deren eigene Server gehackt wurden. Angreifer haben die Registrierungsstellen von drei Länderendungen übernommen: .gh für Ghana, .sl für Sierra Leone und .as für Amerikanisch-Samoa. Über manipulierte DNS-Einträge konnten sie bei Zertifizierungsstellen echte, von Browsern akzeptierte HTTPS-Zertifikate für mehrere Google-Domains beantragen. Google hat den Vorfall am 6. Oktober 2026 im eigenen Blog öffentlich gemacht. Chrome-Nutzer sind nach Angaben des Konzerns bereits geschützt.
Was ist passiert?
Eine Länderendung (ccTLD) wird von einer Registrierungsstelle verwaltet. Sie legt fest, welche Nameserver für eine Domain zuständig sind. Genau dort setzten die Angreifer an. Laut Google bemerkte das Chrome-Team die Übernahmen in der Woche vor der Veröffentlichung. Betroffen war damit potenziell jede Domain, die auf .gh, .sl oder .as endet.
Die Angreifer änderten die maßgeblichen DNS-Einträge so, dass die Domains auf ihre eigene Infrastruktur zeigten. Zertifizierungsstellen prüfen vor der Ausstellung automatisch, ob der Antragsteller eine Domain kontrolliert, etwa über einen DNS-Eintrag. Wer das DNS beherrscht, besteht diese Prüfung. BleepingComputer berichtet, dass dabei TXT-Einträge zur Bestätigung genutzt wurden.
Google betont zwei Punkte: Die eigenen Systeme seien nicht kompromittiert worden. Und die Zertifizierungsstellen, die die Zertifikate ausgestellt haben, hätten nach aktuellem Stand nichts falsch gemacht. Aus ihrer Sicht sah die Prüfung schlicht korrekt aus.
Welche Domains sind betroffen?
Das ist nur teilweise bekannt. Google spricht von „mehreren Google-Domains“, nennt aber keine Namen. Auch welche Zertifizierungsstellen beteiligt waren und wie viele Zertifikate ausgestellt wurden, hat Google nicht veröffentlicht. Über die Auswertung der öffentlichen Certificate-Transparency-Logs (CT) stieß Google auf weitere Opfer, darunter laut Blogbeitrag mehrere große internationale Marken und verbreitete Onlinedienste. Auch sie werden nicht namentlich genannt. Wer hinter dem Angriff steckt, ist ebenfalls offen.
| Punkt | Stand (8. Oktober 2026) |
|---|---|
| Betroffene Länderendungen | .gh (Ghana), .sl (Sierra Leone), .as (Amerikanisch-Samoa) |
| Methode | Übernahme der Registry, Änderung autoritativer DNS-Einträge |
| Ziel | Gültige HTTPS-Zertifikate für fremde Domains |
| Google-Systeme kompromittiert? | Nein, laut Google |
| Betroffene Google-Domains | Nicht veröffentlicht |
| Ausstellende Zertifizierungsstellen | Nicht veröffentlicht |
| Täter | Unbekannt |
Wie hat Chrome reagiert?
Google hat drei Schritte beschrieben:
- Sperre über CRLSets: Chrome bezieht über diesen Mechanismus laufend eine Liste gesperrter Zertifikate. Die unberechtigten Zertifikate für Google-Domains landeten sofort darauf.
- Widerruf: Zusammen mit den ausstellenden Stellen sorgte Google dafür, dass die Zertifikate auch offiziell zurückgezogen werden. Das soll Nutzer anderer Programme schützen.
- Suche nach weiteren Opfern: Anhand der CT-Logs blockierte Chrome vorsorglich auch Zertifikate anderer betroffener Websites und informierte die Betreiber, soweit möglich.
Was bedeutet das für Sie?
Wenn Sie Chrome nutzen, müssen Sie nichts tun; die Sperren kommen automatisch. Google räumt aber offen ein, dass die Analyse nicht zwingend jede betroffene Domain gefunden hat und dass Chrome-Eingriffe Nutzer anderer Browser nicht zuverlässig schützen. Halten Sie daher auch Firefox, Safari oder Edge aktuell. Wie wichtig der Widerruf von Zertifikaten im Alltag ist, zeigte zuletzt auch der Fall der gesperrten AusweisApp-Domain.
Ein gültiges Zertifikat allein ist übrigens kein Beweis für eine seriöse Seite. Ein Schloss-Symbol bestätigt nur die verschlüsselte Verbindung zu der Domain, die Sie aufgerufen haben. Gegen nachgemachte Login-Seiten helfen Passkeys, weil sie nur auf der echten Domain funktionieren.
Was Domaininhaber jetzt tun sollten
Für Unternehmen und Administratoren hat Google konkrete Empfehlungen:
- CT-Logs dauerhaft überwachen: Jedes in Chrome vertrauenswürdige Zertifikat muss in öffentlichen Logs auftauchen. Ein Monitoring, etwa über crt.sh oder kommerzielle Dienste, meldet neue Zertifikate für Ihre Domains nahezu in Echtzeit. Das sollte das gesamte Portfolio abdecken, auch geparkte oder regionale Länderdomains.
- Restriktive CAA-Einträge setzen: Mit einem CAA-Eintrag im DNS legen Sie fest, welche Zertifizierungsstellen für Ihre Domain ausstellen dürfen, idealerweise gebunden an ein bestimmtes ACME-Konto. Während eines laufenden DNS-Hijacks hilft das nicht, verhindert aber, dass Angreifer danach zwischengespeicherte Domainprüfungen weiter nutzen.
- Bei .gh, .sl oder .as: Google rät, die jüngsten CT-Einträge gezielt auf unerwartete Zertifikate zu prüfen.
Hintergrund: Schwachstelle DNS
Der Fall zeigt eine bekannte Schwäche im System der Web-Zertifikate: Die Prüfung hängt am DNS. Wer eine Registry oder einen Nameserver übernimmt, kann sich legitim wirkende Zertifikate besorgen, ohne eine Zertifizierungsstelle zu hacken. Google will deshalb unter anderem kürzere Laufzeiten für Zertifikate und eine kürzere Wiederverwendung von Domainprüfungen über das Chrome Root Program durchsetzen.
Häufige Fragen
Muss ich als Chrome-Nutzer etwas tun?
Nein. Die gesperrten Zertifikate werden automatisch über CRLSets blockiert. Halten Sie Chrome trotzdem aktuell.
Wurde Google gehackt?
Nein. Laut Google waren die eigenen Systeme nicht betroffen. Angegriffen wurden die Registrierungsstellen der drei Länderendungen.
Sind auch deutsche Websites betroffen?
Direkt nur Domains mit den Endungen .gh, .sl und .as. Google hat keine Liste der betroffenen Organisationen veröffentlicht.
