Guia de Resposta a Incidentes com AWS CloudTrail: Análise Forense em Cenários Reais – Parte 1

Por que o CloudTrail é o ponto de partida de qualquer investigação na AWS

O AWS CloudTrail registra praticamente tudo que acontece em um ambiente AWS: quem fez o quê, quando, de onde e com qual resultado. Mas ter os logs não é suficiente — saber quais campos observar e como interpretar os padrões é o que separa uma análise superficial de uma investigação completa.

A AWS publicou um guia de resposta a incidentes baseado em cenários reais utilizados pela equipe interna de resposta a incidentes de segurança (SIRT — Security Incident Response Team). O objetivo é compartilhar as técnicas investigativas aplicadas no dia a dia, com metodologias práticas que qualquer time pode adaptar ao próprio ambiente.

Nesta primeira parte, dois cenários são explorados em profundidade: exclusão de dados entre contas com implicações de ransomware, e mineração de criptomoedas via CloudFormation usando credenciais de console sem MFA.

Glossário de termos de resposta a incidentes

Antes de entrar nos cenários, o guia define os principais termos usados ao longo da investigação. Vale ter esses conceitos claros:

• Reconhecimento (Reconnaissance): fase inicial em que o agente de ameaça coleta informações sobre o ambiente — por exemplo, listando buckets do Amazon Simple Storage Service (Amazon S3) para entender o que está disponível antes de agir.
• Enumeração (Enumeration): catalogação sistemática de recursos, usuários ou configurações para identificar alvos ou caminhos de acesso.
• Movimento lateral (Lateral movement): quando o agente de ameaça se move de um recurso para outro dentro do mesmo ambiente.
• Escalada de privilégios (Privilege escalation): tentativa de obter permissões mais elevadas do que as obtidas inicialmente, como criar usuários administradores ou modificar políticas do AWS Identity and Access Management (IAM).
• Evasão de defesa (Defense evasion): técnicas para evitar detecção, como operar em uma Região AWS onde o monitoramento é menos robusto.
• Persistência (Persistence): estabelecimento de acesso contínuo ao ambiente, por exemplo criando novos usuários IAM ou chaves de acesso.
• Coleta de credenciais (Credential harvesting): roubo de credenciais de autenticação para se passar por usuários ou funções legítimas.
• Falsificação de requisição do lado do servidor (SSRF — Server-Side Request Forgery): técnica em que um usuário não autorizado engana um servidor para fazer requisições em seu nome, frequentemente usada para acessar serviços internos como o endpoint do Serviço de Metadados de Instância (IMDS). Veja mais em Entendendo SSRF.
• IMDSv1 — Serviço de Metadados de Instância versão 1: fornece credenciais temporárias a aplicações rodando em instâncias Amazon Elastic Compute Cloud (Amazon EC2). O IMDSv1 em si não é inseguro, mas quando uma aplicação vulnerável a SSRF roda na instância, o agente de ameaça pode usá-la para acessar o endpoint de metadados e recuperar credenciais. O IMDSv2 mitiga esse risco exigindo tokens de autenticação baseados em sessão.
• Indicadores de comprometimento (IOCs — Indicators of Compromise): artefatos observáveis (endereços IP, user agents, nomes de sessão, nomes de recursos) que sugerem atividade não autorizada.
• Exfiltração (Exfiltration): transferência não autorizada de dados para fora do ambiente.
• Cadeia de eventos (Event chain): sequência de passos seguidos pelo agente de ameaça desde o acesso inicial até o objetivo final.
• Pivô (Pivot): mudança de técnica, serviço ou Região durante um incidente, frequentemente após uma abordagem inicial ser bloqueada ou para evitar detecção.

Cenário 1: Exclusão de dados entre contas com implicações de ransomware

O acesso entre contas é comum em ambientes AWS corporativos, mas uma configuração inadequada cria riscos sérios. Neste cenário, o centro de operações de segurança recebe um alerta automático informando que múltiplos objetos foram deletados do bucket S3 customer-important-data. A investigação inicial parece simples: verificar os logs do CloudTrail, identificar quem deletou os objetos e determinar se foi autorizado. Mas ao aprofundar a análise, o que parecia uma exclusão não autorizada simples revelou-se um incidente entre contas com implicações de ransomware.

