Blog

Du betrachtest gerade MFA schützt die Anmeldung, nicht die Sitzung: Warum Session- und Token-Diebstahl 2026 zur echten Bedrohung für M365-Konten wird

MFA schützt die Anmeldung, nicht die Sitzung: Warum Session- und Token-Diebstahl 2026 zur echten Bedrohung für M365-Konten wird

Warum Session- und Token-Diebstahl 2026 zur echten Bedrohung für M365-Konten wird

Viele Unternehmen haben Multi-Faktor-Authentifizierung eingeführt und fühlen sich damit gut aufgestellt. MFA schützt Microsoft 365-Konten vor Passwort-Diebstahl – das stimmt. Was MFA nicht abdeckt, ist die Sitzung, die nach dem erfolgreichen Login entsteht. Genau dort setzen Angreifer 2026 zunehmend an: mit Session-Token-Diebstahl statt klassischem Passwort-Raten. Dieser Artikel erklärt, warum das ein grundlegender Unterschied ist – und was Ihr Unternehmen dagegen tun kann.

Der blinde Fleck hinter dem Login-Bildschirm

MFA schützt den Anmeldemoment. Kennt ein Angreifer Ihr Passwort, aber nicht den zweiten Faktor, kommt er nicht rein. Das ist ein echter Sicherheitsgewinn, der nicht kleingeredet werden sollte.

Das Problem beginnt danach. Sobald sich ein Nutzer erfolgreich bei Microsoft 365 angemeldet hat, stellt das System ein Session-Token aus. Dieses Token funktioniert wie ein digitaler Ausweis: Es signalisiert dem Browser oder der App, dass dieser Nutzer korrekt authentifiziert wurde und arbeiten darf. Bei jeder weiteren Aktion prüft der Server das Token – nicht erneut das Passwort oder den zweiten Faktor.

Wer dieses Token stiehlt, braucht weder Passwort noch MFA-Code. Er übernimmt die laufende Sitzung direkt.

Wie Angreifer an Session-Tokens gelangen

Es gibt mehrere technische Wege, über die Tokens abgegriffen werden – ohne dass jemals ein Login-Versuch stattfindet.

Adversary-in-the-Middle-Phishing (AiTM)

Beim AiTM-Angriff schalten Angreifer einen Proxy-Server zwischen den Nutzer und den echten Microsoft-Login. Der Nutzer sieht eine täuschend echte Login-Seite, gibt Passwort und MFA-Code ein, und der Proxy leitet alles an Microsoft weiter. Microsoft stellt ein gültiges Session-Token aus – der Proxy fängt es ab. Der Nutzer ist erfolgreich eingeloggt und merkt nichts. Der Angreifer hat das Token und kann die Sitzung parallel übernehmen.

Device-Code-Phishing

Hier bringen Angreifer das Opfer dazu, einen sogenannten Device-Code auf der echten Microsoft-Seite einzugeben. Dieser Mechanismus ist eigentlich für Geräte ohne Browser gedacht – Drucker, Smart-TVs und ähnliches. Angreifer missbrauchen ihn, indem sie einen Code generieren und das Opfer per E-Mail oder Teams-Nachricht dazu bringen, ihn einzugeben. Das Ergebnis: Ein gültiges OAuth-Token landet beim Angreifer, ohne dass ein Passwort übertragen wurde.

Das Opfer wird auf eine legitim aussehende Seite gelockt, die Berechtigungen für eine scheinbar harmlose App anfordert. Stimmt der Nutzer zu, erhält die Angreifer-App ein OAuth-Token mit Zugriff auf Postfach, Kalender oder SharePoint-Daten. MFA spielt dabei keine Rolle – der Nutzer meldet sich gar nicht neu an, sondern erteilt lediglich einer App Zugriff.

Die EvilTokens-Kampagne: Ein konkretes Beispiel aus 2026

Im März 2026 dokumentierte das Sicherheitsunternehmen Huntress eine Angriffskampagne, die unter dem Namen EvilTokens bekannt wurde. Dabei wurden mindestens 344 Organisationen kompromittiert – ausschließlich über Token-Diebstahl, ohne dass ein einziges Passwort geknackt wurde. Alle betroffenen Konten hatten MFA aktiviert.

Das zeigt: MFA-Aktivierung allein bietet keinen Schutz gegen diese Angriffskategorie. Die Angreifer umgingen den Login-Prozess und arbeiteten ausschließlich mit gestohlenen Session-Tokens.

Warum das für Mittelstandsunternehmen besonders relevant ist

