Microsoft 365: Phishing über Google Sites und Cloudflare abwehren

Phishing auf Microsoft-365-Konten läuft längst nicht mehr über plumpe Fake-Seiten auf obskuren Domains. Aktuelle Kampagnen schicken das Opfer über Dienste, denen jeder Filter vertraut: Google Sites, Cloudflare Workers und Cloudflare Turnstile. Am Ende steht eine täuschend echte Microsoft-Anmeldung, die nicht nur das Passwort abgreift, sondern auch den MFA-Code und die Sitzung. Klassische MFA per SMS oder Authenticator-App hilft dagegen nicht.

So läuft der Angriff ab

Die Mail: Das Opfer bekommt eine Mail mit einem Link auf sites.google.com. Weil die Domain Google gehört, lassen Mailfilter und Proxys den Link meist durch.
Die Köderseite: Auf der Google-Site liegt eine Seite im Look einer geteilten Excel-Datei mit einem „Öffnen“-Button. Logos und Icons sind als Base64 direkt in die Seite eingebettet, damit keine verdächtigen Bilder nachgeladen werden.
Die Weiterleitung: Der Button führt auf eine Subdomain von workers.dev, also auf Cloudflare. Auch diese Domain hat einen guten Ruf.
Die Prüfseite: Dort wartet eine echte Cloudflare-Turnstile-Abfrage. Für den Nutzer sieht das nach Sicherheit aus. Tatsächlich hält sie Scanner und Sandboxen draußen. Nebenbei prüft die Seite per JavaScript, ob der Browser im privaten Modus läuft, ein typisches Zeichen für Analyseumgebungen.
Die Anmeldeseite: Erst danach lädt die eigentliche Phishing-Seite, versteckt in einem randlosen Vollbild-iframe von einer weiteren Domain des Angreifers. Der Code wird erst im Browser aus Base64 zusammengesetzt und sieht für statische Scanner harmlos aus. Die Seite bildet die komplette Microsoft-Anmeldung nach, inklusive MFA per Code oder SMS, Device-Code-Anmeldung und sogar Passkey-Dialog.
Der Abgriff: Passwort und MFA-Code laufen live über den Server des Angreifers zu Microsoft weiter. Der Angreifer steht also zwischen Opfer und Microsoft (Adversary in the Middle, AiTM) und bekommt das fertige Sitzungscookie oder die Tokens. Danach landet das Opfer auf der echten Microsoft-Seite und merkt nichts.

Warum Filter das nicht erkennen

Vertrauenswürdige Domains: Google und Cloudflare kann niemand pauschal blockieren, ohne den Arbeitsalltag zu stören.
Gestaffelte Weiterleitungen: Jede Station sieht für sich harmlos aus. Die eigentliche Phishing-Domain taucht in der Mail gar nicht auf.
Abwehr gegen Analyse: CAPTCHA, Erkennung des privaten Modus, kurzlebige Zugangstokens und Code, der erst zur Laufzeit entsteht, sorgen dafür, dass automatische Scanner nur eine leere oder harmlose Seite sehen.
Echte MFA-Abläufe: Weil der Angreifer die Anmeldung live an Microsoft weiterreicht, ist die MFA-Abfrage echt. Für den Nutzer gibt es keinen Unterschied.

So schützt du deinen Tenant

Phishing-resistente MFA

Der wirksamste Schutz gegen AiTM sind Anmeldeverfahren, die an die echte Microsoft-Domain gebunden sind: Passkeys (FIDO2), Windows Hello for Business oder zertifikatsbasierte Anmeldung. Ein Proxy auf einer fremden Domain kann diese Anmeldung nicht weiterreichen.

Setze das über Conditional Access durch: Grant → Require authentication strength → Phishing-resistant MFA. Fang mit Admin-Konten an und weite es dann auf alle Benutzer aus.

Conditional Access verschärfen

Gerätebindung: Verlange für den Zugriff ein konformes oder hybrid eingebundenes Gerät. Die Anmeldung des Angreifers kommt von seiner eigenen Infrastruktur und scheitert daran.
Device-Code-Flow sperren: Die meisten Benutzer brauchen ihn nie. Blockiere ihn per Conditional Access unter Conditions → Authentication flows → Device code flow.
Risikobasierte Richtlinien: Mit Entra ID P2 kann Entra ID Protection verdächtige Anmeldungen und gestohlene Tokens erkennen. Lass bei erhöhtem Risiko eine erneute Anmeldung oder eine Passwortänderung verlangen.

Mails und Links

Prüfe, ob Safe Links in Defender for Office 365 aktiv ist. Es prüft Links beim Klick und nicht nur beim Empfang der Mail.
Links auf sites.google.com/view/ und *.workers.dev in Mails von außen solltest du nicht pauschal blockieren, aber im Blick behalten. Mails mit solchen Links von unbekannten Absendern verdienen einen Warnhinweis.
Erkläre den Nutzern, dass eine Cloudflare-Prüfung vor einem Microsoft-Login nichts mit Sicherheit zu tun hat. Microsoft fragt so etwas nie ab.

Woran du einen erfolgreichen Angriff erkennst

In den Anmeldeprotokollen von Entra ID fällt ein AiTM-Angriff meist so auf: Kurz nach einer normalen Anmeldung des Benutzers folgt eine erfolgreiche Anmeldung von einer fremden IP-Adresse, oft aus einem Rechenzentrum oder einem anderen Land.

Hast du die Anmeldeprotokolle in Log Analytics oder Sentinel, findest du solche Fälle zum Beispiel so:

KUSTO

SigninLogs
| where TimeGenerated > ago(7d) and ResultType == "0"
| summarize Laender = make_set(tostring(LocationDetails.countryOrRegion)), IPs = make_set(IPAddress) by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Laender) > 1

Weitere typische Spuren nach einem Abgriff:

neue Posteingangsregeln, die Mails löschen, verschieben oder weiterleiten
neu registrierte MFA-Methoden, die der Benutzer nicht selbst angelegt hat
Zustimmungen zu unbekannten Apps (OAuth-Consents)

Wenn ein Konto betroffen ist

Melde den Benutzer überall ab. Ein neues Passwort allein reicht nicht, die gestohlene Sitzung bleibt sonst gültig.
PowerShell
```
Connect-MgGraph -Scopes "User.ReadWrite.All"
Revoke-MgUserSignInSession -UserId "max.mustermann@domain.de"
```
Setze das Passwort zurück.
Prüfe die MFA-Methoden des Benutzers und entferne alles, was er nicht selbst eingerichtet hat.

Prüfe die Posteingangsregeln:

PowerShell

Connect-ExchangeOnline
Get-InboxRule -Mailbox "max.mustermann@domain.de" | Format-List Name, Enabled, Description

Prüfe in Entra ID unter Enterprise applications, ob der Benutzer neuen Apps zugestimmt hat.
Schau in den Anmeldeprotokollen nach, was der Angreifer mit der Sitzung gemacht hat, und informiere bei Bedarf die Empfänger von Mails, die in seinem Namen verschickt wurden.

Fazit

Gegen diese Art von Phishing helfen weder Domain-Sperrlisten noch klassische MFA zuverlässig. Wirklich schützt nur eine Anmeldung, die sich nicht weiterreichen lässt: Passkeys oder Windows Hello, kombiniert mit Conditional Access auf verwaltete Geräte. Alles andere verringert das Risiko, schließt die Lücke aber nicht.