Automatización de laboratorios de malware en tiempo real y GOAD

Introducción: La necesidad de un rango de simulación escalable y automatizado

En las operaciones de seguridad modernas, la ingeniería de detección ya no es una disciplina de "lo pones y lo olvidas". El reto central para cualquier equipo de seguridad —y la pregunta que sustenta todo el enfoque del equipo morado— es simple: ¿cómo saber si tus reglas de detección realmente funcionan? Validar continuamente la lógica de detección frente a un conjunto de herramientas de adversarios en constante cambio es ahora un requisito fundamental.

Probablemente, el mayor obstáculo para este ejercicio siempre fue montar el laboratorio. Provisionar manualmente un bosque de Active Directory multidominio, configurarlo con vulnerabilidades específicas y desplegar un entorno de análisis de malware separado y contenido es un proceso complejo y que consume mucho tiempo. Este trabajo repetitivo de configuración supone una carga significativa para el recurso más valioso de una organización: el tiempo de sus analistas de seguridad senior. Las discusiones comunitarias reflejan esta frustración, destacando las horas perdidas en la configuración manual antes de poder ejecutar una sola prueba.

Este blog detalla una solución moderna que elimina este cuello de botella combinando la automatización rápida de infraestructuras con una plataforma unificada de análisis de seguridad. La solución aprovecha dos componentes clave:

1. Ludus: Una superposición de automatización de código abierto que despliega y configura ciberataques complejos con múltiples VM abarca desde un solo comando.
2. Elastic Security: La plataforma que unifica la Gestión de Eventos de Información de Seguridad (SIEM), la Detección y Respuesta Extendida (XDR) y la seguridad en la nube, proporcionando una solución consolidada para ingerir, detectar y responder a amenazas. Ofrece la "visibilidad ilimitada" necesaria para observar cada acción dentro del entorno simulado.

El objetivo de esta guía es proporcionar un plan definitivo paso a paso para construir este sistema integrado. Mostrará cómo pasar de pruebas de laboratorio lentas, manuales e inconsistentes a un flujo de trabajo de ingeniería de detección continuo, automatizado y escalable más allá de lo que ofrece Elastic Cortado .

La arquitectura de la solución: Ludus + Elastic

Esta arquitectura representa una simulación de alta fidelidad de una compañía híbrida moderna. La gama Ludus actúa como centro de datos "on-premise" o IaaS, mientras que el despliegue de Elastic Cloud representa la pila de seguridad "SaaS". Este modelo refleja perfectamente los entornos híbridos y multi-nube que Elastic Security está diseñado para proteger, haciendo que la arquitectura de la prueba sea tan valiosa como los propios ataques.

La construcción consta de los siguientes componentes principales.

Componente 1: La Fundación (Ludus)

Ludus actúa como la capa de Infraestructura como Servicio (IaaS). Construido para funcionar en Proxmox 8/9 o Debian 12/13, emplea archivos de configuración YAML para definir redes virtuales complejas, soportando hasta 255 VLANs distintas. Tras bambalinas, Ludus aprovecha fácilmente Packer y Ansible para construir, configurar y desplegar las plantillas de máquinas virtuales a partir de ese único archivo.
Revisa y sigue los pasos de instalación y los requisitos de hardware en el inicio rápido de Luus.

Componente 2: Los objetivos (Los laboratorios)

Esta guía fusiona dos entornos Ludus distintos en un único y completo rango para probar un espectro más amplio de amenazas:

• Juego de Active Directory (GOAD): Un laboratorio de Active Directory diseñado específicamente por investigadores de seguridad de Orange Cyberdefense. Está preconfigurado con las configuraciones erróneas y vulnerabilidades específicas necesarias para simular rutas de ataque comunes basadas en identidad, como el Kerberoasting, NTLM Relay y el abuso de Active Directory Certificate Services (ADCS).
• Laboratorio de Malware XZbot: Un entorno de malware de alto riesgo y alta fidelidad. Este laboratorio contiene la puerta trasera real y funcional CVE-2024-3094. Esto proporciona un caso de prueba perfecto y moderno para un ataque sofisticado a la cadena de suministro de software.

Aviso importante

Manipular malware real, incluso para investigación, puede violar las Políticas de Uso Aceptable (PUA) de los ISP o proveedores de nube. Cerciórate de ser propietario de la infraestructura (Ludus es local) y de que tu proveedor de Internet upstream permita esa investigación o enrutara el tráfico a través de una VPN.

Componente 3: La Red de Sensores (Agente Elástico y Defensa)

Para obtener visibilidad, cada máquina virtual en la gama Ludus tanto en los laboratorios GOAD como XZbot estará instrumentada con Elastic Agent, un agente único y unificado para la recogida y protección de datos (a través de Elastic Defend).

Esta instrumentación está automatizada a través del rol badsectorlabs/ludus_elastic_agent Ansible. Este papel es la pieza clave que conecta programáticamente la fase de provisión de infraestructura (Ludus/Ansible) con la fase de instrumentación de seguridad (Elastic), permitiendo un verdadero flujo de trabajo de "infraestructura como código".

Lo crucial es que la política de Elastic Agent se configurará con la integración de Elastic Defend . Esto eleva al agente de un simple colector de logs a una solución completa de Detección y Respuesta de Endpoint (EDR)/eXtendeD Detection & Response (XDR), proporcionando detecciones basadas en el host (incluyendo malware y detección de ransomware impulsados por Machine Learning (ML)) y la telemetría profunda a nivel de núcleo esencial para la detección.

Nota: Para el enfoque del equipo morado que se describe en este blog, establece las políticas en modo Detectar .

Componente 4: El cerebro (alojado en la nube elástica / Serverless elástico)

