# T1578.005 - Modify Cloud Compute Configurations ## Técnica Pai Esta é uma sub-técnica de [[t1578-modify-cloud-compute-infrastructure|T1578 - Modify Cloud Compute Infrastructure]]. Enquanto a técnica pai cobre a manipulação de instâncias, snapshots e imagens de máquinas virtuais, esta sub-técnica foca específicamente na alteração de **configurações globais de compute** - cotas, políticas de tenant e restrições regionais - para expandir silenciosamente a capacidade de ataque sem acionar alertas convencionais. ## Descrição Adversários que comprometem ambientes de nuvem IaaS (AWS, Azure, GCP, Oracle Cloud) podem modificar configurações que afetam diretamente o tamanho, a localização e os recursos disponíveis para a infraestrutura de computação - com o objetivo de evadir defesas, abusar de recursos da vítima ou expandir o escopo do ataque de forma discreta. Essas configurações incluem: - **Cotas de serviço (*service quotas*):** limites impostos pelo provedor de nuvem sobre o número de vCPUs, instâncias, endereços IP elásticos e outros recursos que uma conta pode utilizar. Adversários podem solicitar ajustes de cota ou modificá-los via API para suportar operações como [[t1496-resource-hijacking|Resource Hijacking]] (mineração de criptomoedas, por exemplo) sem esgotar o limite original da vítima - o que geraria alertas. - **Políticas de tenant:** configurações em nível organizacional que definem restrições sobre tipos de máquinas virtuais, tamanhos permitidos e regiões habilitadas. A remoção de restrições permite ao adversário provisionar instâncias de alto poder computacional. - **Regiões habilitadas:** por padrão, muitas organizações operam em um conjunto restrito de regiões geográficas. Habilitar [[Unsupported Cloud Regions]] permite que o adversário implante infraestrutura em regiões não monitoradas, fora do escopo das ferramentas de segurança e logs configurados. - **Associações de assinatura:** em ambientes Azure, a manipulação de associações entre assinaturas e grupos de gerenciamento pode alterar o escopo de políticas de segurança aplicadas. A técnica é especialmente eficaz porque as modificações de configuração frequentemente não afetam instâncias em execução, não geram alertas de intrusão baseados em payload e podem ser confundidas com atividades legítimas de administração de nuvem. ## Como Funciona A exploração ocorre em quatro fases principais: 1. **Comprometimento de identidade privilegiada:** O adversário obtém credenciais de uma conta com permissões de administração de nuvem - via [[t1078-valid-accounts|credenciais válidas]], phishing, SSRF ou exploração de metadados de instância (IMDSv1). As permissões necessárias variam por provedor: - AWS: `servicequotas:RequestServiceQuotaIncrease`, `organizations:CreatePolicy` - Azure: `Microsoft.Compute/virtualMachines/write`, acesso ao nível de Management Group - GCP: `compute.projects.setCommonInstanceMetadata`, `iam.roles.updaté` 2. **Reconhecimento das configurações atuais:** O adversário enumera as cotas vigentes, políticas de organização e regiões habilitadas para entender os limites operacionais do ambiente e identificar onde expandir. 3. **Modificação das configurações:** As configurações são alteradas via API, CLI ou console - solicitações de aumento de cota, remoção de políticas restritivas, habilitação de regiões adicionais. Essas operações aparecem nos logs de auditoria, mas podem se perder em ambientes com alto volume de atividade administrativa legítima. 4. **Exploração da capacidade expandida:** Com cotas aumentadas e regiões adicionais habilitadas, o adversário provisiona recursos para mineração, C2, exfiltração de dados ou persistência - usando a infraestrutura e os créditos da vítima enquanto opera em zonas com menor vigilância. > [!tip] Controles preventivos recomendados > - **AWS:** Usar Service Control Policies (SCPs) para restringir quais contas podem solicitar aumentos de cota. Configurar AWS Config Rules para detectar regiões habilitadas fora da baseline. > - **Azure:** Usar Azure Policy com modo `Deny` para restringir SKUs de VMs e regiões permitidas. Configurar alertas de custo e Resource Locks em assinaturas críticas. > - **GCP:** Implementar Organization Policy Constraints (ex.: `constraints/compute.restrictCloudStorageForBigQueryTransfer`, `constraints/gcp.resourceLocations`) para limitar onde recursos podem ser criados. ## Attack Flow ```mermaid graph TB A["Comprometimento de identidade cloud<br/>(IAM, Service Principal, API Key)"] --> B["Reconhecimento de configurações<br/>Cotas, políticas, regiões habilitadas"] B --> C["Modificação de service quotas<br/>Aumento via API/console"] B --> D["Remoção de políticas restritivas<br/>Tenant policies, org constraints"] B --> E["Habilitação de novas regiões<br/>Regiões não monitoradas pela vítima"] C --> F["Provisionamento de instâncias extras<br/>Alto poder computacional sem alertas"] D --> F E --> G["Deploy em região não monitorada<br/>Fora do escopo de ferramentas SIEM"] F --> H["Resource Hijacking<br/>(mineração, C2, exfiltração)"] G --> H H --> I["Operação discreta<br/>Sem afetar cargas legítimas em execução"] ``` ## Exemplos de Uso **Campanhas de cryptojacking em cloud:** Adversários que comprometem contas AWS via credenciais expostas em repositórios GitHub frequentemente solicitam aumentos de cota de instâncias EC2 (especialmente famílias `p` e `g` com GPU) para maximizar o retorno de campanhas de mineração de criptomoedas. A solicitação de aumento de cota - que normalmente requer aprovação da AWS - pode ser antecipada ou contornada via modificação de configurações de organização em contas com permissões elevadas. **Persistência em regiões não monitoradas:** Um padrão documentado por pesquisadores de segurança cloud envolve habilitar regiões AWS como `ap-east-1` (Hong Kong) ou `af-south-1` (África do Sul) em contas de organizações que operam exclusivamente em `us-east-1`. O SIEM e as ferramentas de monitoramento configuradas para regiões específicas não capturam eventos nas novas regiões. O adversário implanta instâncias de C2 ou armazenamento de dados exfiltrados nessas regiões "cegas". **Azure Management Group manipulation:** Em ambientes Azure com múltiplas assinaturas, adversários com acesso ao nível de Management Group podem remover Azure Policies que impõem restrições de conformidade (ex.: `Allowed virtual machine SKUs`) ou desabilitar políticas de diagnóstico, reduzindo a visibilidade do SIEM sobre atividades subsequentes. **GCP Quota Abuse para exfiltração em escala:** Ao aumentar cotas de armazenamento (Cloud Storage buckets) e largura de banda de saída, adversários podem exfiltrar volumes maiores de dados sem acionar alertas de throttling baseados em limites de cota. A modificação de configurações de rede (VPC, firewall rules) em conjunto com aumento de cotas cria uma jánela de exfiltração mais ampla. **Cenário combinado com T1578 pai:** Em um ataque sofisticado, o adversário pode primeiro modificar as configurações de compute (T1578.005) para habilitar instâncias grandes em uma nova região, depois criar uma snapshot de um volume com dados sensíveis ([[t1578-modify-cloud-compute-infrastructure|T1578]]) e restaurá-la nessa nova região fora do monitoramento - combinando múltiplas sub-técnicas para maximizar a evasão. ## Detecção ### Estrategia principal A detecção eficaz requer monitoramento centralizado dos logs de auditoria de nuvem (CloudTrail, Azure Activity Log, GCP Audit Logs) com alertas específicos para operações de modificação de configuração em nível de organização ou tenant. **Indicadores de comprometimento:** - Solicitações de aumento de cota de serviço fora de padrões históricos da organização - Habilitação de regiões geográficas não utilizadas anteriormente - Modificações em políticas de organização (AWS SCPs, Azure Policies, GCP Org Policies) por contas não usuais - Remoção de políticas de restrição de SKUs de máquinas virtuais - Acesso ao Service Quotas API em horários atípicos ou por usuários sem histórico de uso - Alterações em associações de Management Groups (Azure) por contas não administrativas **Fontes de telemetria recomendadas:** - AWS: CloudTrail - eventos `RequestServiceQuotaIncrease`, `PutServiceQuotaIncreaseRequestIntoQueue`, `CreatePolicy` (Organizations) - Azure: Activity Log - operações em `Microsoft.Management/managementGroups`, `Microsoft.Authorization/policyDefinitions` - GCP: Cloud Audit Logs - `compute.projects.setCommonInstanceMetadata`, `resourcemanager.organizations.setIamPolicy` ```yaml title: Modificação de Service Quota em Conta AWS status: experimental description: > Detecta solicitações de aumento de cota de serviço AWS fora do padrão, potencialmente indicando comprometimento de conta para Resource Hijacking ou expansão de infraestrutura maliciosa (T1578.005). logsource: category: cloud product: aws service: cloudtrail detection: selection_quota: eventSource: 'servicequotas.amazonaws.com' eventName: - 'RequestServiceQuotaIncrease' - 'PutServiceQuotaIncreaseRequestIntoQueue' selection_compute: requestParameters.serviceCode: - 'ec2' - 'sagemaker' - 'lambda' condition: selection_quota and selection_compute falsepositives: - Solicitações legítimas de expansão de capacidade aprovadas pelo time de cloud - Processos automatizados de FinOps com documentação de mudança level: medium tags: - attack.defense_evasion - attack.t1578.005 ``` ## Mitigação | ID | Mitigação | Descrição | |---|-----------|-----------| | M1018 | [[m1018-user-account-management\|M1018 - User Account Management]] | Implementar o princípio do menor privilégio rigorosamente em identidades cloud. Separar funções: apenas contas de administração de plataforma devem ter permissão para modificar cotas, políticas de organização ou habilitar novas regiões. Revisar regularmente permissões IAM com ferramentas de análise de acesso (AWS IAM Access Analyzer, Azure AD Access Review). Habilitar MFA para todas as contas com privilégios de modificação de configuração. | | M1047 | [[m1047-audit\|M1047 - Audit]] | Configurar alertas em tempo real em CloudTrail/Azure Activity Log/GCP Audit Logs para operações de modificação de quota, políticas e regiões. Implementar baselines de uso de cotas e alertar sobre desvios. Revisar periodicamente as configurações de cotas e políticas de organização para identificar modificações não autorizadas. Usar ferramentas como AWS Config, Azure Policy Compliance ou GCP Security Command Center para rastrear o estado de configuração ao longo do tempo. | > [!warning] Risco de impacto financeiro > Além do risco de segurança, a modificação de cotas e configurações de compute representa risco financeiro direto. Campanhas de cryptojacking em cloud podem gerar faturas de dezenas de milhares de reais em dias. Configurar alertas de orçamento e limites de gasto no provedor de nuvem é uma camada adicional de detecção para abusos de Resource Hijacking via T1578.005. ## Contexto Brasil/LATAM A modificação de configurações de compute em nuvem é um vetor crescente de ameaça para organizações brasileiras e latino-americanas que adotaram infraestrutura IaaS. Campanhas de cryptojacking direcionadas a contas AWS e GCP com credenciais expostas em repositórios públicos têm afetado empresas de médio porte no Brasil, onde a maturidade de segurança cloud ainda está em desenvolvimento em muitos setores. O [[_sectors|setor financeiro]] brasileiro - que opera sob regulação do Banco Central (BACEN Resolução CMN 4.893/2021) e LGPD - enfrenta riscos específicos com esta técnica: adversários que modificam configurações de nuvem para habilitar regiões internacionais podem mover dados de clientes para fora do território nacional sem acionar alertas imediatos, violando requisitos de residência de dados. Grupos de [[t1496-resource-hijacking|resource hijacking]] que operam com foco em LATAM frequentemente exploram credenciais de cloud expostas por desenvolvedores em plataformas como GitHub e GitLab - um problema endêmico documentado em múltiplas pesquisas sobre práticas de segurança DevOps na região. Uma vez com acesso, a modificação de cotas para escalar operações de mineração antes da detecção é uma tática padrão. A combinação de [[t1578-modify-cloud-compute-infrastructure|T1578]] com [[t1535-unusedunsupported-cloud-regions|T1535]] (regiões não utilizadas) representa um risco elevado para organizações que não têm visibilidade multi-regional de seus ambientes cloud, situação comum em empresas brasileiras que inicialmente provisionam recursos exclusivamente em `sa-east-1` (São Paulo) sem configurar monitoramento global. ## Referências - MITRE ATT&CK - T1578.005: Modify Cloud Compute Configurations - AWS Documentation: Service Quotas - solicitação e gerenciamento de cotas - Azure Documentation: Management Groups e Azure Policy - GCP Documentation: Organization Policy Service e Constraints - Pesquisas sobre cryptojacking via credenciais cloud expostas em repositórios públicos - BACEN Resolução CMN 4.893/2021 - requisitos de segurança para instituições financeiras em cloud - Relatórios de [[t1496-resource-hijacking|Resource Hijacking]] em ambientes IaaS - Unit 42, Wiz Research *Fonte: MITRE ATT&CK - T1578.005*