M365: Wie Angreifer Zugangsdaten stehlen (und wie man reagiert)

Es war ein Montagmorgen, als Anna, die Leiterin der Beschaffung, beim Helpdesk anrief — mit dieser Stimme, die man sofort erkennt: "Ich bekomme Antworten auf E-Mails, die ich nie gesendet habe". Rechnungen in Verhandlung, Lieferanten, die Bestätigungen anfragen, Überweisungen zur Freigabe. Das ist kein hypothetisches Szenario — es passiert jede Woche, in Unternehmen jeder Grösse. Und jedes Mal ist die Kette dieselbe.

Wie Zugangsdaten gestohlen werden

Der häufigste Einstiegspunkt heute ist keine technische Schwachstelle — es ist eine geklonte Microsoft-Login-Seite. Angreifer nutzen OSINT (LinkedIn, Unternehmenswebsites, Datenlecks), um Phishing zu personalisieren: Der Link enthält den Namen, die Rolle und oft die Azure-Tenant-ID des Unternehmens. Der Nutzer sieht eine plausible URL auf einer Typosquatting-Domain — micros0ft-login.com, login.microsoftonIine.com — und die Seite ist pixelgenau identisch.

Der eigentliche Fortschritt ist AiTM (Adversary-in-the-Middle). Frameworks wie EvilProxy, Mamba2FA und Tycoon2FA klonen keine statische Seite: Sie fungieren als transparenter Proxy zum echten Microsoft-Login. Der Nutzer gibt Benutzername, Passwort und MFA-Code ein — alles echt, alles zum legitimen Server weitergeleitet. Aber der Proxy fängt das Session-Cookie und das Authentifizierungstoken in Echtzeit ab. Zu diesem Zeitpunkt ist die MFA bereits erfüllt: Das Token ist gültig, authentifiziert und bereit, vom Angreifer wiederverwendet zu werden.

Der zweite Angriffsvektor ist direkter: MFA-Fatigue. Der Angreifer kennt das Passwort bereits (aus einem Datenleck oder Credential-Stuffing) und sendet 20-30 Push-Benachrichtigungen an die Authenticator-App in schneller Folge, oft nachts oder während eines Meetings. Er setzt auf Erschöpfung, Ablenkung — den Nutzer, der auf "Genehmigen" tippt, nur damit das Telefon aufhört zu vibrieren. Genau das ist Uber 2022 passiert.

Das dritte Szenario ist Token-Diebstahl. Entra-ID-Session-Tokens und Refresh-Tokens haben Laufzeiten von Stunden bis Tagen. Ein Infostealer wie Redline oder Lumma auf dem Laptop eines Nutzers kann diese Tokens aus dem Browser oder dem MSAL-Cache extrahieren. Mit einem gültigen Token wird weder Passwort noch MFA benötigt — der Angreifer greift direkt auf Microsoft-365-APIs zu. Tools wie AADInternals automatisieren diesen Prozess in wenigen Befehlen.

Der vierte Vektor, der im Frühjahr 2026 explodierte, ist Device-Code-Phishing: Die PhaaS-Plattform Kali365, im Mai 2026 vom FBI gemeldet, missbraucht Microsofts OAuth-2.0-Device-Authorization-Grant-Flow. Der Angreifer startet eine Device-Code-Anfrage gegen seine eigene registrierte App, fügt den erhaltenen Code in eine Phishing-Seite ein, die eine OneDrive- oder SharePoint-Freigabe vortäuscht, und das Opfer gibt ihn auf microsoft.com/devicelogin ein — einer legitimen Microsoft-Domain. Die App des Angreifers erhält daraufhin das Token: kein eingegebenes Passwort, kein zu bestätigender MFA-Prompt. Die MFA wird nicht einmal berührt, weil der Flow sie gar nicht vorsieht.

Nach dem ersten Zugriff

Die ersten Minuten nach der Kompromittierung sind stille Aufklärung. Der Angreifer liest den Posteingang, prüft Entwürfe, sucht nach Schlagwörtern wie "Überweisung", "IBAN", "Rechnung", "Vertrag". Er enumeriert Nutzer, Gruppen, SharePoint und OneDrive über die Graph API. All das mit dem legitimen Token des Nutzers — kein Alert, keine sichtbare Anomalie.

Persistenz wird in Schichten aufgebaut. Zuerst kommen Posteingangsregeln: automatische Weiterleitung an eine externe Adresse oder eine Regel, die E-Mails mit "Passwort zurücksetzen", "Sicherheitswarnung", "Verdächtige Aktivität" automatisch löscht — damit der Nutzer keine Sicherheitsbenachrichtigungen sieht. Dann wird eine zweite MFA-Methode hinzugefügt (Telefonnummer des Angreifers). Schliesslich die heimtückischste Persistenz: eine OAuth-App mit delegierten Berechtigungen (mail.read, mail.send, files.read), die auf dem Konto registriert wurde. OAuth-Apps überleben ein Passwort-Reset — sie sind eine Hintertür, die auch nach der scheinbaren Behebung des Vorfalls offen bleibt.

