t1550-001-application-access-token

# T1550.001 - Application Access Token ## Técnica Pai [[t1550-use-alternate-authentication-material|T1550 - Use Alternaté Authentication Material]] ## Descrição Adversários podem usar tokens de acesso de aplicação roubados para contornar o processo típico de autenticação e acessar contas, informações ou serviços restritos em sistemas remotos. Esses tokens são tipicamente roubados de usuários ou serviços e utilizados no lugar de credenciais de login tradicionais (usuário e senha). Tokens de acesso de aplicação são usados para realizar requisições autorizadas a APIs em nome de um usuário ou serviço, sendo amplamente utilizados para acesso a recursos em nuvem, aplicações baseadas em contêineres e SaaS (*Software-as-a-Service*). A ausência de senha no fluxo de autenticação baseado em token torna essa técnica particularmente eficaz para contornar controles como autenticação multifator (MFA) - já que o segundo fator geralmente só é verificado no momento da concessão original do token, não nas requisições subsequentes. **OAuth e frameworks similares:** OAuth 2.0 é o framework mais amplamente implementado para emissão de tokens. Nesse modelo, um usuário autoriza uma aplicação a agir em seu nome, e a aplicação recebe um *access token* (curta duração) e, opcionalmente, um *refresh token* (longa duração). Uma vez que um adversário compromete um token, especialmente um refresh token, pode manter acesso prolongado mesmo que a senha do usuário sejá alterada - desde que o token não sejá explicitamente revogado. O abuso de tokens pode ocorrer em múltiplos contextos: - **Aplicações de email e produtividade** (Microsoft 365, Google Workspace) - **Plataformas IaaS** (AWS STS tokens, GCP service account tokens) - **Ambientes Kubernetes** (service account tokens em arquivos de configuração) - **Provedores de identidade** (Azure AD, Okta, PingIdentity) - **APIs de SaaS** (Salesforce, GitHub, Slack) > **Plataformas afetadas:** SaaS, IaaS, Containers, Office Suite, Identity Provider ## Como Funciona O ataque segue um fluxo de obtenção, válidação e abuso do token comprometido. **1. Obtenção do token** Os tokens podem ser obtidos por diferentes métodos: - **Phishing de consentimento OAuth** - O adversário cria uma aplicação maliciosa que solicita permissões OAuth ao usuário. Quando o usuário autoriza (muitas vezes sem perceber o escopo real), o token é concedido à aplicação controlada pelo adversário. Essa técnica é usada pelo [[g0007-apt28|APT28]] em campanhas contra organizações governamentais. - **Roubo de token de memória ou disco** - Tokens armazenados em cache no navegador, arquivos de configuração de ferramentas (`.aws/credentials`, `.kube/config`, `~/.config/gcloud`), ou variáveis de ambiente de pipelines CI/CD. - **Interceptação de token em trânsito** - Via ataques Man-in-the-Middle ou comprometimento de proxies reversos. - **Exfiltração de token de serviço** - Em ambientes Kubernetes, tokens de service account frequentemente estão acessíveis dentro do pod em `/var/run/secrets/kubernetes.io/serviceaccount/token`. - **API de metadados de instância cloud** - Em instâncias EC2 sem proteção IMDSv2, um adversário pode consultar `http://169.254.169.254/latest/meta-data/iam/security-credentials/` para obter credenciais temporárias de instância. - **Comprometimento de refresh token** - Um refresh token OAuth válido permite solicitar novos access tokens indefinidamente, mantendo o acesso mesmo após rotação de senhas. **2. Uso do token comprometido** Com o token em mãos, o adversário realiza chamadas de API autenticadas: - **Microsoft Graph API** - Pesquisa de emails, acesso a arquivos OneDrive, enumeração de contatos e calendários - **AWS STS `GetFederationToken`/`AssumeRole`** - Criação de sessões federadas com permissões do usuário original que persistem mesmo com desativação da conta - **GCP `generateAccessToken`** - Solicitação de token de curta duração com os privilégios de outra service account - **Kubernetes API Server** - Criação de pods privilegiados, leitura de secrets, execução de comandos em contêineres **3. Extensão do acesso** O acesso via token pode ser usado como ponto de partida para comprometer outros serviços - por exemplo, acesso ao email principal permite acionar rotinas de "esqueci minha senha" em outros serviços vinculados ao mesmo endereço, expandindo o controle do adversário de forma silenciosa. ## Attack Flow ```mermaid graph TB A[Acesso Inicial Phishing de Consentimento OAuth ou Credenciais Comprometidas] --> B[Obtenção do Token OAuth / API Key / Service Account] B --> C{Tipo de Token} C --> D[Access Token Curta duração] C --> E[Refresh Token Longa duração - persiste após reset de senha] C --> F[Service Account Token Kubernetes / Cloud IAM] D --> G[Chamadas de API Autenticadas Microsoft Graph / AWS API / GCP API] E --> H[Renovação Contínua de Access Tokens Acesso persistente sem re-autenticação] F --> I[Acesso a Recursos Cloud Pods / Datastores / Secrets] G --> J[Objetivos do Adversário] H --> J I --> J J --> K[Exfiltração de Dados Emails, arquivos, segredos] J --> L[Movimentação Lateral Acesso a outros serviços via email] J --> M[Escalada de Privilégios AssumeRole / GetFederationToken] J --> N[Persistência Backdoor OAuth app registrada] ``` ## Exemplos de Uso **APT28 - Campanha de phishing OAuth contra governos** O [[g0007-apt28|APT28]] (Fancy Bear, Unidade 26165) conduziu campanhas de phishing de consentimento OAuth direcionadas a funcionários de governos europeus e NATO. A técnica consiste em enviar emails com links para aplicações falsas que solicitam permissões do Microsoft 365 (leitura de emails, acesso a contatos). Uma vez que a vítima autoriza, o grupo obtém acesso persistente via refresh token, independentemente de MFA. **HAFNIUM - Exfiltração via Microsoft Graph após comprometimento Exchange** O [[g0125-silk-typhoon|HAFNIUM]], grupo associado à China que explorou vulnerabilidades do Exchange Server (ProxyLogon), também utilizou tokens OAuth para manter acesso a contas do Microsoft 365 após a instalação de web shells. Após o patch das vulnerabilidades, os tokens roubados garantiram acesso contínuo via Graph API para exfiltração de emails. **Peirates - Exploração de tokens Kubernetes** A ferramenta de exploração [[s0683-peirates|Peirates]], usada em red team e por atores maliciosos, automatiza a coleta de service account tokens em pods Kubernetes e os usa para escalar privilégios dentro do cluster - criando pods privilegiados, acessando secrets e comprometendo o plano de controle. **CreepyDrive - Abuso de OneDrive como C2** O malware [[s1023-creepydrive|CreepyDrive]], associado ao grupo Polonium com nexo iraniano, utilizou tokens OAuth roubados para abusar do Microsoft OneDrive como canal de comando e controle, enviando comandos via arquivos na nuvem e exfiltrando dados para o mesmo storage - técnica que contorna firewalls e proxies que confiam no tráfego Microsoft. **AWS - Abuso de Instance Metadata Service (IMDS)** Em ambientes AWS sem IMDSv2 obrigatório, adversários dentro de uma instância EC2 comprometida (ou via SSRF) consultam o serviço de metadados para obter credenciais temporárias IAM da instância, que incluem `AccessKeyId`, `SecretAccessKey` e `SessionToken`. Com esses tokens, é possível realizar ações com as permissões da instância sem precisar comprometer credenciais de usuário IAM. **Cenário LATAM - Comprometimento de conta Microsoft 365 em empresa financeira** Em 2024, uma instituição financeira brasileira sofreu comprometimento de conta executiva via phishing de consentimento OAuth. O adversário registrou uma aplicação maliciosa que solicitava permissões de leitura de email e acesso ao SharePoint. Com o refresh token, manteve acesso por 47 dias sem ser detectado, exfiltrando documentos estratégicos antes da descoberta do incidente. ## Detecção A detecção de abuso de tokens é desafiadora porque o tráfego gerado pelos tokens é legítimo do ponto de vista da API - o desafio está em identificar padrões anômalos de comportamento. **Sinais de alerta chave:** - Aplicações OAuth registradas com escopos excessivos (ex: `Mail.ReadWrite`, `Files.ReadWrite.All`, `offline_access`) por usuários não-administradores - Acesso via API de locais geográficos ou endereços IP incomuns, especialmente sem correspondência com o login interativo - Volume anormal de chamadas à Microsoft Graph API (especialmente `GET /users/{id}/messages`) em horários fora do padrão - Uso de `sts:AssumeRole` ou `sts:GetFederationToken` em AWS por contas que normalmente não assumem papéis - Tokens de service account Kubernetes acessados fora do pod original ou por processos não esperados - Aplicações OAuth recém-registradas com consentimento administrativo não solicitado ```yaml title: Suspicious OAuth Application Consent with High-Privilege Scopes status: experimental logsource: product: azure service: auditlogs detection: selection: OperationName: "Consent to application" properties.targetResources.modifiedProperties.newValue|contains: - "Mail.ReadWrite" - "Files.ReadWrite.All" - "offline_access" - "Directory.ReadWrite.All" filter_known_apps: properties.initiatedBy.user.userPrincipalName|contains: - "@datarunk.com" condition: selection and not filter_known_apps falsepositives: - Novos aplicativos corporativos sendo integrados ao tenant - Administradores concedendo acesso a ferramentas aprovadas level: high tags: - attack.defense_evasion - attack.lateral_movement - attack.t1550.001 ``` **AWS - Detecção de uso de credenciais IMDS:** ```yaml title: AWS EC2 Instance Credentials Used from External IP status: experimental logsource: product: aws service: cloudtrail detection: selection: userIdentity.type: AssumedRole userIdentity.sessionContext.sessionIssuer.type: Service userIdentity.sessionContext.sessionIssuer.service: ec2.amazonaws.com filter_internal: sourceIPAddress|cidr: - "10.0.0.0/8" - "172.16.0.0/12" - "192.168.0.0/16" condition: selection and not filter_internal level: critical tags: - attack.t1550.001 - attack.credential_access ``` ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | [[m1036-account-use-policies\|M1036]] | Account Use Policies | Implementar políticas de uso de conta que restrinjam quais aplicações podem receber consentimento OAuth e com quais escopos. No Azure AD, usar políticas de consentimento para exigir aprovação administrativa antes que usuários possam conceder escopos sensíveis. Revisar e revogar regularmente consentimentos OAuth não utilizados ou suspeitos. Limitar lifetime de tokens e refresh tokens conforme o perfil de risco. | | [[m1047-audit\|M1047]] | Audit | Auditar regularmente aplicações OAuth registradas no tenant, especialmente aquelas com escopos de alto privilégio. Revisar logs de consentimento e identificar aplicações com consentimento administrativo não esperado. Monitorar uso de tokens de service account em ambientes Kubernetes e cloud. Usar ferramentas como Microsoft Secure Score, AWS IAM Access Analyzer, e GCP Security Command Center. | | [[m1021-restrict-web-based-content\|M1021]] | Restrict Web-Based Content | Bloquear acesso a aplicações OAuth externas não aprovadas via políticas de proxy e CASB. Implementar listas de permissão de aplicações confiáveis. Restringir a capacidade de usuários de autorizar aplicações de terceiros sem revisão de segurança. | | [[m1013-application-developer-guidance\|M1013]] | Application Developer Guidance | Orientar desenvolvedores a solicitar apenas os escopos OAuth necessários (*least privilege*). Evitar armazenar tokens em código-fonte, variáveis de ambiente ou arquivos de configuração versionados. Implementar rotação regular de tokens de serviço. Usar armazenamento seguro de secrets (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault). | | [[m1041-encrypt-sensitive-information\|M1041]] | Encrypt Sensitive Information | Armazenar tokens de forma criptografada em repouso. Garantir que tokens não trafeguem por canais não criptografados (HTTP). Proteger arquivos de configuração que contêm tokens (`.kube/config`, `.aws/credentials`) com permissões restritivas de sistema de arquivos. | ## Contexto Brasil/LATAM O abuso de tokens de acesso é uma ameaça crescente para organizações brasileiras e latino-americanas, impulsionado pela rápida adoção de Microsoft 365, Google Workspace e plataformas cloud sem os controles de segurança adequados. **Campanhas de phishing OAuth no Brasil:** O Brasil é um dos países com maior taxa de adoção corporativa de Microsoft 365 na América Latina. Campanhas de phishing de consentimento OAuth têm sido observadas direcionadas a profissionais financeiros e executivos de empresas brasileiras, frequentemente utilizando páginas que imitam portais de autenticação Microsoft para capturar consentimento OAuth e obter refresh tokens de longa duração. **Risco em startups e fintechs:** O ecossistema de startups e fintechs brasileiro tende a adotar ferramentas SaaS e pipelines CI/CD com alta velocidade e menor rigor de governança de acesso. Tokens de service account GitHub Actions, AWS e GCP frequentemente são expostos em repositórios públicos ou têm permissões excessivas, criando superfície de ataque para essa técnica. **Serviços financeiros e BACEN:** A resolução [[2018]] exige que instituições financeiras mantenham controles de acesso adequados para ambientes cloud e SaaS. O comprometimento de tokens OAuth com acesso a sistemas bancários pode configurar violação regulatória com obrigação de comunicação ao Banco Central. **Ataques a provedores de identidade na LATAM:** Campanhas direcionadas a provedores de identidade utilizados por grandes empresas latino-americanas (Okta, Azure AD, PingFederaté) buscam comprometer tokens de administrador que permitem acesso a toda a organização. O incidente Okta de 2023 afetou clientes ao redor do mundo, incluindo organizações brasileiras que dependem do serviço para SSO corporativo. **APT28 e espionagem governamental:** O [[g0007-apt28|APT28]] tem histórico de ataques contra governos da América Latina, incluindo campanhas de phishing OAuth documentadas contra funcionários de ministérios e agências de segurança. A técnica de uso de tokens OAuth é preferida pelo grupo por contornar MFA e deixar rastros menos evidentes nos logs de autenticação interativa. **Conformidade LGPD:** O roubo de tokens que resulte em acesso não autorizado a dados pessoais armazenados em SaaS (emails, documentos, CRM) configura incidente de segurança sob a [[lgpd|LGPD]], com potencial obrigação de notificação à ANPD dentro de 2 dias úteis do conhecimento do incidente. ## Referências - [[t1550-use-alternate-authentication-material|T1550 - Use Alternaté Authentication Material]] - Técnica pai - [[g0007-apt28|APT28]] - Grupo que usa phishing de consentimento OAuth - [[g0125-silk-typhoon|HAFNIUM]] - Grupo que abusa de tokens Microsoft Graph pós-comprometimento - [[s0683-peirates|Peirates]] - Ferramenta de exploração de tokens Kubernetes - [[s1023-creepydrive|CreepyDrive]] - Malware que abusa de tokens OneDrive para C2 - [[m1036-account-use-policies|M1036 - Account Use Policies]] - Mitigação principal para OAuth - [[m1047-audit|M1047 - Audit]] - Auditoria de consentimentos e uso de tokens - [[m1013-application-developer-guidance|M1013 - Application Developer Guidance]] - Boas práticas de tokens para devs - [[t1071-application-layer-protocol|T1071 - Application Layer Protocol]] - Técnica frequentemente combinada para C2 via API legítima - [[t1078-valid-accounts|T1078 - Valid Accounts]] - Técnica relacionada para uso de credenciais legítimas *Fonte: MITRE ATT&CK - T1550.001*