Amazon SCS-C02: Respuesta a Incidentes y Análisis Forense — Guía de estudio

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

Forma parte de la AWS Security Specialty SCS-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Aislamiento de instancias EC2 comprometidas

El primer objetivo operativo cuando se sospecha que una instancia EC2 está comprometida es la contención sin destruir la evidencia. La contención en AWS es una actividad en capas que abarca la exposición de red de la instancia, los vínculos de su ciclo de vida y la accesibilidad para los equipos de respuesta.

La secuencia canónica de aislamiento comienza por restringir el grupo de seguridad de la instancia. Dado que idealmente cada instancia tiene su propio grupo de seguridad dedicado, puedes reemplazar las reglas de entrada y salida con un conjunto mínimo que permita el acceso únicamente al equipo forense (o a un grupo de seguridad de diagnóstico dedicado). Si la instancia se encuentra detrás de un Application Load Balancer o en un grupo de destino, primero anula su registro; si es miembro de un grupo de Auto Scaling, desvincúlala con la bandera --should-decrement-desired-capacity para que el ASG no lance inmediatamente un reemplazo o, peor aún, termine la instancia “no saludable” a mitad de la investigación.

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 la protección contra terminación es esencial porque un operador bien intencionado, un script de automatización o un evento de escalado hacia adentro (scale-in) del ASG podrían destruir los mismos volúmenes que intentas preservar. La protección contra terminación no sustituye la desvinculación del ASG; un ASG aún puede terminar instancias protegidas durante un evento de scale-in a menos que también elimines la instancia del alcance del grupo.

Para la contención a nivel de subred cuando necesitas un corte inmediato del tráfico de salida (por ejemplo, una instancia que se comunica con IPs maliciosas conocidas), puedes agregar una regla explícita de denegación total de salida a la ACL de red de la subred como la regla con el primer número. Esta regla no tiene estado (stateless) y tiene efecto instantáneo en todos los flujos, a diferencia de los cambios en los grupos de seguridad que solo afectan a los flujos nuevos. Una vez que tu ruta de acceso forense esté establecida a través de un SG de diagnóstico, la denegación de la NACL puede eliminarse para que la subred del equipo de respuesta pueda alcanzar el objetivo a través de la lista de permisos del SG.

Preservación de evidencia volátil y no volátil

La evidencia volátil —listados de procesos, sockets de red abiertos, módulos del kernel cargados, contenido de la memoria, contenido de tmpfs— se destruye en el momento en que la instancia se detiene. La evidencia no volátil reside en EBS y sobrevive a las detenciones/inicios, pero aún puede perderse si los volúmenes se desvinculan o la instancia se termina sin tener snapshots. La regla de oro: recolectar primero los artefactos volátiles mientras la instancia aún está en ejecución, y luego tomar snapshots de EBS.

La recolección volátil debe ser automatizada mediante scripts y ejecutada a través de SSM Run Command en lugar de que un humano escriba en una shell interactiva. Run Command registra la invocación, los parámetros, el principal que la ejecuta y la salida en CloudWatch Logs o S3, lo que a su vez se convierte en parte del registro de la cadena de custodia.

Problema práctico: Escenario de caso de uso

Escenario: Meridian Financial ejecuta sus aplicaciones web orientadas al cliente en una única cuenta de AWS a través de múltiples VPCs, utilizando grupos de Auto Scaling detrás de Application Load Balancers, instancias EC2 respaldadas por EBS, registro centralizado con CloudTrail y CloudWatch, GuardDuty y un archivo de logs basado en S3 cifrado con KMS. El equipo de operaciones de seguridad utiliza AWS Systems Manager para la gestión remota y almacena copias de seguridad y snapshots en una cuenta de recuperación designada.

Desafío: Una instancia EC2 de producción muestra signos de estar comprometida, con tráfico de salida sospechoso y actividad de procesos inesperada; el equipo debe aislar la instancia y preservar tanto la evidencia de la memoria volátil como la del disco no volátil para el análisis forense, sin destruir los registros de auditoría.

Enfoque recomendado:

