Da immer mehr Unternehmen Cloud-Dienste für ihren täglichen Betrieb nutzen, ist es wichtig, die potenziellen Risiken eines Token-Diebstahls zu kennen. In der Welt der On-Premise-Systeme gibt es mehrschichtige Schutzmöglichkeiten für Tokens, aber es gibt immer noch Vorfälle, bei denen Tokens nicht ausreichend geschützt waren. In der Cloud ist das Risiko höher, da die Access Tokens oft nicht ausreichend geschützt sind und auf verschiedene Arten entwendet werden können. Einmal erlangt, können Angreifer schnell von Remote auf Unternehmensdaten zugreifen, was es wahrscheinlicher macht, dass ein Vorfall grosse Auswirkungen hat.

Obwohl Access Tokens bei verschiedenen Cloud-Plattformen, Lösungen oder Websites einen ähnlichen Zweck erfüllen, kann es Unterschiede in der Implementierung und der spezifischen Funktionalität geben. In diesem Artikel geht es in erster Linie darum, wie man die von der Microsoft Cloud ausgestellten Access Tokens auslesen kann. Abschliessend werden einige Möglichkeiten aufgezeigt, wie man den Diebstahl von Access Tokens erschweren kann.

Was ist ein Microsoft Cloud Access Token?

Ein Access Token ist ein Sicherheits-Token, das von einem Autorisierungsserver als Teil eines OAuth 2.0-Flows ausgegeben wird. Es enthält Informationen über den Nutzer und die Ressource, für die das Token bestimmt ist. Diese Informationen können verwendet werden, um auf Web-APIs und andere geschützte Ressourcen zuzugreifen. Ressourcen validieren Zugriffstoken, um einer Client-Anwendung Zugang zu gewähren.

Die Microsoft Identity Platform implementiert Sicherheits-Tokens als JSON Web Tokens (JWTs), die Claims enthalten. Da JWTs als Sicherheits-Token verwendet werden, wird diese Form der Authentifizierung manchmal auch als JWT-Authentifizierung bezeichnet. Ein Claim enthält Aussagen über eine Entität, z. B. eine Client-Anwendung oder einen Ressourcenbesitzer, gegenüber einer anderen Entität, z. B. einem Ressourcenserver. Ein Claim kann auch als JWT-Claim oder JSON-Web-Token-Claim bezeichnet werden. Zusätzlich stellt die kryptografische Signierung die Integrität und Authentizität des Tokens sicher. Das Token wird mit einem privaten Schlüssel digital signiert, und der Empfänger kann seine Authentizität mit dem entsprechenden öffentlichen Schlüssel überprüfen.

Das standardmässige Microsoft Cloud JWT-Token ist base64url-kodiert, kann also enkodiert werden. Die enkodierung erfolgt vorzugsweise offline, um das Risiko einer Kompromittierung zu vermeiden. Zum Beispiel, indem der Code von jwt.ms oder jwt.io heruntergalden und überprüft wird. Danach kann die HTML/JavaScript Lösung offline verwendet werden. Oder indem ein PowerShell-Skript wie das von Vasil Michev oder die Python-Lösung roadtx von DirkJan verwendet wird. Sobald das JWT enkodiert ist, kann es wie das folgende verkürzte Access Token Beispiel aussehen:

