Acelerando la confirmación de ataques APT con descubrimiento de ataques, flujos de trabajo y Agent Builder

9:15 AM: El No-Evento - Un titular suena: "Chrysalis Backdoor: Una inmersión profunda en la flor de loto." Tu CISO envía un mensaje en Slack: "¿Nos afecta?"

En un SOC tradicional, estás a punto de perder toda la mañana en un proceso de revisión manual: filtrando decenas de alertas, escribiendo consultas, comprobando manualmente VirusTotal y pivotando entre patrones de índice para construir una línea de tiempo esperando no perderte nada.

Pero en un SOC agente, el trabajo ya está hecho. Detección de Ataques, que se ejecuta con su calendario horario, ya correlacionó 5 alertas críticas de 30+ en una única narrativa de ataque: "Malware con persistencia de carga lateral DLL." Ese descubrimiento activaba automáticamente un flujo de trabajo, que entregaba los hallazgos a un agente. El agente usó sus herramientas y verificó el hash del malware en VirusTotal, buscó en tus registros con ES|QL, revisó el horario de guardia, creó un caso y puso en marcha un canal de incidentes en Slack con el analista de guardia ya agregado, y también generó un resumen listo para CISO — todo antes de sentar a tomar un café.

Respondes a tu CISO: "Ya confirmado y clasificado. El caso está abierto. Aquí tienes el enlace."

Esta publicación explica cómo construimos esa canalización: la integración de Detección de Ataques, Flujos de Trabajo y Constructor de Agentes.

La amenaza: Chrysalis backdoor de Lotus Blossom

Perfil de actor amenazante

Resumen de la campaña

Lotus Blossom ejecutó una reducción de la cadena de suministro de la infraestructura de actualización de Notepad++:

• Ventana de ataque: 2025 de junio – 2025 de diciembre (~6 meses)
• Vector: Mecanismo de actualización secuestrado de Notepad++ (WinGUp)
• Método: Redirección selectiva de usuarios objetivo hacia servidores de actualización maliciosos
• Carga útil: Puerta trasera "Crisálida" previamente no documentada
• Descubrimiento: Equipo Rapid7 MDR, publicado el 2026-02-02

Capacidades de backdoor de Chrysalis

La puerta trasera Chrysalis es un implante sofisticado y rico en funciones:

• Cifrado personalizado (LCG, hash FNV-1a, MurmurHash)
• Carga de DLL reflectante
• Hashing de API para evasión
• Carga lateral de DLL vía binario legítimo de Bitdefender (BluetoothService.exe)
• Capacidades completas de acceso remoto
• Instalación persistente del servicio de Windows

Cadena de ataque

[1] INITIAL ACCESS
    └── User executes malicious NSIS installer from Desktop
              ↓
[2] EXECUTION
    └── Installer drops files to hidden AppData folder
        ├── BluetoothService.exe (legitimate binary)
        └── log.dll (malicious Chrysalis loader)
              ↓
[3] PERSISTENCE
    └── BluetoothService.exe registered as Windows service
        └── Runs under SYSTEM context
              ↓
[4] DEFENSE EVASION
    └── DLL sideloading via legitimate signed binary
              ↓
[5] COMMAND & CONTROL
    └── DNS beacon to api[.]skycloudcenter[.]com ✅ CONFIRMED

Mapeo de MITRE ATT&CK

El reto: Velocidad vs. Precisión

Cuando la inteligencia de amenazas aparece en una campaña APT de estado-nación, los equipos SOC se enfrentan a un compromiso brutal:

Velocidad: Los ejecutivos quieren respuestas ya. "¿Estamos comprometidos?"

Precisión: Los analistas necesitan tiempo para buscar, correlacionar y confirmar antes de tomar la decisión.

Los flujos de trabajo tradicionales requieren que los analistas:

