Microsoft 365 Phishing trotz MFA: Wie Angreifer Sitzungen übernehmen

Microsoft 365 Phishing nutzt mehr als schlechte E-Mails und gefälschte Anmeldeseiten. Angriffe beginnen in einem kompromittierten Geschäftskonto, führen auf täuschend echte oder legitime Microsoft-Seiten und enden trotz MFA im Postfach, in SharePoint oder Teams.

Der Halbjahresbericht 2026/1 des Bundesamts für Cybersicherheit betrifft Schweizer Unternehmen. Im ersten Halbjahr 2026 nahmen Meldungen zu kompromittierten Microsoft-365-Konten zu. Sie dienten für Phishing und Betrug. Angreifer traten als IT-Helpdesk oder Führungskraft auf und umgingen Kontrollen mit Session-Tokens, Device Code Phishing oder Reverse Proxies.

MFA bleibt unverzichtbar. Nicht jede Methode ist phishing-resistent. Eine bestätigte Sitzung kann zum Angriffsziel werden. Microsoft 365 muss als Identitätsplattform statt nur als E-Mail-Dienst abgesichert werden.

Wie Microsoft 365 Phishing trotz MFA funktioniert

Nach Prüfung von Passwort, zweitem Faktor, Gerätezustand und Bedingungen stellt Entra ID Tokens oder Sitzungscookies aus. Wie beim Besucherausweis zählt danach vor allem ihre Gültigkeit. Gelangen sie zu einer anderen Person, muss diese die Prüfung unter Umständen nicht wiederholen.

Tokenarten in Microsoft Entra ID unterscheiden sich in Aufgabe und Laufzeit. Entscheidend: Ein gestohlener oder für den Angreifer freigegebener Token kann eine authentifizierte Sitzung repräsentieren.

Adversary-in-the-Middle Phishing mit Reverse Proxy

Bei Adversary-in-the-Middle (AiTM) steht die Phishing-Infrastruktur zwischen Browser und Microsoft und leitet die echte Anmeldung in Echtzeit weiter:

1. Eine E-Mail verweist etwa auf ein SharePoint-Dokument, eine Voicemail, Rechnung oder Signatur.
2. Der Link führt über den Reverse Proxy des Angreifers zur Microsoft-Anmeldung.
3. Benutzername, Passwort und MFA-Antwort werden an Microsoft weitergereicht.
4. Microsoft akzeptiert die bestätigte Anmeldung und stellt die Sitzung aus.
5. Der Proxy fängt Sitzungscookie oder Tokens ab. Der Zugriff endet erst durch Ablauf, Widerruf oder Blockierung.

Die MFA wurde nicht geknackt. Der Benutzer bestätigte eine mitgelesene Sitzung. TOTP-Codes und Push-Bestätigungen verhindern diesen Relay nicht grundsätzlich. FIDO2-Schlüssel, Windows Hello for Business und korrekt eingesetzte Passkeys binden die Anmeldung dagegen kryptografisch an den legitimen Dienst. Gegen Malware auf einem angemeldeten Gerät und jeden Session-Diebstahl schützen auch sie nicht.

Device Code Phishing über eine echte Microsoft-Seite

Der Device Code Flow ist für Geräte ohne komfortable Eingabe gedacht. Ein Konferenzraumgerät oder Kommandozeilenprogramm zeigt einen Code, der auf einem zweiten Gerät über Microsoft bestätigt wird.

Angreifer starten den Ablauf selbst und übermitteln den Code unter einem Vorwand. Nach dessen Eingabe auf der echten Microsoft-Seite landen die Tokens in ihrer Sitzung. Domain und Zertifikat sind korrekt, autorisiert wird aber eine fremde Anmeldung. Microsoft stuft den Flow als risikoreich ein und empfiehlt ohne dokumentierten Bedarf die Blockierung.

E-Mail-Flut, falscher IT-Support und Ketten-Phishing

Eine Angriffskette beginnt mit Hunderten Newsletter-, Registrierungs- und Benachrichtigungs-E-Mails. Sie erzeugen Stress und verdecken echte Warnungen. Danach verlangt ein angeblicher IT-Support über Teams oder Telefon Quick Assist oder ein Fernwartungswerkzeug. Damit lassen sich Befehle ausführen, Malware installieren, Browserdaten auslesen und Zugangsdaten stehlen. Übernommen wird der Arbeitsplatz, nicht der Login.

