# PROC — APT29: Roubo de Tokens de Acesso Cloud (Azure AD / M365) ## Visão Geral O [[g0016-apt29|APT29]] (também conhecido como NOBELIUM e Midnight Blizzard), braço cibernético do SVR russo, opera com um nível de sofisticação que o distingue da maioria dos grupos de ameaça avançada. Em vez de explorar vulnerabilidades de software com CVEs conhecidos, o grupo prefere abusar de **mecanismos legítimos de autenticação** — especialmente tokens OAuth e Application Access Tokens do Azure AD. Esses tokens, quando obtidos, permitem acesso persistente a recursos cloud como se fossem uma aplicação autorizada, frequentemente contornando MFA porque o protocolo OAuth já pressupõe que a autenticação humana foi concluída anteriormente. No incidente de janeiro de 2024 contra a própria Microsoft, o [[g0016-apt29|APT29]] demonstrou essa técnica em escala: comprometeu um tenant de teste esquecido, sem MFA, escalou via permissões OAuth herdadas, e leu caixas de email de executivos sênior e da equipe do MSTIC por semanas sem ser detectado. O objetivo era uma forma refinada de contra-inteligência — descobrir o que a Microsoft e outras organizações de segurança sabiam sobre o próprio grupo, para ajustar operações futuras e evitar exposição. O que torna esse procedimento especialmente perigoso para organizações brasileiras é a proliferação de **tenants Azure AD legados ou de desenvolvimento** criados por equipes de TI e esquecidos sem política de descomissionamento. Qualquer um desses tenants, se tiver uma conta sem MFA e uma aplicação OAuth com permissões de alto privilégio, representa o mesmo vetor explorado contra a Microsoft — independentemente do porte da organização. **Contexto Brasil/LATAM:** A adoção acelerada de Microsoft 365 no setor corporativo e de governo brasileiro cria uma superfície de ataque ampla para essa técnica. Organizações do setor financeiro ([[financial|Setor Financeiro]]), governo federal e estadual, e grandes empresas de infraestrutura crítica estão entre os alvos de maior interesse para grupos patrocinados por Estados que buscam acesso persistente a ambientes cloud. O [[g0016-apt29|APT29]] historicamente persegue **inteligência de longa duração** — não destruição imediata — o que significa que comprometimentos podem durar meses antes de serem descobertos. A maturidade de detecção de abusos OAuth ainda é baixa na maioria das equipes de segurança brasileiras, que tipicamente monitoram ameaças de endpoint mais do que movimentação em plano de controle cloud. ## Attack Flow ```mermaid graph TB A[Password Spray<br/>Tenant de Teste] --> B[Enumeração<br/>OAuth Apps] B --> C[Criação de<br/>Service Principal] C --> D{Abuso de Token<br/>EWS full_access}:::critical D --> E[Exfiltração de<br/>Emails / Contra-Intel] classDef critical fill:#e74c3c,color:#fff ``` ## Como Funciona ### 1. Preparação — Comprometimento do Tenant de Teste via Password Spray O [[g0016-apt29|APT29]] começa identificando **tenants Azure AD legados** da organização-alvo — ambientes criados para desenvolvimento, provas de conceito ou demonstrações que raramente recebem a mesma aténção de segurança que o ambiente de produção. A enumeração é feita via consultas DNS, headers HTTP de respostas de autenticação e ferramentas como `AADInternals`. Uma vez identificado um tenant sem MFA habilitado, o grupo conduz um password spray distribuído: tentativas espalhadas por dias, originadas de múltiplos IPs residenciais e VPNs comerciais, usando listas de senhas comuns e padrões corporativos previsíveis (`Empresa2024!`, `Summer@2023`, sazonais). O volume baixo por conta por dia evita bloqueios por políticas de Identity Protection. > **Event IDs relevantes:** `4625` (falha de login), `4648` (logon com credenciais explícitas), Azure AD Sign-in logs com `ResultType: 50126` (senha incorreta) seguido de `ResultType: 0` (sucesso). ### 2. Execução — Escalada via OAuth e Criação de Service Principal Com acesso ao tenant de teste, o [[g0016-apt29|APT29]] enumera as **OAuth Applications registradas** — especialmente aquelas com permissões de alto privilégio herdadas do tenant de produção via relações de confiança cross-tenant. A permissão mais perigosa é `full_access_as_app` para Exchange Web Services (EWS), que permite ler qualquer caixa de email da organização sem a senha ou MFA do usuário. O grupo cria um novo Service Principal vinculado a essa aplicação, usando um nome que imita serviços internos legítimos da Microsoft (como `Microsoft.Exchange.HealthMetrics`) para passar despercebido em listagens administrativas. O token emitido para esse Service Principal tem válidade longa e não requer re-autenticação humana. > **Event IDs relevantes:** Azure AD Audit Log `Add service principal` (operação fora de pipeline de CI/CD), `Add app role assignment to service principal`, `Consent to application`. ### 3. Pós-execução — Exfiltração Silenciosa via Exchange Web Services Com o token do Service Principal, o [[g0016-apt29|APT29]] autentica diretamente na Exchange Web Services API do tenant de produção e impersona usuários-alvo selecionados por cargo — executivos (CEO, CFO, CISO), equipe jurídica, equipe de segurança e equipe de resposta a incidentes. Consultas EWS (`FindItem` + `GetItem`) buscam emails contendo termos relacionados ao próprio grupo (APT29, SVR, Midnight Blizzard, NOBELIUM) — uma estratégia de contra-inteligência para entender o que o adversário sabe. O volume de acesso é deliberadamente baixo para ficar abaixo de limites de alerta DLP. A operação pode durar semanas ou meses sem detecção, já que o tráfego parece ser de uma aplicação corporativa autorizada. > **Event IDs relevantes:** Exchange Audit Log `MailItemsAccessed` (auditoria de acesso a itens de email), Microsoft Purview Audit `EWSGetItem` e `EWSFindItems` de Service Principal fora do baseline esperado. ## Detecção ### Event IDs Críticos | Event ID / Log | Produto | Indicador | |---|---|---| | Azure AD Sign-in — `ResultType: 50126` em volume | Azure AD | Password spray em andamento | | Azure AD Audit — `Add service principal` | Azure AD | SP criado fora de jánela de deploy | | Azure AD Audit — `Add app role assignment` | Azure AD | Permissão de alto privilégio adicionada | | Exchange Audit — `MailItemsAccessed` por SP | Exchange Online | Acesso de aplicação a caixas de executivos | | Purview Audit — `EWSGetItem` em horário incomum | Microsoft Purview | Leitura de emails via API de aplicação | | MCAS Alert — `Impossible travel` ou novo país | Microsoft Defender for Cloud Apps | Token usado de localização inesperada | ### Sigma Rule — Service Principal Criado Fora de Pipeline Aprovado ```yaml title: APT29 - Criação de Service Principal Suspeita no Azure AD id: a3f7c2b1-9e4d-4a8f-b6c3-1d2e5f0a9b8c status: experimental description: > Detecta criação de Service Principal no Azure AD fora de jánelas de deploy aprovadas ou por contas que não pertencem ao grupo de administradores de aplicações. Técnica usada pelo APT29 para escalar privilégios via OAuth. author: RunkIntel daté: 2026-03-24 references: - https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/ logsource: product: azure service: auditlogs detection: selection: operationName: "Add service principal" result: "success" filter_expected_accounts: initiatedBy.user.userPrincipalName|endswith: - "@devops-pipeline.yourdomain.com" - "@ci-service.yourdomain.com" condition: selection and not filter_expected_accounts falsepositives: - Criação legítima de SP por administradores durante onboarding de aplicações - Pipelines de CI/CD com UPNs não listados no filtro level: high tags: - attack.credential_access - attack.t1528 - attack.lateral_movement - attack.t1550.001 ``` ## Mitigação | Controle | Ação Recomendada | Prioridade | |---|---|---| | MFA universal | Habilitar MFA em **todos** os tenants Azure AD sem exceção — incluindo dev, test e sandbox | Crítica | | Descomissionamento de tenants legados | Auditoria semestral de todos os tenants da organização; desativar os não utilizados | Alta | | Revisão de permissões OAuth | Nenhuma aplicação deve ter `full_access_as_app` para EWS sem justificativa documentada e revisão periódica | Alta | | Conditional Access | Exigir dispositivo compliant, localização aprovada e risco de login baixo para tokens de aplicação de alto privilégio | Alta | | Monitoramento de Service Principals | Alertar P1 para criação de SP fora de pipelines aprovados de CI/CD (ITSM + SIEM) | Média | | Auditoria de MailItemsAccessed | Habilitar auditoria de acesso a itens de email para contas de executivos e equipe de segurança no Microsoft Purview | Média | | Inventário de OAuth Apps | Revisar mensalmente todas as aplicações OAuth com permissões de `Mail.Read`, `Mail.ReadWrite` e EWS | Média | | Cross-tenant trust review | Auditar relações de confiança entre tenants; remover permissões cross-tenant não utilizadas | Alta | ## Referências - [[ Cozy Bear]] — grupo responsável — SVR russo, espionagem de longo prazo - [[microsoft-corporate-breach-2024|Microsoft Corporaté Breach 2024]] — incidente base deste procedimento - [[european-diplomatic-phishing-2025|European Diplomatic Phishing 2025]] — campanha relacionada do mesmo ator - [[t1528-steal-application-access-token|T1528 - Steal Application Access Token]] — técnica MITRE central - [[t1550-001-app-access-token|T1550.001 - Application Access Token]] — uso do token roubado para autenticação - [[t1098-account-manipulation|T1098 - Account Manipulation]] — criação de Service Principal como forma de persistência - [[t1110-brute-force|T1110 - Brute Force]] — password spray como acesso inicial ao tenant de teste - [[t1539-steal-web-session-cookie|T1539 - Steal Web Session Cookie]] — técnica relacionada de roubo de sessão - [[proc-muddywater-blockchain-c2|PROC - MuddyWater Blockchain C2]] — outro exemplo de abuso de infraestrutura legítima - [[_techniques|Índice de TTPs]] — visão geral de todas as técnicas documentadas --- *Fonte: [Microsoft MSRC — Midnight Blizzard Breach Jánuary 2024](https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/)* *Fonte: [CISA Advisory — APT29 Cloud TTPs AA21-116A](https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-116a)* *Fonte: [Mandiant — APT29 Cloud Lateral Movement Techniques](https://www.mandiant.com/resources/blog/apt29-cloud-techniques)*