Execute a ferramenta:```bash
python3 AzureRedOps.py -a <activity> [options]

### Fornecendo um token

Atividades que chamam o Microsoft Graph precisam de um token de acesso. Você pode fornecê-lo de duas maneiras:

| Método | Flag | Exemplo |
|--------|------|---------|
| Passar um token bruto | `-ac, --access-token` | `-ac eyJ0eXAi...` |
| Carregar um token em cache pelo nome | `-l, --load-access-token` | `-l mytoken` |

Quando `-l` é usado, o `access_token` correspondente (e, quando relevante, `refresh_token`
e `tenant`) é lido do armazenamento `.azure_creds`.

### Salvando tokens em um arquivo (`-s` / `-n`)

Qualquer atividade que obtenha tokens (`auth`, `auth-app`, `auth-interactive`,
`phish-start`/`phish-capture`, `refresh`) pode **persisti-los automaticamente** no
armazenamento local de credenciais (`.azure_creds`) ao adicionar `-s/--save` junto com
`-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`, o nome do arquivo fornecido é usado como sufixo e um arquivo é escrito
por endpoint do Graph (ex.: `users-<name>`, `groups-<name>`, ...).

> Dica: `-j` controla a exportação JSON estruturada, enquanto `-re/--redirect-to-file` espelha
> a saída do console formatada para `output.txt`. Os dois são independentes.

### Identificadores do inquilino

- `-t, --tenant` espera um **nome de domínio** (ex.: `contoso.com`) e é usado pela atividade `id`.
- `-tid, --tenant-id` espera um **GUID do inquilino** ou `common`, usado pelas atividades de autenticação.

---

## Opções de Linha de Comando

| Curto | Longo | Padrão | Descrição |
|-------|-------|--------|-----------|
| `-a` | `--activity` | `id` | **(obrigatório)** Atividade a ser realizada (veja [Atividades](#activities)). |
| `-ac` | `--access-token` | | Token de acesso do Azure. |
| `-n` | `--name` | | Nome usado para salvar/carregar um token, ou nome de exibição para `register-app`/`new-group`/`invite`. |
| `-t` | `--tenant` | | Nome de **domínio** do inquilino do Azure (usado por `id`). |
| `-c` | `--devicecode` | | Código do dispositivo (usado por `phish-capture`). |
| `-tid` | `--tenant-id` | | **ID** do inquilino do Azure (GUID) ou `common`. |
| `-app` | `--appid` | `d3590ed6-52b3-4102-aeff-aad2292ab01c` | ID do aplicativo (cliente). |
| `-e` | `--endpoint` | `microsoftonline.com` | Domínio do endpoint de login para alvo. |
| `-r` | `--refresh-token` | | Token de atualização de autenticação. |
| `-as` | `--auto-start` | `True` | Iniciar automaticamente a captura do código do dispositivo após `phish-start`. |
| `-l` | `--load-access-token` | | Carregar um token em cache pelo nome de `.azure_creds`. |
| `-j` | `--json` | | Salvar a saída da atividade no arquivo JSON fornecido. |
| `-fl` | `--filter` | | Imprimir apenas atributos cuja chave corresponda a um destes (separados por vírgula). |
| `-u` | `--username` | | Nome principal do usuário (email). |
| `-p` | `--password` | | Senha do usuário. |
| `-s` | `--save` | `False` | Salvar automaticamente os tokens obtidos em `.azure_creds` (**requer `-n`**). |
| `-cp` | `--check-privileges` | `False` | Após um login de spray bem-sucedido, verificar se usuários/aplicativos podem ser enumerados. |
| `-uid` | `--uid` | | ID do objeto do usuário do Azure (usado por `add-group`). |
| `-headers` | `--headers` | | Cabeçalhos HTTP extras como JSON, ex.: `{"X-Foo": "bar"}`. |
| `-gid` | `--gid` | `62e90394-69f5-4237-91f9-056ad24d70a7` | ID de função de diretório / grupo (padrão = **Administrador Global**). |
| `-i` | `--id` | `False` | Para `interest`: imprimir apenas os IDs do aplicativo. |
| `-ty` | `--type` | | Para `interest`: filtrar para uma categoria específica. |
| `-fp` | `--filepath` | | Arquivo para fazer upload (`push-file`) ou lista de aplicativos personalizada para spraying. |
| `-v` | `--version` | `v2.0` | Versão da API de autenticação: `v0` ou `v2.0`. |
| `-ua` | `--user-agent` | *(string UA Chrome)* | Substituir o `User-Agent` HTTP. |
| `-au` | `--audience` | `https://graph.microsoft.com` | Público-alvo/recurso do token. |
| `-sc` | `--scope` | `openid offline_access` | Escopo OAuth2. Use `https://graph.microsoft.com/.default` para Graph, `openid` para spraying. |
| `-url` | `--url` | | URL alvo para `raw-url`/`invite`; lista separada por vírgula de URLs para `auth-interactive`. |
| `-beta` | `--beta` | `False` | Usar o endpoint **beta** do Microsoft Graph para `list-users`/`list-applications`. |
| `-exp` | `--expand` | `False` | Expandir listas/dicionários aninhados na saída para um formato legível por humanos. |
| `-k` | `--keep` | `False` | Manter o arquivo `session.har` após `auth-interactive` / `browser-sso`. |
| `-cs` | `--client-secret` | | Segredo de cliente confidencial usado pela concessão `obo` On-Behalf-Of. |
| `-prt` | `--prt-cookie` | | Valor do cookie PRT (`x-ms-RefreshTokenCredential`) para semear SSO do navegador para `browser-sso`. |
| `-br` | `--browser` | `firefox` | Mecanismo do navegador Playwright para os fluxos do navegador (`auth-interactive`, `browser-sso`). Um de `firefox`, `chromium`, `webkit`. |
| `-aprt` | `--auto-prt` | `False` | Para `browser-sso`: emitir automaticamente um cookie PRT a partir do token de atualização (registro de dispositivo → PRT → `x-ms-RefreshTokenCredential`) para que o navegador abra **já autenticado**. Requer `cryptography` e um token de atualização FOCI/broker. |
| `-d` | `--debug` | `False` | Habilitar log de depuração. |
| `-dd` | `--verbose-debug` | `False` | Habilitar log detalhado de requisição/resposta HTTP. |
| `-re` | `--redirect-to-file` | `False` | Espelhar toda a saída do console para `output.txt`. |