Fase de reconhecimento

A investigação começa nos logs do CloudTrail, onde a atividade não autorizada se inicia com algo que muitos analistas poderiam descartar como rotina: uma chamada de API ListBuckets feita por meio de uma função assumida às 14:31:22 UTC.

O registro do CloudTrail contém uma sessão chamada dev-migration-script usando a função CrossAccountS3Access. Embora o acesso entre contas seja comum em ambientes corporativos, os nomes de sessão normalmente refletem unidades de negócio legítimas. Agentes de ameaça frequentemente usam técnicas de mascaramento — nomeando suas sessões como tarefas comuns de desenvolvedor ou scripts de automação — para se misturar ao ruído operacional diário. A correlação desse nome de sessão com o IP de origem externo e os registros históricos de implantação confirmou que nenhum projeto de migração estava autorizado, sinalizando uma tentativa clara de evasão e o primeiro indício de acesso não autorizado.

Três segundos depois, os logs mostram uma requisição GET para listar objetos no bucket — comportamento clássico de reconhecimento. O agente de ameaça estava catalogando alvos disponíveis usando a mesma função assumida e o mesmo endereço IP.

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAEXAMPLE123456789:threat-actor-session",
    "arn": "arn:aws:sts::111122223333:assumed-role/CrossAccountS3Access/threat-actor-session"
  },
  "eventTime": "2025-01-20T14:31:22Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "ListBuckets",
  "sourceIPAddress": "203.0.113.47",
  "recipientAccountId": "444455556666"
}

Pontos forenses a observar nesse log:

• arn com CrossAccountS3Access: função entre contas foi assumida; o acesso veio de outra conta.
• Nome de sessão threat-actor-session: nome personalizado atribuído no momento da assunção da função.
• eventName ListBuckets: enumeração de todos os buckets S3 da conta — reconhecimento claro.
• sourceIPAddress 203.0.113.47: origem da chamada de API.
• recipientAccountId 444455556666: conta AWS que recebeu a requisição.

Exclusão sistemática

Após completar o reconhecimento às 14:31:25 UTC, o agente de ameaça ficou em silêncio por 14 minutos antes da primeira exclusão às 14:45:12 UTC. Durante essa janela, provavelmente revisou o inventário de objetos enumerados, selecionou os alvos de maior valor (dados financeiros, informações pessoalmente identificáveis — PII, e backups de banco de dados) e preparou um script automatizado de exclusão.

Dentro de 13 segundos (14:45:12–14:45:25 UTC), o agente deletou três arquivos do bucket: um relatório financeiro (q4-2024.xlsx), um banco de dados de PII de clientes (pii-database.csv) e um backup de banco de dados de produção (prod-database-backup.sql). Cada exclusão retornou o código HTTP 204 (sucesso). Os logs de acesso do Amazon S3 confirmam essas operações DELETE bem-sucedidas, todas originadas da mesma sessão.

Os logs de acesso também revelam que, antes das exclusões, houve operações REST.COPY.OBJECT — os dados financeiros e o banco de PII foram copiados antes de serem destruídos. Esse padrão “copiar e depois destruir” é característico de operações com implicações de ransomware: o agente exfiltra os dados antes de apagá-los, aumentando o poder de coerção.

Análise de padrões de tempo e acesso

A janela de exclusão de 13 segundos não foi arbitrária. A string de user-agent mostrou uso da Interface de Linha de Comando da AWS (AWS CLI) no Linux, e o timing preciso indicou execução por script, não operações manuais. O IP de origem consistente em todos os eventos permitiu buscar outras atividades suspeitas da mesma origem e correlacionar com feeds de inteligência de ameaças.

As amplas permissões de S3 da função CrossAccountS3Access levantam questões sobre implementação do princípio do menor privilégio, revisões regulares de acesso e a justificativa de negócio para permissões tão extensas entre contas.

Prioridades de investigação e checklist de resposta

