Amazon SCS-C02: Resposta a Incidentes e Forense — Guia de estudos

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Faz parte do AWS Security Specialty SCS-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Isolamento de Instâncias EC2 Comprometidas

O primeiro objetivo operacional quando uma instância EC2 é suspeita de comprometimento é a contenção sem a destruição de evidências. A contenção na AWS é uma atividade em camadas que afeta a exposição de rede da instância, seus vínculos de ciclo de vida e sua acessibilidade para a equipe de resposta.

A sequência canônica de isolamento começa restringindo o security group da instância. Como idealmente cada instância tem seu próprio security group dedicado, você pode substituir as regras de entrada (ingress) e saída (egress) por um conjunto mínimo que permite o acesso apenas da equipe de forense (ou de um security group de diagnóstico dedicado). Se a instância estiver atrás de um Application Load Balancer ou em um target group, desregistre-a primeiro; se for membro de um Auto Scaling group, desanexe-a com a flag --should-decrement-desired-capacity para que o ASG não inicie imediatamente uma substituição ou, pior, encerre a instância “não saudável” no meio da investigação.

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

Habilitar a proteção contra encerramento é essencial porque um operador bem-intencionado, um script de automação ou um evento de scale-in do ASG pode, de outra forma, destruir os próprios volumes que você está tentando preservar. A proteção contra encerramento não substitui a desanexação do ASG — um ASG ainda pode encerrar instâncias protegidas durante o scale-in, a menos que você também remova a instância do escopo do grupo.

Para contenção no nível da sub-rede, quando você precisa de um corte imediato do tráfego de saída (por exemplo, uma instância se comunicando com IPs maliciosos conhecidos), você pode adicionar uma regra explícita de negação total (deny-all) de saída à network ACL da sub-rede como a regra de menor número (a primeira a ser avaliada). Isso é stateless e tem efeito instantâneo em todos os fluxos, diferente das alterações de security group, que afetam apenas os novos fluxos. Uma vez que seu caminho de acesso forense esteja estabelecido por meio de um SG de diagnóstico, a regra de negação da NACL pode ser removida para que a sub-rede da equipe de resposta possa alcançar o alvo através da lista de permissões do SG.

Preservação de Evidências Voláteis e Não Voláteis

Evidências voláteis — listagens de processos, sockets de rede abertos, módulos de kernel carregados, conteúdo da memória, conteúdo do tmpfs — são destruídas no momento em que a instância é parada. Evidências não voláteis residem no EBS e sobrevivem a paradas/inícios, mas ainda podem ser perdidas se os volumes forem desanexados ou a instância for encerrada sem snapshots. A regra de ordem é: colete os artefatos voláteis primeiro, enquanto a instância ainda está em execução, e depois crie snapshots do EBS.

A coleta de dados voláteis deve ser roteirizada e executada via SSM Run Command, em vez de por um humano digitando em um shell interativo. O Run Command registra a invocação, os parâmetros, o principal que executou o comando e a saída no CloudWatch Logs ou no S3, o que, por si só, se torna parte do registro da cadeia de custódia.

Problema Prático: Cenário de Caso de Uso

Cenário: A Meridian Financial executa suas aplicações web voltadas para o cliente em uma única conta AWS em várias VPCs, usando Auto Scaling groups atrás de Application Load Balancers, instâncias EC2 com volumes EBS, logs centralizados do CloudTrail e CloudWatch, GuardDuty e um arquivo de logs baseado em S3 criptografado com KMS. A equipe de operações de segurança usa o AWS Systems Manager para gerenciamento remoto e armazena backups e snapshots em uma conta de recuperação designada.

Desafio: Uma instância EC2 de produção mostra sinais de comprometimento com tráfego de saída suspeito e atividade de processo inesperada; a equipe deve isolar a instância e preservar tanto a memória volátil quanto as evidências de disco não voláteis para análise forense, sem destruir as trilhas de auditoria.

Abordagem Recomendada:

