# T1578.002 - Creaté Cloud Instance
## Técnica Pai
Esta é uma sub-técnica de [[t1578-modify-cloud-compute-infrastructure|T1578 - Modify Cloud Compute Infrastructure]], que cobre o conjunto de técnicas onde adversários manipulam a infraestrutura de computação em nuvem para evasão, persistência ou exfiltração de dados.
## Descrição
Um adversário pode criar uma nova instância ou máquina virtual (VM) dentro do serviço de computação de uma conta em nuvem como forma de contornar defesas. A criação de uma nova instância permite ao adversário operar em um ambiente sem as restrições de firewall, políticas de segurança e controles de monitoramento aplicados às instâncias existentes na conta.
O atacante pode combinar esta técnica com [[t1578-001-create-snapshot|T1578.001 - Creaté Snapshot]] - criando um snapshot de volumes da conta comprometida, montando-os na nova instância e aplicando uma política de segurança menos restritiva - para acessar dados via [[t1005-data-from-local-system|T1005 - Data from Local System]] ou realizar [[t1074-002-remote-data-staging|T1074.002 - Remote Data Staging]] antes da exfiltração.
Criar uma nova instância também permite ao adversário conduzir atividades maliciosas no ambiente sem interferir na operação das instâncias legítimas em execução, reduzindo o risco de detecção por anomalias de comportamento em hosts existentes.
Esta técnica se insere em [[ta0005-defense-evasion|TA0005 - Defense Evasion]] e é frequentemente utilizada por adversários que já comprometeram credenciais de alto privilégio em plataformas de nuvem como AWS, Azure ou GCP.
## Como Funciona
**Pré-requisito:** O adversário deve ter obtido credenciais com permissões suficientes para criar instâncias computacionais - tipicamente via [[t1078-004-cloud-accounts|T1078.004 - Valid Accounts: Cloud Accounts]] após comprometimento de console web, roubo de chaves de API ou escalada de privilégios dentro do ambiente de nuvem.
**Fluxo de ataque típico:**
1. **Reconhecimento da conta** - O adversário enumera as instâncias, grupos de segurança, sub-redes e políticas de IAM existentes para planejar a nova instância
2. **Criação da instância** - Usando as APIs nativas da plataforma (`ec2:RunInstances` na AWS, `compute.instances.insert` no GCP, `Microsoft.Compute/virtualMachines/write` no Azure), o adversário provisiona uma nova VM com uma imagem controlada ou com uma imagem legítima modificada
3. **Configuração permissiva** - A nova instância recebe um grupo de segurança com regras amplas (ex: SSH aberto para qualquer IP) e políticas IAM menos restritivas do que as instâncias de produção
4. **Montagem de dados** - Snapshots de volumes existentes são montados na nova instância para acesso aos dados sem alterar as instâncias originais
5. **Operações maliciosas** - Exfiltração de dados, uso como infraestrutura de C2, mineração de criptomoedas ou movimentação lateral para outros serviços da conta
6. **Cobertura de rastros** - A instância pode ser encerrada após a operação usando [[t1578-004-revert-cloud-instance|T1578.004 - Revert Cloud Instance]] ou simplesmente deletada para remover evidências
**APIs de criação por plataforma:**
| Plataforma | Serviço | Ação/Permissão |
|-----------|---------|----------------|
| AWS | EC2 | `ec2:RunInstances` |
| AWS | ECS/Fargaté | `ecs:RunTask` |
| GCP | Compute Engine | `compute.instances.insert` |
| Azure | VM | `Microsoft.Compute/virtualMachines/write` |
| Oracle Cloud | Compute | `instance.creaté` |
## Attack Flow
```mermaid
graph TB
A[Comprometimento de Credenciais Cloud - T1078.004] --> B[Enumeração da infraestrutura existente]
B --> C[Criar snapshot de volumes sensíveis - T1578.001]
C --> D[Provisionar nova instância com API nativa]
D --> E{Configuração da instância maliciosa}
E -->|Política IAM permissiva| F[Bypass de controles de segurança existentes]
E -->|Security Group aberto| G[Acesso remoto sem restrições de rede]
E -->|Volumes montados| H[Acesso a dados - T1005]
F --> I[Operações sem interferir nas instâncias legítimas]
G --> I
H --> I
I --> J{Objetivo do adversário}
J -->|Exfiltração| K[T1074.002 - Remote Data Staging]
J -->|C2| L[Infraestrutura de Comando e Controle]
J -->|Cryptomining| M[Abuso de recursos computacionais]
K --> N[Encerrar/deletar instância - cobrir rastros]
L --> N
M --> N
N --> O[Evasão de Defesa - TA0005]
```
## Exemplos de Uso
**LAPSUS$**
O grupo [[g1004-lapsus|LAPSUS$]], com membros identificados no Brasil e no Reino Unido, utilizou amplamente técnicas de abuso de infraestrutura em nuvem durante sua campanha de 2021-2022 contra alvos como Microsoft, Okta, Samsung e Nvidia. O grupo comprometia contas de alto privilégio e criava recursos computacionais para exfiltrar dados de propriedade intelectual antes de ser detectado, aproveitando as permissões obtidas por meio de engenharia social contra funcionários de suporte técnico.
**Scattered Spider**
O [[g1015-scattered-spider|Scattered Spider]] (UNC3944), grupo com sobreposição com LAPSUS$ e especializado em ataques a ambientes Azure e AWS, documentadamente cria instâncias de VM em contas comprometidas para usar como pivôs de acesso a outros recursos da conta e para staging de dados exfiltrados. O grupo tem histórico de ataques a empresas de telecomúnicações e hospedagem em nuvem.
**Cenário de mineração de criptomoedas (Cryptojacking)**
Grupos de ameaça financeiramente motivados que operam na América Latina frequentemente utilizam credenciais AWS/GCP comprometidas para criar dezenas de instâncias de alta CPU em regiões pouco monitoradas (como `us-east-1` ou `eu-west-1`), executando mineradores de Monero por horas antes de serem detectados via alertas de custo. O prejuízo pode chegar a centenas de milhares de dólares em uma única campanha.
**Cenário de exfiltração via snapshot:**
Um adversário com acesso à conta AWS cria um snapshot do volume EBS do banco de dados de produção, monta-o em uma nova instância EC2 em uma sub-rede diferente, copia os dados para um bucket S3 com ACL pública e então encerra ambas as instâncias - tudo em menos de 30 minutos.
## Detecção
```yaml
title: Suspicious Cloud Instance Creation in Non-Standard Region or Config
status: experimental
logsource:
category: cloud
product: aws
service: cloudtrail
detection:
selection_creaté:
eventSource: 'ec2.amazonaws.com'
eventName: 'RunInstances'
filter_legit_users:
userAgent|contains:
- 'Terraform'
- 'CloudFormation'
- 'console.amazonaws.com'
selection_anomaly:
requestParameters.instanceType|contains:
- 'metal'
- '32xlarge'
- '16xlarge'
condition: selection_creaté and (not filter_legit_users or selection_anomaly)
level: high
tags:
- attack.defense_evasion
- attack.t1578.002
```
**Estrategias de detecção complementares:**
- **CloudTrail / Audit Logs** - Monitorar eventos `RunInstances` (AWS), `compute.instances.insert` (GCP) e operações de criação de VM (Azure) realizados por identidades fora do fluxo normal de IaC (Terraform, CloudFormation)
- **Instâncias em regiões incomuns** - Alertar sobre criação de instâncias em regiões onde a organização não opera normalmente
- **Aumento repentino de custo** - Integrar alertas de orçamento de nuvem com o SIEM; picos abruptos de custo computacional são indicativos
- **Configuração de Security Group permissiva** - Detectar instâncias criadas com regras de ingresso amplas (0.0.0.0/0 em portas sensíveis como 22, 3389, 4444)
- **Uso de AMIs externas** - Alertar sobre instâncias criadas a partir de AMIs não catalogadas no inventário aprovado da organização
- **Correlação com snapshots** - Detectar a sequência `CreateSnapshot` → `RunInstances` → `AttachVolume` em curto intervalo de tempo como padrão de acesso a dados
## Mitigação
| ID | Mitigação | Descrição |
|---|-----------|-----------|
| M1047 | [[m1047-audit\|M1047 - Audit]] | Habilitar logging completo de CloudTrail (AWS), Cloud Audit Logs (GCP) ou Azure Monitor para todas as operações de criação de instâncias; revisar periodicamente o inventário de instâncias ativas versus o estado esperado via IaC |
| M1018 | [[m1018-user-account-management\|M1018 - User Account Management]] | Aplicar princípio do menor privilégio nas políticas IAM; restringir permissões de criação de instâncias a roles específicas de automação (CI/CD, Terraform); implementar SCPs (Service Control Policies) na AWS para limitar regiões e tipos de instância permitidos; exigir MFA para operações privilegiadas de computação |
**Controles adicionais recomendados:**
- **AWS Organizations SCPs** - Restringir `ec2:RunInstances` por região, tipo de instância e AMI usando Service Control Policies
- **GCP Organization Policies** - Restringir regiões de compute e uso de imagens externas via `constraints/compute.restrictCloudRunRegion`
- **Azure Policy** - Negar criação de VMs fora de regiões aprovadas e sem tags obrigatórias de gerenciamento
- **Just-in-Time Access** - Implementar acesso JIT para operações de criação de infraestrutura, exigindo aprovação humana para instâncias fora do fluxo automatizado
## Contexto Brasil/LATAM
A criação maliciosa de instâncias em nuvem é uma das técnicas mais documentadas em incidentes que afetam empresas brasileiras e latino-americanas que migraram para AWS, Azure e GCP, impulsionadas pela aceleração da transformação digital pós-pandemia.
O [[g1004-lapsus|LAPSUS$]], com membros identificados no Brasil (incluindo um adolescente de São Paulo que participou de ataques contra Claro, Embratel e outras empresas), demonstrou que adversários da região têm capacidade sofisticada para explorar ambientes de nuvem. O grupo [[g1015-scattered-spider|Scattered Spider]] também tem histórico de ataques a empresas com operações na América Latina.
**Vetores de comprometimento mais comuns no Brasil:**
- Roubo de credenciais de contas IAM via phishing ([[t1566-phishing|T1566]]) direcionado a desenvolvedores
- Exposição acidental de chaves de API em repositórios públicos no GitHub
- Engenharia social contra suporte técnico de provedores de nuvem
- Comprometimento de pipelines de CI/CD com acesso a credenciais de deploy
**Impacto financeiro direto:** Ataques de cryptojacking contra contas AWS de empresas brasileiras resultaram em faturas de dezenas a centenas de milhares de dólares antes da detecção - o custo operacional da nuvem como vetor de impacto financeiro direto é pouco considerado em planos de resposta a incidentes no Brasil.
**Recomendações para equipes brasileiras:**
- Implementar AWS Cost Anomaly Detection ou equivalente como primeira linha de alerta
- Configurar SCPs restritivos em contas de produção, permitindo criação de instâncias apenas via roles de automação
- Auditar regularmente chaves de API expostas em repositórios usando ferramentas como `git-secrets` ou `trufflehog`
## Referências
- [[t1578-modify-cloud-compute-infrastructure|T1578 - Modify Cloud Compute Infrastructure]] - Técnica pai desta sub-técnica
- [[t1578-001-create-snapshot|T1578.001 - Creaté Snapshot]] - Frequentemente combinada para acesso a dados
- [[t1074-002-remote-data-staging|T1074.002 - Remote Data Staging]] - Objetivo comum após criação de instância
- [[t1078-004-cloud-accounts|T1078.004 - Valid Accounts: Cloud Accounts]] - Pré-requisito típico desta técnica
- [[g1004-lapsus|LAPSUS$]] - Grupo de ameaça com uso documentado e conexão ao Brasil
- [[g1015-scattered-spider|Scattered Spider]] - Grupo especializado em ambientes de nuvem
- [[m1047-audit|M1047 - Audit]] - Mitigação primária recomendada
- [[ta0005-defense-evasion|TA0005 - Defense Evasion]] - Tática MITRE ATT&CK desta técnica
---
*Fonte: MITRE ATT&CK - T1578.002*