{
  "typ": "JWT",
  "nonce": "OwJxBtbDQCPbBNDAfLGfXVExE0pF8sLb36nC_MWvpDQ",
  "alg": "RS256"
}.{
  "aud": "https://graph.microsoft.com",
  "iss": "https://sts.windows.net/d2a16643-x/",
  "iat": 1715765602,
  "nbf": 1715765602,
  "exp": 1715770910,
  "amr": [
    "pwd",
    "mfa"
  ],
  "app_displayname": "My Profile",
  "appid": "8c59ead7-d703-4a27-9e55-c96a0054c8d2",
  "appidacr": "0",
  "ipaddr": "141.195.x.x",
  "name": "Rabban",
  "oid": "4c422389-x-x-x-x",
  "scp": "AuditLog.Read.All BitlockerKey.Read.All CrossTenantInformation.ReadBasic.All CrossTenantUserProfileSharing.ReadWrite.All Device.EnableDisableAccount.All Device.Read.All email Group.Read.All Group.ReadWrite.All GroupMember.Read.All MailboxSettings.ReadWrite openid Organization.Read.All Policy.Read.All profile RoleManagement.ReadWrite.Directory User.Invite.All User.Read.All User.ReadBasic.All User.ReadWrite",
  "signin_state": [
    "kmsi"
  ],
  "tid": "d2a16643-x-x-x-x",
  "upn": "rabban@x.onmicrosoft.com",
  "xms_cc": [
    "cp1"
  ],
}.[Signature]

Im obigen Beispiel enthält das Token mehrere Angaben. Die wichtigsten sind unten aufgelistet, um zum Beispiel den Eigentümer, die Zielgruppe, den Geltungsbereich, die xms_cc und das Ablaufdatum zu identifizieren.

Weitere Details zu den Token-Claims der Microsoft-Cloud sind dokumentiert unter der ID token claims reference.

Ein Microsoft Cloud Access Token ist auf eine Ressource beschränkt, in der Regel eine Stunde lang gültig und kann nicht widerrufen werden. Es gibt auch ein Continuous Access Evaluation (CAE) Access Token, das 24 Stunden lang gültig ist und widerrufen werden kann. Tools wie TokenTacticsV2 oder roadtx können verwendet werden, um ein CAE-Zugangs-Token aus einem gültigen Refresh-Token oder einem Cookie zu erstellen. Leider werden Refresh-Tokens in diesem Artikel nicht behandelt, da sie ein ganz eigenes Thema sind. Wenn du mehr über Refresh-Tokens erfahren möchtest, schau dir Dirk-Jan Mollema blogs an.

Wenn ein Access Token extrahiert werden kann, kann dieses in der Regel von jedem Gerät und von jedem Ort aus verwendet werden, solange dieses gültig ist. Deshalb ist es wichtig, Access Tokens vor allem von privilegierten Nutzern zu schützen. Wie man das macht, ist im Kapitel Access Token Schützen beschrieben.

Ich will eins

Es gibt viele Möglichkeiten, ein Microsoft Cloud Access Token zu erhalten. Hier sind einige Beispiele, die wir bei Security Assessments, Pentests oder Red Teaming verwenden.

Über den Browser

Der einfachste Weg für einen angemeldeten Nutzer, ein Access Token zu erhalten, ist das Öffnen der Browser-Entwicklertools und das browsen von Microsoft Cloud-Frontend URLs wie https://myapps.microsoft.com/, https://myaccount.microsoft.com/, https://portal.azure.com/ oder https://mysignins.microsoft.com/. Hier ist ein kurzer Überblick über die Zugriffstoken, die von bekannten API-Endpunkten extrahiert werden können, und ob sie für Tools wie RoadRecon oder AzureHound verwendet werden können.

Eine andere Möglichkeit, ein Access Token zu erlangen, ist das Stehlen von Web-Session-Cookies. Das Cookie wird dann gegen ein Access Token ausgetauscht. Das Stehlen von Cookies aus einem Browser wird von Justin Bui in seinem Artikel Hands in the Cookie Jar: Dumping Cookies with Chromium’s Remote Debugger Port sehr gut beschrieben. Danach kann roadtx von Dirkjan verwendet werden, z.B. mit dem Befehl roadtx interactiveauth --estscookie 0.AYIAQ --tokens-stdout -r msgraph -c azps, um das Cookie gegen ein Access Token auszutauschen. Verwende zum Beispiel für Azurehound und RoadTools für -r: msgraph, https://graph.windows.net oder https://management.azure.com. Für -c sollte jede Family of Client IDs (FOCI) funktionieren.

