¿Que es Atomic Red Team y en que se diferencia de un pentest?

Atomic Red Team es una biblioteca open source de Red Canary con tests unitarios mapeados a tecnicas MITRE ATT&CK. A diferencia de un pentest, no busca comprometer un sistema sino ejecutar tecnicas aisladas y verificar si tus detecciones las capturan. Es testing de deteccion, no testing de seguridad ofensiva.

¿Como se usa Atomic Red Team para validar reglas Sigma?

El flujo es: escribes una regla Sigma para una tecnica ATT&CK concreta, la conviertes a tu SIEM con sigma-cli, ejecutas el test atomico correspondiente a esa tecnica con Invoke-AtomicTest, y verificas que tu SIEM genera la alerta esperada. Si no la genera, ajustas la regla y repites.

¿Se puede integrar Atomic Red Team en un pipeline CI/CD?

Si. Puedes automatizar la ejecucion de tests atomicos en un entorno aislado (VM o contenedor) como parte de tu pipeline CI/CD. Cada vez que se modifica una regla de deteccion, el pipeline ejecuta los tests atomicos correspondientes, verifica que las alertas se generan en el SIEM y reporta cobertura. Herramientas como chain-reactor y detection-as-code facilitan esta integracion.

IntermedioAtomic Red Teamtestingpurple teamvalidaciónDetection Engineering

Testing de Detecciones con Atomic Red Team: Validar Antes de Confiar

Guia completa para validar reglas de deteccion con Atomic Red Team. Cubre instalacion, ejecucion de tests atomicos por tecnica MITRE ATT&CK, integracion con Sigma rules, matrices de cobertura y automatizacion en pipelines CI/CD para purple teams.

MalwareIntel Research·5 de junio de 2026·14 min lectura

Serie: Detection Engineering — Parte 7

El problema: reglas de deteccion que nunca se prueban

Un equipo SOC despliega 200 reglas Sigma en su SIEM. La pregunta incomoda: ¿cuantas de esas reglas realmente detectan lo que prometen? Sin un mecanismo de validacion, las reglas de deteccion son promesas sin verificar. Un campo mal referenciado, un log source que no emite el evento esperado, un filtro demasiado restrictivo: cualquier error silencioso convierte una regla en codigo muerto que da falsa sensacion de seguridad.

Atomic Red Team resuelve este problema. Es el equivalente a los tests unitarios en desarrollo de software, pero aplicado a detecciones de seguridad. Cada test ejecuta una tecnica adversarial especifica, mapeada a MITRE ATT&CK, y permite verificar que tu SIEM genera la alerta correspondiente.

Este articulo cubre la instalacion, ejecucion de tests, integracion con reglas Sigma, construccion de matrices de cobertura y automatizacion del testing de detecciones en pipelines CI/CD.

Que es Atomic Red Team

Atomic Red Team es un proyecto open source de Red Canary que proporciona una biblioteca de tests ejecutables mapeados a tecnicas del framework MITRE ATT&CK. Cada "test atomico" es una receta reproducible que simula un comportamiento adversarial especifico.

Conceptos clave

Concepto	Descripcion
Atomic test	Test individual que ejecuta una tecnica ATT&CK concreta (ej. T1003.001 LSASS Memory)
Atomics folder	Directorio con YAML que define inputs, ejecutor, comandos y cleanup de cada test
Invoke-AtomicTest	Modulo PowerShell para ejecutar tests en Windows
invoke-atomicredteam	Wrapper que simplifica la ejecucion, logging y cleanup
Test GUID	Identificador unico de cada variante de test dentro de una tecnica

Estructura de un test atomico

Cada test se define en un archivo YAML dentro del directorio de su tecnica ATT&CK:

# atomics/T1003.001/T1003.001.yaml
attack_technique: T1003.001
display_name: "OS Credential Dumping: LSASS Memory"
atomic_tests:
  - name: Dump LSASS.exe Memory using ProcDump
    auto_generated_guid: 0be2230c-9ab3-4ac2-8826-3199b9a0ebf8
    description: |
      Uses ProcDump to create a dump of lsass.exe memory.
      Credential access technique used by many threat actors.
    supported_platforms:
      - windows
    input_arguments:
      output_file:
        description: Path to output dump file
        type: path
        default: C:\Windows\Temp\lsass_dump.dmp
    executor:
      command: |
        procdump.exe -accepteula -ma lsass.exe #{output_file}
      cleanup_command: |
        del /f #{output_file} 2>nul
      name: command_prompt
      elevation_required: true