---

## Atividades

Abaixo, cada atividade lista seus argumentos **obrigatórios** e *opcionais*.
'Token' significa que `-ac` ou `-l` é obrigatório.

### Gerenciamento de Token

| Atividade | Obrigatório | Opcional | Descrição |
|-----------|-------------|----------|-----------|
| `save` | `-ac`, `-n` | `-tid`, `-r` | Salvar um token de acesso (e token de atualização opcional) em `.azure_creds`. |
| `list-token` | — | — | Listar os nomes de todos os tokens salvos. |
| `view` | `-n` | — | Decodificar e exibir as declarações JWT de um token salvo. |
| `delete` | `-n` | — | Remover um token salvo do armazenamento. |```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

#### Como os fluxos de autenticação funcionam

O AzureRedOps implementa várias formas distintas de obter tokens. Escolha aquela que
se adequa ao seu engajamento; todas respeitam `-s/-n` para salvar automaticamente o resultado.

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

A **concessão de autorização de dispositivo** do OAuth 2.0 é projetada para dispositivos
com restrição de entrada, o que a torna uma primitiva de phishing poderosa: você solicita um código
em nome de um aplicativo Microsoft de primeira parte e, em seguida, faz engenharia social para que um
alvo insira esse código em `https://microsoft.com/devicelogin` enquanto está logado em sua conta.
Assim que o fizer, os tokens são emitidos **para você**.

- `phish-start` solicita um código de dispositivo e imprime o **código de usuário**, a URL de login
  e o **código de dispositivo** bruto. Como `-as/--auto-start` padrão é `True`, ele então
  começa imediatamente a consultar o token — então simplesmente executar `phish-start` e
  entregar o código de usuário ao alvo geralmente é tudo que você precisa.
- `phish-capture` é a contraparte manual: forneça a ele um código de dispositivo obtido anteriormente
  com `-c/--devicecode` e ele consulta o endpoint do token até que a vítima complete o
  login (a ferramenta tenta novamente silenciosamente enquanto a autorização estiver pendente).