Toda la telemetría de seguridad y las alertas de los Agentes Elastic en la gama Ludus se transmiten a un despliegue centralizado Elastic Cloud Hosted (ECH) o Elastic Serverless . Aquí es donde cobra vida el poder analítico de la plataforma unificada. Usar una plataforma nativa en la nube no es solo para alojar; es lo que desbloquea las funciones más avanzadas de Elastic para multiplicar la fuerza, incluyendo el Descubrimiento de Ataques y el AI Assistant. Haz clic aquí para iniciar una prueba en Elastic Cloud.

El diagrama siguiente ofrece una visión general de la construcción, que se basa en el laboratorio GOAD.

Fase 1: Construcción e instrumentación del rango

Esta sección ofrece una guía técnica paso a paso para configurar y desplegar el rango automatizado. El proceso sigue un claro modelo de "infraestructura como código" (IaC), donde la instrumentación de seguridad se define junto con la propia infraestructura, cerciorando una postura de monitorización coherente y repetible para cada despliegue. La instancia de Elastic Cloud y sus configuraciones pueden gestionar con el proveedor Elastic Cloud y Elastic Stack Terraform para un modelo completo IaC del rango y el SIEM.

3.1 Configuración de la Política de Agente Elástico (en Kibana)

Antes de ejecutar el despliegue de rangos de Ludus, la política de agente debe crear en la instancia de Elastic Cloud. Esta política es la que permite la poderosa telemetría EDR/XDR.

El flujo operativo es el siguiente:

1. Inicia sesión en la instancia de Kibana de Elastic Cloud (ECH) o Elastic Serverless.
2. Navega hasta Gestión > Flota.
3. Crea una nueva política de Agente (por ejemplo, "ludus-rango-política"). El rol ludus_elastic_agent inscribe agentes en la política que especifiques en la personalización a nivel de VM o en la política predeterminada vinculada a la variable global.
4. Agrega la integración de Elastic Defend a esta política.
5. Configura la integración de Elastic Defend para que funcione en modo Detect . Esto activa todo el conjunto de telemetrías EDR.
6. Almacena la póliza y haz clic en "Agregar agente". Esto proporcionará el token de inscripción (para ludus_elastic_enrollment_token) y la URL del servidor Fleet (para ludus_elastic_fleet_server) necesarios para el archivo ludus.yml.
7. (Opcional) Repite los pasos 3-6 para crear políticas personalizadas que se alineen con las funciones y capacidades del anfitrión para la personalización de políticas a nivel de VM.

Una vez creada esta política y el token pegado en el archivo ludus.yml, ejecutar el despliegue por rango de Ludus ejecutará el flujo de trabajo completo y automatizado. Ludus provisiona las máquinas virtuales y Ansible instala el Agente Elástico, que luego se inscribe en Fleet y automáticamente desactiva la política que contiene la integración con Elastic Defend. Esto proporciona la rica telemetría EDR —eventos de proceso, archivo, red y registro a nivel de núcleo— desde el momento en que nace el laboratorio.

3.2 La configuración YAML del Ludus (ludus.yml)

Ludus proporciona los pasos para desplegar la gama GOAD aquí. La configuración del rango se almacena en el archivo de configuración ludus.yml. Para el rango GOAD, está ubicado en ad/GOAD/providers/ludus/config.yml.
La configuración completa en el apéndice es un ejemplo basado en una configuración de ejecución de muestra que fusiona un laboratorio GOAD completo (en VLAN 10) con el laboratorio XZbot (en VLAN 20).

Para desplegar una versión personalizada durante la instalación, actualiza el archivo ad/GOAD/providers/ludus/config.yml antes de ejecutar el script goad.sh en el paso 2.

git clone https://github.com/Orange-Cyberdefense/GOAD.git
cd GOAD
sudo apt install python3.11-venv
export LUDUS_API_KEY='myapikey'  # put your Ludus admin api key here nano ad/GOAD/providers/ludus/config.yml # customize the configuration here
./goad.sh -p ludus
GOAD/ludus/local > check
GOAD/ludus/local > set_lab GOAD # GOAD/GOAD-Light/NHA/SCCM
GOAD/ludus/local > install

Se pueden emplear dos opciones clave de configuración para personalizar el rango:

1. Variables globales: Para simplificar la configuración y evitar repeticiones, las variables del Agente Elástico se definen una vez en el nivel superior de un bloque global Ansible.vars y son heredadas por todas las máquinas virtuales.

   El token de inscripción determina la política de Agente Elástico empleada.

# ludus.yml
---
# --- GLOBAL ANSIBLE VARS (Simplification) ---
# Define Elastic agent vars once and apply globally
global_role_vars:
  ludus_elastic_fleet_server: "<your-fleet.example.com:443>" # Use 443 for cloud
  ludus_elastic_enrollment_token: "<your_enrollment_token>"
  ludus_elastic_agent_version: "9.2.1"

2. Variables a nivel VM: Las variables del Agente Elástico pueden configurar a nivel de VM para personalizar la política aplicada. Estos pueden combinar con la variable global, por ejemplo, donde la versión del agente y fleet_server se establecen mediante variables globales, y los tokens de inscripción se establecen a nivel de VM para aplicar diferentes políticas a las VMs.

# --- VM DEFINITIONS ---
vms:
  # --- GOAD LAB (VLAN 10) ---
  - name: "{{ range_id }}-GOAD-DC01"
    hostname: "{{ range_id }}-DC01"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 10
    ram_gb: 4
    cpus: 2
    windows: { sysprep: true }
    ansible:
      roles:
        - badsectorlabs.ludus_elastic_agent
      role_vars:
        ludus_elastic_enrollment_token: "<your_enrollment_token>" # different token for different policies
  # (Definitions for GOAD-DC02, GOAD-DC03, GOAD-SRV02, GOAD-SRV03 
  #  would follow, all inheriting the global ansible vars)

Automatización del despliegue de agentes elásticos