La estructura es autodescriptiva: plataformas soportadas, argumentos parametrizables, comando de ejecucion y comando de limpieza. Esto permite repetir el test de forma segura y dejar el sistema en estado limpio.

Cobertura ATT&CK

A fecha de 2026, Atomic Red Team cubre mas de 800 tests distribuidos en las 14 tacticas de ATT&CK Enterprise. La cobertura no es uniforme: tacticas como Execution (TA0002), Persistence (TA0003) y Defense Evasion (TA0005) tienen la mayor densidad de tests, mientras que Resource Development (TA0042) tiene menos, ya que sus tecnicas son dificiles de simular en un entorno local.

Instalacion y setup

Windows (PowerShell)

La forma mas directa es instalar el modulo Invoke-AtomicRedTeam desde la PowerShell Gallery:

# Instalar el framework de ejecucion
Install-Module -Name invoke-atomicredteam -Scope CurrentUser -Force

# Descargar la biblioteca de tests atomicos
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
Install-AtomicRedTeam -getAtomics -Force

Tras la instalacion, los tests quedan en C:\AtomicRedTeam\atomics\ organizados por tecnica ATT&CK. El modulo PowerShell proporciona cmdlets para listar, ejecutar y limpiar tests.

Linux/macOS

En sistemas Linux, puedes clonar el repositorio directamente y usar los scripts de shell:

# Clonar la biblioteca de tests
git clone https://github.com/redcanaryco/atomic-red-team.git
cd atomic-red-team/atomics

# Para ejecucion con el runner de Go (alternativa multiplataforma)
go install github.com/redcanaryco/atomic-red-team/execution-frameworks/Invoke-AtomicRedTeam/...@latest

Tambien existe chain-reactor, un runner nativo para Linux desarrollado por Red Canary que ejecuta tests atomicos definidos en YAML sin depender de PowerShell.

Entorno de laboratorio recomendado

Para testing seguro, monta un entorno aislado:

┌─────────────────────────────────────────────────┐
│                 RED NETWORK (aislada)            │
│                                                  │
│  ┌──────────────────┐  ┌──────────────────────┐ │
│  │  Windows 10/11   │  │  Ubuntu 22.04        │ │
│  │  + Sysmon        │  │  + auditd            │ │
│  │  + Atomic RT     │  │  + Atomic RT         │ │
│  │  + Winlogbeat    │  │  + Filebeat          │ │
│  └────────┬─────────┘  └──────────┬───────────┘ │
│           │                       │              │
│           └───────────┬───────────┘              │
│                       ▼                          │
│            ┌─────────────────────┐               │
│            │  SIEM (Elastic /    │               │
│            │  Splunk / Wazuh)    │               │
│            │  + Sigma rules      │               │
│            └─────────────────────┘               │
└─────────────────────────────────────────────────┘

Lo importante es que el host de testing tenga los log sources correctamente configurados (Sysmon en Windows, auditd en Linux) y que los logs lleguen al SIEM donde estan desplegadas las reglas que quieres validar.

Ejecutar tests atomicos

Listar tests disponibles para una tecnica

# Ver todos los tests para T1003 (OS Credential Dumping)
Invoke-AtomicTest T1003 -ShowDetailsBrief

# Ver detalles completos incluyendo comandos
Invoke-AtomicTest T1003 -ShowDetails

Ejecutar un test especifico

# Ejecutar todos los tests de T1003.001 (LSASS Memory)
Invoke-AtomicTest T1003.001

# Ejecutar solo un test por GUID
Invoke-AtomicTest T1003.001 -TestGuids 0be2230c-9ab3-4ac2-8826-3199b9a0ebf8

# Ejecutar con argumentos personalizados
Invoke-AtomicTest T1003.001 -InputArgs @{ output_file = "C:\Temp\test.dmp" }

Verificar prerequisitos antes de ejecutar

# Comprobar si las dependencias del test estan disponibles
Invoke-AtomicTest T1003.001 -CheckPrereqs