1. Usar las APIs de Auto Scaling y ELB para desvincular la instancia de los grupos de destino y suspender los procesos de Auto Scaling, luego aplicar un Security Group restrictivo (denegar todo el tráfico de entrada/salida) y actualizar las reglas de la Network ACL de la instancia para aislar el acceso a la red, manteniendo la gestión a través de AWS Systems Manager Session Manager.
2. Usar AWS Systems Manager Run Command para ejecutar una captura de memoria en el sistema operativo invitado (por ejemplo, LiME) que escribe el volcado de RAM en un volumen EBS adjunto y cifrado, o directamente a un bucket de S3 cifrado con SSE-KMS y con S3 Object Lock habilitado para la retención.
3. Usar EC2 CreateSnapshot (o CreateImage) para capturar snapshots de EBS de un momento específico (point-in-time) de todos los volúmenes adjuntos, luego copiar esos snapshots a una cuenta de AWS separada o a otra región para preservar la cadena de custodia y evitar la manipulación.
4. Habilitar o recuperar VPC Traffic Mirroring para la ENI de la instancia para recolectar capturas de paquetes en una EC2 de monitoreo dedicada, y exportar simultáneamente los VPC Flow Logs, los logs de acceso de ELB, CloudTrail, CloudWatch Logs y los hallazgos de GuardDuty al archivo seguro de S3.
5. Etiquetar e inventariar todos los artefactos recolectados en AWS Security Hub o en un sistema de tickets, asegurarse de que los objetos de S3 estén cifrados y que Object Lock esté configurado, y restringir el acceso de IAM a un pequeño equipo forense, registrando todo el acceso a través de CloudTrail.

Justificación: Aislar el acceso a la red antes de tomar imágenes previene una mayor contaminación, mientras que usar SSM evita abrir nuevos vectores de red; capturar primero la memoria volátil y crear snapshots inmutables de EBS y archivos seguros en S3 preserva la integridad de la evidencia y la cadena de custodia, en línea con las mejores prácticas de respuesta a incidentes de 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

Inmediatamente después de la captura volátil, toma un snapshot de cada volumen EBS adjunto. Etiqueta los snapshots con el identificador del incidente para que estén vinculados inequívocamente al 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}]'

Etiqueta la propia instancia con el mismo ticket de incidente, el nombre del investigador y una etiqueta de estado como Quarantine. El etiquetado consistente de metadatos es el mecanismo nativo de AWS para la cadena de custodia: es consultable, inmutable a través de las claves de condición de IAM y aparece en cada evento de CloudTrail sobre el recurso.

Respuesta en vivo con Session Manager y Run Command

Un punto sutil pero crítico para el examen: las sesiones SSH existentes sobreviven a la eliminación de las reglas de los grupos de seguridad. Los grupos de seguridad son stateful (con estado) y evalúan las reglas al establecer la conexión; una sesión TCP ya establecida continúa fluyendo incluso después de que se elimine la regla de entrada que la permitió. Si un respondedor aísla una instancia eliminando las reglas del SG mientras depende de su propia sesión SSH para el acceso, esa sesión funcionará, hasta que se caiga, momento en el cual quedará bloqueado y cualquier reingreso basado en un bastión o en claves será imposible.

El patrón correcto es otorgar al equipo forense acceso a través de SSM Session Manager, que no requiere que ningún puerto de entrada esté abierto. Session Manager funciona sobre la conexión de salida del SSM Agent hacia los endpoints de SSM, EC2 Messages y SSM Messages (idealmente a través de VPC interface endpoints para que la instancia aislada no necesite una ruta a internet). Asocia un perfil de instancia que permita ssm:UpdateInstanceInformation y las API de mensajería, y otorga a los respondedores el permiso ssm:StartSession acotado por etiqueta a la instancia en cuarentena.

Debido a que las sesiones de Session Manager son intermediadas por el plano de control de SSM, restringir o vaciar por completo las reglas de entrada del grupo de seguridad no las interrumpe, y cada pulsación de tecla puede registrarse en S3 o CloudWatch Logs, lo que resulta en una sesión interactiva auditable, no en una caja negra.

Recuperación entre cuentas de snapshots cifrados