Um zu verhindern oder zu erschweren, dass ein Angreifer die oben genannten Methoden als Benutzer mit geringen Rechten ausführt, können die Entwicklerwerkzeuge und das Remote-Debugging für die meisten Browser über Gruppenrichtlinien deaktiviert werden.

Aus Dateien oder Prozessen

Access Token können auch aus Dateien extrahiert werden. Zum Beispiel hat Sander Maas früh entdeckt, dass Outlook für Windows (ja, nur das neue) Refresh und auch Access Token unter %localappdata%\Microsoft\Olk\EBWebView\Default\Session Storage\00000x.log speichert. Ältere Versionen von Azure CLI und anderen Cmdlets haben Access Tokens im Klartext unter %USERPROFILE%\.azure gespeichert. Es ist immer noch ein guter Ordner zum Überprüfen, denn wer aktualisiert schon PowerShell Module?

Access Tokens können auch in Prozessen wie Outlook, Word, Teams, PowerShell usw. gefunden werden. Am einfachsten ist es, den Prozess über den Task Manager zu dumpen und im Dump mit sysinternals strings.exe und findstr /i eyJ0eX nach Zugriffstokens zu suchen. Token, die für https://graph.microsoft.com ausgestellt wurden, können normalerweise gefunden werden und sind für AzureHound verwendbar.

Weitere Informationen oder Tools zur Automatisierung der Suche und Extraktion von Access Tokens aus Prozessen:

• Stealing Access Tokens From Office Desktop Applications
• A tool to extract JWT from processes
• A took for extracting information and dumping sensitive strings from Windows processes
• WAM BAM – Recovering Web Tokens From Office

Von APIs

Eine einfache Möglichkeit, ein Access Token zu erhalten, ist der OAuth 2.0 Device Authorization Grant Flow. Weitere Details dazu sind im Artikel mit dem Titel Hidden dangers of phishing attacks beschrieben. Heutzutage kann dieser Flow durch Conditional Access Policies blockiert werden.

Es gibt weitere OAuth 2.0 Grant Flows, über die ein Access Token erhalten werden kann. Zum Beispiel der password credentials grant flow oder andere, die unter Microsoft identity platform app types and authentication flows gut dokumentiert sind. Diese Flows können verwendet werden, wenn die Anmeldedaten bekannt sind oder missbraucht werden, z. B. durch den Einsatz einer Phishing-Anwendung. Eine gute Artikel ist der von Nyxgeeks Creating a Malicious Entra ID OAuth2 Application.

Von Cmdlets

Es gibt mehrere Azure- oder Entra-ID-bezogene Cmdlets. Mit einigen der Cmdlets kann das Access Token angezeigt/abgerufen werden, wenn eine Sitzung zwischengespeichert wurde oder nach einer erfolgreichen Anmeldung.

Das Cmdlet connect-mggraph verfügt derzeit nicht über eine integrierte Methode zur Anzeige des Access Tokens. Mit der Prozessdump-Methode kann jedoch das Zugriffstoken aus einem aktiven PowerShell-Prozess extrahiert werden, der das Cmdlet connect-mggraph verwendet hat.

Vom Microsoft Graph Explorer

Wenn eine zwischengespeicherte Sitzung zum Microsoft Graph Explorer geöffnet ist, kann ein Access Token über die GUI extrahiert werden. Das Access Token kann nicht für die Tools azurehound oder roadtools verwendet werden. Manchmal wird die Anwendung Microsoft Graph Explorer jedoch für alle Benutzer zugelassen und ist daher eine gute Möglichkeit, eine erste Enumeration vorzunehmen.

Vom Abfangen des Webverkehrs

Tools, die den Webverkehr abfangen können, wie z.B. Proxies, Burp, Fiddler oder Zap, können zum Abfangen von Access Tokens verwendet werden.

Von Azure Cloud Ressourcen

Wenn ein Benutzer über ausreichenden Zugriff auf Ressourcen wie Azure Cloud Shell, Azure Cloud Shell-Images, RunAs-Konten für Azure Automation, DevOps-Pipelines oder eine virtuelle Maschine verfügt, die Managed Identities verwendet, ist es häufig möglich, Access Tokens zu extrahieren.

