Validar detecciones: Atomic Red Team y purple teaming

El panel de reglas activas de un SIEM engaña con facilidad: una fila en verde, un icono de «habilitada», una fecha de última modificación de la semana pasada. Nada de eso dice si esa regla dispararía ante el comportamiento real que dice cubrir. Lo único que lo dice es haberla probado, con la técnica de verdad, en un sistema de verdad, mirando qué llegó al SIEM y si la regla lo recogió.

El módulo 1 de este curso ya nombró la prueba como el cuarto paso del ciclo de vida de una detección. Este módulo es ese paso entero: cómo elegir qué probar, cómo probarlo sin dejar la máquina en un estado raro, qué mirar cuando el test termina y qué hacer cuando el resultado no es el esperado, que es lo que pasa la mayoría de las veces.

Qué aprenderás

Por qué una regla sin probar es una hipótesis, aunque el panel la muestre en verde.
El ciclo de validación completo: elegir la técnica, ejecutarla de forma controlada, mirar la telemetría cruda, comprobar el observable, ajustar y reejecutar.
Cómo está organizado el repositorio de Atomic Red Team y cómo se lee el YAML de un test atómico: nombre, descripción, plataformas, dependencias, executor y cleanup.
A ejecutar tests con Invoke-AtomicTest, comprobar sus prerrequisitos y por qué el bloque de limpieza nunca es un extra opcional.
Qué aporta Caldera frente a un test atómico suelto y cuándo compensa el trabajo de montarlo.
A usar Hayabusa para pasar un lote de ficheros EVTX por un conjunto de reglas Sigma y sacar una línea de tiempo.
A documentar un ejercicio de validación con una matriz que sirva de entregable real, no de justificante.
Qué es (y qué no es) un purple team, y con qué frecuencia hay que repetir todo este trabajo.

La pregunta que nadie hace

Una regla Sigma bien escrita, con la sintaxis correcta, apuntando al logsource adecuado y con un nombre descriptivo, sigue siendo, hasta que se prueba, una afirmación sin comprobar: «creo que esta condición aparece cuando ocurre esta técnica, y creo que mi tubería de telemetría la trae hasta aquí». Las dos partes de esa frase pueden fallar. La condición puede estar mal escrita (un campo con el nombre que no es, un operador que no hace lo que el autor pensaba). O la condición puede estar perfecta y el campo que necesita simplemente no llega nunca al SIEM, porque nadie activó esa categoría de auditoría, o el agente la descarta, o el parser la deja fuera al normalizar.

Nadie se pregunta esto en el día a día porque preguntarlo cuesta tiempo, y porque el SIEM no ofrece ningún indicador de «esta regla, probada de verdad, funciona». Ofrece un estado (habilitada o deshabilitada) y, con suerte, un contador de coincidencias históricas. Ese contador mide cuántas veces disparó, no si debería haber disparado más veces y no lo hizo. A mí me ha pasado más de una vez dar por buena una detección solo porque el YAML parecía razonable, sin haberla visto saltar jamás contra el comportamiento real que decía cubrir. Cuando por fin la probé, fallaba por un detalle tonto: un valor de campo con mayúsculas distintas a las que esperaba el backend de conversión.

El ciclo de validación

Validar una detección es un ciclo corto y se repite igual cada vez, tanto si es la primera prueba de una regla recién escrita como si es la enésima repetición tras un cambio de versión del agente:

Elegir la técnica ATT&CK que la regla dice cubrir, y con ella el test atómico concreto que la reproduce.
Ejecutar ese test de forma controlada, en una máquina de laboratorio, con permiso y con una instantánea previa.
Mirar la telemetría cruda, es decir el evento tal como llega al SIEM, antes de pasar por ninguna regla. No la alerta: el log.
Comprobar si el observable que la regla busca está presente en ese log (el campo, el valor, la combinación de ambos).
Si está y la regla no disparó, corregir la regla. Si no está, corregir la telemetría (la política de auditoría, la configuración de Sysmon, el parser, la ruta de transporte).
Reejecutar el test entero después de cualquier cambio, no solo revisar el cambio sobre el papel.