Nach der Übernahme nutzt der Angreifer echte Korrespondenz, bekannte Lieferanten und Gesprächsverläufe für manipulierte Rechnungen, weiteres Phishing und neue Kontoübernahmen. SPF, DKIM und DMARC genügen nicht, wenn die Nachricht aus dem legitimen Microsoft-365-Tenant stammt.

Was MFA leistet und wo ihre Grenze liegt

MFA verhindert viele Kontoübernahmen, weil ein Passwort nicht mehr genügt. Die Verfahren unterscheiden sich:

• Passwort plus SMS, Telefon oder einfache Push-Bestätigung: besser als ein Passwort, aber anfällig für Social Engineering, SIM-Swapping, MFA-Fatigue und Echtzeit-Phishing.
• TOTP oder Authenticator mit Number Matching: robuster gegen versehentliche Bestätigungen, ein Code lässt sich auf einer AiTM-Seite jedoch direkt weiterreichen.
• Phishing-resistente Authentifizierung: FIDO2, Windows Hello for Business, zertifikatsbasierte Authentifizierung und Passkeys prüfen den legitimen Dienst kryptografisch und reduzieren AiTM-Logins deutlich.

Risiken bleiben: Ein infizierter Endpoint kann Sitzungen auslesen, eine OAuth-Anwendung dauerhafte Rechte erhalten und ein Benutzer fremde Device Codes oder Fernzugriffe bestätigen. Phishing-resistente MFA ist zentral, aber kein vollständiges Sicherheitskonzept.

Microsoft Entra ID sinnvoll härten

Conditional Access und Token Protection benötigen passende Entra-Lizenzen, Gerätebedingungen eine verwaltete Gerätebasis. Richtlinien sollten zuerst im Report-only-Modus mit einer Pilotgruppe geprüft werden.

Phishing-resistente Anmeldung priorisieren

Der erste Rollout sollte Administratoren, Finanzverantwortliche, Geschäftsleitung und Helpdesk umfassen. Conditional Access Authentication Strengths können dort Windows Hello for Business, FIDO2-Schlüssel, Passkeys oder zertifikatsbasierte Authentifizierung verlangen.

Dazu gehört ein Recovery-Prozess mit mindestens zwei registrierten Verfahren, geprüften Ersatzgeräten und getrennt überwachten Notfallkonten. Ein verlorener Schlüssel darf weder lange Ausfälle noch leicht manipulierbare Helpdesk-Ausnahmen verursachen. Passkeys eignen sich auch für die Sophos-Central-Anmeldung, wobei Recovery und Gerätewechsel ebenfalls geplant werden müssen.

Device Code Flow prüfen und möglichst blockieren

Die Nutzung lässt sich in den Entra Sign-in Logs über Authentication protocol > Device code inventarisieren. Konferenzraumgeräte, ältere Werkzeuge oder Kommandozeilenanwendungen können darauf angewiesen sein. Ohne begründeten Bedarf wird unter Entra ID > Conditional Access > Policies eine Richtlinie erstellt:

1. Reguläre Benutzer oder Gruppen auswählen.
2. Notfallkonten und begründete technische Ausnahmen ausschliessen.
3. Unter Target resources möglichst All resources wählen, engere Ziele nur begründet.
4. Unter Conditions > Authentication flows den Device code flow aktivieren.
5. Unter Grant den Zugriff blockieren.
6. Zuerst Report-only verwenden, Logs prüfen und erst danach aktivieren.

Ausnahmen sollten eng begrenzt, dokumentiert und konkreten Konten oder Ressourcen zugeordnet sein.

Zugriff an verwaltete Geräte binden

Conditional Access kann für sensible Anwendungen ein konformes oder Microsoft-Entra-verbundenes Gerät verlangen. Das erschwert Token-Missbrauch auf unbekannten Geräten, betrifft aber BYOD, Gäste, Mobilgeräte und Spezialclients. Deshalb müssen Gerätebestand, Betriebssysteme und Anwendungen bekannt sein. Veraltete Einträge, schwaches Enrollment oder grosszügige Ausnahmen untergraben die Kontrolle.

Token Protection gezielt testen

Token Protection bindet unterstützte Sign-in-Session-Tokens kryptografisch an das ausstellende Gerät und erschwert den Replay auf anderen Systemen. Die Funktion benötigt Entra ID P1 und deckt nur bestimmte Plattformen, Anwendungen und Ressourcen ab. Unter Windows schützt sie vor allem unterstützte native Microsoft-365-Anwendungen. Apple-Geräte benötigen Verwaltung und den Microsoft Enterprise SSO Plug-in. Apples Mail- und Kalender-Apps unterstützen Token Protection derzeit nicht.