El fragmento ludus.yml anterior demuestra la automatización. Al agregar el rol badsectorlabs.ludus_elastic_agent a la sección ansible.roles de cada definición de VM, Ludus instalará y configurará automáticamente el agente durante el despliegue.

Este único rol de Ansible es compatible con todos los sistemas operativos de nuestro laboratorio heterogéneo, incluyendo Windows (para GOAD), Kali y Debian (para XZbot).

Como se muestra en el YAML simplificado, el bloque ansible.vars en el nivel superior pasa los parámetros críticos al rol:

• ludus_elastic_fleet_server: La URL del servidor de Fleet y el puerto para tu despliegue de Elastic Cloud (por ejemplo, your-fleet.example.com:443).
• ludus_elastic_enrollment_token: El token que inscribe al agente.
  El ejemplo completo establece el ludus_elastic_enrollment_token a nivel de VM para demostrar la capacidad de usar diferentes políticas.
• ludus_elastic_agent_version: La versión específica del agente a instalar (por ejemplo, 9.2.1).

Nota: El host Kali también tendrá Elastic Defend desplegado para monitorizar el comportamiento de los atacantes, esto no será posible en un escenario real.

Seguridad primero: aislamiento, OPSEC y malware en tiempo real

Esta sección contiene una advertencia crítica de seguridad y protección operativa (OPSEC). Esta configuración implica un riesgo significativo y no trivial que debe ser gestionado profesionalmente.

4.1 La amenaza: Esto no es una simulación

Debe decir sin lugar a dudas: La guía de laboratorio del Ludus XZbot y su rol asociado en Ansible instalan la puerta trasera funcional y funcional del CVE-2024-3094. Esto no es un código simulado y benigno. La propia documentación del laboratorio indica: "Peligro: Este rol contiene malware (a propósito)."

Aunque se describe como una "puerta trasera pasiva" (es decir, requiere que un atacante la active activamente), cualquier máquina virtual que ejecute este código con una conexión a Internet abierta es una responsabilidad catastrófica. Podría ser escaneado, explotado por actores desconocidos o empleado como punto de pivote para atacar otras redes.

4.2 La contradicción: aislamiento vs. conectividad en la nube

Esta arquitectura crea un conflicto operativo directo y crítico:

1. 1 requisito (Seguridad): El laboratorio de malware debe estar aislado de la red pública para evitar compromisos o fugas.
2. Requisito 2 (Función): El Agente Elastic debe tener conectividad a Internet saliente para acceder a los endpoints Elastic Cloud Hosted / Elastic Serverless para la inscripción y la transmisión de datos.

Un usuario novato fallaría aquí, ya sea exponiendo su laboratorio infectado al mundo o aislándolo tan completamente que no se pueda obtener telemetría de seguridad.

4.3 La solución: Salida por orificio de ojo de agua mediante el modo de pruebas Ludus

El conflicto se resuelve empleando el modo de "pruebas" integrado en Ludus, que proporciona un control granular sobre la salida de la red. Esta función se emplea para la salida estenopeica, que permite el control del agente, la telemetría y la salida logarítmica.

# 1. Start the isolated testing session
ludus testing start # Note external DNS resolvers may also need to be added # ludus testing allow -i 1.1.1.1,8.8.8.8

# 2. Allow Elastic Fleet Server (Control Plane)
# Replace <id> with your specific deployment ID # Note the endpoint will differ based on the cloud providers
ludus testing allow -d <your-deployment-id>.fleet.us-central1.gcp.cloud.es.io

# 3. Allow Elasticsearch Ingest (Data Plane) # Note the endpoint will differ based on the cloud providers
ludus testing allow -d <your-deployment-id>.es.us-central1.gcp.cloud.es.io

Esta configuración ofrece una solución a nivel experto: el malware está contenido de forma segura, mientras que al Agente Elastic solo se le concede la conectividad mínima necesaria para realizar actualizaciones de políticas (mediante comunicación con el punto final fleet ) y para ingerir datos (mediante comunicación con el punto final ES ).

4.4 Acceso al rango en modo de prueba (WireGuard)

Una vez activado el Modo de Prueba, falla el enrutamiento estándar. No puedes simplemente conectarte por SSH a tu máquina virtual Kali desde tu LAN local porque el router pierde el tráfico. Ludus ofrece un canal de gestión fuera de banda usando WireGuard.

Ludus configura una interfaz WireGuard (wg0) en la máquina virtual del router (198.51.100.1) y te asigna una IP estática del cliente (por ejemplo, 198.51.100.2).

• Reglas de licencia persistente: La configuración del firewall del router incluye reglas específicas en la cadena LUDUS_DEFAULTS. Estas reglas ACEPTAN explícitamente el tráfico procedente o destinado a la subred de WireGuard (198.51.100.0/24).
• Prioridad: Como estas reglas existen en la cadena de LUDUS_DEFAULTS, anulan las reglas DROP aplicadas por el Modo de Prueba.

Cómo conectarse:

1. Genera tu configuración: ludus user wireguard > ludus.conf
2. Importala a tu cliente local de WireGuard y activa el túnel.
3. Conéctate directamente a las IPs privadas de tus máquinas virtuales (por ejemplo, 10.10.10.11) a través del túnel.

Fase 2: Ejecutar los ataques

Con el rango de alta fidelidad y totalmente instrumentado desplegado, puede comenzar la fase del "Equipo Rojo". Esto implica iniciar sesión en una máquina virtual dedicada al atacante (como la VM incluida Kali o una VM remnux-analyzer) y ejecutar los ataques. Esta actividad genera la rica y maliciosa telemetría que Elastic Defend capturará.

Este alcance combinado permite probar defensas contra los dos vectores de amenaza dominantes a nivel macro: ataques basados en identidad "viviendo de la tierra" (LotL) e intrusiones en la cadena de suministro basadas en vulnerabilidades.

5.1 Simulación de Active Directory (GOAD)

