Lab 06 – averigua si tu laboratorio detecta algo de verdad.
Tienes un SIEM y un IDS. Ninguno ha demostrado que funcione. Atomic Red Team ejecuta una técnica documentada cada vez, para que veas saltar una alerta o compruebes que nunca salta.
Al terminar el Lab 05 tenías un entorno funcionando: una máquina atacante, una red segmentada, un objetivo vulnerable, detección en el host y detección en la red. Lo que no tenías era ninguna prueba de que la mitad defensiva funcione. Un panel sin alertas tiene exactamente el mismo aspecto tanto si estás protegido como si estás ciego. Este laboratorio cierra ese hueco: ejecuta técnicas conocidas a propósito y comprueba, una a una, si tus propias herramientas dicen algo.
Una detección sin probar es una suposición
Instalar Wazuh en el Lab 03 te dio un SIEM con su conjunto de reglas por defecto, y el Lab 05 te dio Suricata con las firmas de ET Open. Ambos llegaron con cientos de reglas ya activadas, y eso es fácil de leer como cobertura. No lo es. Una regla salta solo cuando el log o el paquete con el que compara llega de verdad a la herramienta, y en una instalación recién hecha hay una cantidad sorprendente de eventos interesantes que sencillamente no se recogen nunca.
La forma de averiguarlo es generar el evento tú mismo. Suena a que hace falta un ataque, pero no hace falta uno real, y desde luego no hace falta un objetivo que no sea tuyo. Hace falta una acción pequeña, precisa y repetible cuyo comportamiento exacto ya conoces.
Qué es Atomic Red Team
Atomic Red Team es una biblioteca libre y de código abierto mantenida por Red Canary. Cada entrada, llamada atomic, reproduce una única técnica de la matriz MITRE ATT&CK en un puñado de comandos, y cada una se publica junto con los comandos exactos que va a ejecutar y una rutina de limpieza que los revierte.
Esa última parte es la que la hace utilizable aquí. No estás desplegando malware a ver qué pasa; estás ejecutando una acción documentada, con un identificador conocido como T1087.001, que se corresponde con una fila concreta de una matriz pública. Cuando aparece una alerta puedes decir con precisión qué técnica la produjo, y cuando no aparece ninguna sabes exactamente qué se te ha escapado.
Instala el ejecutor en un objetivo tuyo
Las pruebas las lanza un proyecto complementario, Invoke-AtomicRedTeam, que funciona sobre PowerShell. Instálalo en una máquina virtual del laboratorio que ya esté reportando a tu SIEM, para que los eventos tengan a dónde ir. Haz antes una instantánea de esa máquina.
# en la vm del laboratorio, en una sesion de PowerShell elevada
PS> IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
PS> Install-AtomicRedTeam -getAtomics
# confirma que ha cargado
PS> Import-Module invoke-atomicredteam -Force
La instantánea importa más de lo que parece. Los atomics son pequeños, pero no son simulaciones: crean cuentas locales, escriben tareas programadas y dejan ficheros de verdad. En una máquina virtual que puedes revertir, eso es justo lo que quieres. En un equipo que te importa, no.
Lee la prueba antes de ejecutarla
Nunca ejecutes un atomic que no hayas leído. Cada prueba puede imprimir primero su propio plan, y hacerlo es la mitad del valor formativo del ejercicio:
# muestra que haria T1087.001, sin hacerlo
PS> Invoke-AtomicTest T1087.001 -ShowDetails
# comprueba y resuelve lo que la prueba necesita antes
PS> Invoke-AtomicTest T1087.001 -CheckPrereqs
# ejecutala
PS> Invoke-AtomicTest T1087.001
# deja la maquina como la encontraste
PS> Invoke-AtomicTest T1087.001 -Cleanup
T1087.001 es descubrimiento de cuentas locales: lo típico que hace un intruso en los primeros minutos tras aterrizar en un host, para saber quién más tiene cuenta en él. Es un punto de partida deliberadamente suave. Lee información, no cambia casi nada, y aun así produce exactamente el tipo de actividad de línea de comandos que se supone que un SIEM debe notar.
| Técnica | Qué hace, y por qué es una buena primera prueba |
|---|---|
| T1087.001 Descubrimiento de cuentas locales | Enumera usuarios locales. Casi sin efectos secundarios, y comprueba si estás recogiendo líneas de comandos de procesos siquiera. |
| T1082 Descubrimiento de información del sistema | Le pide al host que se describa. Ruidosa en los logs, inofensiva en efecto, y con frecuencia se le escapa a las reglas por defecto. |
| T1053.005 Tarea programada | Crea un mecanismo de persistencia, así que hace un cambio real. Deja esta para cuando ya te fíes de tu limpieza y de tu instantánea. |
Lee el resultado por los dos lados
Ahora ve a mirar, en este orden. Primero el SIEM: busca en Wazuh los eventos de ese host en el minuto en que lanzaste la prueba, y fíjate en si algo quedó marcado como alerta o solo registrado. Después el IDS: la mayoría de técnicas de descubrimiento son locales y no producirán nada en Suricata, y darse cuenta de ese silencio es en sí mismo la lección. La detección de red y la de host ven cosas distintas, que es precisamente por lo que mereció la pena construir el Lab 04 y el Lab 05 por separado.
Apunta tres columnas por cada atomic que ejecutes: el identificador de la técnica, si el evento en bruto se recogió, y si alguna regla alertó realmente sobre él. Son tres estados distintos, y confundir los dos últimos es el error más común de quien evalúa su propia cobertura. Un evento guardado en el índice que no coincide con nada no va a despertar a nadie a las tres de la madrugada.
Cuando no salta absolutamente nada
Tarde o temprano ejecutarás una prueba, irás al SIEM y no encontrarás nada. Resiste la tentación de tratarlo como un laboratorio roto. Es el resultado más útil que produce el ejercicio, y casi siempre tiene la misma causa: el dato no se estaba recogiendo desde el principio.
Revisa esa dirección antes de tocar ninguna regla. ¿Se está registrando la creación de procesos con su línea de comandos en el objetivo? ¿Está activo el registro de bloques de script de PowerShell? ¿El agente reenvía ese canal al gestor, o lo filtra? La ingeniería de detección del mundo real dedica muchísimo más tiempo a los huecos de recolección que a la lógica ingeniosa de las reglas, y aquí es donde ves por qué.
Solo cuando estés seguro de que el evento llega tiene sentido preguntarse por qué nada coincidió con él. En ese punto estás escribiendo o afinando una regla contra un log que puedes ver de verdad, que es un sitio mucho mejor para empezar que adivinando.
Dónde deja esto a la serie
Con seis laboratorios, el entorno ya no está solo construido: está medido. Sabes qué técnicas nota tu montaje, cuáles registra sin reaccionar y cuáles lo atraviesan enteras. Esa lista corta vale más que cualquier panel, porque es específica del laboratorio que tú tienes y la has producido tú.
Es además la versión honesta de la pregunta que todo el mundo hace sobre las herramientas de seguridad. No si están instaladas, sino qué se ha demostrado que cazan.
Preguntas frecuentes
¿Qué es Atomic Red Team?
¿Es peligroso ejecutar Atomic Red Team en mi propio laboratorio?
¿Por qué mi SIEM no alertó al ejecutar un atomic?
¿Esto es red team o blue team?
Daniel A. y Óscar S. llevan Breachfolio, un sitio independiente y pequeño sobre seguridad e IA. Este artículo se redactó con ayuda de IA y lo revisó una persona antes de publicarlo. Escribimos a partir de documentación, fuentes de fabricantes e investigación publicada, no de pruebas de laboratorio propias, y enlazamos la fuente en la frase que se apoya en ella. Cómo trabajamos · Sobre nosotros