1. Use as APIs do Auto Scaling e do ELB para desanexar a instância dos target groups e suspender os processos do Auto Scaling, depois aplique um Security Group restritivo (negar todo o tráfego de entrada/saída) e atualize as regras da Network ACL da instância para isolar o acesso à rede, mantendo o gerenciamento via AWS Systems Manager Session Manager.
2. Use o AWS Systems Manager Run Command para executar uma captura de memória no sistema operacional convidado (ex: LiME) que grava o dump da RAM em um volume EBS anexado e criptografado ou diretamente em um bucket S3 criptografado com SSE-KMS e com o S3 Object Lock habilitado para retenção.
3. Use o EC2 CreateSnapshot (ou CreateImage) para capturar snapshots point-in-time do EBS de todos os volumes anexados, depois copie esses snapshots para uma conta AWS separada ou para outra região para preservar a cadeia de custódia e evitar adulteração.
4. Habilite ou recupere o VPC Traffic Mirroring para a ENI da instância para coletar capturas de pacotes para uma EC2 de monitoramento dedicada e, simultaneamente, exporte os VPC Flow Logs, logs de acesso do ELB, CloudTrail, CloudWatch Logs e os achados do GuardDuty para o arquivo seguro no S3.
5. Etiquete e inventarie todos os artefatos coletados no AWS Security Hub ou em um sistema de tickets, garanta que os objetos do S3 estejam criptografados e que o Object Lock esteja configurado, e restrinja o acesso do IAM a uma pequena equipe de forense, registrando todos os acessos através do CloudTrail.

Justificativa: Isolar o acesso à rede antes de criar as imagens evita contaminação adicional, enquanto usar o SSM evita a abertura de novos vetores de rede; capturar a memória volátil primeiro e criar snapshots imutáveis do EBS e arquivos seguros no S3 preserva a integridade da evidência e a cadeia de custódia, de acordo com as melhores práticas de resposta a incidentes da AWS.

# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

Imediatamente após a captura volátil, crie um snapshot de cada volume EBS anexado. Etiquete os snapshots com o identificador do incidente para que fiquem inequivocamente ligados ao caso.

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

Etiquete a própria instância com o mesmo ticket do incidente, o nome do investigador e um rótulo de status como Quarentena. O uso consistente de tags de metadados é o mecanismo nativo da AWS para a cadeia de custódia — é consultável, imutável por meio de chaves de condição do IAM e aparece em todos os eventos do CloudTrail sobre o recurso.

Resposta ao Vivo com o Session Manager e o Run Command

Um ponto sutil, mas crucial para o exame: sessões SSH existentes sobrevivem à remoção de regras de security group. Security groups são stateful e avaliam as regras no estabelecimento da conexão; uma sessão TCP já estabelecida continua a fluir mesmo após a exclusão da regra de entrada que a permitiu. Se um respondedor isolar uma instância removendo as regras do SG enquanto depende de sua própria sessão SSH para acesso, essa sessão funcionará — até que caia, momento em que ele ficará sem acesso e qualquer reentrada baseada em bastion ou chave se tornará impossível.

O padrão correto é conceder acesso à equipe de forense por meio do SSM Session Manager, que não exige que nenhuma porta de entrada esteja aberta. O Session Manager funciona pela conexão de saída do SSM Agent para os endpoints do SSM, EC2 Messages e SSM Messages (idealmente por meio de VPC interface endpoints, para que a instância isolada não precise de rota para a internet). Anexe um instance profile que permita ssm:UpdateInstanceInformation e as APIs de mensagens, e conceda aos respondedores a permissão ssm:StartSession com escopo definido por tag para a instância em quarentena.

Como as sessões do Session Manager são intermediadas pelo control plane do SSM, restringir ou esvaziar completamente as regras de entrada do security group não as afeta, e cada pressionamento de tecla pode ser registrado no S3 ou no CloudWatch Logs — uma sessão interativa auditável, não uma caixa-preta.

Recuperação Entre Contas de Snapshots Criptografados

