Exécutez l'outil :```bash
python3 AzureRedOps.py -a <activity> [options]

### Fournir un jeton

Les activités qui appellent Microsoft Graph nécessitent un jeton d'accès. Vous pouvez le fournir de deux manières :

| Méthode | Option | Exemple |
|--------|------|---------|
| Fournir un jeton brut | `-ac, --access-token` | `-ac eyJ0eXAi...` |
| Charger un jeton en cache par nom | `-l, --load-access-token` | `-l mytoken` |

Lorsque `-l` est utilisé, le `access_token` correspondant (et, le cas échéant, `refresh_token`
et `tenant`) est lu depuis le magasin `.azure_creds`.

### Enregistrer les jetons dans un fichier (`-s` / `-n`)

Toute activité qui obtient des jetons (`auth`, `auth-app`, `auth-interactive`,
`phish-start`/`phish-capture`, `refresh`) peut **les conserver automatiquement** dans le
magasin local d'informations d'identification (`.azure_creds`) en ajoutant `-s/--save` avec
`-n/--name` :```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

Pour `gather-all`, le nom de fichier fourni est utilisé comme suffixe et un fichier est écrit
par point de terminaison Graph (p. ex. `users-<name>`, `groups-<name>`, ...).

> Astuce : `-j` contrôle l'export JSON structuré, tandis que `-re/--redirect-to-file` réplique
> la sortie console formatée vers `output.txt`. Les deux sont indépendants.

### Identifiants du locataire

- `-t, --tenant` attend un **nom de domaine** (p. ex. `contoso.com`) et est utilisé par l'activité `id`.
- `-tid, --tenant-id` attend un **GUID de locataire** ou `common`, utilisé par les activités d'authentification.

---

## Options de ligne de commande

| Option courte | Option longue | Défaut | Description |
|-------|------|---------|-------------|
| `-a` | `--activity` | `id` | **(requis)** Activité à effectuer (voir [Activités](#activities)). |
| `-ac` | `--access-token` | | Jeton d'accès Azure. |
| `-n` | `--name` | | Nom utilisé pour enregistrer/charger un jeton, ou nom d'affichage pour `register-app`/`new-group`/`invite`. |
| `-t` | `--tenant` | | Nom de **domaine** du locataire Azure (utilisé par `id`). |
| `-c` | `--devicecode` | | Code d'appareil (utilisé par `phish-capture`). |
| `-tid` | `--tenant-id` | | **ID** du locataire Azure (GUID) ou `common`. |
| `-app` | `--appid` | `d3590ed6-52b3-4102-aeff-aad2292ab01c` | ID d'application (client). |
| `-e` | `--endpoint` | `microsoftonline.com` | Domaine du point de terminaison de connexion à cibler. |
| `-r` | `--refresh-token` | | Jeton d'actualisation d'authentification. |
| `-as` | `--auto-start` | `True` | Démarrer automatiquement la capture du code d'appareil après `phish-start`. |
| `-l` | `--load-access-token` | | Charger un jeton mis en cache par son nom depuis `.azure_creds`. |
| `-j` | `--json` | | Enregistrer la sortie de l'activité dans le fichier JSON indiqué. |
| `-fl` | `--filter` | | N'afficher que les attributs dont la clé correspond à l'une de celles-ci (séparées par des virgules). |
| `-u` | `--username` | | Nom d'utilisateur principal (e-mail). |
| `-p` | `--password` | | Mot de passe de l'utilisateur. |
| `-s` | `--save` | `False` | Enregistrer automatiquement les jetons obtenus dans `.azure_creds` (**nécessite `-n`**). |
| `-cp` | `--check-privileges` | `False` | Après une connexion par pulvérisation réussie, sonder si les utilisateurs/applications peuvent être énumérés. |
| `-uid` | `--uid` | | ID d'objet utilisateur Azure (utilisé par `add-group`). |
| `-headers` | `--headers` | | En-têtes HTTP supplémentaires au format JSON, p. ex. `{"X-Foo": "bar"}`. |
| `-gid` | `--gid` | `62e90394-69f5-4237-91f9-056ad24d70a7` | Rôle d'annuaire / ID de groupe (défaut = **Administrateur général**). |
| `-i` | `--id` | `False` | Pour `interest` : n'afficher que les ID d'application. |
| `-ty` | `--type` | | Pour `interest` : filtrer selon une catégorie spécifique. |
| `-fp` | `--filepath` | | Fichier à téléverser (`push-file`) ou liste d'applications personnalisée pour la pulvérisation. |
| `-v` | `--version` | `v2.0` | Version de l'API d'authentification : `v0` ou `v2.0`. |
| `-ua` | `--user-agent` | *(Chrome UA string)* | Remplacer le `User-Agent` HTTP. |
| `-au` | `--audience` | `https://graph.microsoft.com` | Audience/ressource du jeton. |
| `-sc` | `--scope` | `openid offline_access` | Portée OAuth2. Utiliser `https://graph.microsoft.com/.default` pour Graph, `openid` pour la pulvérisation. |
| `-url` | `--url` | | URL cible pour `raw-url`/`invite` ; liste d'URL séparées par des virgules pour `auth-interactive`. |
| `-beta` | `--beta` | `False` | Utiliser le point de terminaison **bêta** de Microsoft Graph pour `list-users`/`list-applications`. |
| `-exp` | `--expand` | `False` | Développer les listes/dictionnaires imbriqués dans la sortie en un format lisible. |
| `-k` | `--keep` | `False` | Conserver le fichier `session.har` après `auth-interactive` / `browser-sso`. |
| `-cs` | `--client-secret` | | Secret client confidentiel utilisé par l'octroi `obo` (On-Behalf-Of). |
| `-prt` | `--prt-cookie` | | Valeur du cookie PRT (`x-ms-RefreshTokenCredential`) afin d'amorcer le SSO du navigateur pour `browser-sso`. |
| `-br` | `--browser` | `firefox` | Moteur de navigateur Playwright pour les flux de navigateur (`auth-interactive`, `browser-sso`). L'un de `firefox`, `chromium`, `webkit`. |
| `-aprt` | `--auto-prt` | `False` | Pour `browser-sso` : générer automatiquement un cookie PRT à partir du jeton d'actualisation (enregistrement de l'appareil → PRT → `x-ms-RefreshTokenCredential`) afin que le navigateur s'ouvre **déjà authentifié**. Nécessite `cryptography` et un jeton d'actualisation FOCI/broker. |
| `-d` | `--debug` | `False` | Activer la journalisation de débogage. |
| `-dd` | `--verbose-debug` | `False` | Activer la journalisation détaillée des requêtes/réponses HTTP. |
| `-re` | `--redirect-to-file` | `False` | Répliquer toute la sortie console vers `output.txt`. |

