Esegui lo strumento:```bash
python3 AzureRedOps.py -a <activity> [options]

### Fornire un token

Le attività che chiamano Microsoft Graph richiedono un token di accesso. Puoi fornirlo in due modi:

| Method | Flag | Example |
|--------|------|---------|
| Passa un token grezzo | `-ac, --access-token` | `-ac eyJ0eXAi...` |
| Carica un token memorizzato per nome | `-l, --load-access-token` | `-l mytoken` |

Quando si usa `-l`, il `access_token` corrispondente (e, quando rilevante, `refresh_token`
e `tenant`) viene letto dal deposito `.azure_creds`.

### Salvare i token in un file (`-s` / `-n`)

Qualsiasi attività che ottiene token (`auth`, `auth-app`, `auth-interactive`,
`phish-start`/`phish-capture`, `refresh`) può **persisterli automaticamente** nel
deposito di credenziali locale (`.azure_creds`) aggiungendo `-s/--save` insieme a
`-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

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>`, ...).

> Suggerimento: `-j` controlla l'esportazione JSON strutturata, mentre `-re/--redirect-to-file` rispecchia l'output formattato della console su `output.txt`. I due sono indipendenti.

### Tenant identifiers

- `-t, --tenant` si aspetta un **nome di dominio** (es. `contoso.com`) ed è usato dall'attività `id`.
- `-tid, --tenant-id` si aspetta un **GUID del tenant** o `common`, usato dalle attività di autenticazione.

---

## Opzioni da riga di comando

| Short | Long | Default | Descrizione |
|-------|------|---------|-------------|
| `-a` | `--activity` | `id` | **(obbligatorio)** Attività da eseguire (vedi [Activities](#activities)). |
| `-ac` | `--access-token` | | Token di accesso Azure. |
| `-n` | `--name` | | Nome usato per salvare/caricare un token, o nome visualizzato per `register-app`/`new-group`/`invite`. |
| `-t` | `--tenant` | | Nome del **dominio** del tenant Azure (usato da `id`). |
| `-c` | `--devicecode` | | Codice dispositivo (usato da `phish-capture`). |
| `-tid` | `--tenant-id` | | **ID** del tenant Azure (GUID) o `common`. |
| `-app` | `--appid` | `d3590ed6-52b3-4102-aeff-aad2292ab01c` | ID applicazione (client). |
| `-e` | `--endpoint` | `microsoftonline.com` | Dominio dell'endpoint di login da targetizzare. |
| `-r` | `--refresh-token` | | Token di aggiornamento dell'autenticazione. |
| `-as` | `--auto-start` | `True` | Avvia automaticamente la cattura del codice dispositivo dopo `phish-start`. |
| `-l` | `--load-access-token` | | Carica un token dalla cache per nome da `.azure_creds`. |
| `-j` | `--json` | | Salva l'output dell'attività nel file JSON specificato. |
| `-fl` | `--filter` | | Stampa solo gli attributi la cui chiave corrisponde a una di queste (separate da virgola). |
| `-u` | `--username` | | Nome principale utente (email). |
| `-p` | `--password` | | Password utente. |
| `-s` | `--save` | `False` | Salva automaticamente i token ottenuti in `.azure_creds` (**richiede `-n`**). |
| `-cp` | `--check-privileges` | `False` | Dopo un login spray riuscito, verifica se utenti/app possono essere enumerati. |
| `-uid` | `--uid` | | ID oggetto utente Azure (usato da `add-group`). |
| `-headers` | `--headers` | | Intestazioni HTTP aggiuntive in formato JSON, es. `{"X-Foo": "bar"}`. |
| `-gid` | `--gid` | `62e90394-69f5-4237-91f9-056ad24d70a7` | ID ruolo/gruppo directory (predefinito = **Amministratore globale**). |
| `-i` | `--id` | `False` | Per `interest`: stampa solo gli ID delle applicazioni. |
| `-ty` | `--type` | | Per `interest`: filtra per una categoria specifica. |
| `-fp` | `--filepath` | | File da caricare (`push-file`) o elenco personalizzato di app per lo spraying. |
| `-v` | `--version` | `v2.0` | Versione API di autenticazione: `v0` o `v2.0`. |
| `-ua` | `--user-agent` | *(Chrome UA string)* | Sostituisci l'`User-Agent` HTTP. |
| `-au` | `--audience` | `https://graph.microsoft.com` | Pubblico/risorsa del token. |
| `-sc` | `--scope` | `openid offline_access` | Ambito OAuth2. Usa `https://graph.microsoft.com/.default` per Graph, `openid` per lo spraying. |
| `-url` | `--url` | | URL target per `raw-url`/`invite`; elenco di URL separati da virgola per `auth-interactive`. |
| `-beta` | `--beta` | `False` | Usa l'endpoint **beta** di Microsoft Graph per `list-users`/`list-applications`. |
| `-exp` | `--expand` | `False` | Espandi liste/dizionari annidati nell'output in formato leggibile. |
| `-k` | `--keep` | `False` | Mantieni il file `session.har` dopo `auth-interactive` / `browser-sso`. |
| `-cs` | `--client-secret` | | Segreto client riservato usato dal flusso On-Behalf-Of `obo`. |
| `-prt` | `--prt-cookie` | | Valore del cookie PRT (`x-ms-RefreshTokenCredential`) per inizializzare il SSO del browser per `browser-sso`. |
| `-br` | `--browser` | `firefox` | Motore del browser Playwright per i flussi del browser (`auth-interactive`, `browser-sso`). Uno tra `firefox`, `chromium`, `webkit`. |
| `-aprt` | `--auto-prt` | `False` | Per `browser-sso`: genera automaticamente un cookie PRT dal token di aggiornamento (registrazione dispositivo → PRT → `x-ms-RefreshTokenCredential`) in modo che il browser si apra **già autenticato**. Richiede `cryptography` e un token di aggiornamento FOCI/broker. |
| `-d` | `--debug` | `False` | Abilita il logging di debug. |
| `-dd` | `--verbose-debug` | `False` | Abilita il logging dettagliato delle richieste/risposte HTTP. |
| `-re` | `--redirect-to-file` | `False` | Rispecchia tutto l'output della console su `output.txt`. |

