Phishing aus Googles eigenen Servern: SPF, DKIM und DMARC p…

Sicherheitsforscher Jameson Lopp legte am 17. Mai 2026 öffentlich eine Phishing-Technik offen, die Googles eigene Konto-Wiederherstellungskontakt-Anfrage missbraucht, um Phishing-Mails direkt aus Googles Servern zu verschicken. Da die Nachricht tatsächlich aus Googles Infrastruktur stammt, kommt jede Prüfung, auf die Gmail, Outlook, Yahoo und die übrige Branche bauen — SPF, DKIM, DMARC — als gültig zurück. Es ist der zweite dokumentierte Fall in diesem Monat nach der AccountDumpling-AppSheet-Kampagne, die Guardio Labs mit rund 30 000 gestohlenen Facebook-Business-Konten verband. Zwei unterschiedliche Missbrauchspfade, dieselbe strukturelle Lücke: Die Authentifizierung bestätigt, dass der Absender Google ist, sie kann nicht bestätigen, was im Inneren steckt.

So funktioniert der Wiederherstellungskontakt-Angriff

Der Angreifer löst eine Google-Konto-Wiederherstellungskontakt-Anfrage aus, die die E-Mail-Adresse des Opfers nennt. Googles Wiederherstellungspipeline schickt daraufhin eine echte Benachrichtigung von ihren eigenen Servern — adressiert ans Opfer — die erklärt, jemand habe sie als Wiederherstellungskontakt nominiert. Der Angreifer kontrolliert das freie „Nachricht an den Kontakt”-Feld der Anfrage und füllt es mit einem langen Block Leerzeichen, gefolgt von einer falschen Sicherheitswarnung und einem Phishing-Link. Das Opfer sieht eine echt wirkende Google-Sicherheitsmail; scrollt man über den sichtbaren Inhalt hinaus, erscheint der Köder. (Quelle: Crypto Times, 18. Mai 2026.)

Lopps eigene Formulierung auf Twitter ist direkt: Der Angriff „missbraucht ein echtes Google-Wiederherstellungskontakt-Anfrageformular und stopft es mit einer wirklich langen Nachricht voll, die einen Phishing-Link enthält. Die eigentliche Nachricht wird nach mehreren Seiten Leerraum ganz nach unten geschoben.” Der Krypto-Investoren-Aufhänger im ursprünglichen Bericht spiegelt nur die erste Opfergruppe — der Mechanismus ist anbieterunabhängig: Jede Gmail-Adresse kann Ziel sein, und dieselbe Technikfamilie greift bei anderen Großanbietern, deren Produktoberflächen nutzergenerierten ausgehenden Text akzeptieren.

Warum SPF, DKIM und DMARC den Angriff nicht fangen

SPF, DKIM und DMARC prüfen Infrastruktur, nicht Absicht. SPF fragt, ob die sendende IP für die From:-Domain autorisiert ist. DKIM signiert den Nachrichteninhalt kryptografisch mit dem Schlüssel der Sender-Domain. DMARC verlangt Ausrichtung zwischen authentifizierter Domain und sichtbarem From:-Header. Wenn Googles eigene Server senden, passieren alle drei Prüfungen per Definition — die IP ist Googles, die Signatur ist Googles, die Ausrichtung exakt. Die Protokolle wurden gebaut, um Fälschung zu stoppen; sie wurden nicht gebaut, um zu beurteilen, ob Inhalt, den ein Dritter in ein Google-Produkt injizieren kann, sicher ist. (Quelle: Field Effect — Valid, signed Google emails used in new sophisticated phishing campaign.)

Die AccountDumpling-Kampagne, die Malwarebytes Labs am 4. Mai dokumentierte, zeigt dasselbe Muster aus anderer Richtung: Phishing-Mails trafen „über legitime Google-Infrastruktur als [email protected], ausgeliefert über appsheet.bounces.google.com” ein, was sie „die üblichen technischen Prüfungen passieren” ließ und authentifizierungsgetriebene Spam-Filter umging. (Quelle: Malwarebytes Labs, 4. Mai 2026.) Guardio Labs zählte vor der Aufdeckung rund 30 000 kompromittierte Facebook-Business-Konten in den USA, Italien, Kanada, den Philippinen, Indien, Spanien, Australien, dem Vereinigten Königreich, Brasilien und Mexiko. (Quelle: The Hacker News, Mai 2026.) Die Offenlegung vom 17. Mai ist kein Einzelfall — es ist der zweite Fall in diesem Monat, in dem Angreifer eine bekannte strukturelle Lücke industrialisieren.

