Resposta a incidentes na nuvem AWS: onde olhar primeiro

Quando um alerta dispara em uma conta AWS, a diferenca entre uma investigacao de duas horas e uma de duas semanas e saber onde olhar primeiro. A resposta a incidentes na nuvem nao e igual a investigar um notebook ou um servidor local: nao ha disco para imagear no sentido tradicional, o plano de controle e uma API, e a evidencia mais importante costuma ser uma entrada de log que expira se voce nao ligou o logging com antecedencia. Este guia foi escrito para defensores. O objetivo e entender a superficie de ataque para detectar o abuso e recuperar com seguranca, nao ensinar ninguem a invadir. Vamos percorrer a telemetria da AWS que importa, os sinais que separam o ruido de uma intrusao real e como conter o dano sem destruir a evidencia de que voce precisa.

Por que a resposta a incidentes na nuvem e diferente#

Em um ambiente tradicional voce responde a um host: isola, captura a memoria e imageia o disco. Na AWS, o objeto primario da investigacao e a conta e suas identidades. Um atacante que obtem uma credencial valida pode agir de qualquer lugar do mundo pela mesma API que voce usa, e suas acoes parecem sintaticamente identicas a administracao legitima. Em uma comprometimento do plano de controle nao ha malware a encontrar, apenas uma sequencia de chamadas de API. Isso desloca o centro de gravidade da investigacao dos binarios e arquivos para identidade, permissoes e logs de auditoria. Tambem significa que a preparacao e decisiva: a evidencia que voce pode coletar depois e exatamente a que configurou antes do incidente. Se o logging no nivel da organizacao estava desligado, a reconstrucao possivel fica fundamentalmente limitada.

Prepare-se antes do incidente: prontidao que compensa#

Prontidao e o controle mais barato que voce jamais comprara. Antes que algo aconteca, confirme que ha um trail do CloudTrail multi-regiao e no nivel da organizacao habilitado e entregando para uma conta de logging dedicada, apenas de escrita, que os respondedores possam ler mas as contas de servico nao possam apagar. Habilite o GuardDuty em todas as regioes e contas, ligue o Config para registrar o estado dos recursos ao longo do tempo e garanta que VPC Flow Logs e os logs de servico relevantes (log de acesso ao S3, logs de balanceadores, log de consultas DNS via Route 53 Resolver) sejam capturados de forma centralizada. Estabeleca papeis de emergencia com MFA forte e documente quem pode assumi-los. Um runbook curto e ensaiado que nomeie os locais dos logs, os passos de isolamento e os contatos de escalonamento poupara mais tempo num evento real do que qualquer ferramenta.

As fontes de log centrais da AWS em que voce se apoiara#

Quatro fontes sustentam a maioria das investigacoes na nuvem. CloudTrail e o log de auditoria do plano de controle: cada chamada de API, quem a fez, de qual IP e identidade e se teve sucesso. GuardDuty e um detector gerenciado que correlaciona dados de CloudTrail, DNS e fluxo em achados como exfiltracao de credenciais ou uso anomalo da API. VPC Flow Logs registram as conversas de rede no nivel da ENI, onde voce reconstroi movimento lateral e saida de dados. Config lhe da uma linha do tempo de como um recurso estava em cada momento, inestimavel para provar quando um security group foi aberto ou uma politica alterada. Ao redor delas ficam logs especificos de servico (S3, RDS, Lambda, CloudFront, WAF) que agregam contexto sobre as cargas de trabalho envolvidas.

Onde olhar primeiro: CloudTrail#