1. Determinar el alcance del análisis y los criterios de búsqueda relevantes
2. Busca manualmente IOCs en múltiples fuentes de datos
3. Correlaciona las alertas que pueden abarcar días o semanas
4. Validar los hallazgos frente a la inteligencia de amenazas
5. Construye la línea temporal de ataque
6. Escalar con confianza

Este proceso dura de horas a días, durante los cuales un atacante activo puede exfiltrar datos o mover lateralmente.

La solución: Detección de ataques + flujos de trabajo + Constructor de agentes

La pila de automatización impulsada por IA de Elastic Security transforma este flujo de trabajo de búsqueda manual a confirmación automatizada. Pero antes de entrar en la configuración específica, merece la pena entender cómo encajan los bloques de construcción.

Agentes y flujos de trabajo: Dos puntos de entrada, uno de arquitectura componible

Agent Builder te da dos primitivas que funcionan juntas:

• Los agentes son la capa de inteligencia. Razonan sobre una tarea, deciden qué herramientas llamar y se adaptan según lo que encuentran. Un agente puede llamar herramientas de búsqueda, herramientas MCP y, de forma crítica, flujos de trabajo como herramientas.
• Los flujos de trabajo son la capa estructural. Son pipelines deterministas: los pasos se ejecutan en orden, de forma fiable y repetible. Cualquier paso en un flujo de trabajo puede ser opcionalmente un paso de agente, dándole la capacidad de razonar a mitad de la pipeline.

Ambos son totalmente componibles. Un flujo de trabajo puede invocar a un agente. Un agente puede llamar a un flujo de trabajo. Un paso de agente dentro de un flujo de trabajo puede llamar a otro flujo de trabajo. Cada conexión es opcional, permitiéndote mezclar y combinar según lo que requiera el problema.

Esto es lo que hace que la arquitectura sea poderosa: los agentes razonan y deciden; los flujos de trabajo se ejecutan y coordinan. Para nuestro escenario de ataque con Chrysalis, usamos ambos.

Nuestro flujo

El flujo:

1. Muchas alertas → descubrimiento de ataques correlacionan alertas dispares en una sola narrativa de ataque
2. Detección de ataques → Genera una alerta que activa el flujo de trabajo
3. Flujo de → Invoca Agent Builder para analizar los hallazgos del descubrimiento de ataques
4. Agent Builder → Llamadas a flujos de trabajo de enriquecimiento (VirusTotal, Threat Intel, ES|Consultas QL)
5. Constructor de Agentes llama a un flujo de trabajo → Constructor de agentes continúa con acciones de respuesta a incidentes que llaman al flujo de trabajo como herramienta (acciones de casos, aislar host, notificar al equipo)

Paso 1: El descubrimiento de ataques pone a la luz la amenaza

El Descubrimiento de Ataques emplea LLMs para analizar alertas de seguridad e identificar patrones de ataque. A diferencia del agrupamiento tradicional de alertas, entiende las relaciones semánticas entre alertas.

La cola de alertas: Aguja en un pajar

Esta es la realidad para un analista de SOC. Abres la página de alertas y ves decenas de alertas en múltiples hosts, usuarios y reglas, combinaciones de severidades mixtas, tipos mixtos, muchas de ellas ruido.

Docenas de alertas. Disparos con varias reglas. Niveles de gravedad que van desde bajos hasta críticos. Algunos son el ataque Chrysalis. Algunos son eventos no relacionados con Windows Defender. Algunos son detecciones de cambios SIEM de un flujo de trabajo completamente diferente. Es difícil encontrar el ataque coordinado en este muro de ruido.

Qué encontró Attack Discovery

Attack Discovery analizó todas estas alertas e identificó 5 alertas que pertenecían a un solo ataque coordinado, sacándolas del ruido y correlacionándolas en una sola narrativa:

En lugar de presentar 5 alertas individuales, Attack Discovery las correlacionó en un solo descubrimiento:

Malware con persistencia de carga lateral de DLL

Un ejecutable malicioso en srv-win-defend-01 escaló a persistencia mediante BluetoothService.exe con carga lateral DLL