Weitere Informationen:

• Gathering Bearer Tokens from Azure Services
• Exploring the Microsoft Graph API from Azure Cloud Shell
• Managed Identity – Get a token using HTTP
• Persist files in Azure Cloud Shell

Access Token Schützen

Wenn ein Access Token gestohlen wird, kann es verwendet werden, um von jedem beliebigen Gerät aus auf Daten zuzugreifen oder diese zu manipulieren, und zwar unter Umgehung aller Conditional Access Regeln. Microsoft hat zwar Sicherheitsfunktionen wie CAE oder Token Protection implementiert, um den Diebstahl von Access Token zu verhindern, indem sichergestellt wird, dass ein Token nur von dem dafür vorgesehenen Gerät verwendet werden kann. Diese Funktionen unterstützen jedoch nicht alle 1st-Party-Cloud-Anwendungen, und Token Protection unterstützt derzeit nur Refresh-Tokens. Die einzige vielversprechende Funktion, die vor Access Token-Diebstahl schützen könnte, ist Global Secure Access. Wir haben die Preview Implementierung noch nicht getestet und können daher nicht sagen, ob sie hält, was sie verspricht.

Die oben genannten Methoden zum Extrahieren von Access Tokens, mit Ausnahme der Gerätecode-Authentifizierung, bösartigen OAuth 2.0-Anwendung sowie Azure Cloud Ressourcen, setzen voraus, dass sich ein Angreifer bereits auf dem Gerät befindet. Dazu sind jedoch nicht-lokale Administratorrechte erforderlich. Der Schutz des Endgerätes und insbesondere der privilegierten Benutzer ist daher von entscheidender Bedeutung. Aber hey, es gibt einen einfachen Trick für privilegierte Benutzer (z. B. Tier-0), fast kostenlos, ein bisschen nervig und nicht sehr schick, er heisst Privileged Access Workstation. Wenn dieser angewendet wird, ist es die stärkste Verteidigung gegen Token-Diebstahl und löst das Problem am Anfang, nämlich wo die Tastatur sitzt.

Im Allgemeinen und für nicht privilegierte Benutzer ist es ein guter Anfang, den Diebstahl von Access Tokens zu erschweren, indem man den Zugriff nur von vertrauenswürdigen und gesicherten Endpunkten aus zulässt, die empfohlenen Tenant-Sicherheitsempfehlungen umsetzt, Anmeldedaten sicher behandelt und eine phishing-resistente Multifaktor-Authentifizierung (MFA) verwendet.

Weitere Informationen zu Schutzmassnahmen:

• Token tactics: How to prevent, detect, and respond to cloud token theft
• Token theft playbook

Fazit

Wie wir gelernt haben, gibt es mehrere Möglichkeiten, Access Tokens zu erlangen. Gelingt es einem Angreifer, ein Token zu erhalten, kann es eine Stunde oder 24 Stunden lang gültig sein. Genug Zeit, um Daten zu exfiltrieren oder eine Hintertür für die Persistenz zu installieren, wobei letzteres von den Berechtigungen des Benutzers abhängt.

Es gibt derzeit keine einfache Möglichkeit, die unbefugte Verwendung von Access Tokens zu verhindern, ausser es einem Angreifer schwer zu machen, in die Nähe eines Benutzers mit einem privilegierten Access Token zu gelangen. Dies beginnt oft mit der Methode, eine sichere Strategie für den privilegierten Zugriff zu implementieren. Richtig gemacht, würde dies einem Angreifer den unbefugten Zugriff erschweren. Bei unseren Sicherheitsüberprüfungen kommt es jedoch nicht selten vor, dass privilegierte oder unternehmenskritische Benutzer private Telefone oder sogar Heimcomputer für den Zugriff auf den Tenant des Unternehmens verwenden. Ähnliche Fehler wurden in der Vergangenheit mit Active Directory gemacht, als jeder ein Domänenadministrator war und es keine Sicherheitshärtung und keinen Token-Schutz gab. Zumindest gab es die Festungsmethode der Firewalls, die die Umgebung vor dem Internet schützten. Aber mit der Cloud funktioniert diese Methode nicht mehr.

