Ein aktueller Fall aus Brasilien zeigt, wie ernst das Thema Session-Token-Diebstahl mittlerweile geworden ist. Die Malware KREMLIN kapert Chrome und Edge, klaut Zugangsdaten und vor allem Session-Tokens – und hebelt damit MFA komplett aus. Für Sysadmins in Microsoft-Umgebungen ist das kein exotisches Randthema mehr, sondern eine reale Bedrohung für Entra ID und Microsoft 365.
Der KREMLIN-Fall: Session-Hijacking in Chrome und Edge
Sicherheitsforscher von Elastic Security Labs haben die Kampagne unter dem Namen REF9334 dokumentiert. Seit mindestens Mai 2025 verteilt die Gruppe eine Malware namens KREMLIN, getarnt als Rechnung oder Bankdokument. Nach mehrstufigem JavaScript-Loading und einem C++-Installer landet am Ende eine bösartige Browser-Extension auf dem System – installiert über eine Technik, die die Chromium-Integritätsprüfung (Secure Preferences, HMAC-Signaturen) austrickst.
Besonders bemerkenswert: Die Angreifer nutzen Ethereum-Smart-Contracts als Dead-Drop-Resolver, um C2-Domains dynamisch zu aktualisieren. Dadurch lässt sich die Infrastruktur kaum abschalten. Die Extension selbst greift über die WebRequest-API auf Cookies, Session-Storage und Local-Storage zu, macht Screenshots und exfiltriert komplette HTML-Seiten – alles getarnt als harmlose CSS-Requests. Laut Elastic waren über 1.500 Systeme betroffen, mehr als 98 Prozent davon in Brasilien. Details dazu liefert der Originalbericht bei The Hacker News.
Was ist Session-Token-Diebstahl technisch gesehen?
Bei einer klassischen Anmeldung prüft Entra ID Benutzername, Passwort und MFA-Faktor. Anschließend erhält der Browser ein Session-Cookie beziehungsweise einen Access- und Refresh-Token. Dieser Token ist der eigentliche Sitzungsausweis – solange er gültig ist, muss sich niemand erneut authentifizieren. Genau hier setzt Token-Diebstahl an: Malware liest den Token direkt aus dem Browser-Speicher oder aus Cookies aus und überträgt ihn an den Angreifer. Der kann den Token anschließend in einem eigenen Browser einspielen und übernimmt damit eine bereits vollständig authentifizierte Sitzung, ganz ohne Passwort und ohne erneute MFA-Abfrage.
Warum klassisches MFA hier versagt
MFA schützt den Login-Vorgang, nicht die Sitzung danach. Wurde der Token einmal gestohlen, ist die Multi-Faktor-Prüfung bereits erfolgreich durchlaufen und für den Angreifer irrelevant. Deshalb sprechen Security-Teams hier auch von „Adversary in the Middle“ beziehungsweise Pass-the-Cookie-Angriffen. Zudem wirken solche Angriffe oft unauffällig, weil die Anmeldung aus Sicht von Entra ID technisch gültig aussieht – lediglich IP-Adresse, Standort oder Gerätefingerabdruck weichen vom Original ab. Wer sich ausschließlich auf klassisches MFA verlässt, hat hier eine echte Schutzlücke.
Entra ID als Schutzschicht: Token Protection, CAE und Conditional Access
Microsoft hat genau für dieses Szenario mehrere Bausteine in Entra ID eingebaut. Token Protection bindet Session-Tokens kryptografisch an das Gerät, auf dem sie ausgestellt wurden. Wird ein Token auf ein anderes Gerät kopiert, ist er dort ungültig. Aktuell greift das vor allem bei Outlook, Teams und weiteren Office-Apps, die den entsprechenden Client unterstützen.
Continuous Access Evaluation (CAE) ergänzt das um eine laufende Neubewertung von Signalen wie Kontosperrung, Passwortänderung oder Standortwechsel – nahezu in Echtzeit statt nur beim nächsten Token-Refresh. Eine passende Conditional-Access-Richtlinie mit Token Protection lässt sich per Microsoft Graph PowerShell anlegen:
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$params = @{
DisplayName = "Require Token Protection - Exchange und Teams"
State = "enabledForReportingButNotEnforced"
Conditions = @{
Applications = @{ IncludeApplications = @("Office365") }
Users = @{ IncludeGroups = @("") }
}
SessionControls = @{
SignInFrequency = @{ IsEnabled = $true; Type = "days"; Value = 1 }
}
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params Wichtig: Neue Richtlinien immer erst im Report-Only-Modus testen, bevor du sie erzwingst. Wer sich generell mit riskanten Anmeldungen beschäftigt, sollte zudem einen Blick auf Entra ID Password Protection und Risky Sign-ins werfen – das ergänzt Token-Schutz um die Login-Ebene. Details zu Token Protection und CAE liefert die Microsoft-Learn-Dokumentation.
Browser-Hardening im Unternehmen
Da KREMLIN gezielt über manipulierte Extensions in Chrome und Edge einsteigt, ist Browser-Hardening die zweite Verteidigungslinie. Über Intune lässt sich per ADMX-Vorlage steuern, welche Extensions installiert werden dürfen. Die zentrale Richtlinie heißt ExtensionInstallAllowlist beziehungsweise ExtensionInstallBlocklist und lässt sich auch per PowerShell über Intune-Konfigurationsprofile ausrollen:
# Beispiel: Registry-Policy für Edge, per Intune-Profil verteilt
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" `
-Name "ExtensionInstallBlocklist" -Value "*" -Type MultiString
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" `
-Name "ExtensionInstallAllowlist" -Value @("","") -Type MultiString Sinnvoll ist außerdem, den Entwicklermodus für Extensions in Chrome und Edge unternehmensweit zu deaktivieren, da genau diese Funktion in der KREMLIN-Kampagne zum Umgehen der Secure-Preferences-Prüfung missbraucht wurde. Zusätzlich hilft App-Bound Encryption (bereits Standard in aktuellen Chrome- und Edge-Versionen), gespeicherte Cookies und Tokens stärker gegen Auslesen abzusichern. Wer Screenshot- und Sharing-Funktionen im Browser dokumentieren möchte, findet dazu auch die Anleitung zu Screenshots in Microsoft Edge nützlich, um Nutzer für ungewöhnliche Extension-Popups zu sensibilisieren.
Erkennung und Reaktion
Selbst mit gutem Hardening bleibt Erkennung Pflicht. Microsoft Defender for Endpoint erkennt bekannte Indikatoren wie DLL-Sideloading über legitime Binaries – genau die Technik, mit der KREMLIN den SentinelOne-Prozess missbraucht. Zusätzlich solltest du in Entra ID regelmäßig Risky Sessions und Sign-in-Logs auswerten, insbesondere ungewöhnliche Token-Replay-Muster wie identische Session-IDs von verschiedenen IP-Adressen. Eine einfache KQL-Abfrage für Log Analytics beziehungsweise Sentinel sieht so aus:
SigninLogs
| where TimeGenerated > ago(1d)
| where RiskLevelDuringSignIn in ("high", "medium")
| summarize Count = count() by UserPrincipalName, AppDisplayName, IPAddress, Location
| sort by Count descDa KREMLIN und ähnliche Toolkits oft auch klassische C2-Kanäle wie Messenger-Dienste zur Nachsteuerung nutzen, lohnt sich zusätzlich ein Blick auf C2-Kommunikation über Messenger-Apps – ein wachsendes Muster bei aktuellen Malware-Kampagnen. Kommt es trotzdem zum Vorfall, hilft ein vorbereiteter Incident-Response-Plan, um Token-Revocation, Passwort-Reset und Forensik strukturiert abzuarbeiten.
Praxis-Checkliste gegen Session-Hijacking
Sofortmaßnahmen: Token Protection für unterstützte Apps aktivieren, Sign-in-Frequency in Conditional Access verschärfen, Extension-Whitelisting per Intune ausrollen, Entwicklermodus für Browser-Extensions sperren. Langfristig: CAE flächendeckend nutzen, Defender for Endpoint mit aktuellen Indikatoren pflegen, Sign-in-Logs regelmäßig auswerten, Mitarbeiter für verdächtige Rechnungs- und Dokument-Anhänge sensibilisieren. Zudem solltest du bei jedem Verdacht auf Token-Diebstahl sofort alle Refresh-Tokens des betroffenen Kontos widerrufen – per Revoke-MgUserSignInSession in Microsoft Graph PowerShell.
Fazit
Session-Token-Diebstahl wird 2026 vom Nischenthema zur Pflichtaufgabe für M365-Admins. Malware wie KREMLIN zeigt eindrücklich, dass klassisches MFA allein nicht mehr ausreicht, sobald der Angreifer bereits eine gültige Sitzung besitzt. Wer Token Protection, CAE und Browser-Hardening konsequent kombiniert und Sign-in-Logs im Blick behält, schließt genau die Lücke, die reines Passwort- und MFA-Denken offenlässt.
FAQ zu Session-Token-Diebstahl
Was ist Session-Token-Diebstahl genau?
Dabei liest Malware den Session-Token oder das Cookie einer bereits authentifizierten Sitzung aus dem Browser aus und überträgt ihn an den Angreifer, der damit ohne erneute Anmeldung Zugriff erhält.
Hilft MFA gegen Session-Token-Diebstahl?
Nur bedingt. MFA schützt den Anmeldevorgang, nicht die bereits laufende Sitzung. Ist der Token gestohlen, ist die MFA-Prüfung bereits erfolgt und wirkungslos.
Wie erkenne ich Session-Token-Diebstahl in Entra ID?
Auffällig sind identische Session-Tokens von unterschiedlichen IP-Adressen, plötzliche Standortwechsel innerhalb einer Sitzung sowie Risky-Sign-in-Einträge mit mittlerem oder hohem Risikolevel im Sign-in-Log.
Wie kann ich einen gestohlenen Session-Token widerrufen?
Über Microsoft Graph PowerShell lässt sich mit Revoke-MgUserSignInSession die gesamte Sitzung eines Nutzers beenden, sodass alle ausgestellten Refresh-Tokens ungültig werden und eine erneute Anmeldung nötig ist.