Los entornos maduros dirigen los snapshots forenses a una cuenta forense dedicada y aislada de la cuenta de la carga de trabajo comprometida. Compartir snapshots entre cuentas requiere dos cosas: el snapshot debe compartirse con la cuenta de destino (modify-snapshot-attribute --create-volume-permission), y si el snapshot está cifrado con una clave de KMS gestionada por el cliente (CMK), la política de la clave de KMS debe otorgar a las entidades principales (principals) de la cuenta forense los permisos kms:Decrypt, kms:CreateGrant y kms:DescribeKey. Los snapshots cifrados con la clave gestionada por AWS aws/ebs no se pueden compartir entre cuentas; primero debes volver a cifrarlos con una CMK mediante una operación de copia. En la cuenta forense, copia el snapshot compartido y vuelve a cifrarlo con una CMK forense local para que la creación de volúmenes posterior no dependa de la cuenta de origen.

Diseño de playbooks y minimización de la sobrecarga

Codifica los pasos de contención como un documento de SSM Automation o un flujo de trabajo de Step Functions activado por hallazgos de GuardDuty o Security Hub a través de EventBridge. Una única automatización debería: (1) capturar datos volátiles a través de Run Command, (2) crear snapshots de los volúmenes con etiquetas del incidente, (3) habilitar la protección contra terminación, (4) desacoplarla del ASG y anular su registro de los destinos del ELB, (5) reemplazar el SG con el SG de cuarentena, y (6) etiquetar la instancia con el ID del tique. Mantener la instancia en ejecución preserva la evidencia en vivo y permite la investigación interactiva a través de Session Manager; apagarla debe ser un paso posterior deliberado, no parte de la contención automática, porque el apagado elimina la evidencia volátil y puede activar lógicas de limpieza incrustadas en el malware.

Las trampas que hay que internalizar: eliminar las reglas del SG confiando en una sesión SSH existente deja al respondedor ciego y da una falsa confianza en el aislamiento; realizar una remediación in-situ antes de crear los snapshots destruye los artefactos que responden a cómo ocurrió la intrusión; y dejar la instancia en su ASG o grupo de destino invita a una terminación automatizada o, peor aún, a un reemplazo silencioso que oculta el alcance del incidente.

Contención inmediata

Cuando se sospecha que una carga de trabajo está comprometida, la primera decisión es si aislarla in-situ o retirarla del servicio. Retirarla (deteniéndola o terminándola) destruye la evidencia volátil como el contenido de la RAM, los procesos en ejecución, los sockets abiertos y cualquier malware que solo viva en la memoria. La contención in-situ es casi siempre el movimiento inicial correcto, y debe ocurrir lo suficientemente rápido como para que un atacante no pueda exfiltrar datos adicionales o pivotar lateralmente antes de que los controles surtan efecto.

Dos controles nativos de AWS operan en diferentes capas, y la distinción es importante. Los grupos de seguridad son stateful (con estado) y se asocian a las interfaces de red elásticas (ENI); las ACL de red (NACL) son stateless (sin estado) y se asocian a las subredes. Reemplazar los grupos de seguridad de una instancia con un SG de «cuarentena» restringido es el enfoque quirúrgico: aísla una ENI sin perturbar otras cargas de trabajo en la misma subred y preserva el estado de ejecución de la instancia. Sin embargo, los cambios en los grupos de seguridad solo afectan a los flujos nuevos que llegan a la ENI, y si la instancia comprometida ya mantiene conexiones de salida de larga duración, el estado existente puede persistir. Las reglas de denegación de las NACL surten efecto en el límite de la subred de inmediato y pueden cortar el tráfico aún más rápido cuando la velocidad importa más que la precisión quirúrgica; por ejemplo, cuando varias instancias en la misma subred están implicadas, o cuando una sesión activa de un atacante debe ser cortada al instante. Las NACL también son útiles cuando una política impide modificar una instancia directamente.

El SG de cuarentena canónico no permite tráfico de entrada (inbound) y solo permite tráfico de salida (outbound) hacia los VPC interface endpoints para com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages y com.amazonaws.<region>.ec2messages. Eso preserva el acceso a Systems Manager Session Manager mientras bloquea los canales de C2, la exfiltración de datos y el movimiento 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: []

Orden de preservación de evidencia

El valor forense se degrada de más a menos volátil, por lo que el orden de las operaciones es fijo y no negociable:

• Habilitar primero la protección contra terminación. Establecer DisableApiTermination=true evita que un evento de Auto Scaling, un error de un operador o una acción programada destruyan la instancia a mitad de la investigación. También, desvincule la instancia de su grupo de Auto Scaling para que las comprobaciones de estado (health checks) del ASG no puedan reemplazarla.