Ambientes maduros direcionam os snapshots forenses para uma conta de forense dedicada, isolada da conta da carga de trabalho comprometida. O compartilhamento de snapshots entre contas exige duas coisas: o snapshot deve ser compartilhado com a conta de destino (modify-snapshot-attribute --create-volume-permission) e, se o snapshot for criptografado com uma chave KMS gerenciada pelo cliente (CMK), a política da chave KMS deve conceder aos principals da conta de forense as permissões kms:Decrypt, kms:CreateGrant e kms:DescribeKey. Snapshots criptografados com a chave aws/ebs gerenciada pela AWS não podem ser compartilhados entre contas — você deve primeiro recriptografá-lo com uma CMK por meio de uma operação de cópia. Na conta de forense, copie o snapshot compartilhado e recriptografe-o com uma CMK local de forense para que a criação de volumes subsequentes não dependa da conta de origem.

Design de Playbook e Minimização de Sobrecarga

Codifique as etapas de contenção como um documento do SSM Automation ou um workflow do Step Functions, acionado por achados (findings) do GuardDuty ou Security Hub via EventBridge. Uma única automação deve: (1) capturar dados voláteis via Run Command, (2) fazer snapshot dos volumes com tags de incidente, (3) habilitar a proteção contra terminação, (4) desanexar do ASG e cancelar o registro dos alvos do ELB, (5) substituir o SG pelo SG de quarentena e (6) taggear a instância com o ID do ticket. Manter a instância em execução preserva evidências vivas e permite a investigação interativa via Session Manager — desligar deve ser uma etapa posterior deliberada, não parte da contenção automática, porque o desligamento zera as evidências voláteis e pode acionar lógicas de limpeza embutidas no malware.

Os erros comuns que devem ser internalizados são: remover regras de SG confiando em uma sessão SSH existente deixa o respondedor cego e dá uma falsa confiança no isolamento; realizar a remediação no local antes de fazer o snapshot destrói os artefatos que respondem como a intrusão aconteceu; e deixar a instância em seu ASG ou target group convida à terminação automatizada ou, pior, a uma substituição silenciosa que oculta o escopo do incidente.

Contenção Imediata

Quando há suspeita de que uma carga de trabalho foi comprometida, a primeira decisão é se devemos isolá-la no local ou removê-la de serviço. Removê-la — parando ou terminando — destrói evidências voláteis como o conteúdo da RAM, processos em execução, sockets abertos e qualquer malware que exista apenas na memória. A contenção no local é quase sempre a ação inicial correta, e ela deve acontecer rápido o suficiente para que um invasor não consiga exfiltrar dados adicionais ou fazer movimento lateral antes que os controles entrem em vigor.

Dois controles nativos da AWS operam em camadas diferentes, e a distinção é importante. Security groups são stateful e anexados a interfaces de rede elásticas (ENIs); network ACLs (NACLs) são stateless e anexadas a sub-redes. Substituir os security groups de uma instância por um SG de “quarentena” restrito é a abordagem cirúrgica — ela isola uma ENI sem perturbar outras cargas de trabalho na mesma sub-rede e preserva o estado de tempo de execução da instância. No entanto, as alterações no security group afetam apenas os novos fluxos que chegam à ENI, e se a instância comprometida já mantiver conexões de saída de longa duração, o estado existente pode persistir. As regras de negação (deny) da NACL entram em vigor na fronteira da sub-rede imediatamente e podem interromper o tráfego ainda mais rápido quando a velocidade é mais importante que a precisão cirúrgica — por exemplo, quando várias instâncias na mesma sub-rede estão implicadas, ou quando a sessão ativa de um invasor deve ser interrompida instantaneamente. As NACLs também são úteis quando uma política impede a modificação direta de uma instância.

O SG de quarentena canônico permite nenhum tráfego de entrada e tráfego de saída apenas para os VPC interface endpoints para com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages e com.amazonaws.<region>.ec2messages. Isso preserva o acesso ao Systems Manager Session Manager enquanto bloqueia canais de C2 (Comando e Controle), exfiltração de dados e movimento lateral.

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

Ordem de Preservação de Evidências

O valor forense se degrada do mais volátil para o menos volátil, então a ordem das operações é fixa e inegociável:

• Habilite a proteção contra terminação primeiro. Definir DisableApiTermination=true impede que um evento do Auto Scaling, um erro de um operador ou uma ação agendada destrua a instância no meio da investigação. Desanexe também a instância de seu grupo do Auto Scaling para que as verificações de saúde (health checks) do ASG não possam substituí-la.

