Tool ausführen:```bash
python3 AzureRedOps.py -a <activity> [options]

### Bereitstellen eines Tokens

Aktivitäten, die Microsoft Graph aufrufen, benötigen ein Zugriffstoken. Sie können es auf zwei Arten bereitstellen:

| Methode | Flag | Beispiel |
|--------|------|---------|
| Ein rohes Token übergeben | `-ac, --access-token` | `-ac eyJ0eXAi...` |
| Ein zwischengespeichertes Token nach Namen laden | `-l, --load-access-token` | `-l mytoken` |

Wenn `-l` verwendet wird, werden das passende `access_token` (und, falls relevant, `refresh_token` und `tenant`) aus dem `.azure_creds`-Speicher gelesen.

### Speichern von Token in einer Datei (`-s` / `-n`)

Jede Aktivität, die Token abruft (`auth`, `auth-app`, `auth-interactive`, `phish-start`/`phish-capture`, `refresh`), kann sie **automatisch** im lokalen Anmeldeinformationsspeicher (`.azure_creds`) speichern, indem `-s/--save` zusammen mit `-n/--name` angegeben wird:```bash
# Authenticate and save the resulting tokens under the name "victim1"
python3 AzureRedOps.py -a auth -u [email protected] -p 'P@ssw0rd!' -tid <tenant-guid> -s -n victim1

For `gather-all`, the supplied filename is used as a suffix and one file is written
per Graph endpoint (e.g. `users-<name>`, `groups-<name>`, ...).

> Tip: `-j` controls structured JSON export, while `-re/--redirect-to-file` mirrors
> the formatted console output to `output.txt`. The two are independent.

### Tenant identifiers

- `-t, --tenant` expects a **domain name** (e.g. `contoso.com`) and is used by the `id` activity.
- `-tid, --tenant-id` expects a **tenant GUID** or `common`, used by the authentication activities.

---

## Command-Line Options