---

## Activités

Ci-dessous, chaque activité liste ses arguments **requis** et *optionnels*.
« Jeton » signifie que `-ac` ou `-l` est requis.

### Gestion des jetons

| Activité | Requis | Optionnel | Description |
|----------|----------|----------|-------------|
| `save` | `-ac`, `-n` | `-tid`, `-r` | Enregistrer un jeton d'accès (et éventuellement d'actualisation) dans `.azure_creds`. |
| `list-token` | — | — | Lister les noms de tous les jetons enregistrés. |
| `view` | `-n` | — | Décoder et afficher les revendications JWT d'un jeton enregistré. |
| `delete` | `-n` | — | Supprimer un jeton enregistré du dépôt. |```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

#### Comment fonctionnent les flux d'authentification

AzureRedOps implémente plusieurs manières distinctes d'obtenir des jetons. Choisissez celle qui correspond à votre engagement ; toutes respectent `-s/-n` pour enregistrer automatiquement le résultat.

##### Hameçonnage par code d'appareil (`phish-start` / `phish-capture`)

Le **flux d'autorisation d'appareil** OAuth 2.0 est conçu pour les appareils à saisie limitée, ce qui en fait une primitive d'hameçonnage puissante : vous demandez un code au nom d'une application Microsoft propriétaire, puis vous amenez une cible par ingénierie sociale à saisir ce code sur `https://microsoft.com/devicelogin` alors qu'elle est connectée à son compte. Une fois qu'elle l'a fait, les jetons sont émis **pour vous**.

- `phish-start` demande un code d'appareil et affiche le **code utilisateur**, l'URL de connexion et le **code d'appareil** brut. Comme `-as/--auto-start` a `True` par défaut, il commence immédiatement à interroger le point de terminaison pour obtenir le jeton — donc il suffit généralement d'exécuter `phish-start` et de transmettre le code utilisateur à la cible.
- `phish-capture` est la contrepartie manuelle : fournissez-lui un code d'appareil obtenu précédemment avec `-c/--devicecode` et il interroge le point de terminaison du jeton jusqu'à ce que la victime termine la connexion (l'outil réessaie silencieusement tant que l'autorisation est en attente).
- Utilisez `-app/--appid` pour usurper l'identité d'un client propriétaire spécifique et `-tid/--tenant-id` pour limiter à un locataire (`common` par défaut). Astuce : définissez le champ d'application sur `'https://graph.microsoft.com/.default offline_access openid'` pour obtenir un jeton prêt pour Graph avec un jeton d'actualisation.```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

##### Interactive browser authentication (`auth-interactive`)