• Desvincular o proteger de Auto Scaling. Use EnterStandby o desvincule la instancia para que el ASG no la termine por no estar en buen estado (unhealthy).

• Hacer un snapshot de cada volumen EBS adjunto. CreateSnapshot (o CreateSnapshots para una captura atómica de múltiples volúmenes) produce un artefacto forense inmutable y cifrado. Etiquete los snapshots con el ID del incidente, el ID de la instancia de origen, la marca de tiempo (timestamp) y el analista. Copie los snapshots a una cuenta forense dedicada, propiedad del equipo de seguridad, para que sobrevivan a un compromiso de la cuenta.

• Capturar la memoria. Use un documento de SSM RunCommand para invocar una herramienta de adquisición de memoria (LiME, AVML en Linux; WinPMEM en Windows) y transmitir la imagen a un bucket de S3 forense con Object Lock en modo de conformidad (compliance mode). La memoria debe capturarse mientras la instancia todavía está en ejecución; una instancia detenida no tiene RAM que adquirir.

• Recopilar metadatos. Registre el ID de la instancia, AMI, perfil de instancia de IAM, VPC/subred, IDs de ENI, etiquetas, lista de procesos en ejecución, salida de netstat y contenidos del IMDS. Etiquete la instancia con Status=Quarantined e IncidentId=<id> para que la automatización posterior y los operadores humanos reconozcan su estado.

• Solo entonces detenga la instancia si la investigación requiere un análisis de disco sin conexión (offline). Detener la instancia borra la memoria, por lo que este es siempre el último paso.

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/"]'

Flujos de trabajo de RI automatizados

Los hallazgos de GuardDuty deberían desencadenar la contención en segundos, no en horas. El pipeline canónico es EventBridge → Lambda → SSM Automation, con SNS para las notificaciones.

