# T1550.001 - Application Access Token ## Descrição **T1550.001 - Application Access Token** descreve o uso de **tokens OAuth2, tokens de API ou tokens de serviço comprometidos** para acesso não autorizado a serviços e aplicações cloud, sem necessidade de conhecer as credenciais originais do usuário. Esta técnica é classificada tanto como **Defense Evasion** quanto como **Lateral Movement** no framework MITRE ATT&CK, pois permite ao adversário se mover entre serviços cloud enquanto evade controles de autenticação tradicionais. O poder desta técnica reside em um princípio fundamental dos sistemas de autenticação modernos: **um token válido é uma prova de autenticação em si mesmo**. Diferente de credenciais (usuário+senha), tokens não requerem novo desafio de MFA - eles já representam uma sessão autenticada. Isso significa que: - O adversário **contorna completamente o MFA** mesmo em ambientes com 100% de cobertura - O acesso persiste enquanto o token não expirar - que pode ser horas, dias ou indefinidamente - Atividade maliciosa aparece nos logs como **tráfego legítimo** de um aplicativo OAuth autorizado - A troca de senha pelo usuário legítimo **não revoga** tokens OAuth já emitidos (sem CAE) **Tipos de tokens alvo:** | Tipo de Token | Plataforma | Validade Típica | |---------------|-----------|-----------------| | OAuth2 Access Token | Microsoft 365, Google, GitHub | 1 hora (renovável via refresh token) | | OAuth2 Refresh Token | Qualquer plataforma OAuth | 90 dias a indefinido | | Service Account Key | GCP, GitHub Actions | Indefinido até revogação manual | | Personal Access Token (PAT) | GitHub, Azure DevOps, GitLab | Configurável (dias a indefinido) | | AWS IAM Temporary Credentials | AWS | 15 min a 36 horas | | SAML Assertion | Azure AD, Okta | Minutos (mas pode gerar sessão longa) | > **Técnica pai:** [[t1550-use-alternate-authentication-material|T1550 - Use Alternaté Authentication Material]] > **Técnicas relacionadas:** [[t1528-steal-application-access-token|T1528 - Steal Application Access Token]], [[t1566-phishing|T1566 - Phishing]], [[t1098-001-additional-cloud-credentials|T1098.001 - Additional Cloud Credentials]] --- ## Como Funciona ### Fase 1: Obtenção do Token O adversário pode obter tokens de aplicação por múltiplos vetores: **OAuth Consent Phishing:** Técnica preferida do [[g0016-apt29|APT29]]. O adversário registra um aplicativo OAuth malicioso e engana o usuário para que clique em um link de consentimento legítimo. Ao clicar, o usuário autoriza o aplicativo a acessar seus dados (email, arquivos, contatos). O token gerado é entregue diretamente ao servidor do atacante via redirect URI controlado. **Roubo de Token em Memória:** Em sistemas comprometidos, tokens OAuth armazenados em browsers (IndexedDB, cookies), aplicativos desktop (Electron apps) ou em memória de processos podem ser extraídos com ferramentas como Mimikatz Cloud Extensions ou TokenTactics. **Comprometimento de Pipelines CI/CD:** Tokens de serviço em variáveis de ambiente de pipelines GitHub Actions, GitLab CI ou Azure DevOps podem ser exfiltrados via código malicioso injetado em dependências (*supply chain attack*). **SSRF em Serviços Cloud:** Server-Side Request Forgery contra o endpoint de metadados de instâncias cloud (ex: `http://169.254.169.254/latest/meta-data/iam/security-credentials/`) retorna credenciais temporárias IAM/IMDSv1. ### Fase 2: Uso do Token Com o token em mãos, o adversário o utiliza diretamente via API REST: ``` GET https://graph.microsoft.com/v1.0/me/messages Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhb... ``` O Microsoft Graph API, Google Workspace API, GitHub API e equivalentes aceitam o token sem verificação adicional de identidade - o acesso é idêntico ao de um usuário legítimo usando o mesmo aplicativo. ### Fase 3: Persistência via Refresh Token Tokens de acesso expiram (tipicamente em 1 hora), mas **refresh tokens** permitem obter novos access tokens indefinidamente: ``` POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token grant_type=refresh_token&refresh_token={stolen_token}&client_id={app_id} ``` Um refresh token não revogado representa **acesso persistente** mesmo após reset de senha do usuário legítimo. --- ## Attack Flow ```mermaid graph TB A([Adversário]) --> B{Vetor de Obtenção} B --> C[OAuth Consent Phishing<br/>T1566 - Phishing] B --> D[Extração de Token em Memória<br/>Browser / Electron App] B --> E[Comprometimento CI/CD<br/>Variável de ambiente] B --> F[SSRF em Metadata Service<br/>AWS IMDSv1 / GCP] C --> G[Usuário Autoriza App Malicioso<br/>Consent Grant via Azure AD] D --> H[Token Capturado<br/>TokenTactics / Mimikatz Cloud] E --> I[Secret Exfiltrado<br/>GitHub PAT / Service Account] F --> J[Credencial Temporária IAM<br/>Sem MFA necessário] G --> K[Access Token + Refresh Token<br/>Válido por dias/indefinido] H --> K I --> K J --> K K --> L[Acesso Direto via API<br/>Microsoft Graph / GWS / AWS] L --> M[Leitura de Emails<br/>Exchange Online] L --> N[Acesso a Arquivos<br/>SharePoint / OneDrive / Drive] L --> O[Movimentação Lateral<br/>Novos Tenants / Subscriptions] L --> P[Persistência<br/>T1098.001 - Novas Credenciais Cloud] M --> Q([Exfiltração de Dados<br/>Sem alertas de credencial]) N --> Q O --> Q P --> Q style A fill:#c0392b,color:#fff style Q fill:#922b21,color:#fff style K fill:#e74c3c,color:#fff style G fill:#f39c12,color:#000 ``` --- ## Exemplos de Uso ### APT29 / Midnight Blizzard - Microsoft Corporaté Breach (2024) O [[g0016-apt29|APT29]] (também denominado Midnight Blizzard / Cozy Bear) protagonizou o incidente de maior visibilidade envolvendo Application Access Tokens em 2024: o comprometimento de emails de executivos e equipes de segurança da própria Microsoft. O vetor inicial foi um tenant de desenvolvimento sem MFA habilitado, onde o grupo obteve acesso via password spray. A partir desse ponto de entrada, o grupo: 1. Utilizou OAuth consent phishing para obter tokens com permissões elevadas no tenant de produção 2. Explorou relacionamentos de confiança OAuth entre tenants para escalar acesso 3. Leu emails de executivos sênior e da equipe de segurança da Microsoft por semanas antes da detecção O ataque ficou documentado no [[microsoft-corporate-breach-2024|Microsoft Corporaté Breach 2024]] e resultou em divulgação regulatória obrigatória pela SEC. ### APT29 - Operação SolarWinds (Sequência Cloud) Na continuação da [[operation-solarwinds|Operação SolarWinds]], após o comprometimento inicial via supply chain, o [[g0016-apt29|APT29]] utilizou tokens SAML forjados (*Golden SAML Attack*) para se autenticar em serviços cloud da Microsoft sem passar pelo processo normal de autenticação. Tokens SAML forjados com o certificado ADFS comprometido das vítimas geravam sessões OAuth válidas em Microsoft 365, contornando todo monitoramento baseado em credenciais. ### Campanhas de Roubo de GitHub PATs Atores de ameaça focados em supply chain (como aqueles responsáveis por comprometimentos de repositórios npm e PyPI) regularmente alvo variáveis de ambiente de CI/CD para extrair Personal Access Tokens do GitHub. Com um PAT comprometido, o adversário pode ler código proprietário, injetar backdoors em repositórios e publicar pacotes maliciosos em registries públicos - tudo sem qualquer interação com credenciais de usuário. --- ## Detecção ### Indicadores de Comprometimento de Tokens - Login bem-sucedido sem evento MFA precedente (token reutilizado) - Acesso de IP/ASN diferente do histórico do usuário com o mesmo token - Novo aplicativo OAuth nunca antes visto nos logs de consentimento do tenant - Refresh token utilizado após reset de senha do usuário (sem revogação CAE) - Acesso em horários fora do padrão de uso do usuário legítimo ### Regra Sigma - OAuth Consent Grant Suspeito ```yaml title: Suspicious OAuth Application Consent Grant id: b8c4d2e6-3f5a-4b9c-8d7e-2f1a6b4c5d8e status: experimental description: > Detecta concessão de consentimento OAuth para aplicativos com permissões elevadas ou de fontes não reconhecidas. Pode indicar OAuth Consent Phishing como vetor para roubo de Application Access Tokens (T1550.001). references: - https://attack.mitre.org/techniques/T1550/001/ - https://www.microsoft.com/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.lateral_movement - attack.t1550.001 - attack.t1528 logsource: product: azure service: auditlogs detection: selection: operationName: "Consent to application" resultType: "Success" suspicious_permissions: properties.targetResources[*].modifiedProperties[*].newValue|contains: - "Mail.Read" - "Mail.ReadWrite" - "Files.ReadWrite.All" - "Directory.ReadWrite.All" - "User.Read.All" filter_known_apps: # Adicionar IDs de apps corporativos conhecidos aqui properties.initiatedBy.app.appId|contains: - "known-app-guid-1" - "known-app-guid-2" condition: selection AND suspicious_permissions AND NOT filter_known_apps falsepositives: - Concessão de acesso a novos aplicativos SaaS legítimos por usuários autorizados - Onboarding de novos serviços aprovados pelo time de segurança level: medium ``` ### KQL - Tokens Usados de Novos Locais (Microsoft Sentinel) ```kusto // Detecta uso de refresh token de IP não visto nos últimos 30 dias let knownIPs = SigninLogs | where TimeGenerated > ago(30d) | summarize KnownIPs = make_set(IPAddress) by UserPrincipalName; SigninLogs | where TimeGenerated > ago(1d) | where AuthenticationRequirement == "singleFactorAuthentication" | where TokenProtectionStatus == "unbound" | join kind=leftouter knownIPs on UserPrincipalName | where not(IPAddress in (KnownIPs)) | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ConditionalAccessStatus, RiskLevelDuringSignIn | sort by TimeGenerated desc ``` --- ## Mitigação | ID | Mitigação | Implementação Prática | |----|-----------|----------------------| | [[m1047-audit\|M1047]] | Audit | Revisar periodicamente aplicativos OAuth com permissões delegadas; identificar apps não gerenciados com acesso a Mail.Read ou Files | | [[m1021-restrict-web-based-content\|M1021]] | Restrict Web-Based Content | Bloquear consent grant para aplicativos de publishers não verificados; habilitar "Admin consent required" para permissões sensíveis | | [[m1036-account-use-policies\|M1036]] | Account Use Policies | Implementar Continuous Access Evaluation (CAE) para revogação de tokens em tempo real; configurar Conditional Access para exigir device compliance em tokens | | CAE | Revogação Contínua | Habilitar CAE no Azure AD para inválidar tokens imediatamente após mudanças de risco detectadas - independente da expiração do token | | Token Lifecycle | Controle de Validade | Reduzir vida útil de refresh tokens para contas privilegiadas; configurar sign-in frequency policies no Conditional Access | | Auditoria de Consentimento | Governança | Configurar alertas para novos consent grants com permissões Mail.Read, Files.ReadWrite.All ou Directory.* - qualquer concessão deve gerar ticket de revisão | --- ## Contexto Brasil/LATAM A técnica T1550.001 é crescentemente relevante no Brasil e na América Latina à medida que organizações migram para ambientes Microsoft 365 e Google Workspace: **Adoção Cloud Acelerada no Brasil:** O Brasil é um dos mercados de maior crescimento em adoção de Microsoft 365 e Google Workspace na América Latina. Essa expansão frequentemente ocorre sem maturidade de segurança equivalente - ambientes são provisionados sem políticas de Conditional Access, CAE não é habilitado, e OAuth consent grants não são auditados. **Alvo: Setor Financeiro e Fintechs Brasileiras:** Grupos de ameaça financeiramente motivados que historicamente atacam bancos brasileiros (como os grupos por trás dos [[s0531-grandoreiro|Grandoreiro]] e [[astaroth-malware|Astaroth]]) estão expandindo táticas para comprometimento de ambientes cloud à medida que bancos modernizam infraestrutura. Tokens de Service Account do Google Cloud Platform com acesso a sistemas de processamento de pagamentos são alvos de alto valor. **Órgãos Governamentais:** Campanhas de espionagem direcionadas a ministérios e agências reguladoras brasileiras (como ANATEL e ANS) registraram uso de OAuth phishing para comprometer contas Microsoft 365 de funcionários - uma evolução das técnicas tradicionais de phishing de credenciais. **Falta de Visibilidade:** A maioria das organizações brasileiras de médio porte não possui logging adequado de Azure AD Sign-in Logs e Audit Logs para detectar uso anômalo de tokens. O [[sources|CERT.br]] emitiu alertas sobre campanhas de OAuth phishing dirigidas a usuários corporativos brasileiros, mas a cobertura de detecção ainda é baixa. --- ## Referências - [MITRE ATT&CK - T1550.001](https://attack.mitre.org/techniques/T1550/001/) - [Microsoft - Midnight Blizzard Guidance](https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/) - [Microsoft - Malicious OAuth Applications](https://www.microsoft.com/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/) - [Mandiant - APT29 OAuth Techniques](https://www.mandiant.com/resources/blog/apt29-microsoft-365) - [TokenTactics - Token Manipulation Tool](https://github.com/f-bader/TokenTacticsV2) - [CISA - Cloud Security Best Practices](https://www.cisa.gov/resources-tools/resources/cloud-security-technical-reference-architecture) *Fonte: [MITRE ATT&CK - T1550.001](https://attack.mitre.org/techniques/T1550/001/)*