`auth-interactive` lance un **vrai navigateur via Playwright** (Firefox par défaut ; choisissez
le moteur avec `-br/--browser`) et permet à
l'opérateur (ou à une cible sur une session partagée) de compléter une connexion interactive — y compris
MFA, l'accès conditionnel et les redirections fédérées/SSO que les flux scriptés ne peuvent pas
satisfaire. Toute la session navigateur est enregistrée dans un fichier HAR (`session.har`) ; l'outil
analyse ensuite cette capture, extrait **chaque** paire de jetons d'accès/actualisation vue sur le
point de terminaison `/oauth2/v2.0/token`, décode chaque JWT, et vous permet de choisir lesquels
enregistrer.

- `-url/--url` définit la ou les pages à ouvrir après le chargement de la page de connexion. Il accepte une
  **liste séparée par des virgules** d'URL (par ex. `https://portal.azure.com,https://outlook.office.com`)
  afin que vous puissiez collecter des jetons pour plusieurs ressources en une seule session. La valeur par défaut est
  `https://portal.azure.com`.
- Cette activité **se sauvegarde toujours automatiquement** : après la récolte, elle demande quel(s) index de jeton
  conserver et un nom sous lequel les stocker.
- Ajoutez `-k/--keep` pour préserver `session.har` pour une analyse hors ligne (il est supprimé par
  défaut).```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

##### Authentification unique du jeton au navigateur (`browser-sso`)

`browser-sso` ouvre un **vrai navigateur déjà authentifié en tant qu’utilisateur** — vous ne cliquez sur rien et arrivez directement, par exemple, dans **Outlook sur le web**. C’est le flux « ouvrez simplement le navigateur et obtenez une session valide ». Le navigateur obtient sa session de l’une des trois manières suivantes, par ordre de préférence :

**1. `-aprt/--auto-prt` — génération automatique d’un cookie PRT (recommandé).**
Le refresh token est transformé par l’outil en **Primary Refresh Token (PRT)** et en cookie navigateur, puis injecté pour qu’ESTS d’Entra termine l’authentification unique sans connexion manuelle. La chaîne (dans `includes/PRT.py`, le protocole ROADtoken / roadtx / AADInternals) est la suivante :

1. Échanger le refresh token contre un jeton **d’enregistrement d’appareil (DRS)**.
2. **Enregistrer un appareil** auprès d’Azure AD → certificat d’appareil + clé de transport.
3. Demander un **PRT + clé de session** avec le refresh token, signé par le certificat de l’appareil.
4. **Dériver le cookie `x-ms-RefreshTokenCredential`** (KDFv2 : SP800-108 KDF sur `SHA256(ctx‖decoded-payload-bytes)` → JWT signé HS256 ; KDFv1 → `AADSTS5000611`, octets incorrects → `AADSTS50058`) et l’injecter dans un nouveau contexte de navigateur.

Le cookie est injecté avec `SameSite=None` et consommé via un **préchauffage `/authorize` ESTS de niveau supérieur** (le client Office `landingv2`) afin que le cookie de session `ESTSAUTH` soit émis en tant que cookie de première partie — après quoi l’application cible s’ouvre déjà connectée. Le cookie est dérivé avec un nouveau nonce juste avant la navigation et réessayé une fois ; si l’authentification unique ne peut toujours pas aboutir, l’outil sonde `prompt=none` et affiche la raison exacte `AADSTS` (par exemple, un accès conditionnel exigeant un appareil conforme/géré, ou une MFA — aucune de ces deux n’est contournable avec un appareil fraîchement enregistré).

Le PRT, la clé de session et le cookie sont affichés (avec une indication `-prt "<value>"` prête à coller) afin que vous puissiez les réutiliser plus tard sans relancer la chaîne.

> **Exigences et opsec pour `-aprt` :**
> - Nécessite le paquet **`cryptography`** (`pip install cryptography` ; il est dans `requirements.txt`).
> - Le refresh token doit appartenir à un client **FOCI / broker** — par exemple, un capturé par **hameçonnage par code d’appareil du Microsoft Authentication Broker** (`29d9ed98-a469-4536-ade2-f981bc1d605e`), ce qui est exactement ce que produit le leurre de code d’appareil SharePoint/OneDrive. L’`-app` par défaut (client FOCI Microsoft Office) fonctionne également.
> - **L’enregistrement d’appareil écrit un objet appareil dans le tenant** — il n’est pas silencieux et laisse un artefact (et exige que l’utilisateur soit autorisé à joindre/enregistrer des appareils).

**2. `-prt/--prt-cookie` — injecter un cookie PRT que vous possédez déjà.**
Si vous détenez déjà une valeur `x-ms-RefreshTokenCredential` (issue d’une exécution précédente de `-aprt`, ou d’un hôte compromis via `ROADtoken`/`browsercore` ou `Mimikatz`), transmettez-la directement et ignorez la chaîne de génération.

**3. Ni l’un ni l’autre — convertir le jeton et se connecter manuellement (secours).**
Sans cookie PRT, le refresh token est échangé contre un jeton d’accès/refresh limité à une ressource (affiché et enregistré avec `-s/-n`), et le navigateur est ouvert sur la cible pour que vous terminiez la connexion à la main.

**Collecte du PRT / des cookies de session.** Lorsque la session du navigateur se termine (délai de fermeture automatique ou vous fermez la fenêtre), `browser-sso` lit le contexte du navigateur actif et **affiche chaque cookie SSO réutilisable qui a été émis** — le cookie PRT (`x-ms-RefreshTokenCredential`) et les cookies de session ESTS (`ESTSAUTH`, `ESTSAUTHPERSISTENT`, ...) — chacun avec une indication `-prt` prête à coller pour que vous puissiez les rejouer la prochaine fois. Les cookies sont interrogés pendant que la session est active, donc la valeur est capturée même si vous fermez la fenêtre prématurément. La même collecte est effectuée à la fin de `auth-interactive`.

- `-url/--url` sélectionne la cible. Utilisez un préréglage pratique — `outlook`, `office`, `teams`, `sharepoint`, `onedrive`, `portal`, `graph` — ou passez une ou plusieurs URL `https://` brutes (séparées par des virgules). La valeur par défaut est `outlook`.
- `-r/--refresh-token` + `-tid` (ou un `-l` mis en cache) fournit le refresh token. `-app/--appid` utilise par défaut le client FOCI Microsoft Office.
- `-br/--browser` choisit le moteur Playwright (Firefox par défaut).
- `-k/--keep` conserve l’enregistrement `session.har` de la session du navigateur.```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

### Pulvérisation de mots de passe

| Activité | Requis | Optionnel | Description |
|----------|----------|----------|-------------|
| `spray` | `-u`, `-p`, `-tid` | `-fp`, `-cp` | Pulvérise des identifiants contre les ID d'applications first-party connus (API v0 + v2.0). |
| `spray-refresh` | `-v`, et (`-l`) **ou** (`-r` + `-tid`) | `-fp`, `-cp` | Rejoue un jeton d'actualisation sur de nombreux ID d'applications. |

Par défaut, les deux activités utilisent `includes/auth_apps.json` comme source d'applications ; remplacez-la avec `-fp`. Ajoutez `-cp` pour tester si chaque connexion réussie peut énumérer les utilisateurs/applications.```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