• Presentador: srv-win-defend-01
• Usuario: james_spiteri
• Gravedad: Crítica
• Cadena de ataque: Acceso inicial → ejecución → persistencia → evasión defensiva → C2

Descubrimiento de ataques también:

• Alertas asignadas a tácticas MITRE ATT&CK
• Identificó la técnica de carga lateral DLL
• Señaló el mecanismo sospechoso de persistencia
• Destacado el indicador de red C2

Paso 2: El descubrimiento programado activa el flujo de trabajo

El Descubrimiento de Ataques no requiere que un analista haga clic en un botón. Lo configuramos para que funcionara con un horario horario, analizando continuamente las últimas alertas para ataques coordinados.

Cuando comenzó nuestra carrera horaria, absorbió todas las alertas de la última hora, incluidas las alertas relacionadas con Chrysalis, ocultas entre detecciones rutinarias, y resurgió el ataque de carga lateral DLL como un descubrimiento.

Vincular un flujo de trabajo como paso de acción tras el descubrimiento de ataques significa que cada vez que el Descubrimiento de Ataque encuentra un ataque coordinado, automáticamente se activa el flujo de trabajo...

Pero esto es lo que hace que este enfoque sea diferente de los playbooks tradicionales de SOAR: el flujo de trabajo no prescribe cada paso. Le entrega todo el descubrimiento del ataque al Agente Builder y dice "descúbrelo".

Definición de flujo de trabajo

Este es el flujo de trabajo real que usamos, que consta de dos pasos, nada más:

name: Auto Triage AD
description: >-
  Demonstrates the application of AI agents and workflows 
  to enable agentic alert triaging.
enabled: true
tags:
  - Example
  - Agentic Workflow

triggers:
  - type: alert                          # Fires when Attack Discovery generates an alert