# Instalar prerequisitos automaticamente (si es posible)
Invoke-AtomicTest T1003.001 -GetPrereqs

Cleanup despues del test

# Ejecutar los comandos de limpieza definidos en el YAML
Invoke-AtomicTest T1003.001 -Cleanup

Ejecucion en Linux

# Usando el runner nativo
cd atomic-red-team/atomics/T1053.003

# Ejecutar directamente el comando del test
# T1053.003 - Cron (Scheduled Task/Job)
echo "* * * * * /tmp/art-test.sh" | crontab -

# Verificar que auditd captura el evento
ausearch -k cron_modification

# Cleanup
crontab -r

Mapear tests atomicos a reglas Sigma

La potencia real de Atomic Red Team aparece cuando lo conectas con tu pipeline de deteccion. El flujo completo es:

1. IDENTIFICAR  →  Tecnica ATT&CK que quieres detectar
                    (ej. T1003.001 LSASS Memory Dump)

2. ESCRIBIR     →  Regla Sigma que detecte esa tecnica
                    (basada en log source + condiciones)

3. CONVERTIR    →  Sigma rule → query de tu SIEM
                    (sigma-cli convert)

4. DESPLEGAR    →  Cargar la query en el SIEM

5. EJECUTAR     →  Invoke-AtomicTest T1003.001

6. VERIFICAR    →  ¿El SIEM genero la alerta?
                    SI → regla validada ✓
                    NO → investigar por que falla

7. ITERAR       →  Ajustar regla, re-ejecutar test

Ejemplo practico: validar deteccion de LSASS dump

Paso 1: Regla Sigma

title: LSASS Memory Dump via ProcDump
id: 5f0f6d43-9d1a-4e2b-8c7f-3b4e5d6a7f8e
status: test
description: Detects LSASS memory dump using ProcDump
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\procdump.exe'
        CommandLine|contains|all:
            - 'lsass'
            - '-ma'
    condition: selection
falsepositives:
    - Legitimate debugging by IT administrators
level: high
tags:
    - attack.credential_access
    - attack.t1003.001

Paso 2: Convertir a Elastic KQL

sigma convert -t elasticsearch -p ecs_windows \
  rules/credential_access/lsass_procdump.yml

Paso 3: Ejecutar el test atomico

Invoke-AtomicTest T1003.001 -TestGuids 0be2230c-9ab3-4ac2-8826-3199b9a0ebf8

Paso 4: Verificar en el SIEM que la alerta se disparo con el evento esperado. Si no se disparo, las causas mas comunes son:

El log source no esta emitiendo el evento (Sysmon no instalado, o falta la configuracion del EventID correcto)
La regla Sigma referencia un campo que no existe en tu normalizacion
El backend de conversion introduce una transformacion que rompe la logica
Un filtro de exclusion demasiado amplio descarta el evento

Construir una matriz de cobertura

Una vez que tienes tests y reglas, puedes construir una matriz que muestre que tecnicas ATT&CK detectas y cuales no. Esta matriz es el artefacto mas valioso del programa de detection testing.

Estructura de la matriz

┌──────────────┬───────────┬─────────────┬────────────┬──────────┐
│ Tecnica      │ Subtecn.  │ Sigma Rule  │ Test ART   │ Estado   │
├──────────────┼───────────┼─────────────┼────────────┼──────────┤
│ T1003        │ .001      │ lsass_dump  │ 0be2230c   │ ✓ PASS   │
│ T1003        │ .002      │ sam_export  │ a3d2f4e1   │ ✓ PASS   │
│ T1003        │ .003      │ ntds_dit    │ b7c8d9e0   │ ✗ FAIL   │
│ T1003        │ .004      │ (ninguna)   │ c1d2e3f4   │ — GAP    │
│ T1053        │ .005      │ schtask_cr  │ d5e6f7a8   │ ✓ PASS   │
│ T1059        │ .001      │ ps_download │ e9f0a1b2   │ ⚠ FP     │
│ T1490        │ —         │ vss_delete  │ f3a4b5c6   │ ✓ PASS   │
└──────────────┴───────────┴─────────────┴────────────┴──────────┘

Los estados posibles:

