Guia de Resposta a Incidentes com AWS CloudTrail – Parte 2: Ataque em Múltiplos Estágios ao Amazon Bedrock

Continuando a investigação: ataques encadeados no ambiente AWS

Na primeira parte deste guia, a equipe de segurança da AWS explorou dois cenários clássicos de incidentes: exclusão de dados no Amazon Simple Storage Service (S3) com implicações de ransomware, e mineração de criptomoedas implantada via AWS CloudFormation com credenciais expostas. Nesta segunda parte, o foco muda para um ataque mais sofisticado e encadeado, que começa com uma falha em uma aplicação web e termina no uso indevido de serviços de Inteligência Artificial (IA) em múltiplas regiões AWS.

Cenário 3: SSRF, coleta de credenciais via IMDSv1 e abuso do Amazon Bedrock

Este cenário demonstra como uma vulnerabilidade de Falsificação de Requisição do Lado do Servidor (SSRF — Server-Side Request Forgery) pode se transformar em um incidente de grande escala. A equipe de segurança recebeu múltiplos alertas aparentemente desconexos: operações falhas do AWS Identity and Access Management (IAM) na região us-east-1, logins bem-sucedidos no console sem Autenticação Multifator (MFA), e chamadas suspeitas ao Amazon Bedrock vindas de us-east-2. O que parecia uma série de eventos isolados era, na verdade, uma cadeia de ataque cuidadosamente orquestrada.

Arquitetura do ataque e progressão em cinco estágios

O ataque explorou a relação de confiança entre instâncias do Amazon Elastic Compute Cloud (EC2) e os serviços AWS. Uma instância EC2 executava uma aplicação web com uma role IAM chamada webdev associada. O agente malicioso identificou a vulnerabilidade SSRF nessa aplicação e a usou para alcançar o endpoint do Serviço de Metadados da Instância versão 1 (IMDSv1), coletando as credenciais temporárias da role sem precisar de nenhuma autenticação adicional — uma característica arquitetural do IMDSv1 que o torna especialmente perigoso em cenários de SSRF.

O ataque se desdobrou em cinco estágios sequenciais:

Acesso inicial: exploração da vulnerabilidade SSRF na aplicação web para fazer requisições em nome da instância.
Coleta de credenciais: essas requisições alcançaram o endpoint IMDSv1 e retornaram as credenciais temporárias da role webdev.
Teste de permissões: com as credenciais em mãos, o agente malicioso tentou operações IAM para mapear o que a role podia fazer.
Pivotamento de serviço: ao ser bloqueado nas ações IAM, o agente redirecionou o foco para o Amazon Bedrock, um serviço que a role conseguia acessar.
Mudança de região: as operações foram migradas de us-east-1 para us-east-2, provavelmente para contornar controles de monitoramento específicos de região.

Evidências no CloudTrail: quatro eventos que contam a história completa

Evento 1 — Teste de permissões (15:53:49 UTC)

A primeira atividade suspeita foi uma chamada CreateUser com falha na região us-east-1. O log do AWS CloudTrail registra uma sessão de AssumedRole tentando criar um usuário IAM chamado adm1n — note o número “1” no lugar da letra “i”, uma técnica de typosquatting para imitar nomes administrativos legítimos. A chamada foi bloqueada com AccessDenied.

Os campos mais relevantes neste evento são:

userName: "webdev" — confirma que a role EC2 comprometida está em uso.
ec2RoleDelivery: "1.0" — prova que as credenciais foram obtidas via IMDSv1, confirmando o vetor SSRF.
eventName: "CreateUser" — indica tentativa de criar persistência via backdoor IAM.
errorCode: "AccessDenied" — o princípio de menor privilégio funcionou e bloqueou a ação.

{
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0",
    "sessionContext": {
      "sessionIssuer": { "type": "Role", "userName": "webdev" },
      "attributes": { "mfaAuthenticated": "false" }
    },
    "ec2RoleDelivery": "1.0"
  },
  "eventTime": "2025-09-22T15:53:49Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "CreateUser",
  "readOnly": false,
  "userAgent": "aws-cli/2.17.48 ua/2.0 os/windows#10 ...",
  "errorCode": "AccessDenied",
  "errorMessage": "User: ...assumed-role/webdev/... is not authorized to perform: iam:CreateUser on resource: .../user/adm1n..."
}

Evento 2 — Acesso ao console (15:59:29 UTC)

Seis minutos depois, o agente malicioso fez login com sucesso no console AWS usando as mesmas credenciais coletadas. O evento ConsoleLogin registra que o MFA não foi utilizado (MFAUsed: No) e que o acesso veio de um navegador Chrome no Windows 10. Este é o pivotamento do acesso programático para o acesso visual interativo.