steps:
  # Step 1: Hand the attack discovery to the agent with clear instructions
  - name: initial_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        agent_id: <your-agent-id>        # Your custom Hunting Agent
        input: |
          Confirm the attack by searching for behaviour in the logs 
          (all logs which are relevant), always leverage security labs tools, 
          always leverage virustotal if file hashes are available. 
          If this is a true positive, create a case with all the relevant content too.

          {{event|json}}

          Create a slack channel for this incident, check who's on call, 
          add them to it, and send a formatted message with what's happening 
          and next steps. If this is a true positive, create a case with all 
          the relevant content too - add a button to the slack message linking 
          to the case, and another button leading to the result of the attack. 
          Lastly, include a button that will take me to this agent conversation, 
          just replace the conversation ID with the actual one from this conversation 
          (https://<your-kibana-url>/app/agent_builder/conversations/<conversation-id>)

          Change the attack discovery status to acknowledged, or, 
          if false positives, close it.
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

  # Step 2: Follow up to catch anything that didn't complete
  - name: followup_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        conversation_id: "{{ steps.initial_analysis.output.conversation_id }}"
        agent_id: <your-agent-id>
        input: |
          Complete any previous steps which might not have ran successfully. 
          Just in case, the conversation ID is 
          {{ steps.initial_analysis.output.conversation_id }}
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

Por qué este flujo de trabajo es tan corto

Toda la automatización consta de dos pasos:

1. initial_analysis: Envía el descubrimiento del ataque a Agent Builder con instrucciones en lenguaje natural que describan lo que quieres que se haga
2. followup_analysis: Un sistema de seguridad que reanuda la misma conversación y pide al agente que verifique que todas las tareas se completaron. Como los agentes llaman a varias herramientas en secuencia y cualquier llamada individual podría caer en tiempo de expiración o encontrar un error transitorio, este paso garantiza que nada se escape por las grietas.

Este es el cambio fundamental: el flujo de trabajo es el detonante y la red de seguridad; el agente es el cerebro.

Bajo el capó: Cómo ampliamos el Agente de Caza de Amenazas

Antes de continuar con los resultados, merece la pena parar sobre lo que hizo esto posible. Una de las capacidades más poderosas de Agent Builder es que puedes ampliar a los agentes existentes con herramientas adicionales. En lugar de construir desde cero, tomamos el Threat Hunting Agent por defecto y agregamos herramientas personalizadas con flujo de trabajo para darle las capacidades específicas que requería este escenario.

Lo que agregamos

Agent Builder viene con herramientas de plataforma integradas como platform.core.generate_esql y platform.core.product_documentation. Pero el verdadero poder viene de agregar los tuyos propios. Ampliamos el Threat Hunting Agent con herramientas en varias categorías:

Cinco herramientas personalizadas. Eso fue suficiente para convertir el Agente de Caza por defecto en una verificación automática de malware, búsqueda en registros, localización del respondedor de guardia, creación de un caso y creación de un canal de incidentes, todo ello acelerando el tiempo para detectar una amenaza potencial.

La cadena de razonamiento del Agente

Esto es lo sorprendente: dado el contexto de Descubrimiento de Ataques, el agente decidía automáticamente qué herramientas llamar y en qué orden. Ningún humano ha guionado estos pasos.

Paso 1: Búsqueda de VirusTotal: vt.hash.lookup

• El primer movimiento del agente: verificar el hash del malware.

Paso 2: Generar ES|Consulta QL: platform.core.generate_esql

• Con el malware confirmado, el agente buscó toda la actividad relacionada.

Paso 3: Documentación del producto: platform.core.product_documentation

• El agente consultó la documentación de Elastic Security para generar comandos de remediación para la Response Console.

Pasos de razonamiento que muestran qué herramientas se llamaron en secuencia para la transparencia

Muestra la cadena de razonamiento adicional: consultar la documentación del producto, luego comprobar la información del horario de guardia antes de crear un caso con toda la información relevante y notificar al analista de llamada por Slack.

Paso 4: Comprobar la hora actual: get.time

Paso 5: Consulta el horario de guardia: check.on.call.schedule

• El agente gestionaba un ES|Consulta QL con el índice on-call-schedule para encontrar al respondedor actual:

Paso 6: Crear caso: create.case

Paso 7: Crear un canal de Slack: create.channel

¿Por qué importa esto?

El agente no seguía un guion. Razonó sobre la situación y decidió:

1. Primero, verifica que el malware sea real (VirusTotal)
2. Luego, entiende el impacto (ES|Búsqueda de registro QL)
3. Luego, averigua cómo remediar (documentación del producto)
4. Luego, encuentra a la persona adecuada para responder (horario de guardia)
5. Luego, crear artefactos de seguimiento (caso)
6. Por último, coordina el equipo (canal de Slack)

Esta es la diferencia entre un flujo de trabajo (que sigue una secuencia fija) y un agente (que justifica qué hacer a continuación). El flujo de trabajo activaba al agente; El agente averiguó el resto.

Paso 3: Respuesta automatizada a incidentes

Con una confirmación de alta confianza, el flujo de trabajo se activa automáticamente:

1. Crea un caso de incidente

Se crea un caso estructurado con todas las pruebas relevantes adjuntas:

• Conclusiones de Descubrimiento de Ataque
• Resultados del análisis de VirusTotal
• Coincidencias de inteligencia de amenazas
• Análisis de Agent Builder
• Acciones de respuesta recomendadas

2. Notifica al SOC

Se envía un mensaje de Slack al canal correcto informando a los analistas del incidente crítico.

3. Habilita acciones de respuesta

El flujo de trabajo puede activar opcionalmente acciones de respuesta automática:

• Aislamiento del huésped: Aislar srv-win-defend-01 mediante Elastic Defend
• Suspensión del usuario: Desactiva james_spiteri en Active Directory
• Bloque de red: Enviar dominio C2 a la lista de bloqueo del firewall
• Registro del COI: Lanzar escaneo de toda la flota para indicadores de Chrysalis

---

Tiempo para la confirmación: Antes y después

---

La otra opción: Simplemente pregúntale al Agente

Todo lo anterior describe la cadena automatizada : el Descubrimiento de Ataques encuentra la amenaza, el flujo de trabajo se activa, el agente lo tria y el/los analista adecuado recibe la notificación.

Pero hay otra forma igualmente poderosa de usar esto: ve directamente a Agent Builder y pregúntalo en un inglés sencillo.

Escenario: Lees primero sobre la amenaza

Imagina que estás navegando por tus feeds de inteligencia de amenazas y ves la entrada del blog de Rapid7 sobre la puerta trasera de Chrysalis. Solo quieres saber: ¿estamos comprometidos?

Eso es todo. El mismo agente con las mismas herramientas hace el resto:

1. Lee el reporte de amenazas usando la herramienta web.search para extraer IOCs y TTPs del blog de Rapid7
2. Genera ES|Consultas QL para buscar indicadores de Chrysalis en tus registros de eventos, archivos de red y procesos
3. Comprueba en VirusTotal si hay hashes de archivo coincidentes encontrados en tu entorno
4. Elabora un resumen listo para CISO con hallazgos, nivel de confianza y acciones recomendadas

El agente llama a las mismas herramientas que en la tubería automatizada. La diferencia está en el punto de entrada: en lugar de que un Descubrimiento de Ataque programado desencadene un flujo de trabajo, activabas al agente con una pregunta.

Por qué esto cambia las reglas del juego para los analistas

Esta es la parte fácil de pasar por alto pero profundamente importante: el analista no necesitaba conocer ni un solo lenguaje de consulta, patrón de índice o nombre de herramienta.

No escribieron ES|QL. No necesitaban recordar dónde residen sus diferentes datos. No necesitaban recordar la sintaxis de la API de VirusTotal ni averiguar qué índice de inteligencia de amenazas consultar.

Hicieron una pregunta en lenguaje natural. El agente resolvió el resto, incluyendo qué índices buscar, qué consultas escribir, qué herramientas llamar y cómo sintetizar los resultados.

Para un analista junior que se unió al equipo el mes pasado, esto es transformador. Para un analista senior que lleva una década haciendo esto, son horas de su vida de vuelta. Para un CISO que quiere una actualización de estado, es una pregunta que no le hay.

La barrera para cazar amenazas de forma efectiva acaba de pasar de "sabe ES|QL y 47 patrones de índice" para "describir lo que buscan."

Conclusiones clave

1. El Descubrimiento de Ataques en un horario te permite no perder ataques : analiza continuamente tus alertas, así que las amenazas coordinadas salen a la luz incluso cuando nadie está vigilando la cola.
2. Los flujos de trabajo orquestan la respuesta, activando los descubrimientos, invocando agentes y ejecutando acciones.
3. Agent Builder te permite crear o ampliar agentes según tus necesidades : ya sea que empieces desde cero o agregues herramientas personalizadas a un agente existente, tú adaptas las capacidades para adaptarlas a tu entorno.
4. El agente razona, los flujos de trabajo se ejecutan : el agente decide de forma autónoma llamar a VirusTotal, buscar registros, comprobar el horario de guardia y crear un canal de Slack. Ningún humano guionó esa secuencia.
5. Dos puntos de entrada, misma potencia : la tubería automatizada y la interfaz de chat usan el mismo agente y las mismas herramientas. Ya sea que un descubrimiento programado lo desencadene o que un analista haga una pregunta, el resultado es el mismo.
6. El lenguaje natural es el nuevo lenguaje de consultas: los analistas no necesitan saber ES|QL, patrones de índice o sintaxis API. Describen lo que buscan, y el agente se encarga del resto.

La campaña de la puerta oculta de Chrysalis demuestra por qué esto importa. Cuando los actores estatales pueden comprometer tu cadena de suministro y establecer persistencia en 4 segundos, necesitas defensas que igualen esa velocidad, ya sea una tubería automatizada mientras duermes o una conversación directa con un agente cuando eres el primero en detectar la amenaza.