Secuencias de ataque en Amazon GuardDuty: un runbook de triaje para el hallazgo Critical que correlaciona el resto
En detección de amenazas, la señal fácil de generar suele ser la difícil de usar. Un escaneo de puertos, una llamada de API poco común o un intento de inicio de sesión fallido son eventos que, por separado, no justifican despertar a nadie a las 3 de la madrugada. El costo de paginar por cada uno es alto y el de ignorarlos también. Ese es el vacío que las secuencias de ataque de Amazon GuardDuty vienen a llenar.
GuardDuta, a su servicio
La serie ha vuelto una y otra vez a la misma disciplina. Elegir la señal correcta, fijar un objetivo, tener un runbook. Una secuencia de ataque es, casi literalmente, la señal correcta empaquetada: GuardDuty toma varios eventos débiles, más findings ya existentes, y solo cuando su orden coincide con un patrón sospechoso genera un único hallazgo de severidad Critical. Este artículo explica qué es esa señal, por qué siempre es Critical, qué la puede volver silenciosa por accidente y cómo triarla con un runbook repetible. Cierra con limitaciones y recursos.
Qué es una secuencia de ataque
GuardDuty Extended Threat Detection detecta ataques de varias etapas que abarcan distintas fuentes de datos, varios tipos de recursos de AWS y una ventana de tiempo, dentro de una cuenta de AWS. En lugar de mirar cada evento aislado, correlaciona la secuencia y, cuando el conjunto se alinea con una actividad potencialmente maliciosa, emite un hallazgo de secuencia de ataque.
GuardDuty llama señales a los eventos que correlaciona, e incluye tanto actividades de la API como findings propios ya identificados. A las actividades de API que por sí solas no representan una amenaza clara las trata como señales débiles. La detección opera sobre una ventana móvil de 24 horas, pensada para capturar comportamientos de ataque en curso o recientes: por ejemplo, un actor que obtiene acceso a una carga de cómputo, luego enumera, escala privilegios y termina exfiltrando credenciales.
Extended Threat Detection viene habilitada por defecto en toda cuenta que tenga GuardDuty activo, sin costo adicional, y correlaciona por defecto las señales de todas las fuentes de datos fundamentales: eventos de administración de AWS CloudTrail, registros de flujo de Amazon VPC y registros de consultas DNS de Amazon Route 53 Resolver. Al activar planes de protección adicionales, como S3 Protection, EKS Protection o Runtime Monitoring, se abren más tipos de secuencia porque se amplía el rango de fuentes.
Los cinco tipos y por qué todos son Critical
Existen cinco tipos de hallazgo de secuencia de ataque, y conviene conocerlos por nombre porque el nombre ya orienta el triaje:
- AttackSequence:IAM/CompromisedCredentials. Una secuencia de solicitudes de API invocadas con credenciales de AWS potencialmente comprometidas. Fuente: eventos de administración de AWS CloudTrail.
- AttackSequence:S3/CompromisedData. Una secuencia de solicitudes en un posible intento de exfiltrar o destruir datos en Amazon Simple Storage Service (Amazon S3). Fuentes: eventos de datos de AWS CloudTrail para S3 y eventos de administración.
- AttackSequence:EKS/CompromisedCluster. Una secuencia de acciones sospechosas en un clúster de Amazon Elastic Kubernetes Service (Amazon EKS) potencialmente comprometido.
- AttackSequence:ECS/CompromisedCluster. Lo mismo para un clúster de Amazon Elastic Container Service (Amazon ECS).
- AttackSequence:EC2/CompromisedInstanceGroup. Una secuencia que sugiere compromiso en un grupo de instancias de Amazon Elastic Compute Cloud (Amazon EC2) que comparten configuración, como un grupo de auto escalado, un perfil de instancia de IAM o una plantilla de lanzamiento.
Los cinco tienen severidad Critical por defecto, y esto no es una etiqueta arbitraria. En GuardDuty, Critical corresponde al rango de valor 9.0 a 10.0 e indica que una secuencia de ataque puede estar en curso o haber ocurrido hace poco, con uno o más recursos potencialmente comprometidos. La recomendación oficial es priorizar el triaje y la remediación de todo hallazgo Critical, porque pueden ser parte de un ataque de ransomware y escalar en cualquier momento.
La consecuencia operativa es directa. Un hallazgo de secuencia de ataque es la señal por la que sí se pagina. No es un evento débil más: es la correlación de varios de ellos que ya cruzó el umbral de confianza. Ese es exactamente el tipo de señal que la disciplina de esta serie pide aislar del ruido.
La trampa silenciosa: findings archivados y reglas de supresión
Hay un detalle que puede desactivar esta señal sin que nadie se dé cuenta, y merece su propio apartado. Al correlacionar eventos para armar una secuencia de ataque, Extended Threat Detection no considera los findings archivados, incluidos los que se archivan de forma automática por reglas de supresión.
El razonamiento de diseño es sensato: solo las señales activas y relevantes deben alimentar la detección. Pero el efecto secundario es real. Una regla de supresión demasiado amplia, creada en su momento para bajar ruido, puede estar retirando de la mesa justo las señales débiles que GuardDuty necesitaría para armar la secuencia. El resultado no es una alerta ruidosa: es la ausencia de una alerta que debería haber existido.
Por eso, antes de confiar en las secuencias de ataque como la señal de paginado, revisa las reglas de supresión vigentes en la cuenta. Es una tarea de una sola vez que evita un punto ciego difícil de diagnosticar después.
Fijar el objetivo: MTTA y MTTR para Critical
Una señal de alta confianza pide un compromiso de respuesta a la altura. En vez de un presupuesto de error, que encaja mejor con métricas de disponibilidad, aquí conviene fijar dos objetivos de tiempo.
Tiempo medio hasta el acuse (MTTA). Toda secuencia de ataque Critical se acusa en minutos, no en horas. Como la ventana de correlación es de 24 horas y describe actividad en curso o reciente, cada minuto de acuse tardío es tiempo que el actor sigue operando.
Tiempo medio hasta la contención (MTTR). Se define un objetivo para las primeras acciones de contención según el tipo: rotar credenciales para IAM/CompromisedCredentials, aislar el clúster para EKS o ECS, o cerrar el acceso al bucket para S3/CompromisedData. La meta no es cerrar la investigación completa dentro del plazo, sino ejecutar la contención inicial que corta el avance.
Ambos objetivos son medibles con marcas de tiempo del hallazgo y del ticket, y se prestan a revisión periódica igual que cualquier otro SLO operativo.
Runbook: triaje de una secuencia de ataque Critical
Este runbook asume GuardDuty habilitado con Extended Threat Detection activa y, de forma ideal, los planes de protección relevantes para las cargas de la cuenta.
- Acusar de inmediato. En el panel de resumen de GuardDuty, la sección de Secuencias de ataque muestra el conteo. Abre el hallazgo Critical y arranca el reloj de MTTA. El nombre del tipo (IAM, S3, EKS, ECS o EC2) ya te dice qué familia de recursos está en juego.
- Leer la secuencia, no el evento. GuardDuty presenta el hallazgo como una cadena de señales en orden. Lee la secuencia completa antes de actuar sobre un solo paso. El valor de esta señal es precisamente el orden: enumeración, luego escalamiento, luego exfiltración cuenta una historia que un evento suelto no cuenta.
- Identificar el recurso y las credenciales. Para IAM/CompromisedCredentials y S3/CompromisedData, el eje son credenciales de AWS potencialmente mal usadas. Para EKS, ECS y EC2, el eje es el recurso comprometido más las credenciales que ese recurso pudo haber usado. Anota ambos, porque la contención casi siempre toca los dos.
- Contener según el tipo. Aplica la primera acción que corta el avance. Rotar o revocar credenciales comprometidas. Aislar la instancia o el clúster con un grupo de seguridad restrictivo. Ajustar la política del bucket de S3 que quedó demasiado permisiva. Registra el tiempo para el MTTR.
- Ampliar el alcance. La documentación de remediación advierte que las credenciales comprometidas pudieron crear o modificar otros recursos, como buckets de Amazon S3, funciones de AWS Lambda o instancias de Amazon EC2. No cierres el caso en el recurso primario: revisa qué más pudo tocar el actor dentro de la ventana.
- Confirmar cobertura hacia adelante. Si el tipo de secuencia dependía de un plan de protección que no estaba activo (por ejemplo, Runtime Monitoring para contenedores), evalúa habilitarlo para no repetir el punto ciego. Verifica también que ninguna regla de supresión esté ocultando señales débiles pertinentes.
- Registrar y revisar. Anota MTTA y MTTR. Documenta la secuencia observada como referencia para el equipo. Si el mismo patrón reaparece, es candidato a una automatización de contención, no a otro triaje manual.
Limitaciones
- Las secuencias solo se arman con señales activas. Los findings archivados o suprimidos quedan fuera de la correlación, así que una regla de supresión mal calibrada puede crear un punto ciego silencioso.
- La profundidad depende de los planes de protección habilitados. Sin S3 Protection, EKS Protection o Runtime Monitoring, GuardDuty no genera ciertos findings individuales y, por lo tanto, no puede armar las secuencias que dependen de ellos.
- La ventana de correlación es de 24 horas. Un ataque que avanza muy lento, con pasos separados por más tiempo, podría no correlacionarse como una sola secuencia.
- Todas las secuencias llegan como Critical. Es coherente con su diseño de alta confianza, pero implica que el equipo necesita capacidad para responder a Critical sin desgaste: si todo es Critical y no hay proceso, la fatiga de alerta regresa por otra puerta.
- Una secuencia describe un patrón sospechoso, no una condena. El triaje debe confirmar si la actividad era autorizada antes de tratar el recurso como comprometido, aunque la confianza de la señal es alta.
Cierre
Las secuencias de ataque resuelven el viejo dilema de las señales débiles: ni paginar por cada una ni ignorarlas, sino dejar que GuardDuty las correlacione y avisar solo cuando el orden cuenta una historia creíble. Esa es la señal correcta para el turno de guardia. El objetivo lo pones con MTTA y MTTR para Critical, y el runbook garantiza que la respuesta sea la misma a cualquier hora. Un cuidado final que no cuesta nada y evita un punto ciego serio: revisa tus reglas de supresión, porque la correlación solo usa lo que sigue activo.
Recursos
- GuardDuty Extended Threat Detection - Cómo funciona la correlación, la ventana de 24 horas y los planes de protección que amplían la cobertura.
- GuardDuty attack sequence finding types - Detalle de los cinco tipos de secuencia, sus fuentes de datos y las acciones de remediación.
- Severity levels of GuardDuty findings - Los rangos de severidad y por qué Critical exige triaje prioritario.
- Navigating Amazon GuardDuty protection plans and Extended Threat Detection - Guía para decidir qué planes de protección habilitar según el entorno.
- Guía de respuesta ante incidentes de seguridad de AWS: runbooks - Marco general para documentar y probar runbooks de respuesta.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article