t1666-modify-cloud-resource-hierarchy

# T1666 - Modify Cloud Resource Hierarchy ## Descrição Adversários podem tentar modificar estruturas hierárquicas em ambientes de infraestrutura como serviço (IaaS) com o objetivo de evadir defesas, escalar privilégios ou persistir no ambiente sem gerar logs visíveis às equipes de segurança da vítima. Ambientes IaaS frequentemente organizam recursos em hierarquias que possibilitam gerenciamento centralizado e aplicação de políticas a grupos de recursos. A estrutura hierárquica varia entre provedores de nuvem: - **AWS**: múltiplas contas agrupadas sob uma organização gerenciada pelo AWS Organizations, com Service Control Policies (SCPs) aplicadas em nível de Organizational Unit (OU) - **Azure**: múltiplas assinaturas agrupadas sob Management Groups, com Azure Policy e RBAC aplicados hierarquicamente - **GCP**: projetos organizados em pastas dentro de uma organização, com políticas IAM herdadas Adversários podem adicionar, excluir ou modificar grupos de recursos dentro de uma hierarquia IaaS para mover recursos para fora do alcance de controles de segurança, monitoramento ou políticas organizacionais. Diferentemente de [[t1578-modify-cloud-compute-infrastructure|T1578 - Modify Cloud Compute Infrastructure]], que manipula instâncias e componentes individuais, o T1666 opera na camada de governança - o adversário não modifica o que existe dentro da hierarquia, mas a própria estrutura que define quem controla e monitora esses recursos. ## Como Funciona O adversário explora permissões de gerenciamento organizacional - tipicamente obtidas via comprometimento de uma conta de Administrador Global (Azure), conta raiz ou conta de gerenciamento (AWS Organizations), ou papel de Org Admin (GCP) - para manipular a hierarquia de recursos. **Cenários de abuso por provedor:** **AWS - Saída de organização via `LeaveOrganization`** Um adversário com permissões suficientes em uma conta membro pode chamar a API `LeaveOrganization`, desvinculando a conta da AWS Organization à qual ela pertencia. Com isso: - Todas as SCPs (Service Control Policies) que restringiam ações na conta são removidas imediatamente - Guardrails de segurança implementados via AWS Control Tower são desativados - Alertas configurados no nível da organização param de monitorar essa conta - A conta passa a operar de forma independente, sem as restrições de compliance da organização **AWS - Criação de conta via `CreateAccount`** O adversário cria uma nova conta dentro da AWS Organization. Essa conta: - Utiliza os mesmos métodos de pagamento da conta de gestão (bilhão de dólares em recursos usados às custas da vítima) - Pode não estar sujeita às detecções ou SCPs existentes se for criada em uma OU sem políticas restritivas - Serve como ambiente isolado para operações sem deixar logs na conta principal da vítima **Azure - Criação de nova assinatura** Um adversário que obteve acesso a uma conta de Administrador Global pode criar novas assinaturas no tenant Azure da vítima para implantar recursos. As novas assinaturas herdam o tenant mas podem não estar cobertas pelas políticas de Azure Defender, Microsoft Sentinel ou Azure Policy configuradas nas assinaturas existentes. **Azure - Subscription hijacking (sequestro de assinatura)** Em um cenário mais sofisticado, o adversário transfere uma assinatura *pay-as-you-go* existente do tenant da vítima para um tenant controlado por ele. Isso permite: - Usar os recursos de computação da vítima sem gerar logs no tenant original - Acessar dados e backups associados à assinatura transferida - Efetivamente "roubar" a infraestrutura sem comprometer instâncias individuais **GCP - Movimentação de projeto entre organizações** No GCP, projetos podem ser movidos entre pastas e organizações. Um adversário com permissões de `resourcemanager.projects.updaté` pode mover projetos contendo recursos sensíveis para fora do escopo de auditoria da organização original. ## Attack Flow ```mermaid graph TB A[Comprometimento de conta privilegiada Org Admin / Global Admin / Root Account] --> B[Reconhecimento da hierarquia ListAccounts / ListSubscriptions / ListProjects] B --> C{Objetivo do adversário} C --> D[Evasão de controles de segurança Remover SCPs / Policy que restringem ações] C --> E[Persistência oculta Criar nova conta ou assinatura fora do radar] C --> F[Sequestro de recursos Transferir assinatura para tenant próprio] D --> G[LeaveOrganization - AWS Conta membro sai da org, SCPs removidas] E --> H[CreateAccount - AWS Nova conta usa billing da vítima sem logs] E --> I[Criar nova assinatura - Azure Fora do escopo de Sentinel e Defender] F --> J[Subscription hijacking - Azure Assinatura transferida para tenant adversário] G --> K[Operações sem restrição de compliance na conta liberada] H & I --> L[Deploy de infraestrutura ofensiva sem alertas nos ambientes monitorados] J --> M[Acesso a recursos e dados da vítima sem gerar logs no tenant original] K & L & M --> N[Evasão bem-sucedida Governança organizacional comprometida] ``` ## Exemplos de Uso **Subscription hijacking em campanha de acesso inicial ao Azure** Em incidentes documentados por equipes de resposta da Microsoft, adversários que comprometeram contas de Administrador Global via phishing de credenciais criaram novas assinaturas no tenant da vítima imediatamente após o acesso inicial. Nessas assinaturas, implantaram VMs para movimento lateral e pivotamento, aproveitando que as novas assinaturas não estavam cobertas pelo Microsoft Sentinel configurado apenas nas assinaturas de produção. **Cryptojacking via conta AWS criada fora da organização** Em campanhas de cryptojacking financeiramente motivadas, grupos como o UNC3944 (Storm-0501) exploraram chaves de acesso de contas com permissões de gerenciamento organizacional para criar novas contas AWS via `CreateAccount`. Essas contas foram usadas para provisionar instâncias EC2 de alto desempenho para mineração de criptomoedas às custas da conta de billing da vítima, com os logs de uso aparecendo apenas nas novas contas - não monitoradas pelo SOC da organização. **Técnica combinada com [[t1578-modify-cloud-compute-infrastructure|T1578]]** O padrão mais sofisticado combina T1666 e T1578: o adversário primeiro move uma conta AWS para fora da organização (removendo SCPs), depois usa essa conta livre de restrições para criar instâncias e snapshots sem as limitações de policy que existiam antes. Essa combinação é especialmente eficaz contra organizações que implementaram SCPs restritivos como controle primário de segurança. **Relacionamento com [[t1136-003-cloud-account|T1136.003 - Cloud Account]]** A criação de novas contas dentro da organização (via `CreateAccount`) está diretamente relacionada à técnica de criação de contas cloud (T1136.003). Em T1666, o foco é a manipulação da hierarquia em si; em T1136.003, o foco é a criação da conta como mecanismo de persistência. Na prática, os adversários frequentemente executam ambas em sequência. ## Detecção A detecção de T1666 exige monitoramento específico das APIs de gerenciamento organizacional, que são frequentemente negligenciadas em favor do monitoramento de APIs de computação e identidade. ```yaml title: Modificação de Hierarquia de Recursos Cloud status: experimental logsource: category: cloud product: aws service: cloudtrail detection: selection_org_events: eventSource: organizations.amazonaws.com eventName|contains: - LeaveOrganization - CreateAccount - MoveAccount - DetachPolicy - DeleteOrganizationalUnit filter_known_automation: userAgent|contains: - aws-sdk-go condition: selection_org_events and not filter_known_automation level: critical tags: - attack.defense_evasion - attack.t1666 ``` **Indicadores adicionais por provedor:** **AWS:** - `LeaveOrganization` - Qualquer chamada deve ser investigada; é rara em operações legítimas e de alto impacto - `CreateAccount` fora de processos de provisionamento conhecidos (ex: Terraform, Control Tower) - `DetachPolicy` em SCPs críticas de segurança - Atividade de uma conta que passou a gerar logs isolados após período de logs integrados à organização **Azure:** - Criação de nova assinatura por conta que não é parte do processo de provisionamento aprovado - `Microsoft.Subscription/subscriptions/write` por conta sem histórico de criação de assinaturas - Transferência de assinatura para tenant diferente (`Microsoft.Subscription/subscriptions/cancel`) - Atividade de Administrador Global fora do horário comercial em operações de gerenciamento de assinatura **GCP:** - `cloudresourcemanager.projects.move` em projetos de produção - Projetos removidos de pastas de organização monitoradas e movidos para pasta raiz ou outra organização - Mudanças em política de IAM no nível de organização por conta não pertencente ao grupo de administradores de plataforma ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1054 | [[m1054-software-configuration\|M1054 - Software Configuration]] | Configurar SCPs no AWS Organizations para bloquear `LeaveOrganization` e `CreateAccount` em todas as contas exceto a conta de gerenciamento. No Azure, usar Azure Policy para restringir criação de assinaturas. No GCP, usar políticas de restrição de organização para impedir movimentação de projetos. | | M1018 | [[m1018-user-account-management\|M1018 - User Account Management]] | Restringir ao máximo o número de identidades com permissões de gerenciamento organizacional. Exigir MFA obrigatório para Administradores Globais (Azure), conta raiz (AWS) e Org Admins (GCP). Revisar periodicamente quem possui essas permissões. | | M1047 | [[m1047-audit\|M1047 - Audit]] | Habilitar auditoria de todas as operações de gerenciamento organizacional. No AWS, garantir que CloudTrail cubra a conta de gerenciamento e todas as contas membro com integridade de log ativada. No Azure, configurar o Azure Activity Log para o tenant com retenção de longo prazo. Alertar sobre qualquer chamada a APIs de hierarquia organizacional. | **Controles preventivos adicionais:** - **AWS**: Usar SCP para explicitamente bloquear `organizations:LeaveOrganization` em todas as OUs de contas membro. Habilitar AWS Config Aggregator para visibilidade consolidada de todas as contas da organização. - **Azure**: Habilitar Privileged Identity Management (PIM) para o papel de Administrador Global, exigindo aprovação just-in-time para ativação. Configurar alertas no Microsoft Sentinel para operações de gerenciamento de assinatura. - **GCP**: Usar Organization Policy Constraints como `constraints/resourcemanager.allowedExportDestinations` para restringir movimentação de projetos entre organizações. - **Breakglass accounts**: Monitorar o uso de contas de acesso de emergência (break-glass), que tipicamente têm as permissões necessárias para T1666 e raramente devem ser utilizadas. ## Contexto Brasil/LATAM A adoção de estruturas multi-conta e multi-assinatura em nuvem pública cresce rapidamente entre grandes corporações brasileiras, especialmente no [[financial|setor financeiro]], [[energy|setor de energia]] e [[government|governo federal]], criando superfície de ataque crescente para T1666. **Panorama e riscos regionais:** - **Complexidade de governança multi-conta**: Grupos financeiros brasileiros com dezenas de subsidiárias tendem a criar estruturas AWS Organizations ou Azure tenants complexas, com permissões de gerenciamento distribuídas entre equipes de plataforma, segurança e negócios. Essa fragmentação aumenta o risco de identidades excessivamente privilegiadas que poderiam executar T1666. - **MSPs e integradores**: O mercado brasileiro de serviços gerenciados de nuvem é amplo. MSPs frequentemente precisam de permissões de Administrador no tenant ou organização do cliente para operar. O comprometimento de um MSP pode fornecer ao adversário permissões de gerenciamento hierárquico em múltiplos clientes simultaneamente. - **Subscription hijacking como fraude financeira**: O sequestro de assinaturas Azure tem um vetor de impacto financeiro direto - a assinatura transferida continua gerando custos na conta de billing da vítima. Para empresas brasileiras com ambientes Azure de grande escala, esse custo pode ser substancial antes de ser detectado. - **Regulação e compliance**: A técnica T1666 tem implicações diretas para conformidade regulatória no Brasil. A remoção de uma conta AWS do perímetro de uma AWS Organization pode efetivamente retirar essa conta do escopo de controles exigidos pelo Banco Central (BACEN) para instituições financeiras, pela ANPD para proteção de dados pessoais (LGPD) e pela ANATEL para empresas de telecomúnicações. - **Visibilidade limitada em incidentes**: Em exercícios de simulação de resposta a incidentes conduzidos no Brasil, equipes de SOC frequentemente não têm visibilidade sobre eventos de gerenciamento organizacional da nuvem. CloudTrail para a conta de gerenciamento AWS e logs de Activity do Azure ao nível de tenant são frequentemente não ingeridos no SIEM, criando pontos cegos que T1666 explora diretamente. ## Referências - MITRE ATT&CK - T1666 (técnica adicionada na versão 16) - AWS Organizations: Service Control Policies e LeaveOrganization API - Microsoft Azure: Subscription transfer e Management Groups documentation - CIS Benchmark for AWS Organizations - CISA: Cloud Security Best Practices - Securing Multi-Account Environments - Microsoft MSRC: Detecção de subscription hijacking em Azure tenants *Fonte: MITRE ATT&CK - T1666*