AiTM-Phishing in Microsoft 365 erkennen und verhindern: Sitzungscookies und Token-Diebstahl stoppen

Eine Mitarbeiterin meldet sich morgens über einen Link aus einer vermeintlichen Microsoft-365-Benachrichtigung an. Passwort und MFA-Bestätigung funktionieren wie gewohnt, der Zugriff erscheint erfolgreich. Wenige Minuten später legt ein Angreifer Posteingangsregeln an, durchsucht E-Mails und versendet Nachrichten unter ihrem Namen. Das Passwort wurde dabei möglicherweise nie abgegriffen. Stattdessen hat der Angreifer das Sitzungscookie oder Zugriffstoken der bereits bestätigten Anmeldung übernommen.

Genau das macht Adversary-in-the-Middle-Phishing, kurz AiTM, so gefährlich. Klassische MFA schützt den Anmeldevorgang, etwa durch eine App-Bestätigung oder einen Einmalcode. Bei AiTM sitzt der Angreifer jedoch zwischen Nutzer und echter Anmeldeseite. Er leitet Eingaben und MFA-Abfragen in Echtzeit weiter und erhält anschließend die authentifizierte Sitzung. Für Microsoft 365, Exchange Online, SharePoint oder andere verbundene Dienste kann diese Sitzung wie ein legitimer Zugriff aussehen.

Für IT-Teams und Mitarbeitende bedeutet das: Phishing-Schutz darf nicht beim Passwort und der MFA-Abfrage enden. Du brauchst phishing-resistente Anmeldeverfahren, sinnvoll konfigurierte Zugriffskontrollen, aussagekräftige Protokolle und einen eingeübten Ablauf für verdächtige Sitzungen.

Infografik zu AiTM-Phishing in Microsoft 365 erkennen und verhindern: Sitzungscookies und Token-Diebstahl stoppen (KI-generiert).

Was bei AiTM-Phishing technisch passiert

Bei einem klassischen Phishing-Angriff versucht die angreifende Person, Benutzername, Passwort und gegebenenfalls MFA-Code zu erbeuten. Bei AiTM-Phishing wird dagegen eine Proxy-Seite vorgeschaltet. Sie sieht einer Microsoft-Anmeldeseite oft sehr ähnlich und leitet die Eingaben im Hintergrund an den echten Microsoft-Dienst weiter.

Der typische Ablauf sieht so aus:

• Die Zielperson erhält eine E-Mail, Chat-Nachricht oder Kalenderanfrage mit einem Link zu einer täuschend echten Anmeldung.
• Die Phishing-Seite fordert Benutzername und Passwort an und übermittelt beides unmittelbar an Microsoft Entra ID.
• Microsoft fordert die konfigurierte MFA-Methode an.
• Die Zielperson bestätigt die MFA-Abfrage oder gibt einen Einmalcode ein.
• Der Angreifer fängt die erfolgreiche Sitzung ab und verwendet das ausgestellte Cookie oder Token weiter.
• Anschließend greift er auf Microsoft-365-Dienste zu, häufig über einen anderen Browser, ein anderes Land oder eine Cloud-Infrastruktur.

Wichtig ist die Abgrenzung: Nicht jede verdächtige MFA-Abfrage ist AiTM. MFA-Fatigue-Angriffe setzen auf viele unerwünschte Bestätigungsanfragen. Consent Phishing versucht, Nutzende zur Freigabe einer OAuth-Anwendung zu bewegen. Beide Varianten können ebenfalls zum Kontozugriff führen. Wie du bösartige App-Zustimmungen einordnest und begrenzt, erläutern wir im Beitrag „OAuth-Apps im Microsoft-365-Tenant absichern: Consent Phishing erkennen und verhindern“.

Woran du AiTM-Phishing erkennst

Für Mitarbeitende beginnt die Erkennung vor der Anmeldung. Entscheidend ist nicht nur das Aussehen einer Seite, sondern der gesamte Kontext: Warum kommt diese Nachricht jetzt? Welcher Dienst fordert die Anmeldung? Wohin führt der Link tatsächlich?

Typische Warnzeichen sind:

• Eine Nachricht erzeugt künstlichen Zeitdruck, etwa durch angeblich ablaufende Dateien, gesperrte Konten oder ausstehende Voicemail-Nachrichten.
• Der Link führt auf eine Domain, die Microsoft, dem eigenen Unternehmen oder einem bekannten Dienst nur ähnlich sieht.
• Die Anmeldeseite öffnet sich nach einem Link aus einer E-Mail, obwohl die Person bereits im Browser angemeldet ist.
• Die Seite fordert eine MFA-Bestätigung an, obwohl kein eigener Anmeldevorgang gestartet wurde.
• Nach erfolgreicher Anmeldung erscheint eine Fehlerseite, eine Weiterleitung oder eine unerwartete Aufforderung zur erneuten Eingabe.
• Die Nachricht stammt von einem bekannten Absender, passt aber sprachlich, zeitlich oder inhaltlich nicht zu dessen üblichem Verhalten.

Mitarbeitende sollten Microsoft 365 bevorzugt über bekannte Lesezeichen, den Unternehmensportal-Link oder eine etablierte Anwendung öffnen. Eine unerwartete MFA-Abfrage wird nie vorschnell bestätigt. Stattdessen wird sie abgelehnt und an das IT-Team gemeldet.

Auch die Absenderprüfung bleibt wichtig. Angreifer können kompromittierte Konten, ähnlich aussehende Domains oder manipulierte Antworten in bestehenden E-Mail-Verläufen nutzen. Maßnahmen wie SPF, DKIM und DMARC verhindern nicht jeden Angriff, erschweren aber Domain-Spoofing erheblich. Praxisdetails findest du in unserem Beitrag „DMARC im Unternehmen einführen: SPF, DKIM und Domain-Spoofing-Schutz richtig umsetzen“.

Warum klassische MFA allein nicht genügt

MFA bleibt unverzichtbar. Ein Passwort ohne zweiten Faktor bietet Angreifern viel zu wenig Widerstand. Doch nicht jede MFA-Methode schützt gleich gut vor AiTM.

Einmalcodes per SMS, TOTP-Codes aus Authenticator-Apps und Push-Bestätigungen können über eine Phishing-Proxy-Seite in Echtzeit abgefangen oder weitergeleitet werden. Der Faktor bestätigt dann zwar die echte Anmeldung bei Microsoft, aber im Kontext der vom Angreifer kontrollierten Sitzung.

Deutlich robuster sind phishing-resistente Methoden, insbesondere Passkeys und FIDO2-Sicherheitsschlüssel. Sie binden die Anmeldung kryptografisch an die echte Website. Eine gefälschte Domain kann diese Anmeldung nicht einfach für die Microsoft-Domain verwenden. Das verhindert nicht jeden denkbaren Kontoangriff, reduziert das Risiko erfolgreicher AiTM-Kampagnen aber entscheidend.

Bei der Einführung solltest du nicht nur die Technik verteilen. Kläre, welche Gruppen zuerst umgestellt werden müssen, wie Ersatzgeräte gehandhabt werden, wer Wiederherstellungsprozesse auslösen darf und wie privilegierte Konten abgesichert werden. Einen konkreten Einstieg bietet unser Ratgeber „Passkeys im Unternehmen einführen: Phishing-resistente Anmeldung mit Microsoft Entra ID“.

Conditional Access gezielt gegen Sitzungsmissbrauch einsetzen

Conditional Access in Microsoft Entra ID ist kein Ersatz für phishing-resistente Anmeldung. Richtig eingesetzt begrenzt es jedoch, von welchen Geräten, Standorten und Risikosituationen aus eine Sitzung nutzbar ist. Die Regeln sollten sich an Schutzbedarf und realen Arbeitsabläufen orientieren, nicht nur an einer möglichst langen Liste von Bedingungen.

Schutzmaßnahme	Nutzen gegen AiTM	Wichtiger Praxispunkt
Phishing-resistente MFA	Erschwert die Übernahme der Anmeldung durch Proxy-Seiten	Für Admins und besonders schützenswerte Konten priorisieren
Konforme oder verwaltete Geräte	Beschränkt Zugriffe auf kontrollierte Endgeräte	Ausnahmen dokumentieren und regelmäßig prüfen
Anmelderisiko und Benutzerrisiko	Erkennt auffällige Anmeldemuster und Kontosignale	Reaktionswege für riskante Ereignisse festlegen
Sitzungssteuerung	Reduziert die Dauer nutzbarer Sitzungen	Nicht so restriktiv einstellen, dass Teams Umgehungen suchen
Standort- und Netzwerkrichtlinien	Erschwert ungewöhnliche Zugriffe	Länderblockaden allein sind kein verlässlicher Schutz
Einschränkung älterer Authentifizierung	Schließt schwächere Protokolle und Umgehungswege	Vorher Abhängigkeiten und Altanwendungen erfassen

Besonders privilegierte Rollen verdienen eigene Regeln. Administrative Konten sollten nicht für E-Mail, Webrecherche oder normale Büroarbeit genutzt werden. Setze für sie starke Anmeldeverfahren, verwaltete Geräte, enge Sitzungsregeln und ein separates Administrationsmodell um.

Achte darauf, dass Conditional Access sorgfältig getestet wird. Nutze Testgruppen, dokumentiere Notfallzugänge und kontrolliere regelmäßig, ob diese Zugänge noch erforderlich und angemessen geschützt sind. Eine Regel, die nur auf dem Papier existiert oder im Incident deaktiviert werden muss, schafft keine belastbare Sicherheit.