El paso que más se salta es el tercero, y es el que sostiene todo lo demás. Es tentador mirar directamente si la alerta apareció en la cola de casos, porque es la señal visible y la que le importa al analista de guardia. Pero si la alerta no aparece, esa comprobación por sí sola no dice por qué: puede ser la regla, puede ser la telemetría, puede ser el pipeline de normalización entre las dos. Mirar el evento crudo primero, y solo después la regla contra ese evento, es lo que separa un diagnóstico real de una conjetura. Si el observable no está en el log crudo, el problema es de telemetría, no de la regla: ninguna reescritura de la condición Sigma va a hacer aparecer un campo que el origen nunca mandó.

Un ejemplo completo: de la técnica a la regla que debería dispararse

Conviene fijar un ejemplo real y seguirlo hasta el final, porque el ciclo de arriba suena abstracto hasta que se ve encadenado. La técnica elegida es T1136.001, Create Account: Local Account (táctica Persistence en ATT&CK v19; si el formato «técnica punto subtécnica» no te resulta familiar todavía, la guía de MITRE ATT&CK del blog lo explica desde cero), y el test es el de «Create a new user in PowerShell» del propio repositorio de Atomic Red Team, GUID bc8be0ac-475c-4fbf-9b1d-9fffd77afbde.

La telemetría esperada, según la documentación de Microsoft sobre esta misma familia de eventos citada en el módulo 3 de este curso, es el Event ID 4720 («A user account was created») de la subcategoría User Account Management del canal Security. Y hay una regla Sigma real, publicada en el repositorio central de SigmaHQ, que apunta exactamente a esa combinación:

title: Local User Creation
id: 66b6be3d-55d0-4f47-9855-d69df21740ea
status: test
description: |
    Detects local user creation on Windows servers, which shouldn't happen in an Active Directory environment. Apply this Sigma Use Case on your Windows server logs and not on your DC logs.
references:
    - https://patrick-bareiss.com/detecting-local-user-creation-in-ad-with-sigma/
author: Patrick Bareiss
date: 2019-04-18
modified: 2021-01-17
tags:
    - attack.persistence
    - attack.t1136.001
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4720
    condition: selection
falsepositives:
    - Domain Controller Logs
    - Local accounts managed by privileged account management tools
level: low

(Regla «Local User Creation», autor Patrick Bareiss, SigmaHQ, win_security_user_creation.yml, licencia DRL 1.1, atribución obligatoria a Bareiss como autor de la regla si la reutilizas.)

Con esas tres piezas alineadas (técnica, test, regla), el ejercicio deja de ser teórico: se ejecuta el test, se abre el visor de eventos o el SIEM y se busca el 4720 correspondiente a la cuenta de prueba, y se comprueba si la condición EventID: 4720 convertida al lenguaje de tu SIEM habría disparado sobre ese evento concreto. El resto de este módulo trabaja sobre este mismo hilo: cómo se ejecuta ese test con la herramienta adecuada, qué hacer si en vez de uno hay que ejecutar veinte a la vez, y cómo se documenta lo que se ha visto.

Atomic Red Team: cómo se lee un test atómico

La estructura del repositorio

El repositorio de Atomic Red Team, mantenido por Red Canary bajo licencia MIT, organiza sus pruebas en una carpeta atomics/ con un subdirectorio por cada técnica de ATT&CK. Dentro de cada uno hay, según la propia guía de inicio del proyecto, un fichero YAML con la definición de los tests, un Markdown legible generado a partir de ese YAML, y de forma opcional una carpeta src para dependencias de código fuente y otra bin para binarios que algún test necesite descargar. El badge del propio README marca 1.817 tests atómicos a fecha de esta consulta (27 de julio de 2026); esa cifra sube con cada aportación de la comunidad, así que no conviene tratarla como un número fijo.

El proyecto mantiene también índices completos por plataforma (Windows, Linux, macOS) en atomics/Indexes/, útiles para no tener que recorrer la carpeta entera cuando se busca qué tests existen para una técnica o una familia de técnicas.

Anatomía de un test atómico

