Lautloser und unauffindbarer Erstzugriff ist der Grundstein für einen erfolgreichen Cyberangriff. MFA wurde entwickelt, um unbefugten Zugriff zu verhindern, aber Angreifer entwickeln ständig neue Techniken, um diese Schutzmaßnahmen zu umgehen.
Die Forscher von Varonis Threat Labs haben Techniken aufgedeckt, die von Angreifern zur Umgehung der MFA mit gestohlenen Browser-Cookies eingesetzt werden. Durch den Einsatz maßgeschneiderter bösartiger Browser-Erweiterungen und Automatisierungsskripte können Angreifer Authentifizierungs-Cookies extrahieren und wiederverwenden, um sich als Benutzer auszugeben, ohne dass sie Anmeldedaten benötigen, und dabei die Persistenz zu wahren.
Bedrohungsakteure verwenden oft Infostealer, um Authentifizierungs-Token direkt vom Rechner eines Opfers zu extrahieren oder sie direkt über Dark Markets zu kaufen, sodass die Angreifer aktive Cloud-Sitzungen kapern können, ohne die MFA auszulösen. Indem diese Cookies eingeschleust werden, während das Betriebssystem, der Browser und das Netzwerk des Opfers nachgeahmt werden, können Angreifer die Conditional Access Policies (CAPs) umgehen und sich dauerhaften Zugriff verschaffen.
Der Proof-of-Concept demonstriert, wie ein Session-Hijacking unbefugten Zugriff auf Microsoft 365-Anwendungen, einschließlich Outlook und Teams, gewähren kann, was weitere Erkundungen und die Ausweitung von Privilegien ermöglicht.
Wir behandeln mehrere Schlüsselpunkte in unserer Forschung:
Infostealer-Malware hat sich zu einem gefürchteten Gegner entwickelt, der es versteht, sensible Daten, einschließlich Authentifizierungs-Cookies, zu entwenden. Diese bösartigen Programme dringen in Systeme ein, um Anmeldeinformationen, Sitzungscookies und Authentifizierungstoken zu stehlen, die dann an von Cyberkriminellen kontrollierte Remote-Server gesendet werden.
Mit gestohlenen Cookies können Angreifer aktive Benutzersitzungen kapern, sich als legitime Benutzer ausgeben und die MFA vollständig umgehen. Einfach ausgedrückt: Sie stehlen Ihre Identität.
Die meisten Infostealer verwenden die gestohlenen Daten nicht direkt. Stattdessen arbeiten sie innerhalb eines Malware-as-a-Service-Modells (MaaS), bei dem verschiedene Akteure spezialisierte Rollen übernehmen. Diese Rollen können Folgendes umfassen:
Sobald sie verkauft sind, ermöglichen gestohlene Authentifizierungs-Cookies Angreifern, sich als das Opfer anzumelden und dabei häufig die MFA zu umgehen. Diese Technik, bekannt als „Session Hijacking“, wird häufig für Unternehmensangriffe, Finanzbetrug und Spionage ausgenutzt.
In der sich ständig weiterentwickelnden Landschaft des Session Hijacking setzen Angreifer verschiedene Techniken ein, um Authentifizierungs-Cookies zu stehlen, wodurch sie die MFA umgehen und sich als legitime Benutzer ausgeben können. Infostealer, Malware-Betreiber und fortgeschrittene Phishing-Kampagnen nutzen den Diebstahl von Cookies als primären Angriffsvektor.
AITM-Phishing-Angriffe gehen über den herkömmlichen Diebstahl von Anmeldedaten hinaus, indem sie Authentifizierungstoken und Sitzungscookies in Echtzeit abfangen. Angreifer verwenden Reverse-Proxy-Tools (z. B. Evilginx, Modlishka, Muraena), um zwischen dem Opfer und dem legitimen Authentifizierungsdienst (z. B. Microsoft 365, Google) zu agieren.
Wenn sich das Opfer anmeldet, erfasst der Proxy die Anmeldedaten, MFA-Token und Sitzungscookies, sodass der Angreifer die MFA umgehen und die Sitzung kapern kann, ohne das Passwort des Benutzers erneut zu benötigen. Diese Technik wird häufig verwendet, um Cloud-Konten zu kompromittieren und moderne Authentifizierungsmechanismen zu umgehen.
Infostealer nutzen die Tatsache aus, dass Browser Cookies während aktiver Sitzungen entschlüsseln und sie für einen schnellen Zugriff im Arbeitsspeicher ablegen. Malware kann Code in laufende Browserprozesse einschleusen (z. B. chrome.exe, msedge.exe), um diesen Speicherbereich zu lesen und Cookies im Klartext zu extrahieren. Dieser Ansatz umgeht die Notwendigkeit, Cookies von der Festplatte zu entschlüsseln, da er während der aktiven Nutzung nach der Entschlüsselung auf sie zugreift.
Bösartige Browser-Erweiterungen ermöglichen Angreifern den direkten Zugriff auf Authentifizierungs-Cookies und Sitzungs-Token, indem sie im Sicherheitskontext des Browsers operieren. Diese Erweiterungen, die oft als legitime Tools getarnt sind, fordern übermäßige Berechtigungen an, die es ihnen ermöglichen, mit Websitzungen zu interagieren, Seiteninhalte zu ändern und gespeicherte Authentifizierungsdaten zu extrahieren. Einmal installiert, können sie auf die Speicher-API des Browsers zugreifen, Netzwerkanfragen abfangen oder bösartiges JavaScript in aktive Sitzungen einschleusen, um Echtzeit-Sitzungscookies zu stehlen.
Im Gegensatz zu herkömmlicher Malware ist keine Prozessinjektion oder Festplattenentschlüsselung erforderlich, was diese Technik auf Endpoint-Ebene schwerer erkennbar macht. Gestohlene Authentifizierungstokens werden auf den Server des Angreifers exfiltriert, wo sie erneut abgespielt werden können, um MFA zu umgehen und sich als das Opfer auszugeben.
Normalerweise speichern Browser Erweiterungen unter folgendem Pfad (Chrome):
Benutzerdefinierte Browser-Erweiterungen, die nicht signiert sind, können im aktivierten Entwicklermodus gestartet und dann geladen werden.
Browser speichern Authentifizierungs-Cookies in verschlüsselten SQLite-Datenbanken, um die Sitzung aufrechtzuerhalten und gleichzeitig sensible Benutzerdaten zu schützen. Angreifer können diese Cookies jedoch extrahieren und entschlüsseln, indem sie sich sowohl die gespeicherte Cookie-Datenbank als auch den zu ihrer Sicherung verwendeten Verschlüsselungsschlüssel beschaffen.
Die Methode variiert je nach Betriebssystem und Browser-Sicherheitsmodell, wobei Windows auf DPAPI-Verschlüsselung setzt, während Linux und macOS systemspezifische Schlüsselbundmechanismen verwenden.
Zum Beispiel:
Unter Windows speichern Chromium-basierte Browser (Chrome, Edge, Brave usw.) Authentifizierungs-Cookies in User Data/.../Network/Cookies, die Haupt-SQLite-Datenbank enthält AES-verschlüsselte CookiesLocal State → Speichert den AES-Verschlüsselungsschlüssel, der seinerseits mit der WindowsData Protection API (DPAPI) verschlüsselt wird
Da DPAPI die Verschlüsselung an das Benutzerprofil und den Computer bindet, können Angreifer Cookies außerhalb des Systems des Opfers nicht einfach entschlüsseln. Um dies zu umgehen, müssen Infostealer entweder:
Entschlüsseln des Blobs mithilfe der DPAPI
Wenn Angreifer ein Gerät kompromittieren, priorisieren sie Cookies nach ihrem Potenzial für weitere Angriffe. Der Wert der gestohlenen Cookies hängt sowohl von den Motiven der Angreifer als auch von der Marktnachfrage ab. In den meisten Fällen sind die wertvollsten Cookies diejenigen, die langfristigen Zugang zu hochwertigen Konten bieten oder tiefgehende Möglichkeiten der Nachnutzung ermöglichen.
Sitzungscookies, die mit Konten in sozialen Medien (z. B. Facebook, Instagram, Twitter) verknüpft sind, können lukrativ sein, insbesondere wenn das Konto eine große Anhängerschaft, geschäftlichen Einfluss oder Zugang zu Werbekonten hat. Ihr Nutzen hängt jedoch vom Kontostand und dem Wiederverkaufswert ab.
Andererseits sind Cookies von aktiven Enterprise Cloud-Sitzungen wie Microsoft 365, Google Workspace oder AWS oft attraktiver für eine gezielte Nachnutzung. Eine gekaperte Unternehmenssitzung kann es Angreifern ermöglichen, auf interne E-Mails zuzugreifen, sensible Daten zu exfiltrieren, Privilegien zu erweitern oder sich sogar seitlich durch ein ganzes Unternehmensnetzwerk zu bewegen, was zu einer vollständigen Kompromittierung des Unternehmens führen kann.
Diese Untersuchung konzentriert sich auf ESTSAUTH und ESTSAUTHPERSISTENT, zwei wichtige Authentifizierungs-Cookies, die von Azure Entra ID (früher AAD) verwendet werden. Diese Cookies verwalten authentifizierte Cloud-Sitzungen und ermöglichen den Zugriff auf Microsoft 365, das Azure-Portal und andere Unternehmensanwendungen.
Durch das Kapern dieser Sitzungstoken können Angreifer die MFA umgehen, sich als Benutzer ausgeben und sich lateral in Cloud-Umgebungen bewegen, was sie zu einem der wertvollsten Ziele für Infostealer und Bedrohungsakteure macht.
Authentifizierungs-Cookies anderer Cloud-Anbieter
Haftungsausschluss: Unser Artikel konzentriert sich hauptsächlich auf Cookies, die mit der Azure-Authentifizierung zusammenhängen, aber die geteilten Techniken und Ansätze können auch auf andere Cloud-Plattformen und -Dienste angewendet werden, die in der obigen Tabelle aufgeführt sind.Praktische Ergebnisse können je nach Zielumgebung und deren Abwehrmaßnahmen variieren, da jeder Dienst über eine eigene Cookie-Architektur, Sitzungsverwaltung und Sicherheit verfügt.
Bei der Webauthentifizierung von Azure Entra ID sind ESTSAUTH und ESTSAUTHPERSISTENT wichtige Sitzungstoken, die als Browser-Cookies gespeichert werden und die authentifizierte Sitzung des Benutzers darstellen:
Diese Cookies spielen eine entscheidende Rolle im Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit von Azure Entra ID. Sie tragen eine Art von Sitzungsnachweis, der bestätigt, dass der Benutzer sich kürzlich authentifiziert hat und, falls zutreffend, die MFA-Anforderungen erfüllt hat. Beispielsweise kann Azure Entra ID nach einer erfolgreichen Authentifizierung ein ESTSAUTHPERSISTENT-Cookie setzen, wenn der Benutzer auf „Ja“ geklickt hat, um angemeldet zu bleiben. Bei späteren Anmeldungen ermöglicht das Vorhandensein dieses Cookies Azure Entra ID, den Benutzer sofort ohne eine weitere MFA-Aufforderung zu authentifizieren. Mit anderen Worten: Das Cookie dient als Nachweis dafür, dass „dieser Benutzer bereits eine MFA in diesem Browser durchgeführt hat, also nicht erneut dazu aufgefordert werden soll“, und gewährt sofortigen Zugriff.
Zusammenfassend lässt sich sagen, dass die ESTSAUTH(PERSISTENT)-Tokens im Wesentlichen „Schlüssel zum Königreich“ für diese Benutzersitzung sind – sie belegen, dass die MFA umgangen wurde, und ermöglichen fortlaufenden Zugriff. Wenn ein Angreifer diese Tokens erlangt, kann er sich als Benutzer ausgeben und den gesamten Anmeldevorgang (einschließlich MFA) umgehen, da Azure Entra ID die Sitzung als bereits authentifiziert behandelt. Die folgenden Abschnitte erläutern, wie Angreifer dies erreichen und wie Sie sich dagegen verteidigen können.
Diese Cookies werden lokal in der SQLite-Datenbank von Chrome gespeichert, die sich an folgendem Ort befindet:
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies
Chrome verschlüsselt Cookie-Werte mithilfe von DPAPI, das die Verschlüsselung an das Windows-Profil des aktuellen Benutzers bindet.
In diesem Proof-of-Concept haben wir einen persistenten Cookie-Stealer erstellt, der Authentifizierungscookies aus einer aktiven Browsersitzung extrahiert und sie jedes Mal exfiltriert, wenn sich das Opfer beim Authentifizierungsportal von Microsoft anmeldet.
Dieser Angriff umgeht die MFA, indem er Sitzungscookies nutzt, was den fortgesetzten Zugriff auf Cloud-Dienste ermöglicht, ohne dass die Anmeldedaten des Benutzers erforderlich sind. Anstelle eines einmaligen Cookie-Diebstahls stellt diese Methode sicher, dass bei jeder Anmeldung des Benutzers gültige Sitzungscookies extrahiert werden, wodurch ein langfristiger unbefugter Zugriff aufrechterhalten bleibt.
Am Ende dieses PoC werden wir Folgendes erreicht haben:
Das folgende Diagramm skizziert den End-to-End-Ablauf unseres Proof of Concept und zeigt, wie Angreifer unbemerkt Authentifizierungs-Cookies erfassen, exfiltrieren und wiederverwenden, um die Cloud-Sitzungen von Opfern zu kapern:
Zunächst erstellen wir eine Chrome-Erweiterung, die auf Authentifizierungsereignisse achtet und Sitzungscookies stiehlt, wenn das Opfer auf login.microsoftonline.com zugreift.
Erstellen Sie ein neues Verzeichnis mit dem Namen „CookieStealer Extension“. Erstellen Sie in diesem Verzeichnis zwei Dateien:
Die Manifestdatei definiert das Verhalten der Erweiterung, die erforderlichen Berechtigungen und die Hintergrundskripte.
Erstellen Sie die Datei manifest.json im Erweiterungsverzeichnis:
Was bewirkt dies:
Die Erweiterung extrahiert Cookies jedes Mal, wenn sich das Opfer beim Authentifizierungsportal von Microsoft anmeldet.
Erstellen Sie „background.js“. fügen Sie Folgendes hinzu:
Erweiterungs-Cookie während der Anmeldung
Die Erweiterung wartet auf Authentifizierungsanfragen an login.microsoftonline.com.
Wenn eine Anmeldung erfolgt, extrahiert es die Cookies (einschließlich ESTSAUTH und ESTSAUTHPERSISTENT).
Ich habe mich dafür entschieden, die Cookies über Google Forms stillschweigend direkt in mein persönliches Laufwerk zu übertragen:
Cookie-Exfiltration über Google Forms
Nachdem die Erweiterung bereit ist, besteht der nächste Schritt darin, ihre Bereitstellung zu automatisieren.
Nachdem die Erweiterung in eine CRX-Datei gepackt und auf VirusTotal hochgeladen wurde, zeigt das Ergebnis, dass derzeit kein Sicherheitsanbieter sie als bösartig erkennt.
Schritt 2: Automatisierung der Bereitstellung mit PowerShell
Um das Laden unserer Erweiterung zu automatisieren, werden wir ein PowerShell-Skript erstellen, das die Erweiterung in das Standardprofil des Chrome-Benutzers lädt. Ein Teil des Codes, der dies ausgeführt hat:
Dieses PowerShell-Skript lädt die Erweiterung in einen neu gestarteten Chrome-Prozess. Die Erweiterung bleibt jedoch nur während der Dauer dieser Chrome-Sitzung aktiv. Sobald Chrome geschlossen wird, wird die Erweiterung automatisch entfernt.
Daher ist es ratsam, dieses Skript regelmäßig auszuführen (z. B. alle paar Stunden oder täglich, was über eine Zeitplanaufgabe oder einen Startordner erfolgen kann). Es gibt zwar Methoden, um Erweiterungen dauerhaft zu laden, wie z. B. die Nutzung von Registry-basierten Richtlinien oder die Injektion der Erweiterung direkt in die Datei „Sichere Einstellungen“ von Chrome unter Umgehung des Message Authentication Code (MAC), aber diese Ansätze sind komplexer und erfordern in der Regel Administratorrechte.
Unternehmen könnten die Verwendung von PowerShell-Skripten einschränken. In solchen Fällen müssen wir Alternativen wie Python, VBScript oder Makros finden, um ähnliche Ergebnisse zu erzielen.
Nach dem Diebstahl der Sitzungscookies besteht der nächste Schritt darin, diese in den Browser des Angreifers einzuschleusen, um den gewünschten Zugriff zu erhalten. Um dies zu erreichen, haben wir eine Chrome-Erweiterung namens Cookie-Editor (ID: hlkenndednhfkekhgcdicdfddnkalmdm) verwendet, die im Chrome Web Store erhältlich ist.
Kopieren Sie zuerst die Cookie-Daten, die von unserem Google-Formular zurückgegeben wurden und bereits im JSON-Format vorliegen.
Als Nächstes importieren wir die kopierten Cookie-Daten in die Cookie-Editor-Erweiterung.
Aktualisieren Sie abschließend die Seite, um Zugriff auf das Cloud-Portal des Opfers zu erhalten.
Wir haben im Azure-Anmeldeprotokoll festgestellt, dass wir innerhalb kurzer Zeit zwei erfolgreiche Authentifizierungen mit derselben Sitzungs-ID von verschiedenen Standorten und mit unterschiedlichen Browserversionen haben:
Der Vorteil dieses Ansatzes besteht darin, dass der Zielbenutzer eine gültige Sitzung für die Azure-Infrastruktur erhält. Dies gilt unabhängig davon, ob die Sitzungsdauer abgelaufen ist oder widerrufen wurde, da die Erweiterung bestehen bleibt und jedes Mal ausgelöst wird, wenn der Microsoft Login initiiert wird.
Dieser PoC demonstriert, wie ein Angreifer einen persistenten Cookie-Stealer nur mit einer Browser-Erweiterung und PowerShell-Automatisierung erstellen kann. Durch die Nutzung von Authentifizierungs-Ereignis-Hooks stellt der Angriff sicher, dass ständig gültige Sitzungs-Cookies extrahiert werden, was einen langfristigen, nicht autorisierten Zugriff ermöglicht.
Wichtige Lektionen:
Conditional Access Policies (CAPs) bieten eine robuste Verteidigungsschicht, indem sie bestimmte Bedingungen definieren, die erfüllt sein müssen, bevor der Zugriff auf Cloud-Ressourcen erlaubt wird. CAP wertet Faktoren wie den Standort des Benutzers, die Konformität des Geräts, Betriebssystemversionen oder Client-Anwendungen aus, um dynamisch Sicherheitskontrollen durchzusetzen und so das Risiko eines unbefugten Zugriffs erheblich zu verringern, selbst wenn Anmeldedaten oder Sitzungen kompromittiert wurden.
Für eine bessere Durchsetzung nutzt CAP die Compliance-Signale von Plattformen wie Microsoft Intune. Intune ermöglicht es Unternehmen, Sicherheitsstandards für Geräte festzulegen (z. B. um sicherzustellen, dass ein Gerät verschlüsselt ist, aktualisiert wird oder die Anforderungen des Betriebssystems erfüllt). Conditional Access wertet diese Signale dann bei jedem Authentifizierungsversuch aus und erlaubt den Zugriff nur dann, wenn die angegebenen Sicherheitsbedingungen erfüllt sind, und stärkt so Ihre allgemeine Sicherheitslage.
Sehen wir uns dies in der Praxis an, indem wir eine CAP erstellen, die den Benutzerzugriff auf Cloud-Ressourcen von anderen Standorten als Deutschland aus einschränkt, das wir als benannten, erlaubten Standort konfiguriert haben:
Wenn wir versuchen, von außerhalb dieses erlaubten Standorts auf Ressourcen zuzugreifen, wird der Zugriff blockiert:
Da die erzwungene CAP den direkten Zugriff verhindert, ist es sinnvoll, zusätzliche Details vom Host des Benutzers zu sammeln, um eine typische Benutzeranfrage genau zu simulieren.
Wir können dies tun, indem wir ein aktualisiertes PowerShell-Skript ausführen, das Informationen wie die Domain, den Hostnamen und das Betriebssystem erfasst:
Datenerfassung über PowerShell
Darüber hinaus hilft die Erfassung von Daten wie der öffentlichen IP-Adresse des Benutzers, der Browserversion, des User-Agents und des Browserverlaufs dabei, genehmigte Standorte und häufig aufgerufene Ressourcen innerhalb der typischen Sitzung des Benutzers zu identifizieren.
Nachdem wir die üblichen Interaktionsmuster des Benutzers mit der Cloud-Infrastruktur kennengelernt haben, können wir den Benutzer effektiv nachahmen und bestimmte CAP-Beschränkungen umgehen.
Ein Angreifer, der sich mithilfe eines gestohlenen Sitzungscookies erfolgreich authentifiziert, erhält Zugriff auf die Azure Enterprise Applications, die diesem Benutzer zur Verfügung stehen.
Jede Anwendung kann über eigene, eindeutige Berechtigungen verfügen – entweder direkt der Anwendung zugewiesen oder über Benutzerberechtigungen delegiert. Outlook nutzt zum Beispiel die Microsoft Graph API, was es einem Angreifer ermöglichen könnte, die Benutzer innerhalb des Tenants aufzuzählen.
Ähnlich kann SharePoint Online Schreibberechtigungen auf Dateiebene bereitstellen, die Datenänderungen oder weitere Inhaltsmanipulationen ermöglichen. Durch die strategische Ausnutzung dieser Anwendungsberechtigungen könnte ein Angreifer vertrauliche Informationen sammeln, gezielte Phishing-Kampagnen für laterale Bewegungen starten oder – abhängig von den erworbenen Berechtigungen – neue Anwendungen registrieren oder sogar zusätzliche Benutzer anlegen.
Nachdem eine Benutzersitzung erfolgreich gekapert wurde, greift ein Angreifer wahrscheinlich zunächst auf die Anwendung Graph Explorer zu, mit der wichtige Azure-Ressourcen wie Benutzer, Geräte, Gruppen und Rollen innerhalb des kompromittierten Mandanten abgefragt werden können.
In diesem Beispiel verwendet die Anwendung den Berechtigungsbereich User.ReadBasic.All, der den Zugriff auf grundlegende Benutzerinformationen wie Benutzernamen, E-Mails und Anzeigenamen ermöglicht. Mit erweiterten oder zusätzlichen Berechtigungen wie „User.Read.All“ oder „Directory.Read.All“ könnte ein Angreifer seine Möglichkeiten, detailliertere und sensitive Daten aufzulisten, erheblich erweitern und so seine Angriffsfähigkeiten innerhalb des Tenants weiter steigern.
Dann können sie auch auf https://outlook.office365.com/mail/ zugreifen und irgendwo interessante persönliche E-Mails oder gespeicherte Passwörter finden.
Mehrere Sicherheitstools erleichtern die Interaktion mit Azure Entra ID-Tokens und ermöglichen es Angreifern, authentifizierte Sitzungen auszunutzen und ihre Berechtigungen zu eskalieren.
Zu den beliebten Tools gehören ROADtools (von Dirk-Jan Mollema), das die Aufzählung, die Token-Extraktion und den anwendungsübergreifenden Token-Austausch über die Family of Client IDs (FOCI) ermöglicht; AADInternals (Nestori Syynimaa), das umfangreiche Funktionen für die Tokenbearbeitung, Extraktion und Rechteausweitung in Azure Active Directory bietet.
TokenSmith (JumpsecLabs) wurde entwickelt, um Azure Entra ID-Token einfach zu manipulieren, zu validieren und zu fälschen. Diese Tools ermöglichen es Angreifern und Sicherheitsforschern gleichermaßen, Azure-Dienste zu wechseln, tieferen Zugriff zu erhalten, Ressourcen aufzuzählen und Privilegien in kompromittierten Azure-Umgebungen zu erweitern.
Mit einer gültigen, authentifizierten Browsersitzung, die über gestohlene Cookies abgefangen wurde, ist es möglich, Zugriffs- und Aktualisierungs-Tokens zu erhalten, ohne die tatsächlichen Anmeldedaten des Opfers eingeben zu müssen. Um dies zu erreichen, verwenden wir TokenSmith, ein Tool, das den Abruf von OAuth-Tokens vereinfacht. Konkret wird TokenSmith verwendet, um einen OAuth-Autorisierungscodefluss gegen den Authentifizierungsendpunkt von Microsoft (https://login.microsoftonline.com/common/oauth2/v2.0/authorize) zu initiieren, wobei die Client-ID von Microsoft Teams (1fec8e78-bce4-4aaf-ab1b-5451cc387264) angegeben wird.
Dieser Ansatz nutzt die authentifizierte Cookie-Sitzung, um die übliche Authentifizierungsaufforderung zu umgehen und direkt einen Autorisierungscode bereitzustellen. TokenSmith tauscht dann diesen Autorisierungscode am Token-Endpunkt (https://login.microsoftonline.com/common/oauth2/v2.0/token) aus und ruft das Access Token und Refresh Token zusammen mit den zugehörigen Bereichen ab.
Diese Token geben die genauen Berechtigungen und Zugriffsebenen an, die von der ursprünglichen authentifizierten Sitzung des Opfers geerbt wurden, und gewähren dem Angreifer effektiv dauerhaften Zugriff, bis die Token ablaufen oder widerrufen werden.
Durch das Dekodieren des Access Tokens können wir kritische Details extrahieren, wie zum Beispiel:
Da wir jetzt sowohl das Zugriffstoken als auch das Aktualisierungstoken besitzen, können wir die zuvor genannten Tools (RoadTools, AADInternals, TokenSmith usw.) nutzen, um zusätzliche Token anzufordern und die Berechtigungen innerhalb des Tenants zu eskalieren.
Diese Demonstration hebt ein kritisches Sicherheitsproblem hervor: Wir konnten in unserer Post-Exploitation-Phase erfolgreich voranschreiten, ohne die Anmeldedaten des Opfers zu benötigen – nur deren authentifizierte Sitzung.
Diese Forschung zeigt auf, wie das Hijacking von Azure Entra ID-Sitzungen Angreifern dauerhaften Zugriff auf kritische Cloud-Anwendungen und -Infrastrukturen verschaffen kann. Durch den Einsatz gestohlener Sitzungscookies kann ein Angreifer Authentifizierungsmechanismen umgehen und sich nahtlos Zugang zu Cloud-Umgebungen verschaffen, ohne dass Benutzeranmeldeinformationen erforderlich sind.
Über den anfänglichen Zugriff hinaus kann das Hijacking von Sitzungen die seitliche Bewegung innerhalb des Tenants erleichtern und es Angreifern ermöglichen, zusätzliche Ressourcen zu erkunden, auf sensible Daten zuzugreifen und die Privilegien zu erweitern, indem sie bestehende Berechtigungen oder falsch konfigurierte Rollen missbrauchen. Die Möglichkeit, sich als legitimer Benutzer auszugeben, schafft Möglichkeiten für die Ausweitung von Privilegien, die Exfiltration von Daten und die langfristige Persistenz innerhalb der Cloud-Umgebung eines Unternehmens.
Das Verständnis dieser Risiken ist entscheidend für die Stärkung der Verteidigung gegen sitzungsbasierte Angriffe, daher empfehlen wir:
Entdecken Sie mehr Inhalte von Varonis Threat Labs.