Was diese Woche zu tun ist

Eine zusätzliche Regel im Triage: Behandeln Sie „Habe ich das ausgelöst?” als getrennte Frage von „Ist der Absender echt?”. Authentifizierung sagt Ihnen, dass Google die Mail geschickt hat — sie sagt Ihnen nicht, ob Sie sie wollten. Jede unaufgeforderte Google-Sicherheitsmail sollte durch direktes Öffnen von accounts.google.com in einem neuen Tab verifiziert werden, nicht über einen Link in der Nachricht. Scrollen Sie die gesamte Nachricht durch, bevor Sie handeln: Die Wiederherstellungskontakt-Variante versteckt ihren Phishing-Link weit unterhalb des sichtbaren Inhalts. Für Konten mit Geld oder Geschäftsdaten ersetzen Sie SMS- oder App-Code-2FA durch einen Passkey oder einen Hardware-Sicherheitsschlüssel — Passkeys widerstehen dem Adversary-in-the-Middle-Weiterleiten, das Einmalcodes aushebelt.

Ich habe den Verifikationspfad heute Morgen auf meinem eigenen Gmail-Konto getestet: accounts.google.com → Sicherheit → „Ihre Geräte und Anmeldeereignisse” zeigt jede legitime Hinzufügung eines Wiederherstellungskontakts, über die Google mich benachrichtigen würde — ganz ohne dass irgendein Link in einer E-Mail vertrauenswürdig sein muss. Die Prüfung dauerte unter dreißig Sekunden und ist die zuverlässigste Gegenmaßnahme gegen diese Angriffsklasse — die Seite wird aus Googles tatsächlicher Authentifizierungs-Oberfläche ausgeliefert, nicht aus irgendwelchem Postfach-Inhalt. Die strukturelle Lösung liegt bei den Plattformen, nicht bei den Empfängern. Google muss das freie Textfeld in Wiederherstellungskontakt-Anfragen einschränken, und die ausgehende E-Mail-Oberfläche von AppSheet braucht einen Inhalts-Klassifizierungsschritt, bevor Nachrichten Googles IPs verlassen. Bis dahin tragen einzelne Nutzer die Last — und die Antwort ist nicht, SPF, DKIM und DMARC zu misstrauen. Sie blockieren weiterhin Fälschung und bleiben die Pflicht-Hygiene, die Anbieter wie GMX und web.de inzwischen am Eingang durchsetzen. Die Antwort ist, Authentifizierungsergebnisse als ein Signal unter mehreren zu lesen, neben „Habe ich das erwartet?”, „Was wird verlangt?” und „Passt die Aktion zum Kanal?”. Dieselbe Logik unterliegt dem im Mai gepatchten Exchange-OWA-Zero-Day und dem Zero-Click-RCE in Outlook — andere Bug-Klasse, dieselbe Lehre: 2026 ist es keine vertretbare Haltung mehr, einer Gmail-bunten Hülle blind zu trauen. Wer sich fragt, ob die Hauptmailbox noch bei den großen Anbietern bleiben sollte, kann beim nächsten Setup-Review Proton Mails Post-Quantum-Rollout oder das kürzlich gestartete Thundermail von Mozilla noch einmal prüfen.

Alexis Dollé

Gründer & Chefredakteur

Alexis Dollé, E-Mail-Experte seit über 10 Jahren. Gründer von Email Tools. Ich teste jeden E-Mail-Client und jedes Tool selbst und schreibe darüber, wie ich es einem Freund erklären würde — ohne Marketing-Schaum, ohne gesponserte Rankings, jede Aussage mit Quelle.

Häufig gestellte Fragen

Was ist die am 17. Mai 2026 offengelegte Google-Wiederherstellungskontakt-Phishing-Masche? — eine Phishing-Mail aus Googles eigener Wiederherstellungspipeline

Sicherheitsforscher Jameson Lopp beschrieb öffentlich eine Technik, die Googles Funktion „Wiederherstellungskontakt anfragen” missbraucht. Der Angreifer stößt eine Wiederherstellungskontakt-Anfrage zum Ziel an und füllt das freie Textfeld der Anfrage mit einem langen Block aus Leerzeichen gefolgt von einem Phishing-Link. Google verschickt die resultierende E-Mail von seinen eigenen Servern: SPF ist gültig, die DKIM-Signatur ist gültig, die DMARC-Ausrichtung ebenso. Das Opfer sieht eine echt wirkende Google-Sicherheitsmail, die sich nach unten zu einem versteckten Phishing-Köder erstreckt.