• Desanexe ou proteja do Auto Scaling. Use EnterStandby ou desanexe a instância para que o ASG não a termine por ser considerada insalubre (unhealthy).

• Faça um snapshot de cada volume EBS anexado. CreateSnapshot (ou CreateSnapshots para captura atômica de múltiplos volumes) produz um artefato forense imutável e criptografado. Marque os snapshots com a ID do incidente, a ID da instância de origem, o timestamp e o nome do analista. Copie os snapshots para uma conta forense dedicada, de propriedade da equipe de segurança, para que eles sobrevivam a um comprometimento da conta.

• Capture a memória. Use um documento do SSM RunCommand para invocar uma ferramenta de aquisição de memória (LiME, AVML no Linux; WinPMEM no Windows) e transmita a imagem para um bucket S3 forense com o Object Lock no modo de conformidade (compliance mode). A memória deve ser capturada enquanto a instância ainda está em execução — uma instância parada não tem RAM para ser adquirida.

• Colete metadados. Registre a ID da instância, AMI, perfil de instância IAM, VPC/subnet, IDs de ENI, tags, lista de processos em execução, saída do netstat e o conteúdo do IMDS. Marque a instância com as tags Status=Quarantined e IncidentId=<id> para que automações downstream e operadores humanos reconheçam seu estado.

• Somente então pare a instância se a investigação exigir análise de disco offline. Parar a instância apaga a memória, então este é sempre o último passo.

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

Workflows Automatizados de RI

Os achados (findings) do GuardDuty devem acionar a contenção em segundos, não em horas. O pipeline canônico é EventBridge → Lambda → SSM Automation, com o SNS para notificações.