• Acceso Inicial (Relleno de Credenciales)
  1. El atacante apunta al perímetro externo. Usando una lista de credenciales vulneradas, ejecutas un ataque de bloqueo de contraseñas contra el dominio Essos.local. Validas con éxito las credenciales del usuario khal.drogo.
  2. Herramienta de ejemplo: kerbrute o smartbrute
  3. Resultado: Credenciales válidas para un usuario de dominio con bajo privilegio.
• Escalada de privilegios (PrintNightmare)
  1. Khal.drogo tiene derechos limitados. Para ganar terreno en el servidor CastelBlack, se aprovecha PrintNightmare (CVE-2021-34527). Esta vulnerabilidad en el servicio Windows Print Spooler permite que cualquier usuario autenticado instale un controlador de impresión malicioso. Subes un controlador que agrega un nuevo usuario administrador local a la máquina.
  2. Herramienta de ejemplo: CVE-2021-34527.py script de exploit
  3. Resultado: Acceso local al SISTEMA en CastelBlack.
• Archivo de credenciales (Preparación de DCSync)
  1. Ahora, ejecutar como SYSTEM/Admin en CastelBlack, inspeccionas la máquina en busca de credenciales en caché. Ejecutas el secretsdump de Impacket para extraer hashes de la base de datos SAM y la memoria LSASS. Descubres el hash NTLM para la cuenta de administrador integrada, que se dejó en memoria de una sesión de soporte anterior.
  2. Herramienta de ejemplo: impacket-secretsdump
  3. Resultado: Hash NTLM de un administrador de dominio o cuenta de alto privilegio.
• Kerberoasting
  1. Con credenciales de dominio válidas, pivotas a la red interna. Aplicar a Kerberos Service Tiquetes (TGS) los Nombres Principales de Servicio (SPNs) en el entorno. Te diriges a la cuenta de MSSQLSvc. Sacas el tiquete cifrado y lo descifras para revelar la contraseña en texto plano de la cuenta del servicio SQL.
  2. Herramienta de ejemplo: Rubeus o GetUserSPNs.py
  3. Resultado: contraseña en texto plano para la cuenta de servicio MSSQL.
• Ataques MSSQL
  1. Usas las credenciales SQL rotas para autenticarte directamente en el SQL Server de Braavos. Como la cuenta de servicio tiene derechos de administrador del sistema, abusas del procedimiento xp_cmdshell almacenado. Esta función te permite generar un shell de comandos de Windows directamente desde una consulta SQL, proporcionándote efectivamente la Ejecución Remota de Código (RCE) en el servidor de base de datos.
  2. Herramienta de ejemplo: mssqlclient.py
  3. Resultado: RCE en el servidor de base de datos.
• Persistencia (Tarea Programada)
  1. Para cerciorarte de no perder el acceso si cambia la contraseña SQL, estableces persistencia. Creas una tarea programada de Windows en el servidor SQL comprometido. Esta tarea está configurada para ejecutar un binario de baliza cada día, ejecutar como SYSTEM.
  2. Herramienta de ejemplo: schtasks.exe o PowerShell
  3. Resultado: persistencia a largo plazo.

5.2 Simulación de laboratorio de malware (XZbot)

• Paso 7: Giro en la cadena de suministro (XZ Backdoor)
• Simultáneamente, apuntas a la infraestructura Linux en la DMZ. Activas la puerta trasera XZ preimplantada (CVE-2024-3094) en la máquina virtual xz-backdoor-dect. Al manipular el handshake SSH con una clave criptográfica específica, se evita completamente la autenticación y se ejecutan comandos como root sin salir de los registros SSH estándar.
• Herramienta: xzbot
• Resultado: acceso root en la infraestructura Linux mediante compromiso de la cadena de suministro.
• El atacante emplea el cliente xzbot proporcionado en el laboratorio de Luus.
• Desde la máquina virtual atacante, se ejecuta el siguiente comando para activar la puerta trasera en el hosts Debian vulnerable:
  xzbot --ssh-addr '10.X.X.X:22' -cmd 'setsid sh -c "prueba de eco"' 2>&1
• Esta acción hace que el proceso sshd en el objetivo genere anómalamente una shell y ejecute el comando como root, creando una prueba definitiva de la ejecución.

Fase 3: Detección e Investigación Unificada con Elastic Security

Esta es la recompensa del "Equipo Azul". La telemetría y las alertas generadas en la Fase 2 ya están disponibles para su análisis dentro de la plataforma unificada Elastic Security.

6.1 El "SIEM Poderoso": Visibilidad Centralizada y Detección Preconstruida

El poder del SIEM elástico no reside solo en su capacidad para recopilar registros de forma pasiva. Su potencia proviene del análisis activo que realiza sobre los datos profundos y contextuales proporcionados por Elastic Defend. La "Visibilidad Completa del Endpoint" de Defend proporciona no solo registros básicos, sino también telemetría a nivel de núcleo: creación de procesos, modificaciones de archivos, conexiones de red y cambios en el registro.

Estos datos ricos, todos estandarizados al Esquema Común Elástico (ECS), alimentan la extensa biblioteca de Elastic de ~1500+ reglas de detección preconstruidas y mapeadas por MITRE. Estas reglas son investigadas, desarrolladas y mantenidas por el equipo de Elastic Security Labs, proporcionando un valor de detección de lista para usar.

La gama Ludus sirve como la plataforma perfecta de validación para este valor. Los ataques ejecutados en la Fase 2 no son teóricos; se asignan directamente a artefactos específicos esperados ("prueba irrefutable"). Una combinación de reglas predefinidas y reglas personalizadas se usa intencionadamente juntas en el ejemplo para alertar sobre comportamientos específicos.