---

## Attività

Di seguito, ogni attività elenca i suoi argomenti **obbligatori** e *opzionali*.
"Token" significa che è richiesto `-ac` o `-l`.

### Gestione Token

| Attività | Obbligatorio | Opzionale | Descrizione |
|----------|--------------|-----------|-------------|
| `save` | `-ac`, `-n` | `-tid`, `-r` | Salva un token di accesso (e opzionalmente di aggiornamento) in `.azure_creds`. |
| `list-token` | — | — | Elenca i nomi di tutti i token salvati. |
| `view` | `-n` | — | Decodifica e mostra i claims JWT di un token salvato. |
| `delete` | `-n` | — | Rimuove un token salvato dall'archivio. |```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

#### Come funzionano i flussi di autenticazione

AzureRedOps implementa diversi modi distinti per ottenere token. Scegli quello che
si adatta al tuo engagement; tutti rispettano `-s/-n` per il salvataggio automatico del risultato.

##### Phishing con codice dispositivo (`phish-start` / `phish-capture`)

La **concessione di autorizzazione per dispositivo** di OAuth 2.0 è progettata per dispositivi con
input limitato, il che la rende una potente primitiva di phishing: richiedi un codice per conto di
un'applicazione Microsoft di prima parte, poi ingegnerizzi socialmente un target affinché inserisca quel
codice su `https://microsoft.com/devicelogin` mentre è autenticato con il proprio account. Una volta
fatto, i token vengono emessi **a te**.

- `phish-start` richiede un codice dispositivo e stampa il **codice utente**, l'URL di login,
  e il **codice dispositivo** grezzo. Poiché `-as/--auto-start` è predefinito su `True`, inizia
  immediatamente a interrogare per il token — quindi basta eseguire `phish-start` e
  consegnare il codice utente al target, di solito è tutto ciò che serve.