ConsoleLogin: "Success" — login bem-sucedido com credenciais sequestradas.
MFAUsed: "No" — ausência de MFA foi a brecha que permitiu este pivotamento.
sourceIPAddress: "75.3.231.105" — dado de atribuição para correlação com outros logs.

{
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0",
    "sessionContext": { "attributes": { "mfaAuthenticated": "false" } }
  },
  "eventTime": "2025-09-22T15:59:29Z",
  "eventSource": "signin.amazonaws.com",
  "eventName": "ConsoleLogin",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "75.3.231.105",
  "responseElements": { "ConsoleLogin": "Success" },
  "additionalEventData": { "MobileVersion": "No", "MFAUsed": "No" },
  "eventType": "AwsConsoleSignIn"
}

Evento 3 — Reconhecimento no Amazon Bedrock (17:20:00 UTC)

Quase duas horas depois, o agente malicioso pivotou para o Amazon Bedrock, fazendo uma chamada ListFoundationModels na região us-east-2. Este evento evidencia a mudança de região como técnica de evasão de defesas, a transição de serviços IAM para serviços de IA, e o campo sessionCredentialFromConsole: "true", que conecta esta chamada à sessão de console estabelecida no Evento 2.

eventSource: "bedrock.amazonaws.com" — pivotamento para serviços de IA gerenciados.
eventName: "ListFoundationModels" — reconhecimento para enumerar modelos disponíveis.
awsRegion: "us-east-2" — mudança de região deliberada para evasão de detecção.

{
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0"
  },
  "eventTime": "2025-09-22T17:20:00Z",
  "eventSource": "bedrock.amazonaws.com",
  "eventName": "ListFoundationModels",
  "awsRegion": "us-east-2",
  "sourceIPAddress": "75.3.231.105",
  "readOnly": true,
  "tlsDetails": { "clientProvidedHostHeader": "bedrock.us-east-2.amazonaws.com" },
  "sessionCredentialFromConsole": "true"
}

Evento 4 — Exploração ativa do modelo (17:25:48 UTC)

Cinco minutos após o reconhecimento, o agente malicioso passou da enumeração para a exploração ativa, invocando o modelo Amazon Nova Pro via API Converse em us-east-2. O campo additionalEventData quantifica o uso não autorizado: 944 tokens de entrada e 126 de saída — confirmando que o modelo foi efetivamente consultado e respondeu.

eventName: "Converse" — transição do reconhecimento para exploração ativa.
modelId: "amazon.nova-pro-v1:0" — identifica o modelo específico sendo utilizado indevidamente.
inputTokens: 944, outputTokens: 126 — quantifica o uso não autorizado (custo financeiro e risco de exfiltração de dados).

{
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0"
  },
  "eventTime": "2025-09-22T17:25:48Z",
  "eventSource": "bedrock.amazonaws.com",
  "eventName": "Converse",
  "awsRegion": "us-east-2",
  "requestParameters": {
    "modelId": "amazon.nova-pro-v1:0",
    "inferenceConfig": { "maxTokens": 1024 }
  },
  "additionalEventData": { "inputTokens": 944, "outputTokens": 126 }
}

Campos-chave para investigação

Ao analisar esses eventos, alguns campos do CloudTrail carregam a maior parte do trabalho investigativo:

userIdentity: ponto de partida para atribuição. Neste cenário, carrega o ID da instância EC2 como nome de sessão, permitindo rastrear as credenciais coletadas até a instância comprometida específica.
readOnly: revela a intenção da ação. Valor true indica reconhecimento; false indica tentativa de modificação ou uso.
awsRegion: expôs a estratégia de evasão do agente malicioso. A mudança de us-east-1 para us-east-2 foi deliberada, aproveitando controles de monitoramento inconsistentes entre regiões.
userIdentity.invokedBy: identifica quando um serviço AWS fez a requisição em nome de um usuário. A ausência deste campo nos eventos confirma que as chamadas vieram diretamente das credenciais coletadas, não de um fluxo legítimo orientado por serviço.

Checklist de resposta ao incidente

Conter e remediar o ponto de entrada

Identificar a funcionalidade da aplicação web que permitiu a requisição externa (buscadores de URLs, callbacks de webhook, renderizadores de PDF ou imagem, geradores de preview de links são os candidatos mais comuns) e confirmar se ela consegue alcançar http://169.254.169.254.
Auditar o restante da aplicação em busca do mesmo padrão, pois um parâmetro de URL não validado geralmente indica que outros existem.
Aplicar IMDSv2 na instância afetada e em toda a frota com o comando: aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1. O parâmetro --http-tokens required garante que credenciais só sejam retornadas quando o solicitante apresentar um token de sessão obtido via requisição PUT — algo que um SSRF básico não consegue fazer. O limite de hop em 1 mantém a resposta de metadados na própria instância.

Mapear o uso do Bedrock

Listar os modelos que a role webdev poderia acessar revisando sua política IAM e políticas baseadas em recurso.
Determinar o que foi enviado e recebido pelo modelo. O CloudTrail registra a chamada Converse e a contagem de tokens, mas apenas o log de invocação de modelos do Amazon Bedrock captura os prompts e respostas completos. Se estava habilitado, extrair os registros da sessão; se não estava, habilitar agora e registrar que o conteúdo não pode ser recuperado retroativamente.
Avaliar exposição de conformidade com base no que esses prompts e respostas continham. Processamento não autorizado de dados regulados (como Informações Pessoais Identificáveis, Informações de Saúde Protegidas ou dados de titulares de cartão) pode gerar obrigações de notificação.

Verificar comprometimento mais amplo e persistência

Consultar o CloudTrail em todas as regiões e serviços para cada evento vinculado à sessão da role webdev.
Correlacionar os timestamps do CloudTrail com VPC Flow Logs e logs da aplicação para o IP de origem 75.3.231.105.
Buscar eventos IAM de escrita na sessão (CreateUser, CreateRole, CreateAccessKey, AttachRolePolicy) que indiquem tentativas de persistência além das credenciais temporárias.

Monitorar impacto contínuo ou oculto

Revisar o uso do Amazon Bedrock no CloudWatch e nos dados de faturamento para identificar picos de invocação ou consumo inesperado de tokens.
Inspecionar os logs de invocação em busca de sinais de dados sensíveis sendo processados ou extraídos pelo modelo.
Verificar também tentativas de injeção de prompt, onde o input tenta sobrescrever as instruções do modelo ou extrair prompts do sistema.

Principais aprendizados e medidas de proteção

Menor privilégio para roles de workload

A role webdev não tinha nenhuma justificativa de negócio para acessar o Amazon Bedrock em múltiplas regiões. Aplique o princípio de menor privilégio às roles de instâncias EC2, limitando permissões apenas aos serviços e ações que a aplicação realmente precisa. Use o AWS IAM Access Analyzer para identificar permissões não utilizadas e ajustar políticas proativamente.

IMDSv1 versus IMDSv2

O campo ec2RoleDelivery: "1.0" nos logs confirma explicitamente o uso do IMDSv1, que permite a recuperação de credenciais sem token de autenticação. Essa fraqueza arquitetural torna o roubo de credenciais via SSRF trivial. A migração para IMDSv2 teria interrompido este ataque já no primeiro estágio, pois exige tokens de sessão locais baseados em PUT — algo que um SSRF básico não consegue fornecer.

Mudança de região como sinal de operador experiente

A migração de us-east-1 para us-east-2 não foi acidental. Agentes maliciosos se movem entre regiões porque monitoramento, alertas e controles de acesso frequentemente são configurados de forma inconsistente. Esse tipo de movimento cross-region é um marcador de consciência operacional e deve elevar a prioridade de uma investigação. A cobertura de detecção consistente em todas as regiões — inclusive as que não são usadas ativamente — deve ser tratada como requisito básico.

Serviços de IA precisam de visibilidade além do CloudTrail

O CloudTrail registra quem chamou o Amazon Bedrock e se a chamada foi bem-sucedida, mas não captura o que foi perguntado ou respondido. Habilite o log de invocação de modelos do Amazon Bedrock para capturar prompts e respostas completos para auditoria de conformidade. Para workloads baseados em agentes, o Amazon Bedrock AgentCore Observability fornece rastreamentos em nível de sessão mostrando ordem de execução de ferramentas e latência. Considere também habilitar o Amazon GuardDuty AI Protection, que analisa a atividade do CloudTrail relacionada ao Amazon Bedrock para detectar invocações anômalas, harvesting de custos e tentativas de injeção de prompt. Para orientações de implementação, consulte Monitoramento e Auditoria de Workloads de IA na AWS.

Técnicas avançadas de evasão para ficar atento

Além dos padrões específicos deste cenário, a equipe de resposta a incidentes da AWS destaca três técnicas de evasão que observa com frequência:

Usuário root real versus usuário IAM chamado “root”: a diferença fica visível no campo type do elemento userIdentity no log do CloudTrail.
Imitação de nomes de roles e usuários: agentes maliciosos criam nomes que imitam os reservados pela AWS — por exemplo, AWSServiceRoIeforSupport com “I” maiúsculo no lugar do “l” minúsculo, para fazer parecer que ações foram executadas pelo AWS Support.
Usuários chamados HIDDEN_DUE_TO_SECURITY_REASONS: o campo userName recebe essa string quando um login falha por nome de usuário incorreto. Porém, agentes maliciosos já criaram usuários com exatamente esse nome para enganar investigadores que poderiam pensar que o nome foi ocultado por razões de segurança.

Recursos adicionais

Fonte

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