Com a confirmação do abuso de acesso entre contas configurado incorretamente, as prioridades de investigação se concentram em três fatores: se o agente ainda tem acesso ativo (urgência de contenção), se dados sensíveis foram expostos ou exfiltrados (impacto regulatório e de negócio), e se o ataque pode se espalhar para outros recursos ou contas (raio de impacto).

Perguntas-chave a responder:

• Como o agente de ameaça obteve acesso à função CrossAccountS3Access?
• Os arquivos foram copiados antes da exclusão?
• Qual é a relevância específica dos objetos deletados?

Checklist de resposta:

• Determinar se o propósito de negócio do acesso entre contas é legítimo
• Identificar os eventos de autenticação correspondentes que mostram como a função foi assumida
• Identificar outros recursos AWS que essa função pode acessar além do S3
• Verificar tentativas falhas ou atividades de reconhecimento que precederam o evento bem-sucedido
• Determinar quando essa relação de confiança entre contas foi criada
• Verificar quando foi feita a última revisão de acesso dessa função
• Localizar cópias de backup dos dados deletados
• Definir regras de detecção para capturar atividades similares no futuro

Cenário 2: Mineração de criptomoedas via CloudFormation com credenciais de console

Neste cenário, o time financeiro percebe um pico inesperado nos custos AWS, especialmente em cobranças de computação EC2 na Região us-east-1. Durante a investigação, examina-se como agentes de ameaça usam acesso legítimo ao console para implantar operações de mineração de criptomoedas via AWS CloudFormation e como investigadores podem descobrir o escopo de eventos de sequestro de recursos.

Uma stack CloudFormation chamada CRYPTO é descoberta sem nenhum registro de criação autorizada. A stack contém instâncias EC2 rodando na Amazon Virtual Private Cloud (Amazon VPC) de produção, consumindo recursos computacionais significativos.

Análise do evento CloudTrail de criação da stack

O registro do evento CloudTrail para a ação não autorizada CreateStack revela informações críticas:

{
  "eventVersion": "1.11",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAFINDANEXAMPLE:Participant",
    "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/WSParticipantRole/Participant",
    "sessionContext": {
      "sessionIssuer": {
        "type": "Role",
        "userName": "WSParticipantRole"
      },
      "attributes": {
        "mfaAuthenticated": "false"
      }
    }
  },
  "eventTime": "2025-09-23T18:07:12Z",
  "eventSource": "cloudformation.amazonaws.com",
  "eventName": "CreateStack",
  "awsRegion": "us-east-1",
  "userAgent": "aws-cli/2.30.0 ... exec-env/CloudShell",
  "requestParameters": {
    "stackName": "CRYPTO",
    "parameters": [
      { "parameterKey": "VpcId" },
      { "parameterKey": "SubnetIds" }
    ]
  },
  "responseElements": {
    "stackId": "arn:aws:cloudformation:us-east-1:...:stack/CRYPTO/2102e190..."
  },
  "sessionCredentialFromConsole": "true"
}

Pontos forenses essenciais:

• stackName: "CRYPTO": indicador direto de atividade de mineração de criptomoedas.
• VpcId + SubnetIds: o agente de ameaça tinha conhecimento prévio da rede — reconhecimento confirmado.
• mfaAuthenticated: "false": a sessão não tinha Autenticação Multifator (MFA) — lacuna crítica de controle de segurança.
• sessionCredentialFromConsole: "true": acesso via portal web do console AWS, não por API externa.
• exec-env/CloudShell: comandos executados via AWS CloudShell baseado em navegador.

Insight forense avançado: o pivô pelo CloudShell

O campo sessionCredentialFromConsole: true indica que o acesso se originou do console AWS, não de chaves de API programáticas externas. Mas o campo userAgent revela que o ambiente de execução foi o exec-env/CloudShell — ou seja, o agente de ameaça não clicou manualmente pela interface do CloudFormation. Em vez disso, abriu o CloudShell logo após o login para executar um script de implantação pré-preparado. Isso permitiu velocidade automatizada enquanto evitava o monitoramento tradicional de chaves de API estáticas.