---

## Sortie et fichiers générés

| Fichier | Créé par | Description |
|------|-----------|-------------|
| `.azure_creds` | Activités de sauvegarde de jetons | Cache JSON local des jetons d'accès/actualisation, indexé par nom. |
| `output.txt` | Option `-re` | Miroir horodaté de toute la sortie console. |
| `session.har` | `auth-interactive` / `browser-sso` | Enregistrement de session navigateur (supprimé sauf si `-k` est défini). |
| `<name>.json` | Option `-j` / `gather-all` | Réponses API enregistrées. |

### Fichiers de données inclus

| Fichier | Description |
|------|-------------|
| `includes/auth_apps.json` | Identifiants d'application cibles utilisés pour le spraying et les listes `interest`. |
| `includes/apps.json` | Identifiants d'applications Microsoft connus et métadonnées pour `knownids`. |
| `includes/Webserver.py` | Listener HTTPS local implémentant la redirection PKCE pour `auth-app`. |
| `includes/PRT.py` | Chaîne de génération de PRT (enregistrement d'appareil → PRT → cookie `x-ms-RefreshTokenCredential`) utilisée par `browser-sso -aprt`. |
| `includes/web/cert.pem`, `includes/web/key.pem` | Matériel TLS pour le listener local. |

---

## Remarques et astuces

- **ID d'application par défaut** (`d3590ed6-52b3-4102-aeff-aad2292ab01c`) est le client
  propriétaire Microsoft Office, qui fonctionne pour la plupart des flux. Les astuces affichées par certaines activités
  suggèrent d'étendre les jetons à l'application **Microsoft Azure CLI** (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`)
  pour un accès plus large.
- **Conseils sur les scopes :** utilisez `-sc openid` pour le password spraying et
  `-sc 'https://graph.microsoft.com/.default'` pour les opérations Graph.
- **`--beta`** bascule `list-users` / `list-applications` vers le point de terminaison beta de Graph,
  ce qui peut révéler des informations supplémentaires (par exemple, les attributs de synchronisation sur site).
- **`auth-app` TLS :** le listener PKCE local nécessite une paire certificat/clé dans
  `includes/web/cert.pem` et `includes/web/key.pem`. Générez une paire auto-signée si
  elles sont absentes, par exemple :  ```bash
  openssl req -x509 -newkey rsa:2048 -nodes \
    -keyout includes/web/key.pem -out includes/web/cert.pem -days 365 -subj "/CN=localhost"