t1671-cloud-application-integration

# T1671 - Cloud Application Integration ## Descrição Adversários podem obter persistência em ambientes SaaS e de nuvem corporativa explorando integrações de aplicações OAuth. Em ambientes como Microsoft 365, Google Workspace e Salesforce, usuários frequentemente autorizam aplicações de terceiros a acessar seus dados e realizar ações em seu nome - esse mecanismo legítimo de produtividade pode ser abusado como um canal de acesso persistente difícil de detectar e revogar. O protocolo OAuth permite que uma aplicação obtenha um token de acesso que representa as permissões de um usuário, sem que a aplicação conheça a senha do usuário. Em um ataque por meio de T1671, o adversário cria uma aplicação OAuth maliciosa ou compromete uma integração existente, e então induz um usuário - preferêncialmente com altos privilégios - a conceder consentimento à aplicação. Uma vez concedido o consentimento, o adversário possui um token de longa duração que lhe permite acessar dados e executar ações no ambiente da vítima, independentemente de mudanças de senha ou revogação de sessões. A técnica é particularmente insidiosa porque os tokens OAuth frequentemente sobrevivem à desativação ou exclusão da conta do usuário que concedeu o consentimento - dependendo da configuração do tenant, uma integração aprovada pode continuar funcionando mesmo após o usuário alvo ser removido da organização. Isso cria um canal de acesso persistente que é invisível em logs de autenticação convencionais, pois as ações são realizadas em nome de uma aplicação autorizada, não por uma sessão de usuário direta. Grupos como o [[g0016-apt29|APT29]] (Cozy Bear), vinculado ao SVR russo, são documentados pelo uso de técnicas de OAuth abuse em campanhas contra organizações governamentais e empresas de tecnologia. O grupo [[g1015-scattered-spider|Scattered Spider]] (UNC3944) é conhecido por campanhas de engenharia social sofisticadas que culminam na concessão de consentimento OAuth a aplicações maliciosas em ambientes Microsoft 365 e Okta. ## Como Funciona ### Fluxo de um Ataque OAuth Abuse **Fase 1 - Criação da aplicação maliciosa:** O adversário registra uma aplicação OAuth em um tenant Azure AD (Microsoft Entra ID), Google Cloud ou outro provedor de identidade. A aplicação pode ser criada em um tenant separado controlado pelo adversário (ataque "cross-tenant") ou dentro do próprio tenant da vítima se o adversário já tiver acesso. **Fase 2 - Phishing de consentimento (Consent Phishing):** O adversário envia um link de autorização OAuth cuidadosamente construído para usuários da organização alvo - frequentemente disfarçado de integração legítima de produtividade (ex: "Novo conector do Teams", "Aprovação necessária para integração de RH"). O link redireciona para a tela de consentimento legítima do Microsoft/Google, tornando o ataque difícil de identificar como fraude. **Fase 3 - Concessão de consentimento:** Se o usuário alvo aceitar, a aplicação maliciosa recebe um token de acesso com os escopos solicitados. Adversários frequentemente solicitam escopos amplos como `Mail.Read`, `Files.ReadWrite.All`, `Directory.Read.All` ou acesso a dados do Exchange/SharePoint. **Fase 4 - Persistência e exploração:** Com o token, o adversário realiza: - Leitura contínua de e-mails e documentos sensíveis (espionagem) - Exfiltração automatizada via [[t1020-automated-exfiltration|Automated Exfiltration]] - Criação de regras de redirecionamento de e-mail para endereços externos - Acesso a dados mesmo após mudança de senha (token não é inválidado por reset de senha) - Bypass de MFA - tokens OAuth não exigem segundo fator após concessão inicial **Bypass de MFA:** Esta é uma das capacidades mais críticas desta técnica. Uma vez que o token OAuth é obtido, as chamadas de API subsequentes usam o token diretamente - sem exigir que o usuário complete o fluxo de autenticação novamente, incluindo MFA. Isso torna T1671 um vetor eficaz para organizações que acreditam estar protegidas pela autenticação multifator. ### Criação de Service Principal (Microsoft 365) Em ambientes Microsoft 365, aplicações OAuth requerem um Service Principal no Azure AD. Um adversário com acesso a uma conta de alto privilégio pode criar um Service Principal e atribuir-lhe permissões diretamente via API do Microsoft Graph, sem necessidade de consentimento de usuário - criando um canal de acesso que opera completamente fora dos fluxos de autenticação convencionais. ## Attack Flow ```mermaid graph TB A[Adversário] --> B{Vetor de acesso\ninicial} B --> C[Consent Phishing Link OAuth malicioso] B --> D[Conta comprometida com privilégios de admin] C --> E[Usuário concede consentimento OAuth] D --> F[Admin cria Service Principal e atribui permissões] E --> G[Adversário obtém Access Token OAuth] F --> G G --> H{Objetivos do adversário} H --> I[Leitura de e-mails e documentos via API] H --> J[Exfiltração automatizada SharePoint / OneDrive] H --> K[Bypass de MFA em acessos subsequentes] H --> L[Persistência mesmo após reset de senha do usuário] I --> M[Acesso persiste até revogação manual do token] J --> M K --> M L --> M ``` ## Exemplos de Uso ### APT29 - Campanha SolarWinds e Pós-Comprometimento em Microsoft 365 O [[g0016-apt29|APT29]] (Cozy Bear / Nobelium), atribuído ao Serviço de Inteligência Estrangeira da Rússia (SVR), é documentado extensivamente pelo uso de OAuth abuse em ambientes Microsoft 365. Após o comprometimento inicial via a cadeia de supply chain do [[solarwinds-attack|ataque SolarWinds]], o APT29 utilizou técnicas de criação de Service Principals e aplicações OAuth para manter acesso persistente ao ambiente de e-mail e documentos de dezenas de organizações governamentais e empresas de tecnologia, mesmo após a descoberta e remediação parcial do comprometimento. O grupo usou as permissões OAuth para ler e-mails de contas de alto valor, incluindo correspondências de líderes de segurança nacional e executivos de empresas de tecnologia. A persistência via OAuth foi particularmente difícil de erradicar porque muitas organizações não tinham processos para auditar e revogar integrações de aplicações de terceiros. ### Scattered Spider (UNC3944) - Engenharia Social e OAuth O [[g1015-scattered-spider|Scattered Spider]], grupo de crime cibernético anglófono conhecido por técnicas avançadas de engenharia social e ataques a empresas de hospitalidade e telecomúnicações, é documentado pelo uso de consent phishing como parte de sua cadeia de ataque. O grupo realiza ligações telefônicas para funcionários de help desk, convencendo-os a aprovar integrações OAuth sob o pretexto de resolver problemas técnicos, e em seguida usa os tokens obtidos para acessar ambientes Okta, Microsoft 365 e AWS. ### Ataques a Microsoft 365 via "Illicit Consent Grant" A Microsoft documentou uma família de ataques chamada "Illicit Consent Grant" onde campanhas de phishing em larga escala distribuem links de autorização OAuth para aplicações maliciosas registradas com nomes que imitam produtos legítimos (ex: "Zoom Updaté", "DocuSign Integration", "IT Security Scanner"). Quando um usuário autoriza a aplicação, o adversário obtém acesso persistente ao e-mail e arquivos, frequentemente configurando regras de redirecionamento de e-mail para exfiltrar comúnicações em tempo real. ### Casos de Persistência em Google Workspace Em ambientes Google Workspace, adversários utilizam o Google Apps Script e Google Cloud Service Accounts para criar integrações OAuth com permissões elevadas. Um Service Account com permissões de "domain-wide delegation" pode impersonar qualquer usuário do domínio e acessar seus dados via API, tornando-se um vetor de acesso extremamente privilegiado que persiste indefinidamente se não for auditado. ## Detecção ### Regra Sigma ```yaml title: Suspicious OAuth Application Consent Grant in Azure AD id: 4b9e2f1c-7a3d-8e5b-d2f4-9c1a7e3b6d2f status: experimental description: > Detecta concessão de consentimento OAuth a aplicações de terceiros em ambientes Azure AD / Microsoft 365, especialmente para escopos com alto privilégio. Indica possível Consent Phishing ou Illicit Consent Grant. Técnica MITRE ATT&CK T1671. references: - https://attack.mitre.org/techniques/T1671/ - https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent author: RunkIntel daté: 2026-03-25 tags: - attack.persistence - attack.t1671 logsource: product: azure service: auditlogs detection: selection: operationName: 'Consent to application' resultType: 'Success' selection_high_risk_scopes: additionalDetails|contains: - 'Mail.Read' - 'Mail.ReadWrite' - 'Files.ReadWrite.All' - 'Directory.ReadWrite.All' - 'Exchange.ManageAsApp' - 'full_access_as_app' condition: selection and selection_high_risk_scopes fields: - initiatedBy - targetResources - additionalDetails - ipAddress - userAgent falsepositives: - Concessões legítimas aprovadas pelo processo de gestão de aplicações da organização - Integrações de produtividade aprovadas pelo time de TI level: high --- title: New Azure AD Service Principal with Sensitive Permissions id: 8c3f5a2b-1e7d-4b9f-a3c5-2e8f4a6b1c9d status: stable description: > Detecta criação de novo Service Principal no Azure AD com permissões sensíveis que permitem acesso a dados de e-mail ou arquivos de usuários. Indica possível abuso de T1671. references: - https://attack.mitre.org/techniques/T1671/ author: RunkIntel daté: 2026-03-25 tags: - attack.persistence - attack.t1671 logsource: product: azure service: auditlogs detection: selection: operationName: 'Add service principal' resultType: 'Success' condition: selection fields: - initiatedBy - targetResources - ipAddress falsepositives: - Criação legítima de Service Principals por times de desenvolvimento - Integrações de parceiros aprovadas pelo processo formal de revisão level: medium ``` **Fontes de dados adicionais para correlação:** | Fonte | O que monitorar | |-------|-----------------| | Azure AD Audit Logs | Eventos `Consent to application`, `Add service principal`, `Add OAuth2PermissionGrant` | | Microsoft 365 Unified Audit Log | Acesso a e-mails e arquivos por aplicações (não por usuários) | | Google Workspace Admin Reports | Concessões de OAuth, adição de service accounts com domain-wide delegation | | Application Log Content | Chamadas de API Microsoft Graph / Google APIs originadas de IPs suspeitos | | User Account Modification | Criação de contas de serviço cloud associadas a novas aplicações | ## Mitigação | ID | Mitigação | Aplicação | |----|-----------|-----------| | M1042 | [[m1042-disable-or-remove-feature-or-program\|Disable or Remove Feature or Program]] | Desabilitar a possibilidade de usuários finais concederem consentimento a aplicações de terceiros sem aprovação prévia de administrador; exigir fluxo de aprovação centralizado via Azure AD "Admin Consent" | | M1047 | [[m1047-audit\|Audit]] | Auditar periodicamente todas as aplicações OAuth com consentimento concedido; revisar escopos e revogar aplicações desconhecidas ou com permissões excessivas; usar Microsoft Entra ID Governance ou Google Workspace Admin para inventário | **Recomendações adicionais de hardening:** - **Microsoft 365:** Configurar `User consent settings` para requerer aprovação de administrador para qualquer concessão de permissão. Habilitar Azure AD Conditional Access para bloquear tokens de aplicações não verificadas. - **Google Workspace:** Configurar "API controls" para restringir quais aplicações podem acessar dados do Workspace. Revisar Service Accounts com "domain-wide delegation" habilitada. - Implementar alertas no SIEM para novos consentimentos OAuth com escopos de alto privilégio (`Mail.Read`, `Files.ReadWrite.All`, `Directory.ReadWrite.All`) - Treinar usuários para não conceder consentimento a aplicações fora do processo formal de aprovação de TI - especialmente aplicações solicitadas via e-mail, mensagens ou ligações não solicitadas - Revogar periodicamente tokens OAuth de aplicações não utilizadas há mais de 90 dias ## Contexto Brasil/LATAM A adoção crescente de Microsoft 365 e Google Workspace nas empresas brasileiras torna T1671 cada vez mais relevante no contexto local. O Brasil é consistentemente um dos países com maior volume de ataques de phishing direcionados a credenciais corporativas na América Latina, criando o vetor de acesso inicial que frequentemente precede o abuso de integrações OAuth. **Setor corporativo e financeiro:** Grandes corporações brasileiras, bancos e fintechs que migraram para Microsoft 365 são alvos atrativos para campanhas de consent phishing. Um token OAuth com `Mail.Read` e `Files.ReadWrite.All` em um ambiente M365 corporativo brasileiro pode dar acesso a contratos, dados financeiros e comúnicações estratégicas de alto valor para espionagem industrial ou extorsão. **Setor governamental:** Órgãos do governo federal brasileiro que utilizam Microsoft 365 (via acordos governamentais) são alvos de interesse para grupos de espionagem patrocinados por estados estrangeiros. Ataques similares ao que o [[g0016-apt29|APT29]] realizou contra agências americanas via OAuth abuse têm potencial de impactar órgãos equivalentes brasileiros - especialmente com a crescente digitalização de processos governamentais. **Ataques de ransomware e extorsão:** Grupos de ransomware que operam no Brasil, incluindo afiliados do [[lockbit|LockBit]] e do [[blackcat|BlackCat]], têm adotado técnicas de acesso inicial via ambientes cloud antes de mover-se lateralmente para infraestrutura on-premises. Uma integração OAuth comprometida pode ser o ponto de entrada para exfiltração de dados usado como alavanca em esquemas de dupla extorsão. **Conformidade LGPD:** Do ponto de vista regulatório, ataques via OAuth que resultam em exfiltração de dados pessoais enquadram-se nos requisitos de notificação da Lei Geral de Proteção de Dados (LGPD). Organizações brasileiras precisam incluir a auditoria de integrações OAuth em seus processos de gestão de acesso para garantir conformidade. ## Referências - [[g0016-apt29|APT29]] - grupo com uso documentado de OAuth abuse em M365 - [[g1015-scattered-spider|Scattered Spider]] - consent phishing via engenharia social - [[t1550-001-app-access-token|T1550.001 - Application Access Token]] - técnica complementar de uso de tokens - [[t1020-automated-exfiltration|T1020 - Automated Exfiltration]] - técnica frequentemente combinada - [[t1136-003-cloud-account|T1136.003 - Cloud Account]] - criação de contas de serviço cloud - [[t1098-003-additional-cloud-roles|T1098.003 - Additional Cloud Roles]] - atribuição de permissões elevadas - [[m1042-disable-or-remove-feature-or-program|M1042 - Disable or Remove Feature or Program]] - mitigação central - [[m1047-audit|M1047 - Audit]] - auditoria de integrações OAuth - [[solarwinds-attack|Ataque SolarWinds]] - campanha que usou OAuth abuse extensivamente - [[financial|Setor Financeiro]] - setor brasileiro de alto risco para esta técnica --- *Fonte: MITRE ATT&CK - T1671 Cloud Application Integration, v16.2*