Estado	Significado
PASS	El test se ejecuto y la regla genero la alerta correctamente
FAIL	El test se ejecuto pero la regla no detecto la actividad
GAP	Existe test atomico pero no hay regla Sigma para esa tecnica
FP	La regla detecta el test pero tambien genera falsos positivos excesivos
NO TEST	Existe regla Sigma pero no hay test atomico disponible

Generar la matriz automaticamente

El proyecto atomic-threat-coverage automatiza la generacion de matrices que cruzan reglas Sigma del repositorio SigmaHQ con tests de Atomic Red Team, produciendo un informe de cobertura navegable.

Tambien puedes usar ATT&CK Navigator para visualizar la cobertura como un heatmap sobre la matriz ATT&CK, coloreando en verde las tecnicas con deteccion validada y en rojo las que tienen gaps.

Integracion con CI/CD: detection-as-code

El concepto de detection-as-code trata las reglas de deteccion como codigo fuente: versionadas en Git, revisadas en pull requests, y validadas automaticamente antes del despliegue.

Arquitectura del pipeline

┌───────────┐    ┌────────────┐    ┌─────────────┐    ┌──────────┐
│  Git Push │───►│  CI Runner │───►│  Test Stage  │───►│  Deploy  │
│  (Sigma   │    │            │    │              │    │  a SIEM  │
│   rules)  │    │  Lint +    │    │  VM aislada  │    │          │
│           │    │  Convert   │    │  + Atomic RT  │    │          │
└───────────┘    └────────────┘    │  + SIEM temp  │    └──────────┘
                                   │  → Verificar  │
                                   │    alertas     │
                                   └─────────────┘

Pipeline en GitHub Actions (ejemplo)

name: Detection Testing
on:
  push:
    paths:
      - 'rules/**/*.yml'

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validate Sigma syntax
        run: |
          pip install sigma-cli
          sigma check rules/

  test-detections:
    needs: lint
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Atomic Red Team
        shell: powershell
        run: |
          Install-Module invoke-atomicredteam -Force
          IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
          Install-AtomicRedTeam -getAtomics -Force

      - name: Run mapped atomic tests
        shell: powershell
        run: |
          # Parse changed Sigma rules, extract ATT&CK tags
          # Execute corresponding atomic tests
          # Verify alerts in log output
          ./scripts/run-detection-tests.ps1

      - name: Coverage report
        run: |
          python scripts/coverage_report.py \
            --rules-dir rules/ \
            --results-dir test-results/ \
            --output coverage.json

Consideraciones practicas

Entorno aislado: los tests atomicos ejecutan comportamiento real (no simulado). Usa VMs efimeras o contenedores que se destruyen despues de cada run.
Elevacion de privilegios: muchos tests requieren permisos de administrador. Configura el runner con los permisos necesarios pero en red aislada.
Tiempo de ejecucion: ejecutar todos los tests lleva tiempo. En CI, ejecuta solo los tests correspondientes a las reglas modificadas.
Log collection lag: el SIEM puede tardar segundos en indexar los logs. Incluye un delay de verificacion o usa polling hasta que el evento aparezca.

Alternativas y complementos

Atomic Red Team no es la unica herramienta para validar detecciones. Cada una tiene un enfoque diferente:

MITRE Caldera

Framework de emulacion adversarial automatizada. A diferencia de Atomic Red Team (tests individuales), Caldera ejecuta cadenas de ataque completas coordinadas por un agente C2. Es mas realista pero mas complejo de operar.

Atomic Red Team  →  Tests unitarios (tecnica aislada)
Caldera          →  Tests de integracion (cadena completa)

Caldera es ideal cuando ya tienes cobertura basica validada con Atomic Red Team y quieres probar que tus detecciones funcionan en escenarios de ataque multi-fase.

Infection Monkey (Akamai)

Herramienta de Breach and Attack Simulation (BAS) open source que simula un atacante dentro de la red. Se propaga automaticamente buscando vulnerabilidades y tecnicas de movimiento lateral. Es util para validar detecciones de network-level y lateral movement.

DetectionLab

Entorno de laboratorio pre-configurado con Windows AD, Sysmon, Splunk y herramientas de testing. Reduce el tiempo de setup de dias a horas. Ideal para equipos que empiezan un programa de detection testing.