Größere Konzerne verfügen oft über spezialisierte Security-Operations-Center, die anomale Token-Nutzung erkennen. In Unternehmen mit 40 bis 80 Arbeitsplätzen fehlt diese Kapazität in der Regel. Gleichzeitig sind Microsoft-365-Postfächer im Mittelstand attraktive Ziele: Dort laufen Bestellungen, Zahlungsfreigaben, Lieferantenkommunikation und interne Entscheidungen zusammen.

Ein kompromittiertes Geschäftsführer-Postfach, das über ein gestohlenes Token zugänglich ist, ermöglicht Business-Email-Compromise – ohne jede Spur im Login-Protokoll. Kein fehlgeschlagener Login, kein MFA-Alert, keine auffällige Passwortänderung.

Wie eine mehrschichtige Schutzstrategie aussieht

Da MFA die Sitzungsebene nicht absichert, braucht es zusätzliche Maßnahmen. Keine davon ersetzt MFA – sie ergänzen es.

Erkennung verdächtiger E-Mails vor dem Klick

Ein erheblicher Teil der Token-Angriffe beginnt mit einer Phishing-Mail. Systeme wie INKY analysieren eingehende E-Mails auf Merkmale, die auf AiTM-Phishing oder Device-Code-Missbrauch hindeuten, und können verdächtige Nachrichten kennzeichnen oder isolieren, bevor der Nutzer darauf reagiert. Keine Garantie – aber eine deutlich reduzierte Angriffsfläche.

Automatisierte Kontoüberwachung für M365

Moderne Kontoüberwachung für Microsoft 365 wertet Anmeldeprotokolle und Nutzungsmuster aus. Wird ein Token plötzlich aus einem unbekannten Land genutzt, tauchen ungewöhnliche Mailweiterleitungsregeln auf oder greift ein Konto innerhalb kurzer Zeit auf viele Postfächer zu, schlägt das System an. Eine Regel kann das Konto sperren und alle aktiven Sitzungen beenden – automatisiert, ohne manuellen Eingriff.

Das ist der entscheidende Unterschied zu einem reinen MFA-Setup: MFA prüft den Eintrittspunkt. Kontoüberwachung prüft das Verhalten danach.

Conditional Access und Token-Bindung

Microsoft Entra ID bietet Conditional-Access-Richtlinien, mit denen Tokens an bestimmte Bedingungen geknüpft werden können. Eine Regel kann etwa verlangen, dass ein Token nur von einem registrierten, compliant bewerteten Gerät genutzt werden darf. Versucht jemand, das Token von einem fremden Gerät einzusetzen, kann eine Regel sperren, bevor Schaden entsteht. In vielen M365-Umgebungen im Mittelstand ist diese Konfiguration nicht aktiv – obwohl sie in bestimmten Lizenzplänen bereits enthalten ist.

Token-Lebenszeiten und Sitzungsbeschränkungen

Tokens haben konfigurierbare Gültigkeitsdauern. Kürzere Lebenszeiten reduzieren das Zeitfenster, in dem ein gestohlenes Token nutzbar ist. Kein vollständiger Schutz, aber ein sinnvoller Baustein.

Die Ereigniskette: Was passiert, wenn ein Angriff erkannt wird

Eine gut aufgestellte M365-Sicherheitsarchitektur funktioniert in Schichten. Eine realistische Abfolge sieht so aus:

  1. Verdächtige E-Mail trifft ein. INKY erkennt Merkmale einer AiTM-Phishing-Mail und kennzeichnet sie, bevor der Nutzer klickt.
  2. Signal geht an die Kontoüberwachung. Statt ein manuelles Ticket zu erzeugen, wird das Signal automatisiert verarbeitet.
  3. Anomales Verhalten wird erkannt. Hat der Nutzer doch geklickt und wurde ein Token kompromittiert, erkennt die Kontoüberwachung ungewöhnliche Aktivitäten im Postfach.
  4. Konto wird gesperrt, Sitzungen werden beendet. Eine automatisierte Regel sperrt das Konto und beendet alle aktiven Sitzungen – einschließlich der des Angreifers.

Diese Kette funktioniert nur, wenn alle Schichten konfiguriert und aktiv überwacht werden. Eine einzelne Maßnahme reicht nicht.

Was das für Ihre M365-Umgebung bedeutet

MFA aktiviert zu haben ist ein wichtiger Schritt. Der nächste ist zu prüfen, was nach dem Login passiert. Konkret:

  • Sind Conditional-Access-Richtlinien aktiv und korrekt konfiguriert?
  • Werden Anmeldeprotokolle und Sitzungsaktivitäten automatisiert ausgewertet?
  • Gibt es Regeln, die auf anomales Postfachverhalten reagieren?
  • Sind Token-Lebenszeiten sinnvoll begrenzt?
  • Ist Ihr E-Mail-Gateway in der Lage, AiTM-Phishing-Muster zu erkennen?