- `phish-capture` è la controparte manuale: fornisci un codice dispositivo ottenuto in precedenza
  con `-c/--devicecode` e interroga l'endpoint del token fino a quando la vittima completa il
  login (lo strumento riprova silenziosamente mentre l'autorizzazione è in sospeso).
- Usa `-app/--appid` per impersonare un client specifico di prima parte e `-tid/--tenant-id`
  per limitare a un tenant (`common` di default). Consiglio: imposta l'ambito su
  `'https://graph.microsoft.com/.default offline_access openid'` per ottenere un token pronto per Graph
  con un token di aggiornamento.```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` avvia un **browser reale tramite Playwright** (Firefox di default; scegli il motore con `-br/--browser`) e permette all'operatore (o a un target in una sessione condivisa) di completare un login interattivo — inclusi MFA, Accesso Condizionato e reindirizzamenti federati/SSO che i flussi scriptati non possono soddisfare. L'intera sessione del browser viene registrata in un file HAR (`session.har`); il tool analizza quindi quella cattura, estrae **ogni** coppia di token di accesso/refresh vista sull'endpoint `/oauth2/v2.0/token`, decodifica ogni JWT, e permette di scegliere quale/i salvare.

- `-url/--url` imposta la/e pagina/e a cui navigare dopo che la pagina di login si è caricata. Accetta un **elenco separato da virgole** di URL (ad es. `https://portal.azure.com,https://outlook.office.com`) in modo da poter raccogliere token per più risorse in una sola sessione. Il valore predefinito è `https://portal.azure.com`.
- Questa attività **salva automaticamente sempre**: dopo la raccolta, richiede quali indici di token mantenere e un nome sotto cui salvarli.
- Aggiungi `-k/--keep` per conservare `session.har` per analisi offline (viene eliminato di default).```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

##### Single sign-on dal token al browser (`browser-sso`)

`browser-sso` apre un **browser reale già autenticato come utente** — non clicchi nulla e atterri direttamente all'interno, per esempio, **Outlook sul web**. Questo è il flusso "apri il browser e ottieni una sessione valida". Il browser ottiene la sua sessione in uno di tre modi, in ordine di preferenza:

**1. `-aprt/--auto-prt` — generazione automatica del cookie PRT (consigliato).**
Il refresh token viene convertito in un **Primary Refresh Token (PRT)** e nel suo cookie del browser interamente dallo strumento, poi iniettato in modo che l'ESTS di Entra completi l'SSO senza login manuale. La catena (in `includes/PRT.py`, il protocollo ROADtoken / roadtx / AADInternals) è:

1. Riscatta il refresh token per un token **DRS (device-registration)**.
2. **Registra un dispositivo** con Azure AD → certificato del dispositivo + chiave di trasporto.
3. Richiedi un **PRT + chiave di sessione** con il refresh token, firmati dal certificato del dispositivo.
4. **Deriva il cookie `x-ms-RefreshTokenCredential`** (KDFv2: KDF SP800-108 su `SHA256(ctx‖decoded-payload-bytes)` → JWT firmato HS256; KDFv1 → `AADSTS5000611`, bytes sbagliati → `AADSTS50058`)
   e inietta in un nuovo contesto del browser.

Il cookie viene iniettato con `SameSite=None` e consumato tramite un **riscaldamento ESTS `/authorize` di primo livello** (il client Office `landingv2`) in modo che il cookie di sessione `ESTSAUTH` venga creato first-party — dopodiché l'app target si apre già autenticata. Il cookie viene derivato con un nuovo nonce appena prima della navigazione e ritentato una volta; se l'SSO ancora non riesce, lo strumento sonda `prompt=none` e stampa la ragione esatta `AADSTS` (es. Conditional Access che richiede un dispositivo conforme/gestito, o MFA — nessuno dei due è aggirabile con un dispositivo appena registrato).

Il PRT, la chiave di sessione e il cookie vengono stampati (con un suggerimento `-prt "<value>"` pronto per essere copiato) in modo che tu possa riutilizzarli in seguito senza rieseguire la catena.

> **Requisiti e opsec per `-aprt`:**
> - Necessita del pacchetto **`cryptography`** (`pip install cryptography`; è in `requirements.txt`).
> - Il refresh token deve appartenere a un **client FOCI / broker** — ad esempio, uno catturato tramite **device-code phishing del Microsoft Authentication Broker** (`29d9ed98-a469-4536-ade2-f981bc1d605e`), che è esattamente ciò che produce il lure device-code di SharePoint/OneDrive. Il `-app` predefinito (client Microsoft Office FOCI) funziona anche.
> - **La registrazione del dispositivo scrive un oggetto dispositivo nel tenant** — non è silenziosa e lascia un artefatto (e richiede che l'utente sia autorizzato a unire/registrare dispositivi).

**2. `-prt/--prt-cookie` — inietta un cookie PRT che hai già.**
Se possiedi già un valore `x-ms-RefreshTokenCredential` (da una precedente esecuzione di `-aprt`, o da un host compromesso tramite `ROADtoken`/`browsercore` o `Mimikatz`), passalo direttamente e salta la catena di generazione.

**3. Nessuno dei due — converti il token e accedi manualmente (fallback).**
Senza cookie PRT, il refresh token viene riscattato per un token di accesso/refresh con ambito risorsa (stampato e salvato con `-s/-n`), e il browser viene aperto all'indirizzo target per completare il login manualmente.

**Raccolta di PRT / cookie di sessione.** Quando la sessione del browser termina (timeout di chiusura automatica o chiudi la finestra), `browser-sso` legge il contesto live del browser e **stampa ogni cookie SSO riutilizzabile che è stato emesso** — il cookie PRT (`x-ms-RefreshTokenCredential`) e i cookie di sessione ESTS (`ESTSAUTH`, `ESTSAUTHPERSISTENT`, ...) — ciascuno con un suggerimento `-prt` pronto per essere copiato in modo da poterli riutilizzare la prossima volta. I cookie vengono interrogati mentre la sessione è attiva, quindi il valore viene catturato anche se chiudi la finestra presto. La stessa raccolta viene eseguita alla fine di `auth-interactive`.

- `-url/--url` seleziona il target. Usa un preset amichevole — `outlook`, `office`, `teams`, `sharepoint`, `onedrive`, `portal`, `graph` — o passa uno o più URL `https://` grezzi (separati da virgole). Il default è `outlook`.
- `-r/--refresh-token` + `-tid` (o un `-l` dalla cache) fornisce il refresh token. `-app/--appid` predefinito al client Microsoft Office FOCI.
- `-br/--browser` sceglie il motore Playwright (Firefox di default).
- `-k/--keep` preserva la registrazione `session.har` della sessione del browser.```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

| Activity | Required | Optional | Description |
|----------|----------|----------|-------------|
| `spray` | `-u`, `-p`, `-tid` | `-fp`, `-cp` | Spray delle credenziali contro ID di app di prima parte noti (API v0 + v2.0). |
| `spray-refresh` | `-v`, e (`-l`) **oppure** (`-r` + `-tid`) | `-fp`, `-cp` | Riproduci un token di refresh su molti ID di app. |

Per impostazione predefinita, entrambe le attività usano `includes/auth_apps.json` come fonte delle app; sostituisci con `-fp`. Aggiungi `-cp` per testare se ogni login riuscito può enumerare utenti/app.```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

---

## Output e file generati

| File | Creato da | Descrizione |
|------|-----------|-------------|
| `.azure_creds` | Attività di salvataggio token | Cache JSON locale dei token di accesso/refresh, indicizzata per nome. |
| `output.txt` | flag `-re` | Specchio con timestamp di tutto l'output della console. |
| `session.har` | `auth-interactive` / `browser-sso` | Registrazione della sessione del browser (eliminata a meno che non sia impostato `-k`). |
| `<name>.json` | flag `-j` / `gather-all` | Risposte API salvate. |

### File dati inclusi

| File | Descrizione |
|------|-------------|
| `includes/auth_apps.json` | ID delle applicazioni target utilizzati per lo spraying e le liste `interest`. |
| `includes/apps.json` | ID delle app Microsoft noti e metadati per `knownids`. |
| `includes/Webserver.py` | Listener HTTPS locale che implementa il reindirizzamento PKCE per `auth-app`. |
| `includes/PRT.py` | Catena di coniazione PRT (registrazione dispositivo → PRT → cookie `x-ms-RefreshTokenCredential`) utilizzata da `browser-sso -aprt`. |
| `includes/web/cert.pem`, `includes/web/key.pem` | Materiale TLS per il listener locale. |

---

## Note e suggerimenti

- **ID app predefinito** (`d3590ed6-52b3-4102-aeff-aad2292ab01c`) è il client first-party di Microsoft Office, che funziona per la maggior parte dei flussi. I suggerimenti stampati da alcune attività suggeriscono di estendere i token all'app **Microsoft Azure CLI** (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`) per un accesso più ampio.
- **Guida agli ambiti:** utilizzare `-sc openid` per lo spraying delle password e `-sc 'https://graph.microsoft.com/.default'` per le operazioni su Graph.
- **`--beta`** passa `list-users` / `list-applications` all'endpoint beta di Graph, che può mostrare informazioni extra (es. attributi di sincronizzazione on-prem).
- **`auth-app` TLS:** il listener PKCE locale richiede una coppia certificato/chiave in `includes/web/cert.pem` e `includes/web/key.pem`. Generare una coppia autofirmata se mancanti, ad esempio:
  ```bash
  openssl req -new -x509 -keyout includes/web/key.pem -out includes/web/cert.pem -days 365 -nodes
  ```  ```bash
  openssl req -x509 -newkey rsa:2048 -nodes \
    -keyout includes/web/key.pem -out includes/web/cert.pem -days 365 -subj "/CN=localhost"