Protokolle richtig auswerten

AiTM-Angriffe fallen häufig erst durch Folgeaktivitäten auf. Darum müssen IT-Teams nicht nur fehlgeschlagene Logins betrachten, sondern auch erfolgreiche Anmeldungen und auffällige Veränderungen im Konto.

Prüfe in den Microsoft-Entra-Anmeldeprotokollen insbesondere:

• Anmeldungen von ungewöhnlichen IP-Adressen, Regionen oder Internetprovidern.
• Wechsel von Geräten, Browsern oder Betriebssystemen innerhalb kurzer Zeit.
• Ungewohnte Anmeldungen nach einer MFA-Bestätigung.
• Riskante Benutzer- oder Anmeldeereignisse.
• Wiederholte fehlgeschlagene Anmeldungen vor einer erfolgreichen Sitzung.

Kontrolliere zusätzlich die Audit-Protokolle von Microsoft 365 und Exchange Online. Besonders relevant sind neu angelegte Posteingangsregeln, Änderungen an Weiterleitungen, Berechtigungsänderungen, hinzugefügte MFA-Methoden, neu registrierte Geräte sowie Änderungen an Anwendungen oder App-Zustimmungen.

Für die technische Einordnung gilt: Ein einzelnes Signal beweist selten einen Angriff. Eine Anmeldung aus einem Mobilfunknetz kann legitim sein. Treffen aber neue IP-Adresse, unbekannter Browser, Postfachweiterleitung und ungewöhnlicher Datenzugriff zusammen, musst du sofort handeln. Grundlagen für sinnvolle Erkennungsketten behandeln wir auch in „Angriffe früh erkennen: Logging und Monitoring“.

Sofortmaßnahmen bei Verdacht auf Token- oder Cookie-Diebstahl

Wenn eine Person eine verdächtige Anmeldeseite genutzt oder eine unerwartete MFA-Abfrage bestätigt hat, zählt Zeit. Warte nicht darauf, ob weitere Hinweise auftauchen.

• Sperre oder sichere das betroffene Konto entsprechend eurem Incident-Prozess.
• Widerrufe aktive Sitzungen und aktualisiere Anmeldetokens, damit gestohlene Sitzungen ungültig werden.
• Setze das Passwort zurück, auch wenn der Verdacht primär auf Sitzungdiebstahl besteht.
• Prüfe registrierte Authentifizierungsmethoden, Geräte, Wiederherstellungsinformationen und App-Zustimmungen.
• Untersuche Posteingangsregeln, externe Weiterleitungen, delegierte Zugriffe und kürzlich versendete E-Mails.
• Werte Anmelde- und Audit-Protokolle aus und sichere relevante Ereignisse für die Analyse.
• Informiere mögliche Empfänger bösartiger Nachrichten aus dem kompromittierten Konto.
• Suche nach weiteren Betroffenen, insbesondere wenn die Phishing-Nachricht intern weitergeleitet wurde.

Ein Passwortwechsel allein reicht nicht, wenn der Angreifer noch eine gültige Sitzung besitzt oder zusätzliche MFA-Methoden registriert hat. Ebenso wichtig ist die Ursachenanalyse: Welche Nachricht führte zur Anmeldung? War die Domain erreichbar? Haben andere Personen denselben Link erhalten? Welche Schutzregel hätte die Kette früher unterbrochen?

Awareness so gestalten, dass sie im Alltag wirkt

Mitarbeitende müssen keine Token-Formate analysieren können. Sie müssen aber verstehen, warum eine MFA-Bestätigung keine bloße Routinehandlung ist. Vermitteln solltest du vor allem drei Regeln: Nur Anmeldungen bestätigen, die selbst gestartet wurden. Dienste über bekannte Wege öffnen statt über E-Mail-Links. Verdächtige Situationen ohne Sorge vor Schuldzuweisung sofort melden.

Übungen sollten realistische Szenarien enthalten, etwa eine gefälschte Dokumentenfreigabe, eine angebliche Teams-Nachricht oder eine dringende Aufforderung zur Kontoüberprüfung. Nach der Übung gehört eine verständliche Auswertung dazu: Woran war der Angriff erkennbar, welche Meldestelle gilt und welche technischen Kontrollen greifen im Hintergrund? So entsteht keine reine Klickdisziplin, sondern belastbares Sicherheitsverhalten. Mehr dazu liest du in „Security Awareness im Team aufbauen“.

AiTM-Phishing lässt sich nicht durch eine einzelne Einstellung lösen. Wirksam wird der Schutz, wenn du Passkeys priorisierst, Conditional Access sauber konfigurierst, Protokolle aktiv überwachst und Mitarbeitende handlungsfähig machst. Passende Seminare und Termine findest du bei uns auf cmt.de.