El esquema oficial de cada test (documentado en la wiki del proyecto) exige, como mínimo, un name, una description, una lista supported_platforms y un bloque executor. De forma opcional puede traer input_arguments (variables sustituibles con la sintaxis #{variable}), dependencies (con su propio description, prereq_command y get_prereq_command) y un auto_generated_guid que identifica el test de forma estable aunque cambie su número de orden dentro del fichero. Este es el test que ya vimos arriba, copiado de su fuente real:

- name: Create a new user in PowerShell
  auto_generated_guid: bc8be0ac-475c-4fbf-9b1d-9fffd77afbde
  description: |
    Creates a new user in PowerShell. Upon execution, details about the new account will be displayed in the powershell session. To verify the
    new account, run "net user" in powershell or CMD and observe that there is a new user named "T1136.001_PowerShell"
  supported_platforms:
  - windows
  input_arguments:
    username:
      description: Username of the user to create
      type: string
      default: T1136.001_PowerShell
  executor:
    command: |
      New-LocalUser -Name "#{username}" -NoPassword
    cleanup_command: |
      Remove-LocalUser -Name "#{username}" -ErrorAction Ignore
    name: powershell
    elevation_required: true

(Atomic Red Team, T1136.001.yaml, licencia MIT.)

Todo lo que necesitas para leer este bloque está en él: el executor es powershell, la orden crea un usuario local sin contraseña con New-LocalUser, requiere elevación (elevation_required: true, hay que lanzarlo desde una PowerShell con privilegios de administrador) y trae su propio cleanup_command con Remove-LocalUser para deshacer exactamente lo que el test creó.

Ejecutar, comprobar prerrequisitos y limpiar

La forma habitual de correr un test así no es copiar el comando a mano, sino usar el módulo de PowerShell Invoke-AtomicRedTeam (instalación cubierta en el módulo 1). Antes de ejecutar nada conviene comprobar los prerrequisitos, y solo después lanzar el test:

Invoke-AtomicTest T1136.001 -TestNumbers 1 -CheckPrereqs
Invoke-AtomicTest T1136.001 -TestNumbers 1
Invoke-AtomicTest T1136.001 -TestNumbers 1 -Cleanup

La primera línea comprueba si el sistema cumple lo que el test necesita (en este caso, prácticamente nada salvo PowerShell y privilegios de administrador); si el resultado incluyera algo como «Elevation required but not provided», tocaría relanzar la consola como administrador. La segunda ejecuta el test. La tercera, con el modificador -Cleanup, corre el cleanup_command del test para deshacer el cambio, exactamente el Remove-LocalUser que vimos en el YAML.

El bloque de limpieza que no es opcional

No todos los tests son tan amables como el de arriba. Este es un test real, sin recortar, para la técnica T1490, Inhibit System Recovery (táctica Impact):

- name: Windows - Delete Volume Shadow Copies
  auto_generated_guid: 43819286-91a9-4369-90ed-d31fb4da2c01
  description: |
    Deletes Windows Volume Shadow Copies. This technique is used by numerous ransomware families and APT malware such as Olympic Destroyer.
  supported_platforms:
  - windows
  dependency_executor_name: powershell
  dependencies:
  - description: |
      Create volume shadow copy of C: . This prereq command only works on Windows Server or Windows 8.
    prereq_command: |
      if(!(vssadmin.exe list shadows | findstr "No items found that satisfy the query.")) { exit 0 } else { exit 1 }
    get_prereq_command: |
      vssadmin.exe create shadow /for=c:
  executor:
    command: |
      vssadmin.exe delete shadows /all /quiet
    name: command_prompt
    elevation_required: true

(Atomic Red Team, T1490.yaml, licencia MIT.)

Fíjate en lo que falta: no hay cleanup_command. El bloque dependencies crea una instantánea de volumen antes de ejecutar el test (para tener algo que borrar y comprobar que el borrado funciona), pero nada en el test devuelve esas instantáneas si ya existían otras previas, importantes, en ese mismo disco. Ejecutar este test contra una máquina que no sea desechable es jugar con el propio mecanismo de recuperación del sistema, exactamente lo que la técnica describe atacar. Este es el motivo real, no una advertencia genérica, de por qué el bloque de limpieza importa: cuando existe, permite repetir el ciclo de prueba sin acumular basura ni riesgo; cuando no existe, como aquí, la única red de seguridad es la instantánea de la máquina virtual tomada antes de empezar, y restaurarla a mano es la única forma sensata de «limpiar» después de este test en concreto.

Reglas de seguridad del laboratorio

Ejecuta los tests solo en máquinas de laboratorio propias y aisladas de la red de producción, nunca en un endpoint real «solo por esta vez».
Toma una instantánea de la máquina virtual antes de cada sesión de pruebas, no solo antes del primer test del día.
Ejecuta el cleanup_command de cada test inmediatamente después de comprobar el resultado, y verifica que de verdad revirtió el cambio (no todos los cleanups son perfectos).
Lee la descripción completa del test antes de lanzarlo. Algunos, como el de arriba, no tienen limpieza automática porque lo que hacen no es trivialmente reversible.
Si un test no trae limpieza y no puedes verificar a mano que revirtió el cambio, restaura la instantánea en vez de dar el sistema por limpio.

Caldera: cuando un test suelto se queda corto

Qué es y en qué estado está

Un test atómico ejecutado a mano cubre una técnica en un host. Caldera es otra cosa: una plataforma de automatización de emulación de adversarios, con un servidor de mando y control asíncrono, agentes que se despliegan en los sistemas objetivo y una interfaz web para orquestar todo. El proyecto nació en MITRE y, desde el 20 de mayo de 2026, según el propio comunicado de MITRE, su núcleo de código abierto se donó a la Apache Software Foundation: hoy vive como «Apache Caldera (incubating)», en incubación bajo el Apache Incubator PMC, con el repositorio movido de mitre/caldera a github.com/apache/caldera y licencia Apache-2.0. MITRE sigue implicado en el desarrollo; lo que cambia es el modelo de gobernanza, ahora el habitual de un proyecto Apache.

Habilidad, adversario y operación

El modelo de datos de Caldera tiene tres piezas, documentadas en su guía de uso básico. Una ability (habilidad) es la unidad mínima: un identificador único, un nombre, una descripción, la técnica y táctica de ATT&CK a la que corresponde, y un comando por plataforma soportada. Este es un ejemplo real de la propia documentación:

- id: 9a30740d-3aa8-4c23-8efa-d51215e8a5b9
  name: Scan WIFI networks
  description: View all potential WIFI networks on host
  tactic: discovery
  technique:
    attack_id: T1016
    name: System Network Configuration Discovery
  platforms:
    windows:
      psh:
        command: |
          .wifi.ps1 -Scan
        payload: wifi.ps1

Un adversary (adversario) no ejecuta nada por sí mismo: es, literalmente y según la propia documentación, «un objetivo opcional y una lista de habilidades bajo atomic_ordering«, ese orden determina en qué secuencia se lanzan. Y una operation (operación) es la ejecución concreta de un adversario contra un grupo de agentes, con el planificador por defecto (llamado atomic) enviando las habilidades una a una según ese orden. La diferencia con un test suelto está ahí: Caldera encadena varias habilidades contra varios agentes a la vez, con registro centralizado de qué se ejecutó, dónde y con qué resultado.

La conexión con Atomic Red Team

Caldera no sustituye a Atomic Red Team, lo puede envolver: entre los plugins que mantiene el propio equipo del proyecto está Atomic, que importa las TTP del propio repositorio de Atomic Red Team como habilidades ejecutables desde Caldera. El agente por defecto se llama Sandcat.

Cuándo compensa montarlo

Para probar una regla contra una técnica en un solo host, Invoke-AtomicTest hace el trabajo entero en un minuto, sin instalar ningún servidor. Caldera empieza a compensar cuando el ejercicio necesita varios agentes a la vez (comprobar si la detección funciona igual en un servidor y en un puesto de usuario, por ejemplo), cuando se quiere repetir una secuencia completa de técnicas encadenada como la haría un adversario real, o cuando se necesita el historial de operaciones anteriores para comparar ejecuciones en el tiempo sin reconstruirlo a mano. Para eso último existe incluso un plugin propio, Debrief, descrito por el propio proyecto como el plugin para «reunir información y analítica de campaña de un conjunto de operaciones», que convierte el historial de operaciones ejecutadas en un informe consultable en vez de en una lista de logs sueltos. Para una validación puntual de tres o cuatro reglas, todo esto es más peso del que hace falta: monta Caldera cuando el volumen de pruebas o de agentes lo justifique, no como paso previo obligatorio a ejecutar un solo test.

Triaje masivo con Hayabusa

Cuando el ejercicio de validación no es un test suelto sino un lote entero (varios EVTX de varias máquinas, generados a lo largo de una sesión de pruebas), revisarlos uno a uno en el Visor de eventos deja de ser práctico. Hayabusa, de Yamato Security, es una herramienta en Rust que hace justo eso: procesa un directorio entero de ficheros EVTX contra un conjunto de reglas Sigma y saca una línea de tiempo consolidada. La propia documentación del proyecto la describe como la única herramienta de código abierto con soporte completo de Sigma, incluidas las reglas de correlación de la versión 2. La herramienta se publica bajo licencia AGPL-3.0; las reglas Sigma que trae empaquetadas de serie, bajo DRL 1.1, la misma licencia con atribución al autor que vimos antes con la regla de creación de usuario.

Sobre nuestro mismo ejemplo: si has generado un EVTX del canal Security con el evento 4720 del test de T1136.001, y guardas la regla win_security_user_creation.yml de SigmaHQ en una carpeta local, la orden es:

hayabusa.exe csv-timeline -d .lab-evtx -r win_security_user_creation.yml -o triage.csv -w

-d apunta al directorio con los EVTX, -r acepta tanto un directorio de reglas como, como aquí, un fichero suelto, -o escribe la salida en CSV. Hayabusa también admite JSON y JSONL como formato de salida con el comando equivalente json-timeline. El modificador -w (sin asistente) importa en este caso concreto: por defecto Hayabusa lanza un asistente que carga un perfil de reglas llamado «core» (estado test o stable y nivel high o critical), y la regla de creación de usuario tiene level: low, así que ese perfil por defecto la dejaría fuera. Sin el asistente, Hayabusa carga todo lo que encuentre en la ruta indicada por -r, sea cual sea su nivel.

Para mantener el conjunto de reglas que trae Hayabusa al día (no la que has guardado tú a mano, sino la carpeta rules/ por defecto del proyecto):

hayabusa.exe update-rules

Esto sincroniza contra el repositorio hayabusa-rules, que trae Sigma curado y adaptado específicamente para esta herramienta. El propio proyecto aclara algo que conviene tener presente: Hayabusa sabe interpretar reglas Sigma «de fuente», como la de SigmaHQ que usamos arriba, pero las que empaqueta en su propio repositorio llevan una conversión adicional pensada para acelerar la carga y reducir falsos positivos, así que no son sustitutas exactas la una de la otra.

La matriz de validación: el entregable real

Un ejercicio de validación sin registro escrito no deja nada detrás salvo un recuerdo impreciso de si algo funcionó. La forma más simple de documentarlo que de verdad sirve para algo (para justificar una detección ante un auditor, para retomar el trabajo meses después, para no repetir dos veces la misma prueba) es una matriz con una fila por técnica probada:

Técnica ATT&CK	Test ejecutado	Telemetría esperada	¿Observada?	Regla existente	Resultado	Acción tomada
T1136.001, Create Account: Local Account	«Create a new user in PowerShell», GUID bc8be0ac…	Security, Event ID 4720	(verifica en tu entorno)	«Local User Creation», id 66b6be3d… (SigmaHQ)	(verifica en tu entorno)	(verifica en tu entorno)

La primera fila está resuelta hasta donde este módulo puede resolverla sin acceso a tu laboratorio concreto: qué técnica, qué test, qué evento tendría que aparecer y qué regla existe para consultarlo. Las columnas de observación, resultado y acción son tuyas, porque dependen de tu entorno, de tu política de auditoría y de cómo llega ese log hasta tu SIEM, y ninguna de esas tres cosas se puede dar por sentada desde fuera. Las dos filas en blanco son para las dos técnicas adicionales del ejercicio final.

La columna «Resultado» no tiene que ser binaria. Puede valer «disparó como se esperaba», «el evento llegó pero la regla no disparó» (fallo de regla) o «el evento nunca llegó» (fallo de telemetría), que son diagnósticos distintos con acciones distintas: reescribir la condición en el primer caso, activar la categoría de auditoría o revisar el parser en el segundo.

La regla de honestidad de este curso

En ningún punto de este módulo, ni de este curso, se afirma que una herramienta o un producto comercial «detecta» una técnica. Tampoco se dan porcentajes de tasa de detección ni de falsos positivos. No es una cuestión de estilo: cualquier cifra de ese tipo depende por completo de cómo tengas configurada la telemetría, qué versión del agente uses, qué reglas hayas ajustado y qué ruido normal genera tu propio entorno. Una cifra publicada en un laboratorio ajeno, con su propia política de auditoría y su propio conjunto de aplicaciones instaladas, no traslada a tu SIEM sin comprobarlo. Lo único honesto que se puede decir sobre si una detección funciona es «la probé en mi entorno, en esta fecha, y esto fue lo que vi», que es exactamente lo que registra la matriz de arriba.

Qué es (y qué no es) un purple team

Purple team no es un tercer equipo que se contrata aparte del red team y el blue team. Es una forma de trabajar: red y blue colaborando de forma explícita, con el resultado de cada ataque simulado compartido en el momento con quien defiende, en vez de guardado para un informe final que llega semanas después. Todo lo de este módulo (ejecutar una técnica de forma controlada y mirar de inmediato qué vio el SIEM) es, en la práctica, un ejercicio de purple team a pequeña escala, aunque lo hagas tú solo contra tu propio laboratorio. La explicación completa de qué distingue a red, blue y purple team, con sus roles y sus objetivos, está en esta guía del blog; no hace falta repetirla aquí.

Con qué frecuencia hay que validar

Validar una vez, cuando se escribe la regla, y no volver a tocarla nunca más, es casi tan malo como no validarla. Los agentes se actualizan y a veces cambian el nombre de un campo. El SIEM cambia de versión y a veces cambia cómo normaliza un tipo de evento. Un cambio en la política de grupo puede desactivar sin querer una categoría de auditoría que llevaba meses activa. Ninguno de esos cambios avisa: la regla sigue en verde en el panel, pero puede llevar semanas sin telemetría real que consultar.

La frecuencia razonable no es «una vez al año» ni «cuando alguien se acuerde». Es: tras cada cambio de versión del SIEM o del agente de recolección, tras cualquier cambio en la política de auditoría o en la configuración de Sysmon, y de forma periódica sobre el conjunto completo de reglas críticas (mensual es razonable para un equipo pequeño, más frecuente si el volumen de cambios en la infraestructura lo justifica). El módulo 15 de este curso cubre cómo automatizar parte de esta repetición dentro de un pipeline de detection-as-code; aquí basta con dejar claro que sin esta disciplina, ese pipeline solo automatiza la ilusión de cobertura, no la cobertura real.

Ejercicio de laboratorio

Necesitas una máquina Windows de laboratorio, aislada, con una instantánea reciente, con Sysmon o auditoría avanzada activa (módulos 3 y 4 de este curso) y con Invoke-AtomicRedTeam instalado (módulo 1). El objetivo es ejecutar tres tests atómicos completos y documentar el resultado real de cada uno.

Ejecuta el test de T1136.001 que hemos seguido en este módulo (Invoke-AtomicTest T1136.001 -TestNumbers 1). Comprueba en el Visor de eventos o en tu SIEM si aparece el Event ID 4720 correspondiente, y si la condición de la regla «Local User Creation» lo habría capturado. Ejecuta después la limpieza.
Elige un segundo test de una técnica distinta que ya hayas trabajado en los módulos 9 o 10 de este curso (por ejemplo, alguno de los de LOLBAS con padre anómalo o de acceso a LSASS). Repite el mismo proceso: ejecutar, mirar la telemetría cruda, comprobar el observable, limpiar.
Elige un tercer test de tu elección, de una técnica que no hayas visto todavía en este curso. Antes de ejecutarlo, lee su YAML entero: plataformas soportadas, dependencias y, sobre todo, si trae cleanup_command o no. Si no lo trae, decide de antemano cómo vas a revertir el cambio (a mano o restaurando la instantánea) antes de lanzarlo.
Exporta los tres EVTX generados (por ejemplo con wevtutil epl Security C:labsecurity.evtx) y pásalos por Hayabusa con las reglas que correspondan a cada técnica, usando csv-timeline como en el ejemplo de este módulo.
Rellena la matriz de validación completa, con las tres filas, incluidas las columnas de observación, resultado y acción.
Para cualquier fila donde el resultado no haya sido «disparó como se esperaba», corrige lo que corresponda (la regla o la telemetría, según lo que hayas diagnosticado) y reejecuta el ciclo completo sobre esa técnica hasta que la fila quede resuelta.

Preguntas frecuentes

¿Necesito Caldera si ya tengo Atomic Red Team funcionando bien?

Para validar reglas una a una, no. Caldera aporta valor cuando el ejercicio necesita coordinar varios agentes a la vez o encadenar una secuencia larga de técnicas con registro centralizado, no para probar una detección suelta contra un host de laboratorio.

¿Qué hago si un test atómico no genera ningún evento en absoluto?

Comprueba primero que el test se ejecutó de verdad (algunos requieren elevación y fallan en silencio sin ella, otros tienen prerrequisitos que no se cumplieron). Si el test corrió pero no hay ningún evento relacionado en ningún log, el problema es de auditoría o de recolección, no de la regla Sigma: revisa los módulos 3, 4 y 5 de este curso según el origen que corresponda.

¿Puedo ejecutar un test atómico en un endpoint de producción «solo por esta vez»?

No. Los tests están pensados para dejar huella deliberada en el sistema (esa es exactamente su función), y algunos, como el de borrado de instantáneas de volumen que hemos visto en este módulo, no tienen limpieza automática. Ejecuta siempre en una máquina de laboratorio aislada y desechable.

¿Hayabusa sustituye a mi SIEM?

No, cubre un caso de uso distinto: el triaje puntual de un lote de EVTX ya recogido, normalmente fuera del flujo en vivo del SIEM. Para detección continua sigue haciendo falta la tubería completa de recolección y normalización que cubren los módulos 5 y 6.

¿Con qué frecuencia hay que rellenar la matriz de validación completa, no solo tras un cambio puntual?

No hay una cifra universal, pero repetirla sobre el conjunto de reglas críticas al menos una vez al mes es razonable para un equipo pequeño. Lo que sí es obligatorio, no opcional, es repetirla tras cualquier cambio de versión del SIEM o del agente de recolección, como se explica en la sección de frecuencia de este módulo.

¿Y si una regla lleva meses sin disparar en producción, eso significa que está rota?

No necesariamente: puede significar que la técnica simplemente no ha ocurrido en tu entorno, que es la situación deseable. La única forma de distinguir «no ha ocurrido» de «no la detectaría si ocurriera» es exactamente el ciclo de este módulo: provocarla tú mismo, de forma controlada, y comprobarlo.

¿Ejecutar tests atómicos es lo mismo que hacer una prueba de penetración?

No. Un test atómico reproduce un comportamiento puntual y conocido, sin buscar ninguna vulnerabilidad nueva ni encadenar una intrusión completa desde fuera hacia dentro; su objetivo es generar telemetría para comprobar una regla, no comprometer un sistema. Explotar vulnerabilidades, moverse por una red simulando una intrusión real de principio a fin o evaluar aplicaciones web pertenece al terreno del curso de Hacking Web de este mismo centro, no a este módulo.

Módulo 14: Validación y purple teaming