| Short | Long | Default | Description |
|-------|------|---------|-------------|
| `-a` | `--activity` | `id` | **(erforderlich)** Auszuführende Aktivität (siehe [Aktivitäten](#activities)). |
| `-ac` | `--access-token` | | Azure-Zugriffstoken. |
| `-n` | `--name` | | Name, der zum Speichern/Laden eines Tokens verwendet wird, oder Anzeigename für `register-app`/`new-group`/`invite`. |
| `-t` | `--tenant` | | Azure-Mandanten-**Domänen**name (verwendet von `id`). |
| `-c` | `--devicecode` | | Gerätecode (verwendet von `phish-capture`). |
| `-tid` | `--tenant-id` | | Azure-Mandanten-**ID** (GUID) oder `common`. |
| `-app` | `--appid` | `d3590ed6-52b3-4102-aeff-aad2292ab01c` | Anwendungs- (Client-) ID. |
| `-e` | `--endpoint` | `microsoftonline.com` | Ziel-Login-Endpunkt-Domäne. |
| `-r` | `--refresh-token` | | Authentifizierungs-Refresh-Token. |
| `-as` | `--auto-start` | `True` | Automatisches Starten der Gerätecode-Erfassung nach `phish-start`. |
| `-l` | `--load-access-token` | | Ein gecachtes Token nach Namen aus `.azure_creds` laden. |
| `-j` | `--json` | | Aktivitätsausgabe in die angegebene JSON-Datei speichern. |
| `-fl` | `--filter` | | Nur Attribute ausgeben, deren Schlüssel mit einem dieser (kommagetrennt) übereinstimmt. |
| `-u` | `--username` | | Benutzerprinzipalname (E-Mail). |
| `-p` | `--password` | | Benutzerkennwort. |
| `-s` | `--save` | `False` | Automatisches Speichern erhaltener Token in `.azure_creds` (**erfordert `-n`**). |
| `-cp` | `--check-privileges` | `False` | Nach erfolgreichem Spray-Login prüfen, ob Benutzer/Apps aufgelistet werden können. |
| `-uid` | `--uid` | | Azure-Benutzerobjekt-ID (verwendet von `add-group`). |
| `-headers` | `--headers` | | Zusätzliche HTTP-Header als JSON, z.B. `{"X-Foo": "bar"}`. |
| `-gid` | `--gid` | `62e90394-69f5-4237-91f9-056ad24d70a7` | Verzeichnisrolle / Gruppen-ID (Standard = **Globaler Administrator**). |
| `-i` | `--id` | `False` | Für `interest`: nur die Anwendungs-IDs ausgeben. |
| `-ty` | `--type` | | Für `interest`: auf eine bestimmte Kategorie filtern. |
| `-fp` | `--filepath` | | Hochzuladende Datei (`push-file`) oder benutzerdefinierte App-Liste für Spraying. |
| `-v` | `--version` | `v2.0` | Authentifizierungs-API-Version: `v0` oder `v2.0`. |
| `-ua` | `--user-agent` | *(Chrome UA-String)* | HTTP `User-Agent` überschreiben. |
| `-au` | `--audience` | `https://graph.microsoft.com` | Token-Zielgruppe/Ressource. |
| `-sc` | `--scope` | `openid offline_access` | OAuth2-Bereich. Verwenden Sie `https://graph.microsoft.com/.default` für Graph, `openid` für Spraying. |
| `-url` | `--url` | | Ziel-URL für `raw-url`/`invite`; kommagetrennte Liste von URLs für `auth-interactive`. |
| `-beta` | `--beta` | `False` | Den **Beta**-Endpunkt von Microsoft Graph für `list-users`/`list-applications` verwenden. |
| `-exp` | `--expand` | `False` | Verschachtelte Listen/Dicts in der Ausgabe in ein menschenlesbares Format erweitern. |
| `-k` | `--keep` | `False` | Die Datei `session.har` nach `auth-interactive` / `browser-sso` behalten. |
| `-cs` | `--client-secret` | | Vertrauliches Client-Geheimnis, das vom `obo` On-Behalf-Of-Grant verwendet wird. |
| `-prt` | `--prt-cookie` | | PRT-Cookie-Wert (`x-ms-RefreshTokenCredential`) zum Initialisieren des Browser-SSO für `browser-sso`. |
| `-br` | `--browser` | `firefox` | Playwright-Browser-Engine für die Browser-Flows (`auth-interactive`, `browser-sso`). Einer von `firefox`, `chromium`, `webkit`. |
| `-aprt` | `--auto-prt` | `False` | Für `browser-sso`: Automatisches Erstellen eines PRT-Cookies aus dem Refresh-Token (Geräteregistrierung → PRT → `x-ms-RefreshTokenCredential`), sodass der Browser **bereits authentifiziert** geöffnet wird. Erfordert `cryptography` und ein FOCI/Broker-Refresh-Token. |
| `-d` | `--debug` | `False` | Debug-Logging aktivieren. |
| `-dd` | `--verbose-debug` | `False` | Ausführliches HTTP-Anfrage-/Antwort-Logging aktivieren. |
| `-re` | `--redirect-to-file` | `False` | Alle Konsolenausgaben in `output.txt` spiegeln. |

---

## Activities

Below, each activity lists its **required** and *optional* arguments.
"Token" means either `-ac` or `-l` is required.

### Token Management

| Activity | Required | Optional | Description |
|----------|----------|----------|-------------|
| `save` | `-ac`, `-n` | `-tid`, `-r` | Ein Zugriffs- (und optionales Refresh-) Token in `.azure_creds` speichern. |
| `list-token` | — | — | Die Namen aller gespeicherten Token auflisten. |
| `view` | `-n` | — | Die JWT-Ansprüche eines gespeicherten Tokens decodieren und anzeigen. |
| `delete` | `-n` | — | Ein gespeichertes Token aus dem Speicher entfernen. |```bash
# Save a token under the name "mytoken"
python3 AzureRedOps.py -a save -n mytoken -ac eyJ0eXAi... -r 0.AReAB... -tid <tenant-guid>

# List, view, delete
python3 AzureRedOps.py -a list-token
python3 AzureRedOps.py -a view -n mytoken
python3 AzureRedOps.py -a delete -n mytoken

#### So funktioniert der Authentifizierungsfluss

AzureRedOps implementiert mehrere verschiedene Möglichkeiten, Tokens zu erhalten. Wählen Sie diejenige, die zu Ihrem Einsatz passt; alle beachten `-s/-n` zum automatischen Speichern des Ergebnisses.

##### Device-Code-Phishing (`phish-start` / `phish-capture`)

Der **Device Authorization Grant** von OAuth 2.0 ist für eingabeeingeschränkte Geräte konzipiert, was ihn zu einem mächtigen Phishing-Grundbaustein macht: Sie fordern einen Code im Namen einer Microsoft-Erstanbieteranwendung an, und überreden dann ein Ziel, diesen Code unter `https://microsoft.com/devicelogin` einzugeben, während es in seinem Konto angemeldet ist. Sobald dies geschieht, werden die Tokens **an Sie** ausgestellt.

- `phish-start` fordert einen Gerätecode an und gibt den **Benutzercode**, die Anmelde-URL und den rohen **Gerätecode** aus. Da `-as/--auto-start` standardmäßig auf `True` gesetzt ist, beginnt es sofort mit dem Abrufen des Tokens – in der Regel reicht es also aus, `phish-start` auszuführen und dem Ziel den Benutzercode zu geben.
- `phish-capture` ist das manuelle Gegenstück: Geben Sie ihm einen zuvor erhaltenen Gerätecode mit `-c/--devicecode` und es fragt den Token-Endpunkt ab, bis das Opfer die Anmeldung abschließt (das Tool wiederholt die Anfrage still, während die Autorisierung aussteht).
- Verwenden Sie `-app/--appid`, um einen bestimmten Erstanbieter-Client zu imitieren, und `-tid/--tenant-id`, um den Bereich auf einen Mandanten einzuschränken (standardmäßig `common`). Tipp: Setzen Sie den Bereich auf `'https://graph.microsoft.com/.default offline_access openid'`, um ein Graph-fähiges Token mit einem Refresh-Token zu erhalten.```bash
# Start a device-code session (auto-captures the token once the victim logs in)
python3 AzureRedOps.py -a phish-start -tid common -s -n phished

# Or capture against a code you generated separately
python3 AzureRedOps.py -a phish-capture -c <device-code> -tid common -s -n phished

##### Interaktive Browser-Authentifizierung (`auth-interactive`)

`auth-interactive` startet einen **echten Browser über Playwright** (standardmäßig Firefox; wählen Sie die Engine mit `-br/--browser`) und erlaubt dem Bediener (oder einem Ziel in einer gemeinsamen Sitzung), einen interaktiven Login durchzuführen – einschließlich MFA, Conditional Access und föderierten/SSO-Weiterleitungen, die scriptgesteuerte Abläufe nicht erfüllen können. Die gesamte Browsersitzung wird in einer HAR-Datei (`session.har`) aufgezeichnet; das Tool analysiert diese Aufzeichnung, extrahiert **jedes** Access-/Refresh-Token-Paar, das am Endpunkt `/oauth2/v2.0/token` gesehen wurde, dekodiert jedes JWT und lässt Sie auswählen, welche(s) Sie speichern möchten.

- `-url/--url` legt die Seite(n) fest, die nach dem Laden der Login-Seite angesteuert werden sollen. Es akzeptiert eine **durch Kommas getrennte Liste** von URLs (z. B. `https://portal.azure.com,https://outlook.office.com`), damit Sie in einer Sitzung Token für mehrere Ressourcen sammeln können. Standardmäßig: `https://portal.azure.com`.
- Diese Aktivität **speichert immer automatisch**: Nach der Erfassung fragt sie, welche Token-Indizes Sie behalten möchten und unter welchem Namen sie gespeichert werden sollen.
- Fügen Sie `-k/--keep` hinzu, um `session.har` für die Offline-Analyse zu erhalten (standardmäßig wird es gelöscht).```bash
# Log in interactively and harvest tokens for two resources
python3 AzureRedOps.py -a auth-interactive -url https://portal.azure.com,https://outlook.office.com -k

##### Token-zu-Browser Single Sign-On (`browser-sso`)

`browser-sso` öffnet einen **echten Browser, der bereits als Benutzer authentifiziert ist** — Sie klicken nichts und landen direkt drin, z. B. in **Outlook im Web**. Dies ist der „Browser einfach öffnen und eine gültige Sitzung erhalten“-Ablauf. Der Browser erhält seine Sitzung auf eine von drei Arten, in der Reihenfolge der Präferenz:

**1. `-aprt/--auto-prt` — automatisch ein PRT-Cookie ausstellen (empfohlen).**  
Das Aktualisierungstoken wird vollständig durch das Tool in ein **Primary Refresh Token (PRT)** und sein Browser-Cookie umgewandelt, dann eingespeist, sodass Entras ESTS SSO ohne manuelle Anmeldung abschließt. Die Kette (in `includes/PRT.py`, das ROADtoken / roadtx / AADInternals Protokoll) ist:

1. Das Aktualisierungstoken gegen ein **Device-Registration (DRS)** Token einlösen.
2. **Ein Gerät bei Azure AD registrieren** → Gerätezertifikat + Transportschlüssel.
3. Ein **PRT + Sitzungsschlüssel** mit dem Aktualisierungstoken anfordern, signiert durch das Gerätezertifikat.
4. Das **`x-ms-RefreshTokenCredential` Cookie ableiten** (KDFv2: SP800-108 KDF über `SHA256(ctx‖decoded-payload-bytes)` → HS256-signiertes JWT; KDFv1 → `AADSTS5000611`, falsche Bytes → `AADSTS50058`) und in einen neuen Browserkontext einspeisen.

Das Cookie wird mit `SameSite=None` eingespeist und über ein **Top-Level ESTS `/authorize` Warm-up** (den Office `landingv2` Client) verbraucht, sodass das `ESTSAUTH` Sitzungs-Cookie first-party ausgestellt wird — wonach sich die Ziel-App bereits angemeldet öffnet. Das Cookie wird mit einem frischen Nonce unmittelbar vor der Navigation abgeleitet und einmal wiederholt; falls SSO immer noch nicht abgeschlossen werden kann, untersucht das Tool `prompt=none` und gibt den genauen `AADSTS`-Grund aus (z. B. Conditional Access, das ein konformes/verwaltetes Gerät erfordert, oder MFA — beides ist mit einem frisch registrierten Gerät nicht umgehbar).

Das PRT, der Sitzungsschlüssel und das Cookie werden ausgegeben (mit einem fertig zum Einfügen `-prt "<value>"` Hinweis), sodass Sie sie später wiederverwenden können, ohne die Kette erneut ausführen zu müssen.

> **Anforderungen & OpSec für `-aprt`:**
> - Benötigt das **`cryptography`** Paket (`pip install cryptography`; es ist in `requirements.txt` enthalten).
> - Das Aktualisierungstoken muss zu einem **FOCI / Broker Client** gehören — z. B. einem, der durch **Device-Code Phishing des Microsoft Authentication Brokers** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) erfasst wurde, was genau das ist, was der SharePoint/OneDrive Device-Code-Köder liefert. Der Standard-`-app` (Microsoft Office FOCI Client) funktioniert ebenfalls.
> - **Die Geräteregistrierung schreibt ein Geräteobjekt in den Mandanten** — sie ist nicht still und hinterlässt ein Artefakt (und erfordert, dass der Benutzer berechtigt ist, Geräte zu verbinden/registrieren).

**2. `-prt/--prt-cookie` — ein bereits vorhandenes PRT-Cookie einspeisen.**  
Wenn Sie bereits einen `x-ms-RefreshTokenCredential`-Wert besitzen (von einem vorherigen `-aprt`-Lauf, oder von einem kompromittierten Host über `ROADtoken`/`browsercore` oder `Mimikatz`), übergeben Sie ihn direkt und überspringen Sie die Erstellungskette.

**3. Keines von beidem — Token umwandeln und manuell anmelden (Fallback).**  
Ohne PRT-Cookie wird das Aktualisierungstoken gegen ein ressourcenbezogenes Zugriffs-/Aktualisierungstoken eingelöst (ausgegeben und mit `-s/-n` gespeichert), und der Browser wird am Ziel geöffnet, damit Sie die Anmeldung von Hand abschließen.

**PRT / Sitzungs-Cookie-Ernte.** Wenn die Browsersitzung endet (Auto-Close-Timeout oder Sie schließen das Fenster), liest `browser-sso` den Live-Browserkontext aus und **gibt jedes wiederverwendbare SSO-Cookie aus, das ausgestellt wurde** — das PRT-Cookie (`x-ms-RefreshTokenCredential`) und die ESTS-Sitzungs-Cookies (`ESTSAUTH`, `ESTSAUTHPERSISTENT`, ...) — jedes mit einem fertig zum Einfügen `-prt`-Hinweis, damit Sie sie beim nächsten Mal wiedergeben können. Cookies werden abgefragt, solange die Sitzung aktiv ist, sodass der Wert auch dann erfasst wird, wenn Sie das Fenster vorzeitig schließen. Die gleiche Ernte läuft am Ende von `auth-interactive`.

- `-url/--url` wählt das Ziel aus. Verwenden Sie eine freundliche Voreinstellung — `outlook`, `office`, `teams`, `sharepoint`, `onedrive`, `portal`, `graph` — oder übergeben Sie eine oder mehrere rohe `https://` URLs (kommagetrennt). Standardmäßig `outlook`.
- `-r/--refresh-token` + `-tid` (oder ein zwischengespeichertes `-l`) stellt das Aktualisierungstoken bereit. `-app/--appid` standardmäßig zum Microsoft Office FOCI Client.
- `-br/--browser` wählt die Playwright-Engine aus (standardmäßig Firefox).
- `-k/--keep` bewahrt die `session.har`-Aufzeichnung der Browsersitzung.```bash
# BEST: auto-mint a PRT from a device-code-phished (broker) token and drop straight
# into an authenticated Outlook on the web — no manual login.
python3 AzureRedOps.py -a browser-sso -l phished -url outlook -aprt

# Seed a PRT cookie you already have
python3 AzureRedOps.py -a browser-sso -l mytoken -url outlook -prt <x-ms-RefreshTokenCredential>

# Target Teams from a raw refresh token, auto-mint the PRT, keep the session recording
python3 AzureRedOps.py -a browser-sso -r 0.AReAB... -tid <tenant-guid> -url teams -aprt -k

### Password-Spraying

| Aktivität | Erforderlich | Optional | Beschreibung |
|-----------|-------------|----------|--------------|
| `spray` | `-u`, `-p`, `-tid` | `-fp`, `-cp` | Anmeldedaten gegen bekannte First-Party-App-IDs (v0 + v2.0 APIs) sprayen. |
| `spray-refresh` | `-v`, und (`-l`) **oder** (`-r` + `-tid`) | `-fp`, `-cp` | Einen Refresh-Token über viele App-IDs hinweg wiederverwenden. |

Standardmäßig verwenden beide Aktivitäten `includes/auth_apps.json` als App-Quelle; Überschreiben Sie mit `-fp`. Fügen Sie `-cp` hinzu, um zu testen, ob jeder erfolgreiche Login Benutzer/Apps aufzählen kann.```bash
# Spray a single credential across first-party apps
python3 AzureRedOps.py -a spray -u [email protected] -p 'P@ssw0rd!' -tid <tenant-guid> -cp

# Cross-app refresh spraying from a saved token
python3 AzureRedOps.py -a spray-refresh -l mytoken -v v2.0

---

## Ausgabe & generierte Dateien

| Datei | Erstellt von | Beschreibung |
|------|-----------|-------------|
| `.azure_creds` | Token-Speicher-Aktivitäten | Lokaler JSON-Cache von Zugriffs-/Aktualisierungstokens, benannt nach Namen. |
| `output.txt` | `-re` Flag | Zeitgestempeltes Spiegelbild der gesamten Konsolenausgabe. |
| `session.har` | `auth-interactive` / `browser-sso` | Browser-Sitzungsaufzeichnung (gelöscht, sofern nicht `-k` gesetzt). |
| `<name>.json` | `-j` Flag / `gather-all` | Gespeicherte API-Antworten. |

### Mitgelieferte Datendateien

| Datei | Beschreibung |
|------|-------------|
| `includes/auth_apps.json` | Zielanwendungs-IDs für Spraying und die `interest`-Listen. |
| `includes/apps.json` | Bekannte Microsoft-App-IDs und Metadaten für `knownids`. |
| `includes/Webserver.py` | Lokaler HTTPS-Listener, der die PKCE-Weiterleitung für `auth-app` implementiert. |
| `includes/PRT.py` | PRT-Minting-Kette (Geräteregistrierung → PRT → `x-ms-RefreshTokenCredential`-Cookie), verwendet von `browser-sso -aprt`. |
| `includes/web/cert.pem`, `includes/web/key.pem` | TLS-Material für den lokalen Listener. |

---

## Hinweise & Tipps

- **Standard-App-ID** (`d3590ed6-52b3-4102-aeff-aad2292ab01c`) ist der Microsoft Office
  First-Party-Client, der für die meisten Abläufe funktioniert. Die von einigen Aktivitäten
  ausgegebenen Hinweise schlagen vor, die Tokens auf die **Microsoft Azure CLI**-App (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`)
  auszuweiten, um einen breiteren Zugriff zu erhalten.
- **Scope-Anleitung:** Verwenden Sie `-sc openid` für Passwort-Spraying und
  `-sc 'https://graph.microsoft.com/.default'` für Graph-Operationen.
- **`--beta`** schaltet `list-users` / `list-applications` auf den Graph-Beta-Endpunkt um,
  was zusätzliche Informationen (z. B. On-Prem-Synchronisationsattribute) sichtbar machen kann.
- **`auth-app` TLS:** Der lokale PKCE-Listener benötigt ein Zertifikat-/Schlüsselpaar unter
  `includes/web/cert.pem` und `includes/web/key.pem`. Generieren Sie ein selbstsigniertes Paar,
  falls es fehlt, z. B.:  ```bash
  openssl req -x509 -newkey rsa:2048 -nodes \
    -keyout includes/web/key.pem -out includes/web/cert.pem -days 365 -subj "/CN=localhost"