Die Einführung beginnt eng begrenzt in Report-only. Danach werden Token Protection Status Details, Clients und Ressourcen in den Sign-in Logs geprüft. Erst bei bestätigter Kompatibilität folgt die Durchsetzung. Browser, Altsoftware und Sondergeräte werden separat bewertet.

Teams und Fernwartung kontrollieren

Festzulegen ist, welche externen Domains oder Tenants Benutzer über Teams kontaktieren dürfen und wie externe Teilnehmer erkennbar sind. Für den Support gilt:

• Fernwartung startet nur mit Ticket oder verifiziertem Rückruf über eine bekannte Nummer.
• Unerwartete Quick-Assist-Sitzungen aus Chats oder Telefonaten werden nicht akzeptiert.
• Erlaubte Fernwartungswerkzeuge sind dokumentiert und überwacht.
• Unbekannte RMM-Tools werden per Application Control, AppLocker, Windows Defender Application Control oder vergleichbaren Kontrollen blockiert oder alarmiert.
• Eine ungewöhnliche E-Mail-Flut wird an IT oder Security gemeldet und nicht nur als Spam behandelt.

Awareness muss diese Abläufe abbilden. Sophos Phish Threat wird wirksamer mit klaren Meldewegen, Teams-Szenarien und einem realistischen Helpdesk-Runbook.

Welche Spuren Administratoren prüfen sollten

Ein erfolgreiches MFA-Ereignis beweist keine legitime Anmeldung. Bei AiTM oder Device Code wurde der Faktor womöglich selbst bestätigt. Identität, Postfach, Endgerät und Kommunikation müssen gemeinsam untersucht werden.

Microsoft Entra Sign-in Logs

Die Protokolle liegen unter Entra ID > Monitoring & health > Sign-in logs, lesbar ab Reports Reader. Je nach Verdacht gehören interaktive und nicht interaktive Anmeldungen, Service Principals und Managed Identities in die Analyse. Relevant sind:

• unbekannte oder nicht konforme Geräte sowie ungewohnte IPs, Regionen, Anwendungen und Clients,
• Device code als Authentication Protocol,
• neue Browser- oder Gerätekombinationen nach einem normalen Login,
• ungewöhnliche Zugriffe auf Exchange Online, SharePoint oder Microsoft Graph,
• Conditional-Access-Ergebnis, erfüllte Authentifizierungsanforderungen und
• erfolgreiche Zugriffe ohne erwartete Benutzerinteraktion durch vorhandene Tokens.

Ein Signal genügt nicht. Eine Schweizer IP kann zu Mobilfunk oder VPN gehören, eine Auslandsanmeldung geschäftlich sein. Entscheidend ist die Kombination aus Benutzer, Gerät, Zeit, Anwendung und Folgeaktivität.

Exchange Online, Audit und Endpoint

Nach einer Übernahme suchen Angreifer häufig nach Rechnungen und Gesprächsverläufen. Zu prüfen sind interne und externe Weiterleitungen, sichtbare und versteckte Inbox Rules, Delegierungen und Send-as-Rechte, ungewöhnliche Such-, Lese-, Download- und Versandaktivitäten, neue OAuth-Zustimmungen und Enterprise Applications, geänderte Authentifizierungsmethoden sowie alle versendeten Nachrichten im Zeitfenster.

Bei falschem IT-Support liegen Spuren auf dem Endpoint: Fernwartungsprogramme, Downloads, PowerShell, MSHTA, geplante Tasks, Browserzugriffe und verdächtige Prozesse. E-Mail-Sicherheit, Endpoint Protection sowie XDR oder MDR können sie blockieren und korrelieren, sofern Datenquellen lizenziert, integriert und überwacht sind. Die Sophos-Fusion-Strategie unterstützt dies, ersetzt aber weder Conditional Access noch den Incident-Prozess.

Aufbewahrung und Detailtiefe der Auditdaten hängen von Lizenz und Konfiguration ab. Beides muss vorab geklärt sein, da nachträglich aktivierte Protokolle keine Historie erzeugen.

Notfallplan für ein kompromittiertes Microsoft-365-Konto

Ein Passwortwechsel genügt nicht. Sitzungen, fremde MFA-Methoden, OAuth-Zustimmungen und Postfachregeln können bestehen bleiben.

1. Sauberes Administrationsgerät verwenden