Nota: Las reglas de detección de elásticos son abiertas y transparentes. Puedes ver la lógica, contribuir o plantear problemas directamente en el(https://github.com/elastic/detection-rules).

6.2 Análisis profundo: Rastreo de cadenas de procesos con analizador de eventos

Los dos laboratorios (GOAD y XZbot) ofrecen una oportunidad perfecta para emplear las herramientas especializadas de investigación de Elastic. La interfaz de usuario del Analizador de Eventos está diseñada para abstraer la complejidad de los registros JSON en un modelo cognitivo que se alinea con la forma en que piensan los analistas de seguridad: las cadenas de procesos. La interfaz está compuesta por tres zonas principales de interacción: el Lienzo Gráfico, el Panel de Detalle y la integración con la Línea de Tiempo.

¿Qué estamos viendo?

El lienzo gráfico (El árbol de procesos)

La vista central es un grafo acíclico dirigido donde:

• Nodos (Cubos): Cada cubo representa una ejecución de proceso distinta. La visualización distingue entre el evento "Ancla" (resaltado con un halo azul) y el contexto circundante.
• Aristas (líneas): Las líneas representan la relación padre-hijo. La direccionalidad es implícita (de arriba abajo o izquierda-derecha), mostrando el flujo de ejecución.
• Insignias visuales: Los nodos no son iconos estáticos; Son indicadores dinámicos.
  • Insignias de alerta: Si un proceso específico activaba una regla de detección (por ejemplo, "Malware detectado"), aparecía una insignia de color en el cubo. Esto permite a un analista identificar instantáneamente qué paso de la cadena fue señalado por el motor de detección.
  • Contexto del usuario: Las señales visuales pueden indicar si un proceso cambió el contexto del usuario (por ejemplo, de usuario local a SISTEMA), señalando la escalada de privilegios.

El Panel de Detalle (Metadatos Forenses)

Al hacer clic en cualquier nodo, se activa el Panel de Detalles, que normalmente se desliza desde la derecha. Este panel es la fuente principal de "Lo que puedes ver" a nivel granular. Expone campos críticos para la verificación:

• Argumentos de línea de comandos: Este es, posiblemente, el artefacto forense más valioso. El Analizador muestra la cadena completa, exponiendo banderas, scripts y cargas útiles codificadas (por ejemplo, powershell.exe -w oculto -enc Base64).
• Ruta de proceso y hash: La ruta completa del archivo ayuda a identificar el enmascaramiento (por ejemplo, svchost.exe ejecutar desde C:Temp en lugar de C:\Windows\System32). Los hashes de archivos (MD5, SHA-1, SHA-256) se presentan para su cruzamiento con inteligencia de amenazas.
• Información del firmante: La información sobre la firma digital del binario ayuda a distinguir entre binarios confiables de Microsoft y malware no firmado.
• Recuentos de eventos relacionados: En lugar de saturar el gráfico con miles de modificaciones de archivo, el nodo muestra estadísticas resumen (por ejemplo, "15 Eventos de Archivo", "3 Conexiones de Red"). Al hacer clic en estas estadísticas, normalmente se detalla en una vista de lista o línea temporal de esas acciones específicas.

La dimensión temporal (filtro temporal)

Un aspecto crítico y a menudo pasado por alto del Analizador es su gestión del tiempo. Los ataques pueden tener largos "tiempos de permanencia". Un proceso padre podría empezar hace semanas (por ejemplo, un servicio legítimo), mientras que hoy surgió el hijo malicioso. El Analizador incluye un control deslizante de tiempo que permite al analista ampliar la ventana de consulta. Por defecto, puede que vea una ventana estrecha alrededor de la alerta, pero ampliar esto permite que el gráfico "retroceda" en los niveles de datos Warm o Cold para encontrar el proceso padre de larga duración.

¿Cómo funciona?

La capacidad operativa del Analizador de Eventos aprovecha el Esquema Común Elástico (ECS). En un entorno de seguridad heterogéneo, los registros se originan en fuentes diversas: endpoints de Windows, servidores Linux, firewall de red y proveedores de servicios en la nube, cada uno con una taxonomía única. Un agente de CrowdStrike podría etiquetar un ID de proceso como TargetProcessId, mientras que un evento de Sysmon emplea ProcessId. Sin normalización, correlacionar estos eventos en una sola cadena es algorítmicamente imposible.
ECS soluciona esto imponiendo una jerarquía estricta de campos. El Analizador de Eventos se basa en campos ECS específicos y de alta fidelidad para construir el grafo visual:

• process.entity_id: Esta es la piedra angular de la lógica del Analizador. Los sistemas operativos reciclan los IDs de Proceso (PIDs). Un PID de 1234 podría pertenecer a svchost.exe en 09:00 y malware.exe en 14:00. Confiar en la PID para un análisis histórico a largo plazo introduce colisiones que corromperían el grafo visual, vinculando eventos no relacionados. El process.entity_id es una cadena única generada por el Agente Elástico (o beats compatibles con ECS) que persiste de forma única en el índice, cerciorando que el grafo represente una instancia de ejecución distinta, independientemente de si se reutiliza el PID.
• process.parent.entity_id: Este campo establece la arista dirigida entre los nodos. Al consultar recursivamente eventos donde la process.entity_id de un evento coincide con la process.parent.entity_id de otro, el Analizador reconstruye la línea genealógica.

evento.secuencia: En entornos de alta velocidad, el orden de los eventos (por ejemplo, ¿la modificación del archivo ocurrió antes o luego de la conexión a la red?) es fundamental. Las marcas de tiempo y números de secuencia ECS permiten al Analizador ordenar los eventos cronológicamente dentro de los detalles visuales del nodo.

6.3 Análisis profundo: Reconstruyendo la actividad del usuario con el visor de sesiones

Para el ataque XZbot (Linux), el Visor de Sesiones es la herramienta superior. Está diseñado específicamente para "monitorizar e investigar la actividad de las sesiones en la infraestructura de Linux".

Cuando se activa la alerta de Ejecución Potencial mediante XZBackdoor, el analista investiga el proceso sshd asociado. El Visor de Sesión presenta un "formato altamente legible inspirado en el terminal". Reconstruye la sesión del atacante, mostrando el proceso sshd y su proceso hijo anómalo (sh).

Además, mostrará el comando exacto que se ejecutó (sh -c setsid sh -c "usermod -aG sudo sysadmin_backup") e incluso puede mostrar la salida de ese comando. Esta es la "prueba irrefutable" definitiva, presentada al analista en texto sencillo y legible para humanos, permitiéndole efectivamente ver la sesión TTY del atacante a posteriori.

¿Qué estamos viendo?

La interfaz de usuario del Visor de Sesión está diseñada explícitamente para tender puentes entre el análisis abstracto de registros y la experiencia nativa de terminal de un administrador de Linux. A diferencia del Analizador de Eventos, que se centra en cadenas de procesos de malware, el Visor de Sesiones presenta una visualización ordenada en el tiempo basada en árbol que reconstruye la narrativa lineal de una sesión shell.

El árbol de procesos y la línea temporal

El componente central de la vista es un Grafo Acíclico Dirigido (DAG) mostrado como una lista jerárquica.

• Flujo vertical: El Visor de Sesiones organiza los procesos verticalmente, imitando el flujo de un archivo de historial de terminal pero preservando la jerarquía. Los procesos de los hijos están indentados en relación con sus padres. Esto permite a un analista distinguir inmediatamente entre un comando ejecutado directamente por el usuario (por ejemplo, curl) y un proceso generado por la ejecución de un script (por ejemplo, curl ejecutar dentro de un script setup.sh).
• Modo verboso: Un interruptor permite a los analistas cambiar entre una vista filtrada (que muestra una actividad significativa del usuario) y un "Modo Verbose". Cuando está habilitado, este modo suele revelar eventos ruidosos como scripts de inicio de shell (ejecución .bashrc), ayudas de completación de shell y bifurcaciones causadas por comandos integrados. Esto es crucial para detectar mecanismos de persistencia ocultos en los scripts de perfil.

Insignias visuales e indicadores

La interfaz emplea un sistema sofisticado de insignias e iconos para proporcionar un contexto inmediato sin que el analista tenga que profundizar en cada nodo. Estas señales visuales son esenciales para una triaje rápida.

Indicadores visuales en el visor de sesiones elástico

Vista de salida terminal

Pasar el cursor sobre el botón de Salida del Terminal en un nodo de proceso revela una insignia que indica el tamaño de la salida capturada. Al hacer clic en este botón se abre la vista de salida del terminal, que muestra los datos proces.io.text. Esta es la función "Prueba Humeante" para investigaciones en Linux.

• Capacidad de repetición: Permite al analista ver exactamente lo que el usuario vio. Si un atacante ejecutó cat /etc/passwd, el árbol de procesos muestra la ejecución; la vista de Salida del Terminal muestra el contenido del archivo passwd tal como se mostró al atacante.
• Reconstrucción de entradas: Como el visor captura la E/S TTY, captura no solo la ejecución del comando, sino también la escritura. Esto puede revelar retrocesos, errores tipográficos y correcciones (por ejemplo, escribir sdo [retroceso] sudo), que son indicadores de comportamiento fuertes de un adversario humano en lugar de un script automatizado.

El beneficio elástico: caza automatizada impulsada por IA

El proceso descrito en la Fase 3 demuestra una investigación poderosa impulsada por analistas. Sin embargo, el principal beneficio de usar Elastic Cloud Hosted (ECH) o Elastic Serverless es el acceso programático a una pila integrada de IA generativa. Esta pila eleva el proceso de correlación manual a caza automatizada impulsada por IA.

Nota: Las funciones de IA de Elastic funcionan con los LLMs gestionados de Elastic ya de fábrica o con LLMs de terceros configurados usando uno de los conectores disponibles.

7.1 De alertas a ataques: correlación automatizada con el descubrimiento de ataques

Los laboratorios GOAD + XZbot generarán múltiples alertas discretas, como se muestra en la tabla anterior. Un analista junior se enfrentaría a una cola de alertas: Posible Kerberoasting, Solicitud de Certificado Sospechosa y Posible XZBackdoor, y tendría que "coser" manualmente este complejo ataque cruzado entre dominios.

Este es el problema que resuelve Attack Discovery. Esta función GenAI, disponible en niveles Enterprise y Serverless, "ofrece una caza de amenazas totalmente automatizada a gran escala". "La IA analiza cada alerta para descubrir amenazas ocultas", correlacionando automáticamente las señales dispares del laboratorio Ludus en una única investigación de "Ataque" de alta fidelidad.

El valor principal de la Detección de Ataques para un analista forense es la compresión del tiempo. Automatiza el "punto de unión mental" que define el análisis de primer y segundo nivel.

Deconstruyendo la "costura mental"

Consideremos una investigación de ejemplo sin Descubrimiento de Ataque.

1. Desencadenante: Ves una alerta: "Ejecución sospechosa de PowerShell."
2. Consulta: Pivotas hacia la línea temporal del anfitrión.
3. Escaneo: Retrocedes 15 minutos. Ves un evento de "Descarga de archivo".
4. Hipótesis: "Quizá el usuario descargó un archivo defectuoso que abrió PowerShell."
5. Verificación: Revisa el nombre del archivo. Es invoice.js.
6. Conclusión: "Descarga de malware confirmada."

Este proceso dura entre 10 y 30 minutos, dependiendo de la habilidad y familiaridad del analista con el entorno. Detección de Ataque realiza toda esta secuencia en segundos. Analiza la alerta de PowerShell, detecta el evento de descarga de archivos en el contexto relacionado y presenta un Discovery que dice: "El usuario ejecutó un script sospechoso de PowerShell probablemente originado en el archivo descargado 'invoice.js'."

Esta función incluye Persistencia de Datos (los resultados se almacenan para seguimiento histórico) y Planeación y Acciones (se ejecuta automáticamente y puede desencadenar respuestas o flujos de trabajo elásticos posteriores), moviendo el SOC de una postura reactiva a una proactiva.

Ejemplo

En nuestro ejemplo, a medida que ocurre el ataque, empezamos a ver alertas. En lugar de clasificar las alertas individualmente, aprovechamos el Descubrimiento de Ataques para el triaje.
Comprimiendo el tiempo medio hasta la triaje a segundos e identificando rápidamente los ataques 2 .

7.2 Acelerando el triaje con el asistente de IA

El Asistente de Seguridad Elastic emplea IA generativa para ayudarte a encontrar, corregir y comprender amenazas de seguridad. Funciona directamente dentro de Elastic Security. Interactúas con él a través de una interfaz de chat para investigar alertas y escribir código.

En nuestro ejemplo, una vez que el Descubrimiento de Ataque identifica un ataque correlacionado, usamos el Asistente de IA para investigar. El asistente proporciona dos funciones clave:

1. Investigaciones sobre el lenguaje natural: El analista puede hacer preguntas en inglés sencillo como: "Resume este ataque", "¿Cuál es la táctica MITRE para este proceso?", "¿Qué es el spooler de impresión?" o "Ofrece algunas sugerencias de remediación."

2. Flujo de trabajo de validación de consultas agente: Esta avanzada función permite a la IA "generar ES| personalizados y validados"Consultas QL". Un analista puede preguntar: "Encuentra todas las conexiones de red del host implicado en la alerta XZbot", y el asistente escribirá, validará y corregirá la consulta antes de presentarla, reduciendo significativamente la barrera de habilidades para la caza de amenazas de alto nivel.
   

Cómo funciona

El Asistente conecta tu Elastic Stack a un LLM de tu elección (por ejemplo, GPT-5, Claude, Gemini). Emplea Generación Aumentada por Recuperación (RAG) para obtener datos relevantes—registros, alertas y documentación interna—de tu entorno. Puedes configurarlo para anonimizar campos sensibles (PII o metadatos de host/IP) antes de enviar el aviso al modelo, cerciorando que tus datos permanezcan privados mientras el modelo razona los patrones de comportamiento.

7.3 Automatización inteligente con flujos de trabajo elásticos

Los ataques descritos anteriormente generan alertas complejas y de varias etapas. Manejar esto manualmente es lento. Elastic solucionó esto adquiriendo Keep, una plataforma de gestión de alertas y AIOps de código abierto. En Elastic 9.3, esta tecnología está integrada directamente en Kibana en Technical Preview como Flujos de TrabajoElásticos.

¿Qué son los flujos de trabajo?

Elastic Workflows es un motor de automatización integrado en la plataforma Elasticsearch. Defines flujos de trabajo en YAML: qué los activa, qué pasos realizan, qué acciones realizan, y la plataforma se encarga de la ejecución. Un flujo de trabajo puede consultar tu entorno, transformar y enriquecer datos de seguridad, hacer ramas según condiciones, llamar a APIs externas e integrar con servicios como Slack, Jira, PagerDuty y más a través de conectores que ya configuraste. Los flujos de trabajo también pueden llamar a los agentes de IA para razonar a través de investigaciones complejas y luego continuar con acciones de respuesta basadas en lo que el agente descubra. Elastic Workflows combina automatización guionizada con razonamiento por IA de forma nativa en tu SIEM, donde ya residen tus datos de seguridad.

Cómo funciona: El "Agregador de Alertas y Motor de Flujo de Trabajo"

Los flujos de trabajo se convierten en la capa intermedia entre la detección y la remediación, funcionando a través de tres mecanismos principales:

• Ingestión de múltiples fuentes: Los flujos de trabajo van más allá de Elastic. Incorporar datos adicionales para enriquecimiento, análisis o triaje inicial.
• Flujo de trabajo como código (YAML): Los flujos de trabajo se definen en archivos YAML. Esto permite a los equipos controlar versiones sus procedimientos de respuesta a incidentes como código.
• El motor de flujo de trabajo: Cuando se activa una alerta en Elastic (o una herramienta externa), el Workflow Engine ejecuta un serial de pasos:
  1. Enriquecimiento: Consultar una API (como VirusTotal o Active Directory) para agregar contexto.
  2. Lógica: Usar sentencias if/else para determinar la gravedad.
  3. Acción: Enviar un mensaje de Slack, crear un tiquete de Jira o activar una acción de respuesta de Elastic Defend.

Considera un ejemplo de flujo de alerta y acción.

• Desencadenante: Conectas el flujo de trabajo a una regla específica, como "Alerta de detección maliciosa".
• Pasos: Defines una secuencia de acciones.
  1. Triaje (Agente): Pasa la alerta al Asistente de IA. Haz las preguntas: "¿Cómo remediaríamos y responderíamos a la alerta que aparece a continuación?"
  2. Enrich: Anexa la respuesta del Asistente de IA como nota a la alerta.
  3. Responder: Crea un caso con un enlace a la nota de alerta.

Ejemplo

En nuestro ejemplo, tenemos alertas que activan nuestro flujo de trabajo - Enriquecimiento de alertas y creación de casos.
También lo activaremos directamente desde la interfaz de flujos de trabajo para mostrar los distintos pasos.

• El contexto de Alerta se proporciona como entrada al Asistente de IA de Seguridad
• La respuesta se agrega como nota a las alertas de seguridad
• Se crea un caso con metadatos de la Alerta (marca de tiempo, gravedad, nombre de la regla y motivo de la alerta).
• Se agrega un enlace al caso como comentario. Nota: esto no aparece en el GIF.

Conclusión: De la configuración manual a la emulación continua

Este blog proporcionó un plan completo para un rango de simulación avanzado, escalable y, lo más importante, seguro.

1. Construimos: Se desplegó un complejo rango multilaboratorio (GOAD + XZbot) con un solo comando usando Ludus.
2. Instrumentamos: Toda la gama estaba instrumentada de forma fluida con Elastic Agent y Defender como parte del despliegue automatizado, empleando el rol ludus_elastic_agent Ansible.
3. Conseguimos: El conflicto crítico entre el aislamiento de malware y la conectividad de agente en la nube se resolvió empleando los controles de red granulares "OPSEC" de Ludus.
4. Validamos: Las poderosas capacidades SIEM de la plataforma se demostraron validando las reglas prediseñadas y listas para usar de detección de Elastic contra ataques en tiempo real y conocidos como malos.
5. Investigamos: Las herramientas especializadas de investigación, Event Analyzer y Session Viewer, se emplearon para rastrear las rutas exactas de ataque tanto en hosts Windows como Linux.
6. Automatizamos: Se demostró el "multiplicador de fuerza" de la pila GenAI de Elastic, con Detección de Ataques correlacionando automáticamente alertas dispares en un solo ataque y el Asistente de IA acelerando la investigación final.
7. Respondimos: El poder de los flujos de trabajo elásticos proporciona cerebros y automatización para acciones de respuesta complejas y flujos de remediación.

Esta arquitectura no es una construcción única. Es un modelo para una tubería de ingeniería de detección continua. "Moderniza las operaciones de seguridad" al empoderar a los equipos púrpura para desmantelar, reconstruir y volver a probar sus defensas bajo demanda, cerciorando que su postura de detección evolucione tan rápido como las amenazas.

Da el siguiente paso: capacita a tu equipo de seguridad

La arquitectura de este blog es más que un ejercicio técnico; Es un modelo para la validación continua de la seguridad. Al combinar este rango automatizado con la plataforma unificada SIEM y XDR de Elastic, puedes pasar de pruebas periódicas a un estado de preparación constante.

Te invitamos a iniciar tu propio juicio, aprovechar esta guía para probar y evaluar la plataforma frente a amenazas reales, y dotar a tu equipo de seguridad de las herramientas para mantener un paso por delante del adversario.

¿Usando otro SIEM?

No hay problema. Puedes aprovechar Elastic Serverless y aumentar tu SIEM existente, y luego obtener todos los conocimientos anteriores empleando los datos subyacentes de tu SIEM nativo. Empieza hoy mismo con un despliegue Serverless de Elastic. El paqueteElastic AI SOC Engine (EASE) ofrece estas capacidades impulsadas por IA, permitiendo a las organizaciones agregar rápidamente análisis poderosos y una capa de IA sobre sus herramientas existentes antes de la migración completa.

Apéndice

Ejemplo de rango completo

Nota: La VLAN de la VM Kali está fuera de los hosts backdoor GOAD y XZ para simular una red segmentada o un atacante remoto. La VLAN de la VM Kali puede cambiar a 10/20 para simular "supuesta brecha" o escenarios de ataque interno.

global_role_vars:
  ludus_elastic_fleet_server: "https://<fleet_domain>:<fleet_port>" #443 by default for cloud   ## Note on prem fleet server defaults to 8220
  ludus_elastic_agent_version: "9.2.1"
ludus:
  - vm_name: "{{ range_id }}-GOAD-DC01"
    hostname: "{{ range_id }}-DC01"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 10
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:           # Any values in this array will be added to DNS for the range and return an A record for this VM's IP
      - sevenkingdoms.local
      - kingslanding.sevenkingdoms.local
      - kingslanding
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-DC02"
    hostname: "{{ range_id }}-DC02"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 11
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - winterfell.north.sevenkingdoms.local
      - north.sevenkingdoms.local
      - winterfell
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-DC03"
    hostname: "{{ range_id }}-DC03"
    template: win2016-server-x64-template
    vlan: 10
    ip_last_octet: 12
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - essos.local
      - meereen.essos.local
      - meereen
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-SRV02"
    hostname: "{{ range_id }}-SRV02"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 22
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - castelblack.north.sevenkingdoms.local
      - castelblack
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-SRV03"
    hostname: "{{ range_id }}-SRV03"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 23
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - braavos.essos.local
      - braavos
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<your_enrollment>"
  - vm_name: "{{ range_id }}-xz-backdoor-dect"
    hostname: "{{ range_id }}-xz-backdoor-dect"
    template: debian-12-x64-server-template
    vlan: 20
    ip_last_octet: 1
    ram_gb: 2
    cpus: 2
    linux:
      packages: # You can define packages to install on Linux hosts
        - ca-certificates
        - netcat-openbsd
        - net-tools
    roles:
      - badsectorlabs.ludus_xz_backdoor
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_xz_backdoor_install_xzbot: true
      ludus_xz_backdoor_install_backdoor: true
      ludus_elastic_enrollment_token: "<linux_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-kali"
    hostname: "{{ range_id }}-kali"
    template: kali-x64-desktop-template
    vlan: 50
    ip_last_octet: 99
    ram_gb: 8
    cpus: 4
    linux: true
    testing:
      snapshot: false # Snapshot this VM going into testing, and revert it coming out of testing. Default: true
      block_internet: false # Allow internet access for Kali, default is true
    roles:
      - badsectorlabs.ludus_xz_backdoor
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_xz_backdoor_install_xzbot: true
      ludus_elastic_enrollment_token: "<linux_policy_enrollment_token>"

El lanzamiento y el momento de cualquier característica o funcionalidad descrita en esta publicación quedan a discreción exclusiva de Elastic. Es posible que cualquier característica o funcionalidad que no esté disponible en este momento no se lance a tiempo o no se lance en absoluto.