Comparativa rapida

Herramienta	Enfoque	Complejidad	Cobertura ATT&CK	Open Source
Atomic Red Team	Tests unitarios	Baja	800+ tests	Si
Caldera	Emulacion de cadena	Media	200+ abilities	Si
Infection Monkey	BAS automatizado	Media	50+ tecnicas	Si
DetectionLab	Laboratorio	Baja (setup)	N/A (infra)	Si
Stratus Red Team	Cloud (AWS/Azure/GCP)	Baja	60+ tecnicas	Si

Si tu entorno incluye cloud, Stratus Red Team de Datadog cubre tecnicas ATT&CK especificas de AWS, Azure y GCP con el mismo patron de tests atomicos.

Construir un programa de detection testing

Un programa de detection testing maduro no se limita a ejecutar tests puntualmente. Es un proceso continuo integrado en el ciclo de vida de las detecciones.

Nivel 1: testing manual bajo demanda

Un analista ejecuta tests atomicos cuando escribe una regla nueva
Verifica manualmente en el SIEM que la alerta se genera
Documenta el resultado en un spreadsheet
Frecuencia: cuando alguien se acuerda

Nivel 2: testing periodico estructurado

Sprint mensual de purple team donde se ejecutan los tests por tactica
Matriz de cobertura actualizada y revisada en equipo
Tests priorizados por threat intelligence (que familias de malware afectan a tu sector)
Frecuencia: mensual, con informe de gaps

Nivel 3: testing automatizado en CI/CD

Reglas de deteccion versionadas en Git (detection-as-code)
Pipeline CI ejecuta tests atomicos en cada PR que modifica una regla
Coverage gate: no se despliega una regla sin test atomico validado
Dashboard de cobertura ATT&CK actualizado automaticamente
Frecuencia: por cada cambio de regla

Nivel 4: validacion continua en produccion

Tests atomicos ejecutados periodicamente en el entorno de produccion (con cuidado)
Monitorizacion de regresion: detectar cuando una regla deja de funcionar por cambios en la infraestructura
Integracion con threat intelligence: cuando un nuevo informe documenta una tecnica usada contra tu sector, se crea automaticamente el test y la regla
Frecuencia: continua, automatizada

Metricas del programa

Metrica	Formula	Objetivo
Cobertura ATT&CK	tecnicas con regla validada / tecnicas relevantes	> 60%
Tasa de validacion	reglas con test PASS / total reglas	> 80%
Tiempo medio de validacion	tiempo desde nueva regla hasta PASS	< 48h
Regresion rate	reglas que pasaron a FAIL sin cambios	< 5%
Gap closure rate	gaps cerrados por trimestre	creciente

Recursos y referencias

Repositorios esenciales

Atomic Red Team (Red Canary): biblioteca principal de tests atomicos
Invoke-AtomicRedTeam: framework de ejecucion PowerShell
SigmaHQ: repositorio oficial de reglas Sigma
Atomic Threat Coverage: generador de matrices de cobertura
Stratus Red Team: tests atomicos para cloud
Chain Reactor: runner nativo Linux para tests atomicos

Documentacion

ATT&CK Navigator: visualizacion de cobertura
Red Canary Atomic Red Team Wiki: guia oficial
Detection Engineering Weekly: newsletter de la comunidad

Lectura complementaria

Red Canary, "Atomic Red Team: Measuring Security Control Effectiveness"
MITRE, "Getting Started with ATT&CK: Detection and Analytics"
Florian Roth, "How to Write Sigma Rules and Test Them with Atomic Red Team"

Conclusion: no confies, verifica

Una regla de deteccion sin test es una hipotesis sin validar. Atomic Red Team proporciona la herramienta para convertir esas hipotesis en detecciones verificadas, con un coste de implementacion bajo y una integracion directa con el framework ATT&CK que ya estructura tu programa de deteccion.

El camino practico: empieza con las tecnicas que tu threat intelligence prioriza, escribe reglas Sigma, ejecuta los tests atomicos correspondientes, documenta la cobertura. Repite. Automatiza cuando el volumen lo justifique. La matriz de cobertura resultante es el artefacto mas honesto que puede producir un equipo de detection engineering: muestra lo que realmente detectas, no lo que crees detectar.