Bei möglicher Endpoint-Kompromittierung erfolgen Kennwortänderung und Administration auf einem anderen Gerät. Das betroffene System wird ohne vorschnelle Spurenlöschung isoliert. Bei laufendem Angriff oder privilegiertem Konto kann eine vorübergehende Deaktivierung sinnvoll sein.

2. Aktive Sitzungen widerrufen

Die Sitzungen lassen sich im Entra Admin Center oder mit Microsoft Graph PowerShell widerrufen:

Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId user@example.com

Der User Principal Name wird angepasst. Je nach Anwendung, Tokenart und Continuous Access Evaluation kann Zugriff kurz weiterbestehen. Deshalb wird der Erfolg in Logs und Anwendungen kontrolliert.

3. Kennwort und Authentifizierung bereinigen

Das Kennwort wird in der führenden Identitätsquelle geändert, bei synchronisierten oder föderierten Konten im lokalen Active Directory oder Identity Provider. Danach werden MFA-Methoden, Passkeys, Telefonnummern, Geräte und Temporary Access Passes geprüft und fremde Einträge entfernt. Bei Malware oder Fernzugriff wird der Endpoint parallel untersucht und bei Bedarf neu aufgebaut.

4. OAuth-Zustimmungen und Rollen prüfen

Benutzerzustimmungen, Enterprise Applications und verdächtige Service Principals können dauerhaften Zugriff ermöglichen. Bei privilegierten Konten werden auch Entra-, Azure- und Microsoft-365-Rollen kontrolliert.

5. Weiterleitungen und Inbox Rules prüfen

Exchange Online PowerShell zeigt zentrale Mailbox-Einstellungen:

Get-Mailbox -Identity user@example.com |
  Format-List Forwarding*Address,DeliverTo*

Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

Verdächtige Regeln werden dokumentiert und entfernt. Delegierungen, Send-as-Rechte und administrative Transportregeln werden separat geprüft.

6. Folgeopfer ermitteln und informieren

Message Trace und Auditdaten zeigen versendete Nachrichten. Interne und externe Empfänger werden informiert, bevor Links, Zahlungen oder weitere Konten betroffen sind. Bei verändertem Zahlungsverkehr erfolgt der Kontakt mit Bank, Buchhaltung und Geschäftspartnern über bekannte Kanäle. Weitere Schritte enthält der Beitrag zu Sofortmassnahmen bei Phishing und Hacking.

7. Ursache und Reichweite bestimmen

Abschliessend wird geklärt, ob AiTM, Device Code, bestätigte MFA oder Fernwartung beteiligt waren, welche SharePoint- oder OneDrive-Dateien abflossen, ob weitere Konten, Anwendungen oder Geräte registriert und ob Personendaten oder Geschäftsgeheimnisse betroffen sind. Ohne Ursachenanalyse bleibt die Lücke offen.

Praktische Checkliste für Microsoft-365-Administratoren

• Phishing-resistente Anmeldung für Administratoren, Finanzen, Geschäftsleitung und Helpdesk priorisieren.
• Notfallkonten getrennt halten, überwachen und regelmässig testen.
• Device Code Nutzung inventarisieren, blockieren oder begründet ausnehmen.
• Conditional Access in Report-only mit einer Pilotgruppe prüfen.
• Für sensible Ressourcen verwaltete Geräte verlangen und Token Protection nur mit kompatiblen Clients ausrollen.
• Externe Teams-Kommunikation, Fernwartungswerkzeuge, Helpdesk-Rückruf und Identitätsprüfung verbindlich regeln.
• E-Mail-Fluten, ungewöhnliche Anmeldungen, OAuth-Zustimmungen und Weiterleitungen alarmieren.
• Sitzungswiderruf, MFA-Bereinigung, Inbox Rules, Versandspuren und Endpoint-Isolation testen.
• Audit-Aufbewahrung und Zuständigkeiten vor dem Ernstfall klären.

Meine Empfehlung

MFA bleibt Pflicht, doch Passwort plus Push-App berücksichtigt moderne Angriffe zu wenig. Zuerst sollten privilegierte und finanzkritische Konten phishing-resistent werden. Danach folgen Device Code Kontrolle, verwaltete Geräte und Conditional Access. Token Protection braucht wegen ihrer Grenzen einen kontrollierten Rollout. Parallel benötigt der Helpdesk sichere Prozesse für unerwartete Teams-Kontakte.

Entscheidend ist das Zusammenspiel von starker Identität, vertrauenswürdigem Gerät, kontrollierter Sitzung, überwachter Kommunikation und einem Notfallplan für aktive Tokens und versteckte Persistenz.

FAQ