Validar tus detecciones con ataques simulados

“Tenemos GuardDuty y reglas de EventBridge” es una declaración de fe hasta que la pruebas. Una regla puede estar desplegada en la región equivocada, filtrar un campo que el evento ya no trae, o simplemente no existir para la técnica que te preocupa. La única forma de saberlo es detonar la técnica y mirar si salta la alerta. Eso es validar detecciones: convertir “creo que lo veríamos” en “lo vimos, en 40 segundos, el martes”.

Esta nota es el método, no la teoría. Partimos del mapeo que ya construiste en 5 técnicas cloud y los logs que las detectan y lo sometemos a prueba.

El método en cuatro pasos#

Validar que tus detecciones funcionan de verdad

Stratus Red Team → marcador

Paso 1 de 5El plan

Para cada técnica que te preocupa, escribe qué fuente de log debería delatarla y qué regla debería saltar. Aún no has probado nada: todo está "pendiente".

El marcador del explainer resume el ciclo: planeas qué debería disparar cada técnica, la detonas una vez, registras detectada o no, y cierras cada hueco rojo con una regla hasta dejar el tablero en verde. Lo importante es que el veredicto lo da el ataque real, no tu optimismo.

Paso 1 · Mapea la técnica a lo que debería disparar#

Antes de ejecutar nada, escribe la hipótesis. Para cada técnica: qué harías con ella, qué fuente de log la registra, qué regla o consulta debería convertirla en alerta. Si no puedes nombrar la regla, ya encontraste un hueco sin gastar un solo comando.

Técnica (ATT&CK)	Fuente de log	¿Detectada?	Acción
`T1685.002` Detener el trail	CloudTrail · gestión	✅ sí	Regla EventBridge sobre `StopLogging`/`DeleteTrail`
`T1098.001` Backdoor: nueva access key	CloudTrail · IAM (us-east-1)	✅ sí	Regla sobre `CreateAccessKey` (política: sin usuarios IAM)
`T1537` Compartir AMI/snapshot	CloudTrail · gestión	❌ no	Añadir regla sobre `ModifySnapshotAttribute`
`T1552.005` Robar credenciales por IMDS	GuardDuty · VPC Flow Logs	❌ no	Activar `InstanceCredentialExfiltration` + alerta
`T1530` Descarga masiva de S3	CloudTrail · datos de S3	⚠️ parcial	Activar eventos de datos + umbral por identidad

La columna que importa es ¿Detectada?: empieza vacía y solo la rellenas después de detonar. Un ❌ no es un suspenso del ejercicio; es su producto.

Paso 2 · Detona con Stratus Red Team#

Stratus Red Team te deja ejecutar cada técnica de forma aislada y reversible, con el ciclo warmup → detonate → cleanup. Cada técnica lleva el ID de ATT&CK al que corresponde, así que el mapeo del paso 1 se traduce casi directamente a comandos.

# Qué hay disponible para AWS
stratus list --platform aws

# Detonar una técnica concreta (genera la señal real)
stratus detonate aws.defense-evasion.cloudtrail-stop       # T1685.002
stratus detonate aws.persistence.iam-backdoor-user         # T1098.001
stratus detonate aws.exfiltration.ec2-share-ami            # T1537

# Deshacer SIEMPRE lo que montó la detonación
stratus cleanup --all

Paso 3 · Registra detectado vs no detectado#

Tras cada detonación, ve a tus logs y comprueba el resultado real. No basta con que el evento esté en CloudTrail: tiene que haber llegado a tu canal de triaje. Rellena la tabla con honestidad.

Vulnerable

Seguro

| Técnica   | ¿Detectada? |
| --------- | ----------- |
| T1685.002 | sí          |
| T1098.001 | sí          |
| T1537     | sí          |
| T1552.005 | sí          |

| Técnica   | ¿Detectada? | Tiempo a alerta |
| --------- | ----------- | --------------- |
| T1685.002 | sí          | 00:41           |
| T1098.001 | sí          | 00:58           |
| T1537     | no          | —               |
| T1552.005 | no          | —               |

La diferencia entre las dos tablas es exactamente el valor del ejercicio: dos técnicas que dabas por cubiertas no lo estaban. Sin detonarlas, habrías descubierto el hueco el día del incidente real.

Paso 4 · Cierra los huecos#

Cada ❌ se convierte en una regla, una consulta o un ajuste de configuración. Para T1537, una regla de EventBridge sobre ModifySnapshotAttribute/ModifyImageAttribute que detecte compartir un snapshot o una AMI con una cuenta externa. Para T1552.005, activar el hallazgo de GuardDuty de exfiltración de credenciales de instancia y asegurarte de que imdsv2 es obligatorio. Luego re-ejecuta la misma técnica y confirma que ahora salta.

Donde tenga sentido, el cierre del hueco no es solo detectar sino responder solo: conectar la alerta a una auto-remediación (desactivar la clave, aislar la instancia) para que el tiempo de respuesta no dependa de que alguien esté mirando. Validar la respuesta automática es el mismo bucle: detonar, comprobar que la remediación actuó, medir cuánto tardó.

Tu turno

Valida tres técnicas de principio a fin

En tu cuenta de laboratorio, con autorización escrita y avisando a quien corresponda:

Mapea tres técnicas de ATT&CK que te importen en la plantilla técnica → fuente de log → ¿detectada? → acción. Rellena todo menos la columna “¿detectada?”.
Detónalas una a una con stratus detonate y, tras cada una, comprueba si tu alerta llegó al canal de triaje. Anota el resultado real y el tiempo a alerta. Ejecuta stratus cleanup --all al acabar.
Para cada ❌, escribe la regla o consulta que faltaba, despliégala y re-detona para confirmar que ahora sí salta.
Guarda la tabla final (con fechas y tiempos) en tu repositorio: es tu evidencia de cobertura.

Reto

Detonaste T1537 (compartir una AMI) y no saltó nada, pero el evento sí está en CloudTrail. ¿Qué falló?

▸Mostrar solución

La detección, no el registro. El evento ModifySnapshotAttribute/ModifyImageAttribute quedó en CloudTrail, pero no tenías ninguna regla que lo convirtiera en alerta ni lo enrutara a triaje. El hueco no es de visibilidad, es de detección: el log existe, nadie lo mira. Esa es precisamente la clase de brecha que el ejercicio saca a la luz.

Reto

¿Por qué detonar en producción es mala idea aunque la técnica sea 'reversible'?