O CloudTrail e quase sempre a primeira parada. Comece pivotando sobre a identidade do alerta e faca tres perguntas: o que este principal fez, de onde, e quando o comportamento mudou. Filtre por valores de eventName que indiquem reconhecimento ou tentativas de escalada e de atencao especial aos eventos do plano de gestao. Eventos de alto sinal para um comprometimento incluem mudancas de identidade e confianca, como CreateUser, CreateAccessKey, AttachUserPolicy, PutUserPolicy, UpdateAssumeRolePolicy e CreateLoginProfile. Observe registros de ConsoleLogin sem MFA, um GetCallerIdentity imediatamente seguido de chamadas de listagem ampla e picos de resultados AccessDenied que revelam um ator sondando permissoes. Correlacione o IP de origem, o user agent e se as chamadas vieram por credenciais de papel temporarias, o que indica se uma access key ou um papel assumido foi abusado.

Sinais de identidade e acesso#

Como a identidade e o campo de batalha, invista na visao de permissoes. Enumere os usuarios, papeis e access keys do IAM criados ou modificados recentemente e compare-os com seus registros de mudanca. Uma access key recem-criada em uma conta de servico, uma politica de confianca de papel que de repente permite uma conta externa, ou uma politica inline concedendo iam:* sao fortes indicadores de um atacante estabelecendo acesso duradouro. Achados do GuardDuty das familias UnauthorizedAccess, CredentialAccess e Persistence merecem triagem imediata. O IAM Access Analyzer ajuda a detectar recursos que ficaram acessiveis de fora da conta. O tempo todo, lembre que a automacao legitima tambem cria keys e papeis, entao o sinal e o desvio da linha de base, nao a acao isolada.

Telemetria de rede e do plano de dados#

Uma vez que voce entende o que a identidade fez, siga os dados. Os VPC Flow Logs permitem ver quais instancias falaram com quais endpoints e quantos bytes se moveram, para distinguir trafego de rotina de uma saida em massa para um destino desconhecido. Os logs de consultas DNS frequentemente revelam dominios de comando e controle ou de preparacao que os dados de fluxo por IP escondem atras de CDNs. No lado do armazenamento, os logs de acesso ao servidor do S3 e os data events do CloudTrail para S3 mostram leituras no nivel do objeto: uma serie repentina de chamadas GetObject por um bucket inteiro, ou um ListBuckets seguido de downloads direcionados, e a forma classica da exfiltracao. Para bancos de dados, revise os logs do RDS e qualquer auditoria de consultas que voce habilitou. A pergunta que voce responde e simples e importante: dados sairam e, se sim, quais e quantos.

Transformar sinais em deteccoes#

Cacar com eficacia significa escrever as perguntas como consultas repetiveis. Usando CloudTrail no Athena ou no seu SIEM, construa deteccoes para logins de console de novos paises ou ASNs, para chamadas de API cujo user agent nao corresponde ao seu tooling conhecido, para qualquer uso da conta root e para a desativacao de servicos de seguranca como StopLogging, DeleteTrail, DeleteFlowLogs ou DisableSecurityHub. Alerte sobre pareamentos vistos pela primeira vez de principal e regiao, porque atacantes costumam operar em regioes que suas equipes nunca usam. Ordene os achados por raio de impacto: uma mudanca em uma identidade que pode assumir outros papeis importa mais que uma unica chamada negada. Ajuste com agressividade para que os alertas que acordam uma pessoa sejam os que de fato justificam acorda-la.

Contencao sem destruir evidencia#

A contencao na nuvem e rapida, o que e presente e perigo. Voce pode revogar uma sessao, desativar uma access key ou desanexar uma politica em segundos, mas se apagar o papel comprometido ou terminar a instancia pode apagar evidencia que ainda nao coletou. A sequencia que preserva evidencia e primeiro fazer snapshot e preservar: tire snapshots EBS dos volumes afetados, capture os metadados da instancia e exporte as faixas de log relevantes para seu repositorio do caso. Depois restrinja a identidade anexando um deny explicito ou revogando sessoes em vez de apagar o principal, e isole o compute movendo-o para um security group de quarentena sem saida. Rotacione as credenciais expostas e invalide os tokens temporarios. So depois da preservacao e da contencao voce parte para a erradicacao e reconstroi a partir de infraestrutura como codigo conhecida e boa.