A sessão teve início às 18:06:22Z e a stack foi criada às 18:07:12Z — apenas 50 segundos depois. Essa velocidade indica que o agente chegou preparado com um script, não explorando o ambiente manualmente.

Prioridades de investigação e checklist de resposta

A investigação se organiza em três fases:

• Reconstruir a linha do tempo da sessão no console: filtrar o CloudTrail pelo mesmo token de sessão para identificar se houve reconhecimento antes da implantação da stack, se outros serviços ou Regiões foram acessados, e se houve tentativas de estabelecer persistência (como criação de usuários IAM ou chaves de acesso).
• Examinar o que a stack realmente implantou: inspecionar o template do CloudFormation para entender os tipos de instâncias EC2 criadas, as regras de grupos de segurança, scripts de user data que possam ter instalado software de mineração na inicialização, e se a stack criou funções IAM próprias com permissões para movimento lateral.
• Calcular o impacto de negócio e o raio de impacto: quantificar o custo computacional, verificar se as instâncias de mineração tinham caminhos de rede para bancos de dados de produção ou serviços internos, examinar logs de tráfego de saída para conexões com pools de mineração conhecidos, e buscar stacks similares em outras Regiões e contas.

Checklist de resposta:

• Determinar por que o MFA não era obrigatório para essa operação sensível
• Investigar como o agente obteve credenciais válidas de console
• Verificar tentativas de login malsucedidas antes desse acesso bem-sucedido
• Verificar outras atividades ocorridas durante essa sessão de console
• Identificar recursos criados pela stack CloudFormation
• Determinar há quanto tempo esses recursos estão rodando e consumindo custos
• Buscar outras stacks com nomes similares ou suspeitos no ambiente
• Verificar que acesso de rede essas instâncias têm a recursos internos
• Determinar quais conexões de saída essas instâncias estão fazendo
• Verificar conexões com pools de mineração de criptomoedas
• Verificar se usuários ou funções IAM foram criados
• Verificar se chaves de acesso adicionais foram geradas
• Determinar se o agente modificou permissões ou políticas existentes

Lições aprendidas dos dois cenários

Os dois cenários reforçam princípios que se aplicam amplamente a investigações de incidentes na AWS:

• Nomes de sessão incomuns revelam intenção: agentes de ameaça frequentemente usam nomes que imitam processos legítimos. Sempre cruze com registros históricos de projetos autorizados.
• Timing preciso indica automação: janelas de execução de segundos sugerem scripts preparados previamente, o que exige estratégias de resposta diferentes de intrusões manuais.
• Acesso entre contas precisa de escrutínio extra: relações de confiança se tornam vetores de acesso não autorizado quando credenciais são expostas.
• MFA é inegociável para acesso ao console em ambientes de produção: a ausência de MFA foi o que viabilizou toda a sequência do Cenário 2.
• Monitoramento de custos é monitoramento de segurança: picos inesperados de faturamento podem ser os primeiros indicadores de sequestro de recursos.
• O campo sessionCredentialFromConsole é seu ponto de partida para distinguir entre acesso via console e acesso programático.
• Nomeação de recursos pode ser um indicador: o nome óbvio CRYPTO sugere confiança excessiva do agente ou má segurança operacional — ambos preocupantes por razões diferentes.

O que vem na Parte 2

Na Parte 2 do guia, a AWS examina como uma vulnerabilidade em aplicação web pode se transformar em um incidente multi-Região afetando serviços de inteligência artificial, encadeando SSRF, coleta de credenciais via IMDSv1 e pivô entre Regiões para acessar o Amazon Bedrock. A segunda parte também cobre técnicas investigativas críticas: a diferença entre usuário root e um usuário IAM nomeado “root”, táticas de imitação de nomes de funções, e o truque do nome de usuário HIDDEN_DUE_TO_SECURITY_REASONS — além de passos de hardening e recursos adicionais para fortalecer capacidades forenses na nuvem.

Fonte

Incident response guide for AWS CloudTrail investigations – Part 1 (https://aws.amazon.com/blogs/security/incident-response-guide-for-aws-cloudtrail-investigations-part-1/)