Von dort bewegt sich der Angreifer lateral: sendet internes Phishing an Kollegen ("schau dir dieses Dokument an", mit AiTM-Link), greift über bereits bestehende delegierte Berechtigungen auf Postfächer anderer Nutzer zu und initiiert Business Email Compromise: ändert die IBAN auf einer ausstehenden Rechnung, antwortet in einem Finanz-E-Mail-Thread als CFO-Imitation, genehmigt dringende Zahlungen.

Incident Response: Die genaue Sequenz

Für den Nutzer: Rufen Sie sofort die IT an, warten Sie nicht. Benutzen Sie nicht das kompromittierte Konto dafür (nutzen Sie Ihr Telefon, eine persönliche E-Mail oder kommen Sie persönlich vorbei). Ändern Sie Ihr Passwort nicht selbst, bevor die IT die Sitzungen widerruft — eine Passwortänderung ohne Token-Widerruf lässt den Angreifer drinnen. Listen Sie alles auf, worauf Sie in den letzten 24-48 Stunden geklickt haben.

Für den Admin — operative Sequenz:

1. Sofortiger Widerruf aller aktiven Sitzungen:

# Via PowerShell (AzureAD-Modul)
Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id>

# Oder via Entra ID: Nutzer → auswählen → Sitzungen widerrufen

2. Passwort-Reset durch den Admin (nicht Self-Service):

Set-AzureADUserPassword -ObjectId <user-object-id> -Password <neues-sicheres-passwort> -ForceChangePasswordNextLogin 

3. Nicht erkannte MFA-Methoden entfernen (Entra ID → Nutzer → Authentifizierungsmethoden). Telefonnummer, Authenticator-App, Wiederherstellungs-E-Mail prüfen.

4. Posteingangsregeln prüfen:

Get-InboxRule -Mailbox nutzer@firma.de | Select Name, ForwardTo, DeleteMessage, SubjectContainsWords | Format-List

5. Verdächtige OAuth-Apps widerrufen: Entra ID → Enterprise Applications → nach "Nutzer-Zustimmung" filtern → Apps suchen, die in den letzten 24-48h registriert wurden → Berechtigungen widerrufen.

6. Anmeldeprotokolle analysieren: Entra ID → Anmeldeprotokolle → nach Nutzer filtern, letzte 48h. Nach anomalen IPs, ungewöhnlichen User-Agents (Automatisierung), unerwarteten Ländern suchen. Hinweis: Wiederverwendete Tokens zeigen die IP des AiTM-Proxys, nicht die des eigentlichen Angreifers.

7. Gesendete und gelöschte E-Mails während des Kompromittierungsfensters prüfen. In Exchange Online:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) -UserIds nutzer@firma.de -Operations SendMail,HardDelete,SoftDelete

8. Bei ausgehendem Phishing oder BEC: betroffene Empfänger benachrichtigen, E-Mails als Phishing melden, Rückruf für ungelesene Nachrichten einleiten.

Nützliche Tools: Microsoft Secure Score (Baseline), Defender for Office 365 Threat Explorer (Angriffszeitlinie), Microsoft Defender for Cloud Apps (Impossible Travel, Token-Replay-Erkennung), HAWK oder GOOSE für PowerShell-basierte Log-Forensik.

Die echte Verteidigung ist nicht die MFA

Klassische MFA — Push-Benachrichtigungen, SMS, TOTP — hält AiTM nicht auf. Angreifer umgehen sie systematisch. Echte Verteidigung wird auf mehreren Ebenen aufgebaut: Conditional Access mit Gerätecompliance (nur verwaltete, konforme Geräte können sich authentifizieren), FIDO2/Passkeys, die durch Design phishing-resistent sind (der Schlüssel ist an die Originaldomain gebunden, nicht an einen Proxy), aggressive Token-Lifetime-Richtlinien (kurze Session-Tokens, Refresh-Tokens mit IP-Binding) und kontinuierliche Überwachung anomaler Anmeldungen.

Gegen Kali365 hilft nur eine Abwehr vor der Authentifizierung selbst: Conditional Access → Authentifizierungsabläufe, deaktivieren Sie den Device-Code-Flow, falls Ihre Organisation ihn nicht braucht (die meisten brauchen ihn nicht). Da der Angriff greift, bevor MFA überhaupt ins Spiel kommt, kann keine Richtlinie für starke Authentifizierung ihn stoppen, sobald er läuft.

Und vor allem: Nutzer, die ohne Scham anrufen. Anna hat das Richtige getan. Der Schaden wurde begrenzt, weil sie sofort zum Telefon griff, ohne zu warten, bis sie "sicher" war, dass es ein echtes Problem war. Dieser Anruf kostete 10 Minuten. Ihn nicht zu machen hätte Wochen gekostet.