Saltar al contenido
Breachfolio
Lab 06 – averigua si tu laboratorio detecta algo de verdad.
LAB · SERIE

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.

9 min de lecturaDaniel A. y Óscar S.

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écnicaQué 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.

Legalidad y alcance. Cada técnica de esta serie se ejecuta contra máquinas que tú construiste, dentro de un laboratorio privado que tú controlas. Atomic Red Team hace cambios reales en el host donde se ejecuta, así que haz antes una instantánea de la máquina virtual y ejecuta después el paso de limpieza. Lanzar estas pruebas contra sistemas, sitios o redes que no te pertenezcan –o para los que no tengas autorización explícita por escrito para probar– es ilegal en la mayoría de las jurisdicciones. El laboratorio existe precisamente para que nunca tengas que hacerlo.

Preguntas frecuentes

¿Qué es Atomic Red Team?
Atomic Red Team es una biblioteca libre y de código abierto de simulaciones de ataque pequeñas, mantenida por Red Canary. Cada prueba, llamada atomic, reproduce una única técnica de la matriz MITRE ATT&CK en unos pocos comandos, y se publica junto con los pasos exactos que ejecuta y una rutina de limpieza que los deshace. Existe para que quien defiende pueda comprobar si sus herramientas se enteran de una técnica, en lugar de darlo por supuesto.
¿Es peligroso ejecutar Atomic Red Team en mi propio laboratorio?
Los atomics son deliberadamente pequeños y están documentados, y la mayoría incluye un comando de limpieza, pero hacen cambios reales: crean usuarios, escriben tareas programadas, dejan ficheros. Ejecútalos solo en una máquina virtual de laboratorio que sea tuya, haz una instantánea antes de empezar y lee siempre la prueba con -ShowDetails antes de lanzarla, para saber qué va a hacer. No los ejecutes en un equipo que te importe.
¿Por qué mi SIEM no alertó al ejecutar un atomic?
Normalmente porque el dato que necesita no se está recogiendo. Una regla solo puede coincidir con un log que llega al SIEM, así que lo primero que hay que revisar es si la fuente relevante, como la creación de procesos con línea de comandos o el registro de bloques de script de PowerShell, está activada en el objetivo y la reenvía el agente. Una ejecución silenciosa es un hallazgo en sí misma: señala un hueco real de cobertura, no un fallo del ejercicio.
¿Esto es red team o blue team?
Ninguno de los dos por separado. Ejecutar una técnica conocida con el propósito concreto de medir si la defensa la ve se suele llamar purple team, porque el objetivo no es ganar sino producir evidencia sobre la cobertura de detección. Atomic Red Team está construido para ese bucle: ya sabes la respuesta a qué ha pasado, así que la única pregunta abierta es si tus herramientas se enteraron.
Quién escribe esto

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