- Use `-app/--appid` para personificar um cliente específico de primeira parte e `-tid/--tenant-id`
  para definir o escopo para um inquilino (`common` por padrão). Dica: defina o escopo para
  `'https://graph.microsoft.com/.default offline_access openid'` para obter um token pronto para Graph
  com um token de atualização.```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

##### Autenticação interativa no navegador (`auth-interactive`)

`auth-interactive` inicia um **navegador real via Playwright** (Firefox por padrão; escolha o motor com `-br/--browser`) e permite que o operador (ou um alvo numa sessão compartilhada) complete um login interativo — incluindo MFA, Acesso Condicional e redirecionamentos federados/SSO que fluxos scriptados não conseguem satisfazer. Toda a sessão do navegador é gravada num arquivo HAR (`session.har`); a ferramenta então analisa essa captura, extrai **todos** os pares de token de acesso/atualização vistos no endpoint `/oauth2/v2.0/token`, decodifica cada JWT, e permite que você escolha qual(is) salvar.

- `-url/--url` define a(s) página(s) para navegar após o carregamento da página de login. Aceita uma **lista separada por vírgulas** de URLs (ex.: `https://portal.azure.com,https://outlook.office.com`) para que você possa coletar tokens para múltiplos recursos numa única sessão. O padrão é `https://portal.azure.com`.

- Esta atividade **sempre salva automaticamente**: após a colheita, pergunta qual(is) índice(s) de token manter e um nome para armazená-los.

- Adicione `-k/--keep` para preservar `session.har` para análise offline (é excluído por padrão).```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

##### Logon único de token para navegador (`browser-sso`)

`browser-sso` abre um **navegador real que já está autenticado como o usuário** — você
não clica em nada e cai diretamente dentro, por exemplo, do **Outlook na web**. Este é o
fluxo "apenas abra o navegador e obtenha uma sessão válida". O navegador obtém sua sessão de uma
de três maneiras, em ordem de preferência:

**1. `-aprt/--auto-prt` — criar automaticamente um cookie PRT (recomendado).**
O token de atualização é transformado em um **Token de Atualização Primário (PRT)** e seu cookie de navegador
inteiramente pela ferramenta, então semeado para que o ESTS da Entra complete o SSO sem login manual. A
cadeia (em `includes/PRT.py`, o protocolo ROADtoken / roadtx / AADInternals) é:

1. Resgatar o token de atualização por um token de **registro de dispositivo (DRS)**.
2. **Registrar um dispositivo** no Azure AD → certificado do dispositivo + chave de transporte.
3. Solicitar um **PRT + chave de sessão** com o token de atualização, assinado pelo certificado do dispositivo.
4. **Derivar o cookie `x-ms-RefreshTokenCredential`** (KDFv2: SP800-108 KDF sobre `SHA256(ctx‖decoded-payload-bytes)` → JWT assinado com HS256; KDFv1 → `AADSTS5000611`, bytes-errados → `AADSTS50058`)
   e semeá-lo em um contexto de navegador limpo.

O cookie é semeado com `SameSite=None` e consumido via um **aquecimento `/authorize` do ESTS de nível superior**
(o cliente `landingv2` do Office) para que o cookie de sessão `ESTSAUTH` seja cunhado
como first-party — após o qual o aplicativo de destino abre já conectado. O cookie é derivado com
um novo nonce pouco antes de navegar e tentado novamente uma vez; se o SSO ainda não puder completar, a ferramenta
verifica `prompt=none` e imprime o motivo exato do `AADSTS` (ex.: Acesso Condicional exigindo um
dispositivo compatível/gerenciado, ou MFA — nenhum dos quais é contornável com um dispositivo recém-registrado).

O PRT, a chave de sessão e o cookie são impressos (com uma dica `-prt "<value>"` pronta para copiar)
para que você possa reutilizá-los mais tarde sem reexecutar a cadeia.

> **Requisitos e opsec para `-aprt`:**
> - Precisa do pacote **`cryptography`** (`pip install cryptography`; ele está em
>   `requirements.txt`).
> - O token de atualização deve pertencer a um **cliente FOCI / broker** — ex.: um capturado por
>   **phishing de código de dispositivo no Microsoft Authentication Broker**
>   (`29d9ed98-a469-4536-ade2-f981bc1d605e`), que é exatamente o que a isca de código de dispositivo do SharePoint/OneDrive
>   produz. O `-app` padrão (cliente Microsoft Office FOCI) também funciona.
> - **O registro de dispositivo escreve um objeto de dispositivo no tenant** — não é silencioso e
>   deixa um artefato (e exige que o usuário tenha permissão para ingressar/registrar dispositivos).

**2. `-prt/--prt-cookie` — semear um cookie PRT que você já possui.**
Se você já possui um valor `x-ms-RefreshTokenCredential` (de uma execução anterior do `-aprt`, ou
de um host comprometido via `ROADtoken`/`browsercore` ou `Mimikatz`), passe-o diretamente e
pule a cadeia de criação.

**3. Nenhum dos dois — converter o token e fazer login manualmente (fallback).**
Sem um cookie PRT, o token de atualização é resgatado por um token de acesso/atualização com escopo de recurso
(impresso e salvo com `-s/-n`), e o navegador é aberto no destino para você
finalizar o login manualmente.

**Coleta de PRT / cookies de sessão.** Quando a sessão do navegador termina (tempo limite de fechamento automático ou
você fecha a janela), `browser-sso` lê o contexto do navegador ao vivo e **imprime todos os
cookies SSO reutilizáveis que foram emitidos** — o cookie PRT (`x-ms-RefreshTokenCredential`) e
os cookies de sessão do ESTS (`ESTSAUTH`, `ESTSAUTHPERSISTENT`, ...) — cada um com uma dica
`-prt` pronta para copiar para que você possa reproduzi-los na próxima vez. Os cookies são verificados enquanto a sessão estiver ativa,
para que o valor seja capturado mesmo se você fechar a janela cedo. A mesma coleta é executada ao final
de `auth-interactive`.

- `-url/--url` seleciona o destino. Use um predefinido amigável — `outlook`, `office`, `teams`,
  `sharepoint`, `onedrive`, `portal`, `graph` — ou passe uma ou mais URLs `https://` brutas
  (separadas por vírgulas). O padrão é `outlook`.
