Phishing trotz MFA: Warum ein echter Anmelde-Bildschirm Ihr Konto nicht schützt

Was bei Google-Kalender-Einladungen passiert ist

Seit Mitte August 2026 sammelte eine Phishing-Kampagne aktive Sitzungen von Firmenkonten ein. Der Transportweg war bewusst gewöhnlich: Die Nachrichten kamen als Google-Kalender-Einladungen, teils per BCC, häufig von einer Organisation, mit der die Empfänger schon einmal geschrieben hatten. Die Vorwände waren langweilig — Sprachnachricht, Ausschreibung, Gerichtspost, Zahlungserinnerung.

Die Links darin zeigten fast immer auf Google selbst: auf den /url-Weiterleiter von Google mit dem echten Ziel als Parameter, teils über share.google oder Drive-Dateien. Wer klickte, landete auf einer täuschend echten Google-Anmeldeseite. Dahinter lief ein Reverse-Proxy vor der echten Anmeldeseite: Passwort, SMS-Code, Authenticator-Code, die „Ja, das bin ich"-Abfrage und sogar die Kontowiederherstellung wurden in Echtzeit an Google durchgereicht. Der Angreifer musste nichts entschlüsseln — er sah dieselbe Sitzung, die der Mitarbeitende gerade geöffnet hatte.

Das Framework dahinter ist seit Februar unter dem Namen Nyasher öffentlich dokumentiert. Der Sicherheitsanbieter Material Security hat die Kampagne als „Operation CloudFire" verfolgt und für einen Monat unter anderem 68.676 blockierte Nachrichten, 2.112 geprüfte Links, 897 abgeschaltete Domains und 8.570 kompromittierte Absenderkonten aus 6.354 Root-Domains dokumentiert; BleepingComputer hat den Bericht am 4. November 2026 zusammengefasst. Die Kampagne gilt inzwischen als beendet — die Betreiber haben die Vorlagen aber nachweislich nur auf Google-Drive-Freigaben umgestellt und einen fertigen, noch nicht aktivierten Zweig für Microsoft 365 gebaut. Das ist eine Beobachtung, keine Prognose — aber es macht die Technik für jede Umgebung relevant, nicht nur für Google.

Warum MFA hier nicht greift — und was wirklich hilft

Hier ist der Punkt, an dem viele Annahmen kippen: Der zweite Faktor wurde nicht gebrochen, sondern mitgelesen. Reputationssysteme beantworten nur die Frage, wem eine Domain gehört und ob sie auffällig war. In diesem Aufbau war jede sichtbare Antwort unauffällig — erst Google, dann eine echte Cloudflare-Prüfseite, und die Passwortseite selbst entsteht erst im Browser, sodass es für Filter nichts zum Scannen gibt. Google hat dieses Muster im Betrugsbericht vom Juni 2026 ausdrücklich beschrieben („Adversary-in-the-Middle") und setzt unter anderem auf Device Bound Session Credentials.

Was den Unterschied macht, ist unspektakulär:

• Phishing-resistente Anmeldung. Passkeys oder Sicherheitsschlüssel sind an die echte Domain

gebunden. Eine kopierte Seite kann die Signatur nicht verwerten — genau darum ist die Umstellung auf Codes allein kein Schutz gegen dieses Muster.

• Sitzungen beenden können. Wer im Haus darf innerhalb einer Stunde alle Sitzungen abmelden,

OAuth-Freigaben entziehen und Passwörter zurücksetzen? Eine erbeutete Sitzung reicht bis in Postfach, Ablage und Rechtevergabe.

• Jemand liest die Protokolle. Anmelde- und Freigabeprotokolle sind wertlos, wenn sie niemand

ansieht. Auffällig sind neue Freigaben, ungewohnte Orte und Anmeldungen ohne passenden Anlass.

Was Sie jetzt konkret tun sollten

Fünf Punkte, die sich ohne Projektplan an einem Nachmittag klären lassen:

1. Anmeldewege prüfen. Wo ist der zweite Faktor nur ein Code oder ein Klick? Für Konten mit

Zugriff auf Postfach, Lohn- oder Kundendaten gehört ein Passkey oder ein Sicherheitsschlüssel hin.

1. Notfallgriff üben. Einmal durchspielen: Sitzung abmelden, Freigaben entziehen, Passwort ändern.

Wer das zum ersten Mal im Ernstfall tut, braucht zu lange.

1. Kalender-Einstellungen ansehen. Einladungen müssen nicht automatisch im Kalender landen, bevor

jemand geantwortet hat. Weniger automatische Übernahmen bedeuten weniger Angriffsfläche.

1. Meldeweg etablieren. „Ich habe eine komische Einladung von einem Kunden bekommen" muss ein Satz

sein, der intern ohne Rechtfertigung funktioniert — sonst klickt der nächste Kollege.

1. Den Satz streichen: „Der Link zeigt auf Google, der ist sicher." Genau das war die Annahme, mit

der diese Kampagne gerechnet hat.

Für Betriebe in Fürstenfeldbruck, Augsburg und im Umland gilt dabei nichts anderes als für ein Unternehmen mit eigener IT-Abteilung — außer, dass es niemanden gibt, der nachts um halb elf noch alle Sitzungen eines Kontos abmeldet. Deshalb gehört der Notfallgriff vorher aufs Papier.