Viele Mittelstandsunternehmen können diese Fragen nicht mit Sicherheit beantworten – nicht weil sie nachlässig sind, sondern weil Microsoft 365 ein komplexes System mit vielen Stellschrauben ist.

BREiHOF iT GmbH begleitet Unternehmen in der Rhein-Neckar-Region seit 1998 bei genau diesen Fragen. Wenn Sie wissen möchten, wie Ihre M365-Umgebung in Bezug auf Session-Sicherheit aufgestellt ist, bieten wir ein kostenloses 15-Minuten-Audit an, in dem wir gemeinsam die wichtigsten Konfigurationspunkte durchgehen.

Fazit

MFA bleibt ein wichtiger und notwendiger Schutz. Wer aber glaubt, damit sei die Sicherheit von Microsoft 365 abgedeckt, übersieht eine wachsende Angriffskategorie. Session-Token-Diebstahl umgeht den Login-Moment. Angreifer brauchen kein Passwort und keinen MFA-Code, wenn sie direkt an das Token gelangen. Die Antwort darauf ist keine Einzelmaßnahme, sondern eine Kombination aus E-Mail-Erkennung, Kontoüberwachung, Conditional Access und durchdachten Token-Richtlinien. Wer diese Schichten nicht aktiv betreibt, verlässt sich auf einen Schutz, der nur an der Eingangstür steht.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Passwort-Diebstahl und Session-Token-Diebstahl?
Beim Passwort-Diebstahl versucht ein Angreifer, sich mit gestohlenen Zugangsdaten anzumelden. MFA blockiert diesen Versuch, weil der zweite Faktor fehlt. Beim Session-Token-Diebstahl übernimmt der Angreifer eine bereits bestehende, authentifizierte Sitzung. MFA wurde in diesem Fall bereits erfolgreich durchlaufen – es gibt keinen neuen Login-Versuch, den MFA abfangen könnte.

Kann ich Session-Token-Diebstahl in meinen M365-Protokollen sehen?
Nicht ohne weiteres. Ein gestohlenes Token erzeugt keinen fehlgeschlagenen Login-Eintrag. Anomalien wie ungewöhnliche Standorte, unbekannte Geräte oder untypische Aktivitätsmuster können in den Entra-ID-Protokollen sichtbar sein – aber nur, wenn jemand aktiv danach sucht oder eine automatisierte Überwachung eingerichtet ist.

Was ist Device-Code-Phishing und wie erkenne ich es?
Device-Code-Phishing nutzt einen legitimen Microsoft-Mechanismus für Geräte ohne Browser. Angreifer senden eine E-Mail oder Nachricht mit der Aufforderung, einen Code auf der echten Microsoft-Seite einzugeben. Verdächtig ist jede unaufgeforderte Aufforderung dieser Art – besonders wenn sie per E-Mail oder Teams-Nachricht kommt und Dringlichkeit suggeriert.

Schützt Conditional Access vor Token-Diebstahl?
Conditional Access kann das Risiko erheblich reduzieren. Sind Tokens an registrierte, compliant bewertete Geräte gebunden, ist ein gestohlenes Token auf einem fremden Gerät deutlich weniger nutzbar – eine Regel kann in diesem Fall sperren. Conditional Access ist aber kein absoluter Schutz, sondern eine wichtige Schicht in einem mehrschichtigen Sicherheitskonzept.

Muss ich für diese Schutzmaßnahmen zusätzliche Microsoft-Lizenzen kaufen?
Nicht unbedingt. Viele Conditional-Access-Funktionen sind in Microsoft 365 Business Premium bereits enthalten. Ob Ihre aktuelle Lizenz die benötigten Funktionen abdeckt und ob diese korrekt konfiguriert sind, lässt sich am besten in einem kurzen Audit klären.

Was war die EvilTokens-Kampagne?
EvilTokens war eine im März 2026 vom Sicherheitsunternehmen Huntress dokumentierte Angriffskampagne, bei der mindestens 344 Organisationen über Token-Diebstahl kompromittiert wurden. Alle betroffenen Konten hatten MFA aktiviert. Die Kampagne zeigt exemplarisch, dass MFA allein keinen ausreichenden Schutz gegen sitzungsbasierte Angriffe bietet.

Was bringt ein M365-Sicherheits-Audit konkret?
Ein Audit prüft die wichtigsten Konfigurationspunkte Ihrer M365-Umgebung: Conditional-Access-Richtlinien, Token-Lebenszeiten, aktive Sitzungsüberwachung, Postfachregeln und E-Mail-Schutz. Das Ergebnis ist ein klares Bild, wo Ihre Umgebung gut aufgestellt ist und wo Handlungsbedarf besteht – ohne dass Sie dafür tage- oder wochenlange Projekte einplanen müssen.