Armadilhas comuns#

Varios erros se repetem. As equipes descobrem durante o incidente que o CloudTrail era de uma unica regiao ou nunca entregava a uma conta isolada, entao as acoes do atacante em outra regiao sao invisiveis. Respondedores terminam instancias por pressa e perdem artefatos de memoria e disco. Investigadores confiam nos carimbos de tempo de um unico log sem correlacionar relogios entre fontes. As pessoas perseguem uma chamada de API maliciosa e perdem a persistencia que o atacante plantou tres passos antes, como uma access key esquecida ou uma confianca de papel modificada. E um erro evitavel frequente e corrigir o sintoma e depois nao rotacionar cada credencial que o ator possa ter tocado, o que convida ao reingresso imediato. Escreva essas licoes no runbook para que o proximo respondedor nao as reaprenda sob pressao.

Checklist do blue team#

Use isto como sequencia inicial. 1. Confirme o escopo: quais contas, regioes e identidades estao envolvidas. 2. Preserve primeiro: exporte faixas do CloudTrail, faca snapshot dos volumes, capture metadados de instancia. 3. Reconstrua a linha do tempo da identidade a partir do CloudTrail, com foco em mudancas de IAM e confianca. 4. Puxe os achados do GuardDuty e correlacione com logs de fluxo e DNS. 5. Determine o impacto nos dados pelos data events do S3 e pelo volume de saida. 6. Contenha com politicas de deny, revogacao de sessoes e security groups de quarentena, nao com exclusao. 7. Rotacione cada credencial potencialmente exposta e invalide os tokens temporarios. 8. Erradique e reconstrua a partir de infraestrutura como codigo. 9. Documente a linha do tempo e realimente as deteccoes no seu monitoramento.

FAQ: por quanto tempo os logs da AWS sao mantidos por padrao?#

Depende do servico e da sua configuracao. O historico de eventos do console do CloudTrail e retido por 90 dias, mas isso nao substitui um trail duravel entregando ao S3, que voce controla e deve reter conforme sua politica. Achados do GuardDuty, VPC Flow Logs e logs de servico tem cada um sua propria retencao que voce define. E exatamente por isso que a prontidao importa: se voce depende do historico de console padrao, uma investigacao que comeca tarde pode achar a evidencia mais antiga ja desaparecida. Configure entrega de logs de longa duracao e resistente a adulteracao antes de precisar dela.

FAQ: preciso imagear uma instancia EC2, ou isso ficou obsoleto na nuvem?#

Artefatos volateis e de disco ainda importam quando uma carga de trabalho e comprometida, entao o imaging nao ficou obsoleto para intrusoes no nivel do host. A abordagem que preserva evidencia e tirar um snapshot EBS do volume afetado e, quando viavel, capturar a memoria antes de parar a instancia, e entao anexar o snapshot a uma estacao forense para analise offline. O que muda na nuvem e que para um comprometimento puro do plano de controle pode nao haver host algum a imagear; a investigacao vive inteiramente no CloudTrail e nos registros de identidade. Ajuste a coleta a natureza do incidente em vez de aplicar um habito em todo lugar.

Conclusao#

A resposta a incidentes na nuvem recompensa preparacao e disciplina. As contas que se recuperam rapido sao as que habilitaram logging no nivel da organizacao e resistente a adulteracao antes de um incidente, que sabem que CloudTrail, GuardDuty, VPC Flow Logs e Config sao os quatro pilares, e que contem ameacas sem incinerar evidencia. Trate a identidade como o campo de batalha principal, siga os dados para responder se algo saiu e preserve sempre antes de agir. Integre esses passos em um runbook ensaiado, meca a rapidez com que reconstroi uma linha do tempo de identidade e continue realimentando o aprendizado nas deteccoes. Bem feita, a resposta na nuvem transforma um alerta assustador em um procedimento metodico e repetivel.