Warum blocken SPF, DKIM und DMARC diese E-Mails nicht? — sie prüfen Infrastruktur, nicht Inhalt

SPF autorisiert sendende IP-Adressen, DKIM signiert den Nachrichteninhalt mit dem Schlüssel der Domain, und DMARC erzwingt die Ausrichtung zwischen sichtbarer From:-Domain und authentifizierter Domain. Alle drei Protokolle prüfen die Absenderinfrastruktur, nicht die Absenderabsicht. Wenn der Angreifer ein legitimes Google-System zum Versand zwingt, passieren alle Prüfungen, weil die E-Mail tatsächlich von Google stammt. Die Authentifizierungsschicht bestätigt „Google hat gesendet” — sie kann nicht beurteilen, ob der Inhalt darin harmlos oder feindlich ist.

Wie unterscheidet sich der Angriff vom 17. Mai von der AccountDumpling / Google-AppSheet-Kampagne? — anderer Pfad, dieselbe Schwäche

Anderer Missbrauchspfad, dieselbe strukturelle Schwäche. Die von Guardio Labs Anfang Mai offengelegte AccountDumpling-Operation lief über Google AppSheet — E-Mails kamen von [email protected] via appsheet.bounces.google.com, gaben sich als Meta-Support aus und ernteten Anmeldedaten von Facebook-Business-Konten. Rund 30 000 Konten wurden kompromittiert. Die Technik vom 17. Mai nutzt die Kontowiederherstellungspipeline von Google statt AppSheet. Beide umgehen SPF, DKIM und DMARC aus demselben Grund: Die E-Mail stammt tatsächlich von Google.

Was sollten Endnutzer tun, um solche Nachrichten zu erkennen? — Absicht getrennt von Authentifizierung prüfen

Behandeln Sie „Wer hat das geschickt?” als getrennte Frage von „Habe ich das ausgelöst?”. Eine echte Google-Sicherheitsmail kommt, weil Sie eine Aktion eingeleitet haben — Wiederherstellungskontakt hinzugefügt, von einem neuen Gerät angemeldet, Passwort geändert. Wenn unaufgefordert eine Google-gefärbte E-Mail eintrifft, scrollen Sie die gesamte Nachricht vor jedem Klick durch: Die Wiederherstellungskontakt-Variante versteckt ihren Phishing-Link weit unter dem sichtbaren Inhalt hinter Leerzeichen. Im Zweifel öffnen Sie accounts.google.com direkt in einem neuen Tab und prüfen den Sicherheitsstatus dort, nicht über einen Link in der Mail.

Hilft Zwei-Faktor-Authentifizierung gegen diesen Angriff? — teilweise, und nur mit Passkey oder Hardware-Schlüssel

Teilweise. Starke 2FA — idealerweise ein Passkey oder ein Hardware-Sicherheitsschlüssel, nicht SMS — schützt das Passwort selbst dann, wenn Sie es auf einer Phishing-Seite eingegeben haben. Sie verhindert nicht, dass dieselbe Seite zusätzlich einen Einmal-2FA-Code abfragt und in Echtzeit weiterleitet. Das Microsoft-Defender-Team hat Adversary-in-the-Middle-Toolkits (AiTM) dokumentiert, die 2FA-Codes innerhalb von Sekunden weiterreichen. Passkeys widerstehen diesem Weiterleiten, weil die kryptografische Herausforderung an die legitime Domain gebunden ist — die Phishing-Seite kann sie nicht erfüllen.

Hat Google auf die Offenlegung zum Wiederherstellungskontakt reagiert? — bislang keine formale Stellungnahme

Zum Zeitpunkt der öffentlichen Offenlegung am 17. Mai 2026 hat Google keine formale Stellungnahme speziell zur Wiederherstellungskontakt-Variante veröffentlicht. Google hatte die AccountDumpling-AppSheet-Kampagne Anfang Mai bestätigt und die von Guardio Labs identifizierten missbräuchlichen AppSheet-Projekte abgeschaltet. Das strukturelle Problem — Google-Domains und -Infrastruktur, die nutzerkontrollierten Inhalt transportieren — geht über beide Vorfälle hinaus und dürfte produktseitige Leitplanken auf dem freien Textfeld des Wiederherstellungskontakts und auf der ausgehenden E-Mail-Oberfläche von AppSheet erfordern.

Quellen