- `-r/--refresh-token` + `-tid` (ou um `-l` em cache) fornece o token de atualização.
  `-app/--appid` assume como padrão o cliente Microsoft Office FOCI.
- `-br/--browser` escolhe o mecanismo do Playwright (Firefox por padrão).
- `-k/--keep` preserva a gravação `session.har` da sessão do 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

### Pulverização de Senhas

| Atividade | Obrigatório | Opcional | Descrição |
|-----------|-------------|----------|-------------|
| `spray` | `-u`, `-p`, `-tid` | `-fp`, `-cp` | Pulverizar credenciais contra IDs de aplicativos de primeira parte conhecidos (APIs v0 + v2.0). |
| `spray-refresh` | `-v`, and (`-l`) **or** (`-r` + `-tid`) | `-fp`, `-cp` | Reproduzir um token de atualização em muitos IDs de aplicativos. |

Por padrão, ambas as atividades usam `includes/auth_apps.json` como fonte de aplicativos; substitua com `-fp`. Adicione `-cp` para testar se cada login bem-sucedido pode enumerar usuários/aplicativos.```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

---

## Saída & Arquivos Gerados

| Arquivo | Criado por | Descrição |
|--------|-----------|-------------|
| `.azure_creds` | Atividades de salvamento de tokens | Cache local JSON de tokens de acesso/atualização, indexados por nome. |
| `output.txt` | flag `-re` | Espelho com timestamp de toda a saída do console. |
| `session.har` | `auth-interactive` / `browser-sso` | Gravação de sessão do navegador (excluída a menos que `-k` esteja definido). |
| `<name>.json` | flag `-j` / `gather-all` | Respostas de API salvas. |

### Arquivos de dados incluídos

| Arquivo | Descrição |
|--------|-------------|
| `includes/auth_apps.json` | IDs de aplicativo alvo usados para pulverização (spraying) e as listas `interest`. |
| `includes/apps.json` | IDs de aplicativo conhecidos da Microsoft e metadados para `knownids`. |
| `includes/Webserver.py` | Listener HTTPS local implementando o redirecionamento PKCE para `auth-app`. |
| `includes/PRT.py` | Cadeia de cunhagem 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 o listener local. |

---

## Notas & Dicas

- **ID de aplicativo padrão** (`d3590ed6-52b3-4102-aeff-aad2292ab01c`) é o cliente interno (first-party) do Microsoft Office, que funciona para a maioria dos fluxos. As dicas impressas por algumas atividades sugerem estender os tokens para o aplicativo **Microsoft Azure CLI** (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`) para acesso mais amplo.
- **Orientação de escopo:** use `-sc openid` para password spraying e `-sc 'https://graph.microsoft.com/.default'` para operações no Graph.
- **`--beta`** altera `list-users` / `list-applications` para o endpoint beta do Graph, que pode exibir informações extras (por exemplo, atributos de sincronização local (on-prem)).
- **`auth-app` TLS:** o listener PKCE local requer um par de certificado/chave em `includes/web/cert.pem` e `includes/web/key.pem`. Gere um par autoassinado se estiverem faltando, por exemplo:  ```bash
  openssl req -x509 -newkey rsa:2048 -nodes \
    -keyout includes/web/key.pem -out includes/web/cert.pem -days 365 -subj "/CN=localhost"