Una regla de EventBridge busca coincidencias en source: aws.guardduty con un detail-type de GuardDuty Finding y un patrón que filtra los tipos de hallazgos relevantes para EC2, como UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/* y CryptoCurrency:EC2/*.

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

El destino Lambda extrae el ID de la instancia de detail.resource.instanceDetails.instanceId, luego invoca un documento de SSM Automation (o llama directamente al SDK) para: habilitar la protección contra terminación, reemplazar los grupos de seguridad de la ENI con el SG de cuarentena mediante ModifyNetworkInterfaceAttribute, hacer snapshots de todos los volúmenes adjuntos, etiquetar la instancia y publicar un mensaje de SNS en el canal del SOC. Usar SSM Automation en lugar de llamadas directas al SDK proporciona pistas de auditoría paso a paso en el historial de ejecución de Automation.

Registros para análisis de exfiltración y C2

La contención sin telemetría es una conjetura. Los VPC Flow Logs deben estar habilitados a nivel de VPC o subred con el tipo de tráfico establecido en ALL (tanto ACCEPT como REJECT). Los registros REJECT revelan escaneos, intentos de exfiltración bloqueados y balizas (beacons) de C2 que intentan alcanzar IPs maliciosas conocidas; los registros ACCEPT muestran qué flujos tuvieron éxito. Dirija los flow logs a CloudWatch Logs para consultas en tiempo real y a S3 para retención a largo plazo con Object Lock. CloudTrail con eventos de datos en el bucket de S3 forense y KMS proporciona la cadena de auditoría para el manejo de la evidencia. Combine esto con el registro de consultas DNS (Route 53 Resolver) para detectar DGA y túneles DNS que los flow logs por sí solos no detectarían.

Acceso forense controlado a través de Session Manager

Session Manager elimina la necesidad de claves SSH, bastiones (bastion hosts) o tener abiertos los puertos 22/3389, que es precisamente la razón por la que el SG de cuarentena puede bloquear todo el acceso tradicional. Habilite el registro de sesiones en un bucket de S3 con SSE-KMS y en CloudWatch Logs; fuerce EnforceEncryption=true en las preferencias de la sesión para que ninguna sesión se ejecute sin TLS y sin cifrado de logs. Las políticas de IAM sobre ssm:StartSession deben tener un alcance limitado a instancias con la etiqueta tag:Status=Quarantined y solo deben concederse al rol de respuesta a incidentes.

Trampas comunes y por qué fallan

• Detener o terminar primero. Detener una instancia libera la memoria, mata las conexiones activas y elimina la capacidad de capturar artefactos volátiles. Terminarla, además, libera el volumen raíz a menos que DeleteOnTermination=false, e incluso en ese caso se pierde el estado de tiempo de ejecución. Siempre se debe contener la instancia en su lugar antes de cualquier cambio en su estado de energía.

• Confiar únicamente en los security groups cuando las NACL son más rápidas. Los cambios en los SG son quirúrgicos, pero solo afectan a la ENI a la que están asociados y solo gobiernan los flujos nuevos. Cuando varias instancias en una subred están implicadas, o cuando una sesión saliente existente de un atacante debe cortarse de inmediato, una regla de denegación (deny) en una NACL a nivel de subred cierra la puerta más rápido porque las NACL no tienen estado (stateless) y bloquean cada paquete sin importar su estado previo.

• Remediar antes de crear snapshots. Recrear la imagen, aplicar parches o reemplazar la instancia antes de crear snapshots de EBS destruye la evidencia residente en el disco: binarios de malware, mecanismos de persistencia, registros, marcas de tiempo. Los snapshots son económicos e inmutables; créalos antes de cualquier acción de remediación y cópialos a una cuenta de AWS dedicada a análisis forense para que una cuenta de producción comprometida no pueda eliminarlos.

Problema práctico: Escenario de caso de uso

Escenario: Meridian Financial opera un entorno de AWS multicuenta con cargas de trabajo de producción en una cuenta dedicada: servicios EC2 y EKS que alojan datos de clientes, buckets de S3 para archivos, registro centralizado en una cuenta de seguridad con CloudTrail, GuardDuty, Security Hub y Config habilitados, y una canalización de CI/CD para los despliegues. Su equipo de operaciones utiliza Systems Manager para la aplicación de parches y el mantenimiento, y Route 53/ALB para los puntos de conexión (endpoints) públicos.

Desafío: Un hallazgo de GuardDuty y picos inesperados de tráfico saliente indican una probable instancia EC2 comprometida que está realizando exfiltración de datos y llamadas sospechosas a la API de IAM, lo que requiere una contención inmediata mientras se preserva la evidencia forense y se mantiene un acceso auditable para los investigadores.

Enfoque recomendado:

1. Desencadenar la contención inmediata a través de EventBridge a partir del hallazgo de GuardDuty para invocar un flujo de trabajo de Step Functions que utiliza una automatización de Lambda/SSM para asociar un security group de cuarentena, eliminar las IP públicas o desasociar la ENI, y revocar/rotar las credenciales de IAM implicadas a través de IAM.
2. Preservar la evidencia volátil y persistente ejecutando un documento de SSM Automation para crear un snapshot de EBS y una AMI de la instancia, copiar los snapshots a una cuenta de AWS dedicada a análisis forense y almacenar los artefactos exportados en un bucket de S3 con S3 Object Lock (en modo de cumplimiento) y cifrado de KMS.
3. Capturar registros para el análisis de exfiltración y C2 (Command and Control) asegurando que los eventos de gestión y de datos de CloudTrail (S3, Lambda) estén habilitados, reenviando los VPC Flow Logs, los registros de acceso de ALB/NGINX y los registros de consultas de Route 53 a la cuenta de seguridad central, y elevando el hallazgo a Amazon Detective para la correlación en la línea de tiempo.
4. Automatizar la orquestación y las notificaciones usando EventBridge -> Step Functions -> Lambda para coordinar la contención, la copia de evidencia, las notificaciones de SNS a los responsables del incidente y la creación de tickets en el sistema ITSM existente.
5. Proporcionar acceso forense controlado exigiendo el uso de AWS Systems Manager Session Manager para las sesiones de investigación en vivo, con el registro de la sesión en CloudWatch Logs y en el bucket de S3 forense, permitido únicamente a un rol de IAM forense designado con MFA y credenciales temporales.

Justificación: Este enfoque aísla la amenaza rápidamente, preserva artefactos inmutables y registros centralizados para el análisis, automatiza los pasos de respuesta repetibles para reducir el tiempo de contención (time-to-contain) y aplica un acceso forense auditable y de mínimo privilegio a través de Session Manager, de acuerdo con las mejores prácticas de AWS.

← Seguridad de Contenedores y Serverless · Todos los dominios

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →