# T1528 - Steal Application Access Token
> [!danger] Técnica de Credential Access - Cloud / SaaS / Identidade
> **Tática:** Credential Access | **Plataformas:** SaaS, IaaS, Containers, Office Suite, Identity Provider | **MITRE ID:** T1528
> Adversários roubam tokens de acesso a aplicações (OAuth, JWT, tokens de serviço Kubernetes, tokens de Managed Identity) para impersonar usuários e serviços legítimos sem necessidade de conhecer credenciais primárias.
## Descrição
A técnica **T1528 - Steal Application Access Token** descreve como adversários roubam tokens de acesso a aplicações - OAuth tokens, JWT (JSON Web Tokens), tokens de serviço Kubernetes, tokens de Managed Identity Azure, tokens de Service Account GCP - para realizar ações autorizadas em sistemas e APIs em nome de usuários ou serviços legítimos, sem necessidade de comprometer senhas.
Tokens de acesso a aplicações são o mecanismo fundamental de autorização em arquiteturas cloud-native, SaaS e APIs modernas. Ao contrário de credenciais tradicionais (usuário + senha), tokens são:
- **Temporários:** têm tempo de expiração (segundos a horas), mas adversários frequentemente também roubam **refresh tokens** para obter novos access tokens indefinidamente
- **Delegados:** representam a autorização de um usuário ou serviço para um escopo específico de recursos
- **Opacos à MFA:** uma vez que o token foi gerado após autenticação com MFA, seu uso subsequente geralmente não requer novo fator de autenticação
O cenário de roubo mais crítico envolve **OAuth 2.0** - o protocolo padrão de autorização usado por Microsoft 365, Google Workspace, Salesforce, GitHub e práticamente todos os provedores de identidade modernos. Adversários constroem aplicações OAuth maliciosas ou sequestram tokens existentes para ganhar acesso persistente a recursos cloud, e-mail, documentos e dados corporativos.
**Principais vetores de roubo de tokens:**
1. **Aplicações OAuth maliciosas (Consent Phishing):** O adversário registra uma aplicação legítima no Azure AD/Google Workspace/Okta, e via [[t1566-002-spearphishing-link|T1566.002 - Spearphishing Link]] engana o usuário alvo a conceder acesso OAuth à aplicação maliciosa. Uma vez concedida a permissão, o adversário tem acesso aos recursos do usuário através do token - potencialmente por tempo indeterminado se um refresh token for obtido.
2. **Roubo de tokens de sessão de containers/CI-CD:** Em ambientes Kubernetes, cada pod tem um token de service account montado em `/var/run/secrets/kubernetes.io/serviceaccount/token`. Se um container for comprometido, o adversário pode extrair este token para interagir com a API Kubernetes com as permissões do service account - potencialmente executando commandos em outros pods, exfiltrando segredos, ou escalando privilégios dentro do cluster.
3. **Azure Instance Metadata Service (IMDS) - Managed Identity:** Similar à técnica [[t1552-005-cloud-instance-metadata-api|T1552.005]], recursos Azure com Managed Identity atrelada permitem que adversários que comprometem a VM/container solicitem tokens de acesso de curta duração via IMDS, que podem ser usados para acessar outros serviços Azure (Key Vault, Storage, SQL Database) sem credenciais hardcoded.
4. **Roubo de tokens de pipelines CI/CD:** Ambientes de integração e entrega contínua (GitHub Actions, GitLab CI, CircleCI, Jenkins) frequentemente injetam tokens de API (para npm, PyPI, registros de containers, AWS, Azure) como variáveis de ambiente. Se o pipeline for comprometido por supply chain attack ou código malicioso em um PR, esses tokens podem ser exfiltrados.
5. **Interceptação via Man-in-the-Middle / Logging inadvertido:** Tokens que aparecem em URLs (como query parameters `?token=...`), logs de acesso de servidores web, ou logs de aplicação representam tokens expostos que adversários com acesso a esses logs podem reutilizar.
Os grupos [[g0016-apt29|APT29]] (Cozy Bear / Midnight Blizzard) e [[g0007-apt28|APT28]] (Fancy Bear) são os atores mais documentados no uso avançado desta técnica, particularmente em suas campanhas contra organizações governamentais, think tanks e empresas de tecnologia usando consent phishing OAuth e roubo de tokens de sessão M365.
## Como Funciona
### Fluxo OAuth 2.0 - Authorization Code Grant (alvo mais comum)
O fluxo legítimo do OAuth 2.0 funciona assim:
1. Aplicação redireciona usuário ao Identity Provider (Microsoft, Google, Okta) com `client_id`, `redirect_uri`, e `scope`
2. Usuário faz login e consente com as permissões solicitadas
3. Identity Provider retorna um `authorization_code` para o `redirect_uri`
4. Aplicação troca o `authorization_code` por `access_token` + `refresh_token`
5. Aplicação usa o `access_token` para chamar APIs (Microsoft Graph, Google APIs, etc.)
**Abuso via Consent Phishing:**
O adversário registra uma aplicação maliciosa com nome e ícone de uma aplicação legítima (ex: "Microsoft Teams Connector", "Zoom Integration"). A aplicação solicita escopos amplos: `Mail.Read`, `Files.ReadWrite.All`, `Calendars.Read`, `offline_access` (este último permite obter refresh token para acesso persistente). O usuário engana-se ao ver a tela de consentimento do Microsoft/Google e aprova o acesso. O adversário agora tem um refresh token válido com acesso persistente ao e-mail, arquivos e calendário do usuário.
### Kubernetes Service Account Token
Dentro de pods Kubernetes, o token de service account é automaticamente montado:
```
/var/run/secrets/kubernetes.io/serviceaccount/token
```
Com este token, é possível:
```bash
# Enumerar recursos do cluster com as permissões do service account
kubectl --token=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) get pods -n kube-system
kubectl --token=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) get secrets
```
Se o service account tiver permissões excessivas (ClusterAdmin ou `get/list/creaté` em secrets), o adversário pode exfiltrar outros segredos do cluster, escalar privilégios ou criar novos pods maliciosos.
### AADInternals - Roubo de Tokens Azure AD
A ferramenta [[s0677-aadinternals|AADInternals]] é amplamente utilizada em operações de red team e por adversários reais para manipulação de tokens Azure AD. Permite:
- Obter tokens de access para Microsoft Graph, Azure Resource Manager, SharePoint
- Persistência via criação de tokens de refresh de longa duração
- Impersonação de usuários com tokens roubados
- Bypass de Conditional Access em alguns cenários
## Attack Flow
```mermaid
graph TB
A[Reconhecimento: Identificar plataformas cloud e SaaS do alvo] --> B{Vetor de Roubo de Token}
B --> C[Consent Phishing: Aplicação OAuth maliciosa]
B --> D[Comprometimento de container Kubernetes]
B --> E[Compromisso de pipeline CI/CD]
B --> F[Roubo de token via IMDS Azure/GCP]
C --> G[Usuário concede acesso OAuth via link de phishing]
D --> H[Extrair /var/run/secrets/kubernetes.io/serviceaccount/token]
E --> I[Exfiltrar tokens de env vars ou logs do pipeline]
F --> J[Requisição ao IMDS: obter token de Managed Identity]
G --> K[Obter access_token + refresh_token do Identity Provider]
H --> L[Usar token para chamadas à Kubernetes API]
I --> M[Usar tokens de CI/CD para acessar registros/repositórios]
J --> N[Usar token Azure para acessar Key Vault, Storage, SQL]
K --> O{Escopo dos tokens obtidos}
L --> O
M --> O
N --> O
O --> P[Leitura de e-mails e documentos M365/Google Workspace]
O --> Q[Acesso a repositórios de código e segredos]
O --> R[Exfiltração de dados cloud]
O --> S[Persistência: criar novos apps OAuth / service accounts]
P --> T[Inteligência de negócios e espionagem]
Q --> U[Supply chain attack / acesso a credenciais adicionais]
R --> T
S --> V[Acesso de longo prazo mesmo após reset de senha do usuário]
```
## Exemplos de Uso
### APT29 - Campanhas de Consent Phishing contra Governo e Think Tanks (2021-2024)
O grupo [[g0016-apt29|APT29]] (Cozy Bear, Midnight Blizzard, NOBELIUM) documentou extenso uso de consent phishing OAuth em campanhas de espionagem de longo prazo. Na campanha contra a Microsoft (Midnight Blizzard, 2024), o grupo utilizou password spray para comprometer uma conta de tenant de testes e depois explorou tokens OAuth para escalar acesso a contas de executivos e equipes de segurança da Microsoft. O grupo também utilizou [[s0677-aadinternals|AADInternals]] para persistência via tokens OAuth de longa duração em múltiplas campanhas documentadas pelo [[sources|Mandiant]] e Microsoft MSTIC.
### APT28 - Token Harvesting em Microsoft 365 (2022-2023)
O grupo [[g0007-apt28|APT28]] (Fancy Bear) utilizou roubo de tokens OAuth como parte de operações de espionagem contra organizações governamentais europeias e da OTAN. A técnica envolveu comprometer contas com senhas fracas, depois usar os tokens de sessão obtidos para exportar e-mails e documentos via Microsoft Graph API - contornando o requisito de MFA pois o token já havia sido emitido após autenticação legítima.
### SolarWinds Supply Chain - Tokens SAML Forjados (2020)
A campanha [[_solarwinds|SolarWinds]], atribuída ao [[g0016-apt29|APT29]], incluiu o uso de tokens SAML forjados ("Golden SAML attack") para impersonar qualquer usuário em ambientes Azure AD / Microsoft 365 das vítimas. Após comprometer o ambiente on-premises do Active Directory Federation Services (ADFS), o grupo gerou tokens SAML válidos para qualquer identidade - efetivamente implementando T1528 em escala massiva sem necessidade de roubar tokens individuais.
### Ataques a Pipelines CI/CD - CircleCI Breach (2023)
Em janeiro de 2023, a CircleCI reportou um incidente onde um malware em um laptop de funcionário comprometeu tokens de sessão, permitindo que adversários acessassem variáveis de ambiente e secrets de projetos de clientes. Adversários roubaram tokens AWS, tokens de acesso a repositórios GitHub, chaves de API e outros segredos de pipelines CI/CD de centenas de organizações - um exemplo emblemático de T1528 via comprometimento de infraestrutura de DevOps.
### Campanha de Roubo de Tokens Kubernetes - TeamTNT
O grupo [[g0139-teamtnt|TeamTNT]], em suas campanhas contra ambientes cloud, frequentemente extrai tokens de service account Kubernetes de containers comprometidos. Com os tokens, o grupo executa reconhecimento do cluster, extrai secrets adicionais (que frequentemente contêm credenciais de banco de dados e APIs), e em casos onde o service account tem permissões elevadas, cria novos pods para persistência ou mineração de criptomoedas.
## Detecção
### Estrategias Gerais
A detecção de roubo de tokens de acesso é complexa porque, uma vez que o token é obtido, o uso subsequente é indistinguível de uso legítimo do ponto de vista do servidor de recursos. As estrategias de detecção focam em:
1. **Anomalias de contexto:** Token usado de IP/geolocalização/user-agent incomum
2. **Consentimento OAuth suspeito:** Aplicações com nomes similares a apps legítimos, solicitando escopos excessivos
3. **Tokens de CI/CD:** Uso de tokens em pipelines fora do escopo esperado
4. **Logs de auditoria do Identity Provider:** Registro de novos consentimentos OAuth, alterações em service accounts
### Regra Sigma - Consentimento OAuth Suspeito (Azure AD)
```yaml
title: Suspicious OAuth Application Consent - Potential Consent Phishing
status: experimental
logsource:
product: azure
service: auditlogs
detection:
selection:
OperationName: 'Consent to application'
properties.initiatedBy.user.userPrincipalName|contains: '@'
high_risk_scopes:
properties.targetResources[0].modifiedProperties.newValue|contains:
- 'Mail.Read'
- 'Mail.ReadWrite'
- 'Files.ReadWrite.All'
- 'offline_access'
- 'User.Read.All'
condition: selection and high_risk_scopes
falsepositives:
- Consentimento legítimo de aplicações corporativas aprovadas
- Onboarding de novas ferramentas SaaS pelo departamento de TI
level: high
tags:
- attack.credential_access
- attack.t1528
```
### Regra Sigma - Acesso a Token de Service Account Kubernetes
```yaml
title: Kubernetes Service Account Token Access from Unexpected Process
status: experimental
logsource:
category: file_access
product: linux
detection:
selection:
FileName|contains: '/var/run/secrets/kubernetes.io/serviceaccount/token'
filter_expected:
Image|endswith:
- '/kubectl'
- '/kubelet'
condition: selection and not filter_expected
falsepositives:
- Ferramentas de gerenciamento de cluster legítimas
- Operadores Kubernetes que acessam tokens programaticamente
level: high
tags:
- attack.credential_access
- attack.t1528
```
### Detecção de Anomalias de Token em Logs Cloud
Configurar alertas em:
- **Azure AD Sign-in Logs:** Login bem-sucedido de IP incomum com token (sem MFA step-up)
- **AWS CloudTrail:** `AssumeRoleWithWebIdentity` de origem geográfica inesperada
- **GitHub Audit Log:** `oauth_authorization.creaté` para apps não listadas na allowlist
- **Kubernetes Audit Log:** Chamadas à API com tokens de service account fora do namespace esperado
## Mitigação
| ID | Mitigação | Descrição |
|---|-----------|-----------|
| M1021 | [[m1021-restrict-web-based-content\|M1021 - Restrict Web-Based Content]] | Implementar políticas de consentimento OAuth restritivas: exigir aprovação de administrador para qualquer aplicação OAuth de terceiros que solicite escopos sensíveis (email, arquivos, offline_access). No Azure AD, configurar "Admin consent required" para todas as permissões delegadas. Bloquear consentimento de usuário final para apps não verificadas. |
| M1047 | [[m1047-audit\|M1047 - Audit]] | Auditar regularmente: (1) todas as aplicações OAuth com consentimento ativo no tenant Azure AD/Google Workspace; (2) permissões de service accounts Kubernetes - revisar bindings com ClusterAdmin ou acesso a secrets; (3) tokens de CI/CD - identificar tokens com escopos excessivos ou sem data de expiração; (4) Managed Identities Azure/GCP Service Accounts com permissões além do necessário. |
| M1017 | [[m1017-user-training\|M1017 - User Training]] | Treinar usuários para reconhecer consent phishing: identificar aplicações OAuth que solicitam escopos excessivos, verificar o publisher da aplicação, nunca conceder acesso a apps desconhecidas mesmo que o fluxo OAuth sejá do Microsoft/Google legítimo. Simular exercícios de consent phishing como parte do programa de segurança. |
| M1018 | [[m1018-user-account-management\|M1018 - User Account Management]] | Aplicar princípio do menor privilégio em todos os contextos de token: Kubernetes service accounts com apenas as permissões de namespace necessárias (RBAC granular); Managed Identities Azure com roles mínimas; OAuth apps com escopos mínimos documentados. Implementar token rotation automática e TTL curtos para tokens de serviço. |
**Mitigações adicionais recomendadas:**
- **Kubernetes:** Usar `automountServiceAccountToken: false` como padrão em pods que não necessitam de acesso à API do cluster; implementar RBAC granular com princípio do menor privilégio para todos os service accounts.
- **Azure:** Ativar Conditional Access que exige re-autenticação para tokens utilizados de localizações não reconhecidas; usar Privileged Identity Management (PIM) para limitar tempo de vida de tokens administrativos.
- **CI/CD:** Implementar OIDC Federation (GitHub Actions → AWS/Azure/GCP) ao invés de tokens estáticos de longa duração; rotacionar tokens de CI/CD automaticamente; usar secret scanning nos logs de pipeline.
- **Revogação de tokens:** Monitorar e ter processo de revogação rápida de tokens OAuth comprometidos via portais de administração dos Identity Providers.
## Contexto Brasil/LATAM
O roubo de tokens de acesso a aplicações é uma ameaça crescente no Brasil, diretamente correlacionada com a rápida adoção de Microsoft 365, Google Workspace e plataformas SaaS por empresas brasileiras de todos os setores.
**Tendências observadas na região:**
- **Setor Financeiro e Fintechs:** O ecossistema fintech brasileiro (Nubank, Inter, PicPay, C6) e bancos tradicionais utilizam extensamente APIs OAuth para integrações. Comprometimento de tokens de API financeiras pode resultar em acesso a dados de pagamento e PII de milhões de clientes, com implicações diretas sob a LGPD.
- **Setor Público:** Órgãos governamentais brasileiros que adotaram Microsoft 365 (Gov.br, Ministérios, prefeituras de grande porte) são alvos de consent phishing, especialmente por grupos de espionagem com interesse em correspondências governamentais e documentos de política.
- **Startups e Scale-ups:** Empresas em crescimento acelerado frequentemente implementam OAuth sem controles adequados de revisão de consentimento, e pipelines CI/CD com tokens de longa duração sem rotação.
- **Operações APT na LATAM:** Grupos como [[g0016-apt29|APT29]] e [[g0007-apt28|APT28]] têm presença documentada em operações contra entidades governamentais e diplomáticas latino-americanas, com uso de técnicas de roubo de tokens OAuth como vetor preferêncial para acesso persistente e furtivo a comúnicações.
**Regulatório:** O uso de tokens roubados para acesso não autorizado a dados de usuários brasileiros constitui infração à LGPD (Art. 46 - falta de medidas de segurança adequadas) e potencialmente ao Marco Civil da Internet (Lei 12.965/2014). Organizações que sofrerem incidentes via esta técnica têm obrigação de notificar a ANPD em até 72 horas após a ciência do incidente.
**Recomendação prioritária para o contexto nacional:**
1. Revisar imediatamente aplicações OAuth com consentimento ativo no Microsoft 365/Google Workspace - revogar qualquer aplicação não reconhecida ou com escopos excessivos
2. Implementar política de aprovação administrativa para novos consentimentos OAuth
3. Incluir simulações de consent phishing nos programas de conscientização de segurança
## Referências
- [MITRE ATT&CK - T1528](https://attack.mitre.org/techniques/T1528)
- [Microsoft - Midnight Blizzard / APT29 Campaign Analysis (2024)](https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/)
- [CISA Advisory - APT29 OAuth Consent Phishing](https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-116a)
- [CircleCI Security Incident - CI/CD Token Theft (2023)](https://circleci.com/blog/ján-4-2023-incident-report/)
- [AADInternals - Azure AD Attack Toolkit](https://aadinternals.com/)
- [Kubernetes Service Account Token Security](https://kubernetes.io/docs/concepts/security/service-accounts/)
- [OIDC Federation para GitHub Actions (sem tokens estáticos)](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)
- [[g0016-apt29|APT29]] - Ator principal documentado no uso desta técnica
- [[g0007-apt28|APT28]] - Segundo ator principal associado à técnica
- [[t1566-002-spearphishing-link|T1566.002 - Spearphishing Link]] - Vetor para consent phishing OAuth
- [[t1552-005-cloud-instance-metadata-api|T1552.005 - Cloud Instance Metadata API]] - Técnica relacionada para roubo de tokens via IMDS
- [[t1550-001-app-access-token|T1550.001 - Application Access Token]] - Uso dos tokens roubados
---
*Fonte: [MITRE ATT&CK - T1528](https://attack.mitre.org/techniques/T1528)*