t1578-004-revert-cloud-instance

# T1578.004 - Revert Cloud Instance ## Técnica Pai [[t1578-modify-cloud-compute-infrastructure|T1578 - Modify Cloud Compute Infrastructure]] ## Descrição Após realizar atividades maliciosas em um ambiente de nuvem, um adversário pode reverter a instância de computação para um estado anterior - tipicamente restaurando um snapshot ou reiniciando a VM para usar armazenamento efêmero - com o objetivo de apagar rastros de sua presença e dificultar a análise forense. Em ambientes altamente virtualizados como infraestruturas IaaS (AWS EC2, Azure VMs, GCP Compute Engine), os provedores de nuvem oferecem mecanismos nativos de snapshot e backup que permitem restaurar máquinas virtuais e volumes de armazenamento para estados anteriores. Esses mecanismos, criados para fins de recuperação de desastres e continuidade de negócios, podem ser abusados por adversários para apagar evidências de compromisso. A técnica se enquadra na tática de **Defense Evasion** por visar específicamente a remoção de indicadores de comprometimento (IoCs) como logs, arquivos maliciosos, artefatos de persistência e modificações de configuração, tornando a resposta a incidentes significativamente mais difícil. É uma sub-técnica de [[t1578-modify-cloud-compute-infrastructure|T1578 - Modify Cloud Compute Infrastructure]], que cobre o conjunto mais amplo de manipulações de infraestrutura cloud para evasão. Uma variante desta técnica explora o **armazenamento efêmero** - presente em muitos tipos de instâncias cloud (instance store AWS, discos temporários Azure) - que é redefinido automaticamente ao parar e reiniciar a VM, eliminando qualquer evidência armazenada localmente sem que o adversário precise tomar ação explícita de reversão. ## Como Funciona O adversário, após obter permissões suficientes no ambiente cloud (tipicamente via credenciais comprometidas ou escalada de privilégios), executa a reversão de instância nos seguintes passos: 1. **Acesso às APIs de gerenciamento**: Com credenciais que incluem permissões como `ec2:CreateSnapshot`, `ec2:RestoreSnapshotTier`, `ec2:StopInstances`, `ec2:StartInstances` (AWS) ou equivalentes em Azure/GCP, o adversário acessa as APIs de gerenciamento. 2. **Identificação de snapshots disponíveis**: Enumera snapshots existentes da instância-alvo para identificar pontos de restauração que precedam sua atividade maliciosa, eliminando a necessidade de criar novos snapshots. 3. **Realização das atividades maliciosas**: Executa o objetivo principal - exfiltração de dados, implantação de backdoor, reconhecimento - com os artefatos residindo temporariamente no armazenamento da instância. 4. **Reversão para estado anterior**: Restaura a instância a partir de um snapshot anterior via console de gerenciamento ou APIs, ou simplesmente para e reinicia instâncias com armazenamento efêmero, zerando o estado local. No AWS: `aws ec2 creaté-image` + `aws ec2 run-instances` com AMI antiga; no Azure: restauração de disco gerenciado a partir de snapshot. 5. **Remoção de rastros residuais**: Pode complementar a reversão excluindo logs do CloudTrail, Azure Activity Log ou GCP Audit Logs referentes ao período da atividade (técnica correlacionada: [[t1070-indicator-removal|T1070 - Indicator Removal]]). ## Attack Flow ```mermaid graph TB A[Comprometimento de Credenciais com Permissões de Gerenciamento Cloud] --> B[Enumeração de Instâncias e Snapshots Disponíveis] B --> C{Tipo de Armazenamento} C -->|Persistente com Snapshot| D[Identifica Snapshot Anterior à Atividade Maliciosa] C -->|Efêmero Instance Store| E[Planejá uso de Armazenamento Temporário] D --> F[Execução da Atividade Maliciosa na Instância Alvo] E --> F F --> G{Método de Cobertura} G -->|Snapshot disponível| H[Restaura Instância a partir de Snapshot Pré-compromisso] G -->|Armazenamento efêmero| I[Para e Reinicia a VM Armazenamento Local Zerado] H --> J[Instância retorna ao estado original] I --> J J --> K[Artefatos maliciosos eliminados da instância] K --> L{Cobertura adicional?} L -->|Sim| M[Excluir logs de auditoria CloudTrail / Activity Log] L -->|Não| N[Análise forense da instância não encontra evidências] M --> N ``` ## Exemplos de Uso **Limpeza pós-exfiltração em AWS EC2** Um adversário com credenciais IAM comprometidas acessa uma instância EC2 via SSM Session Manager (sem abrir portas), exfiltra dados de um banco de dados RDS acessível pela instância e, em seguida, restaura a instância a partir de um AMI de backup existente. Os logs do SSM Session Manager podem ser suprimidos se o adversário tiver permissões de modificação na política de logging. **Abuso de armazenamento efêmero Azure** Em Azure, instâncias com disco temporário (`/mnt/resource` no Linux) armazenam dados que são perdidos ao desalocar e realocar a VM. Um adversário que opera exclusivamente nesse armazenamento pode eliminar todos os rastros locais com uma simples operação de restart, aproveitando um comportamento nativo da plataforma. **Reversão em GCP para cobrir rastros** No Google Cloud Platform, adversários com permissões `compute.instances.setDiskAutoDelete` e `compute.snapshots.creaté` podem criar snapshots pontuais antes de operações sensíveis, executar a atividade maliciosa e restaurar o disco gerenciado, simulando que a instância nunca foi comprometida do ponto de vista forense local. **Combinação com exclusão de logs** Esta técnica é frequentemente combinada com [[t1070-indicator-removal|T1070 - Indicator Removal]] para uma cobertura mais completa: a reversão da instância elimina artefatos locais, enquanto a exclusão de logs de auditoria cloud elimina o registro das próprias operações de reversão. ## Detecção A detecção desta técnica depende fundamentalmente de logs de auditoria de gerenciamento de nuvem com escopo global e retenção adequada. Os artefatos forenses residem nos logs das APIs de gerenciamento, não na instância em si. ```yaml title: Reversão Suspeita de Instância Cloud após Atividade Anômala status: experimental logsource: category: cloud product: aws service: cloudtrail detection: selection_revert: eventSource: ec2.amazonaws.com eventName: - RestoreSnapshotTier - ModifySnapshotAttribute - RunInstances - StopInstances - StartInstances selection_preceded_by_anomaly: eventName: - GetObject - CopyObject - DescribeInstances - CreateNetworkInterface timeframe: 2h condition: selection_revert falsepositives: - Operações legítimas de patch e atualização de AMI - Testes de DR e restore de backup - Auto Scaling Group substituindo instâncias unhealthy level: medium ``` **Regra para exclusão de logs precedendo reversão:** ```yaml title: Exclusão de Logs CloudTrail Seguida de Operação de Restore status: experimental logsource: category: cloud product: aws service: cloudtrail detection: selection: eventSource: cloudtrail.amazonaws.com eventName: - DeleteTrail - StopLogging - UpdateTrail condition: selection falsepositives: - Manutenção legítima de configuração de auditoria level: high ``` **Estrategias complementares de detecção:** - **Imutabilidade de logs**: Habilitar S3 Object Lock em buckets do CloudTrail com modo COMPLIANCE para impedir exclusão de logs mesmo por contas com permissões administrativas - **Correlação temporal**: Detectar padrões de `StopInstances` → `StartInstances` ou `RestoreSnapshot` que ocorrem pouco após acesso incomum (login de novo IP, uso de credenciais temporárias STS) - **Integridade de snapshots**: Monitorar criação e uso de snapshots fora dos horários de jánela de backup programada - **Alertas sobre operações de lifecycle de instância**: Qualquer operação de restore ou substituição de instância fora de jánelas de manutenção conhecidas deve gerar alerta para revisão ## Mitigação Não há mitigações MITRE ATT&CK formalmente mapeadas para T1578.004. Os controles compensatórios se concentram em detecção e limitação de permissões: | Controle | Descrição | |----------|-----------| | Princípio do Menor Privilégio | Restringir permissões de gerenciamento de snapshots e instâncias (ex: `ec2:StopInstances`, `ec2:RestoreSnapshotTier`) apenas a roles e contas com necessidade operacional documentada. Separar permissões de gerenciamento de lifecycle de instância das permissões de acesso a dados. | | Logs Imutáveis | Configurar CloudTrail com S3 Object Lock (modo COMPLIANCE), Azure Immutable Storage para logs de diagnóstico, ou GCP Log Sink para Cloud Storage com retenção bloqueada. Garantir que a exclusão de logs exijá aprovação multifatorial ou processo de negócios formal. | | Monitoramento de Atividade de Gerenciamento | Habilitar alertas para operações de restore, criação e exclusão de snapshots fora de jánelas programadas. Integrar CloudTrail / Activity Log ao SIEM com regras de correlação para sequências suspeitas. | | Backup Fora da Conta | Manter cópias de logs e snapshots em contas AWS / assinaturas Azure separadas que as credenciais comprometidas não possam acessar, implementando isolamento de blast radius. | ## Contexto Brasil/LATAM No Brasil, a adoção de infraestrutura IaaS cresceu significativamente com a migração de workloads para AWS São Paulo (`sa-east-1`) e Azure Brazil South. Com essa expansão, adversários sofisticados - especialmente grupos de espionagem e ransomware que operam na região - passaram a incorporar técnicas de manipulação de infraestrutura cloud em suas cadeias de ataque. O uso de armazenamento efêmero como mecanismo de anti-forense é particularmente insidioso em contextos de resposta a incidentes no Brasil, onde equipes de IR muitas vezes não estão familiarizadas com as nuances de armazenamento cloud e podem concluir incorretamente que uma instância não foi comprometida após verificar seu estado atual. A LGPD (Lei Geral de Proteção de Dados) e regulações do Banco Central exigem trilhas de auditoria robustas para sistemas que processam dados pessoais e financeiros - o que torna a configuração de logs imutáveis não apenas uma boa prática de segurança, mas uma obrigação regulatória em muitos contextos. Organizações que operam infraestrutura cloud no Brasil devem garantir que logs de gerenciamento sejam retidos de forma imutável por pelo menos 12 meses, conforme recomendações do CERT.br. A [[t1578-modify-cloud-compute-infrastructure|técnica pai T1578]] cobre o espectro mais amplo de manipulações de infraestrutura cloud utilizadas para evasão, e as organizações LATAM devem considerar controles para todas as sub-técnicas ao desenvolver suas políticas de segurança cloud. ## Referências - MITRE ATT&CK - T1578.004: Modify Cloud Compute Infrastructure - Revert Cloud Instance - AWS - EC2 Instance Store vs EBS: Diferenças de persistência - AWS Security Best Practices - CloudTrail with S3 Object Lock - CERT.br - Boas práticas de segurança em ambientes de nuvem - CIS AWS Foundations Benchmark - Logging and Monitoring Controls *Fonte: MITRE ATT&CK - T1578.004* ## Notas Relacionadas - [[_defenses|Hub de Defesas]] - controles preventivos e detecções - [[t1578-modify-cloud-compute-infrastructure|T1578 - Modify Cloud Compute Infrastructure]] - técnica pai - [[ds0020-snapshot|DS0020 - Snapshot]] - telemetria de snapshots de instâncias cloud