Wir haben ein anderes Bedrohungsmodell, wenn wir mit einer Cloud-Umgebung arbeiten: Die Priorität liegt am Endpunkt, wo dem Benutzer der Zugriff auf die Cloud entweder erlaubt oder verwehrt wird. Folglich sind die Erlaubnis des Zugriffs nur von vertrauenswürdigen und gehärteten Endpunkten, die Umsetzung der empfohlenen Tenant-Sicherheitsempfehlungen, die Anwendung sicherer Praktiken für den privilegierten Zugriff, die sichere Handhabung von Anmeldeinformationen, die Verwendung einer Phishing-resistenten Multi-Faktor-Authentifizierung (MFA) und die Denkweise von Angreifern, um nur einige zu nennen, die Eckpfeiler des Schutzes von Cloud-Ressourcen und der für den Zugriff erforderlichen Access Tokens.

Über den Autor

Marius Elmiger hat seit den frühen 2000er Jahren Erfahrung in verschiedenen Rollen als Administrator, Engineer, Architekt und Consultant gesammelt. Sein Fokus lag hauptsächlich in der Implementierung von komplexen IT-Infrastruktur Projekten, Umsetzung von Sicherheitskonzepten und Compromise Recoveries. Später wechselte er zur offensiven Seite, um sein Wissen weiter auszubauen. Als Grundlage neben zahlreichen Zertifikaten absolvierte Marius ein MSc in Advanced Security & Digital Forensics an der Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• https://blog.xpnsec.com/wam-bam/
• https://developer.microsoft.com/en-us/graph/graph-explorer
• https://dirkjanm.io/
• https://github.com/HackmichNet/AzTokenFinder
• https://github.com/dirkjanm/ROADtools
• https://github.com/dirkjanm/ROADtools/wiki/ROADtools-Token-eXchange-(roadtx
• https://github.com/dirkjanm/ROADtools/wiki/ROADtools-Token-eXchange-(roadtx)#roadtx-describe
• https://github.com/f-bader/TokenTacticsV2
• https://github.com/mlcsec/proctools?tab=readme-ov-file#procinfocs
• https://github.com/secureworks/family-of-client-ids-research
• https://jwt.io/#debugger-io
• https://jwt.ms/
• https://kevinhakanson.com/2020-04-22-exploring-the-microsoft-graph-api-from-azure-cloud-shell/
• https://learn.microsoft.com/en-us/azure/cloud-shell/persisting-shell-storage
• https://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-access
• https://learn.microsoft.com/en-us/entra/identity-platform/authentication-flows-app-scenarios
• https://learn.microsoft.com/en-us/entra/identity-platform/id-tokens
• https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc
• https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-device-code
• https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
• https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protectionthat
• https://learn.microsoft.com/en-us/entra/identity/conditional-access/how-to-policy-authentication-flows
• https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-to-use-vm-token#get-a-token-using-http
• https://learn.microsoft.com/en-us/security/operations/token-theft-playbook
• https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-devices
• https://mrd0x.com/stealing-tokens-from-office-applications/
• https://portswigger.net/burp
• https://posts.specterops.io/hands-in-the-cookie-jar-dumping-cookies-with-chromiums-remote-debugger-port-34c4f468844e
• https://twitter.com/__Retrospect/status/1742929451523117325
• https://www.michev.info/blog/post/2140/decode-jwt-access-and-id-tokens-via-powershell
• https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/
• https://www.netspi.com/blog/technical-blog/cloud-pentesting/gathering-bearer-tokens-azure/
• https://www.telerik.com/fiddler
• https://www.trustedsec.com/blog/creating-a-malicious-azure-ad-oauth2-application
• https://www.zaproxy.org/