Uma regra do EventBridge corresponde a source: aws.guardduty com um detail-type de GuardDuty Finding e um padrão que filtra para tipos de achados relevantes para o EC2, como UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/* e CryptoCurrency:EC2/*.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

O alvo (target) Lambda extrai a ID da instância de detail.resource.instanceDetails.instanceId e, em seguida, invoca um documento do SSM Automation (ou chama diretamente o SDK) para: habilitar a proteção contra terminação, substituir os security groups da ENI pelo SG de quarentena via ModifyNetworkInterfaceAttribute, fazer snapshot de todos os volumes anexados, marcar a instância com tags e publicar uma mensagem SNS no canal do SOC. Usar o SSM Automation em vez de chamadas diretas ao SDK fornece trilhas de auditoria passo a passo no histórico de execução do Automation.

Logging para Análise de Exfiltração e C2

Contenção sem telemetria é um trabalho de adivinhação. Os VPC Flow Logs devem ser habilitados no nível da VPC ou da sub-rede com o tipo de tráfego definido como ALL (tanto ACCEPT quanto REJECT). Os registros REJECT revelam varreduras (scanning), tentativas de exfiltração bloqueadas e beacons de C2 tentando alcançar IPs maliciosos conhecidos; os registros ACCEPT mostram quais fluxos foram bem-sucedidos. Roteie os flow logs para o CloudWatch Logs para consultas em tempo real e para o S3 para retenção de longo prazo com o Object Lock. O CloudTrail com data events no bucket S3 forense e no KMS fornece a cadeia de auditoria para o manuseio de evidências. Combine isso com o logging de consultas DNS (Route 53 Resolver) para capturar DGA e tunelamento DNS que os flow logs sozinhos não detectariam.

Acesso Forense Controlado via Session Manager

O Session Manager elimina a necessidade de chaves SSH, bastion hosts ou de abrir as portas 22/3389, e é exatamente por isso que o SG de quarentena pode bloquear todo o acesso tradicional. Habilite o logging da sessão para um bucket S3 com SSE-KMS e para o CloudWatch Logs; imponha EnforceEncryption=true nas preferências da sessão para que nenhuma sessão seja executada sem TLS e criptografia de log. As políticas do IAM em ssm:StartSession devem ter seu escopo limitado a instâncias com a tag tag:Status=Quarantined e ser concedidas apenas à role de resposta a incidentes.

Armadilhas Comuns e Por Que Elas Falham

• Parar ou terminar primeiro. Parar a instância libera a memória, encerra conexões ativas e elimina a capacidade de capturar artefatos voláteis. Terminar a instância, adicionalmente, libera o volume raiz, a menos que DeleteOnTermination=false, e mesmo assim você perde o estado de tempo de execução. Sempre contenha a instância no local antes de qualquer alteração no estado de energia.

• Confiar apenas em security groups quando as NACLs são mais rápidas. As alterações em SGs são cirúrgicas, mas afetam apenas a ENI à qual estão anexadas e governam apenas novos fluxos. Quando várias instâncias em uma sub-rede estão implicadas, ou quando uma sessão de saída existente de um invasor deve ser cortada imediatamente, uma regra de negação (deny) em uma NACL no nível da sub-rede fecha a porta mais rápido, porque as NACLs são stateless e bloqueiam todos os pacotes, independentemente do estado anterior.

• Remediar antes de criar snapshots. Recriar a imagem, aplicar patches ou substituir a instância antes de criar snapshots do EBS destrói as evidências residentes no disco — binários de malware, mecanismos de persistência, logs, timestamps. Snapshots são baratos e imutáveis; crie-os antes de qualquer ação de remediação e copie-os para uma conta forense dedicada para que uma conta de produção comprometida não possa excluí-los.

Problema Prático: Cenário de Caso de Uso

Cenário: A Meridian Financial opera um ambiente AWS multi-contas com cargas de trabalho de produção em uma conta dedicada: serviços EC2 e EKS hospedando dados de clientes, buckets S3 para arquivos, logs centralizados em uma conta de segurança com CloudTrail, GuardDuty, Security Hub e Config habilitados, e um pipeline de CI/CD para deployments. A equipe de operações usa o Systems Manager para aplicação de patches e manutenção e o Route 53/ALBs para endpoints públicos.

Desafio: Um achado (finding) do GuardDuty e picos inesperados de tráfego de saída indicam uma provável instância EC2 comprometida, envolvida em exfiltração de dados e chamadas de API suspeitas do IAM, exigindo contenção imediata enquanto se preserva a evidência forense e se mantém o acesso auditável para o investigador.

Abordagem Recomendada:

1. Acionar a contenção imediata via EventBridge com base no achado do GuardDuty para invocar um workflow do Step Functions que usa uma automação Lambda/SSM para anexar um security group de quarentena, remover IPs públicos ou desanexar a ENI, e revogar/rotacionar as credenciais IAM implicadas via IAM.
2. Preservar evidências voláteis e persistentes executando um documento de automação do SSM para criar um snapshot do EBS e uma AMI da instância, copiar os snapshots para uma conta AWS forense dedicada e armazenar os artefatos exportados em um bucket S3 com S3 Object Lock (modo compliance) e criptografia KMS.
3. Capturar logs para análise de exfiltração e C2 (Comando e Controle), garantindo que os eventos de gerenciamento e de dados do CloudTrail (S3, Lambda) estejam habilitados, encaminhando os VPC Flow Logs, logs de acesso do ALB/NGINX e logs de consulta do Route 53 para a conta de segurança central, e elevar o achado ao Amazon Detective para correlação na linha do tempo.
4. Automatizar a orquestração e as notificações usando EventBridge -> Step Functions -> Lambda para coordenar a contenção, a cópia de evidências, as notificações via SNS para os responsáveis pelo incidente e a criação de tickets no sistema ITSM existente.
5. Fornecer acesso forense controlado exigindo o AWS Systems Manager Session Manager para sessões de investigação ao vivo, com o registro das sessões no CloudWatch Logs e no bucket S3 forense, permitido apenas para uma IAM role forense designada com MFA e credenciais temporárias.

Justificativa: Esta abordagem isola a ameaça rapidamente, preserva artefatos imutáveis e logs centralizados para análise, automatiza etapas de resposta repetíveis para reduzir o tempo de contenção e impõe um acesso forense auditável e de privilégio mínimo via Session Manager, de acordo com as melhores práticas da AWS.

← Segurança de Contêineres e Serverless · Todos os domínios

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →