Accélérer la confirmation des attaques APT grâce à la découverte d'attaques, aux flux de travail et à la création d'agents

9:15 AM : Le non-événement - Un titre se détache : "Chrysalis Backdoor : A Deep Dive into Lotus Blossom." Votre RSSI envoie un message sur Slack : "Sommes-nous concernés ?"

Dans un SOC traditionnel, vous êtes sur le point de perdre toute votre matinée dans une course manuelle - en passant au crible des dizaines d'alertes, en écrivant des requêtes, en vérifiant manuellement VirusTotal et en pivotant entre les modèles d'index pour construire une chronologie en espérant ne pas manquer quelque chose.

Mais dans un SOC agentique, le travail est déjà fait. Attack Discovery, qui fonctionne selon un programme horaire, a déjà corrélé 5 alertes critiques sur plus de 30 en un seul récit d'attaque : "Malware with DLL Side-Loading Persistence." Cette découverte a automatiquement déclenché un flux de travail, qui a transmis les résultats à un agent. L'agent a utilisé ses outils et a vérifié le hash du logiciel malveillant sur VirusTotal, a recherché vos journaux avec ES|QL, a vérifié le calendrier d'astreinte, a créé un cas et a lancé un canal d'incident Slack avec l'analyste d'astreinte déjà ajouté, et a également généré un résumé prêt pour le CISO - tout cela avant que vous ne vous asseyiez pour prendre un café.

Vous répondez à votre RSSI : "Déjà confirmé et trié. L'affaire est ouverte. Voici le lien."

Ce billet explique comment nous avons construit ce pipeline : l'intégration de la découverte d'attaques, des flux de travail et de la création d'agents.

La menace : Porte dérobée Chrysalis par Lotus Blossom

Profil de l'acteur de la menace

Aperçu de la campagne

Lotus Blossom a compromis la chaîne d'approvisionnement de l'infrastructure de mise à jour de Notepad++ :

• Fenêtre d'attaque : Juin 2025 - décembre 2025 (~6 mois)
• Vecteur : Mécanisme de mise à jour de Notepad++ détourné (WinGUp)
• Méthode : Redirection sélective des utilisateurs ciblés vers des serveurs de mise à jour malveillants.
• Charge utile : Porte dérobée précédemment non documentée "Chrysalis"
• Découverte : Équipe Rapid7 MDR, publié le 2026-02-02

Capacités de la porte dérobée Chrysalis

La porte dérobée Chrysalis est un implant sophistiqué et riche en fonctionnalités :

• Chiffrement personnalisé (LCG, FNV-1a hashing, MurmurHash)
• Chargement réfléchi de DLL
• Le hachage de l'API pour l'évasion
• DLL sideloading via un binaire Bitdefender légitime (BluetoothService.exe)
• Accès à distance complet
• Installation d'un service Windows persistant

Chaîne d'attaque

[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

MITRE ATT&Cartographie CK

Le défi : rapidité ou précision

Lorsque les renseignements sur les menaces tombent sur une campagne APT d'un État-nation, les équipes SOC sont confrontées à un choix brutal :

Rapidité : Les dirigeants veulent des réponses immédiates. "Sommes-nous compromis ?"

Précision : Les analystes ont besoin de temps pour rechercher, corréler et confirmer avant de prendre une décision.

Les flux de travail traditionnels exigent des analystes qu'ils

1. Déterminer l'étendue de l'analyse et les critères de recherche pertinents
2. Recherche manuelle de CIO dans plusieurs sources de données
3. Corréler des alertes qui peuvent s'étaler sur plusieurs jours ou semaines
4. Valider les résultats par rapport aux renseignements sur les menaces
5. Élaborer la chronologie de l'attaque
6. Remonter les échelons en toute confiance

Ce processus prend des heures, voire des jours, au cours desquels un attaquant actif peut exfiltrer des données ou se déplacer latéralement.

La solution : Découverte d'attaques + Workflows + Agent Builder

La pile d'automatisation d'Elastic Security, alimentée par l'IA, transforme ce flux de travail d'une chasse manuelle à une confirmation automatisée. Mais avant de nous plonger dans la configuration spécifique, il est utile de comprendre comment les éléments constitutifs s'imbriquent les uns dans les autres.

Agents & Workflows : Deux points d'entrée, une architecture composable

Agent Builder vous offre deux primitives qui fonctionnent ensemble :

• Les agents constituent la couche d'intelligence. Ils réfléchissent à une tâche, décident des outils à utiliser et s'adaptent en fonction de ce qu'ils trouvent. Un agent peut qualifier d'outils les outils de recherche, les outils MCP et, surtout, les flux de travail.
• Les flux de travail constituent la couche structurelle. Il s'agit de pipelines déterministes : les étapes se déroulent dans l'ordre, de manière fiable et reproductible. Toute étape d'un flux de travail peut éventuellement être une étape agent, ce qui lui donne la possibilité de raisonner à mi-parcours.

Les deux sont entièrement composables. Un flux de travail peut invoquer un agent. Un agent peut appeler un flux de travail. Une étape d'agent dans un flux de travail peut appeler un autre flux de travail. Chaque connexion est optionnelle, ce qui vous permet de combiner les différents éléments en fonction du problème à résoudre.

C'est ce qui rend l'architecture puissante : les agents raisonnent et décident ; les flux de travail exécutent et coordonnent. Pour notre scénario d'attaque de la Chrysalide, nous avons utilisé les deux.

Notre flux

Le flux :

1. Nombreuses alertes → Attack Discovery met en corrélation des alertes disparates pour en faire un récit d'attaque unique
2. Découverte de l'attaque → Génère une alerte qui déclenche le flux de travail
3. Workflow → Invocation de l'Agent Builder pour analyser les résultats de la découverte de l'attaque
4. Agent Builder → Flux d'enrichissement des appels (VirusTotal, Threat Intel, ES|QL queries)
5. Le constructeur d'agents appelle un flux de travail → Le constructeur d'agents poursuit les actions de réponse à l'incident en utilisant le flux de travail comme outil (actions sur le cas, isoler l'hôte, notifier l'équipe).

Étape 1 : Découverte de l'attaque surface de la menace

Attack Discovery utilise les LLM pour analyser les alertes de sécurité et identifier les schémas d'attaque. Contrairement au regroupement traditionnel des alertes, il comprend les relations sémantiques entre les alertes.

La file d'attente : Une aiguille dans une botte de foin

Voici la réalité pour un analyste SOC. Vous ouvrez la page des alertes et vous voyez des dizaines d'alertes sur plusieurs hôtes, utilisateurs et règles, des combinaisons, des sévérités et des types mélangés, dont beaucoup sont bruyants.

Des dizaines d'alertes. Tir de règles multiples. Les niveaux de gravité vont de faible à critique. Certaines sont l'attaque de la Chrysalide. Certains sont des événements sans rapport avec Windows Defender. D'autres sont des détections de changement SIEM provenant d'un flux de travail complètement différent. Il est difficile de trouver l'attaque coordonnée dans ce mur de bruit.

Ce qu'a trouvé Attack Discovery

Attack Discovery a analysé toutes ces alertes et en a identifié 5 qui appartenaient à une seule attaque coordonnée - en les extrayant du bruit et en les mettant en corrélation dans un seul récit :

Au lieu de présenter 5 alertes individuelles, Attack Discovery les a corrélées en une seule découverte :

Logiciels malveillants avec persistance du chargement latéral de DLL

Un exécutable malveillant sur srv-win-defend-01 est passé à la persistance via BluetoothService.exe avec chargement latéral de DLL.

• Hôte : srv-win-defend-01
• Utilisateur : james_spiteri
• Gravité : Critique
• Chaîne d'attaque : Accès initial → Exécution → Persistance → Évasion de la défense → C2

Attaquez également Discovery :

• Alertes mappées vers MITRE ATT&CK tactics
• Identification de la technique de sideloading des DLL
• Signalement du mécanisme de persistance suspect
• Mise en évidence de l'indicateur du réseau C2

Étape 2 : La découverte programmée déclenche le flux de travail

La découverte d'attaques ne nécessite pas qu'un analyste clique sur un bouton. Nous l'avons configuré pour qu'il s'exécute toutes les heures, en analysant en permanence les dernières alertes d'attaques coordonnées.

Lorsque notre exécution horaire a démarré, elle a ingéré toutes les alertes de la dernière heure, y compris les alertes liées à Chrysalis enfouies dans les détections de routine, et a fait apparaître l'attaque par chargement latéral de DLL en tant que découverte.

Le fait de lier un flux de travail à une étape d'action de la découverte d'une attaque signifie que chaque fois qu'Attack Discovery trouve une attaque coordonnée, il déclenche automatiquement le flux de travail.

Mais ce qui différencie cette approche des manuels SOAR traditionnels, c'est que le flux de travail ne prévoit pas toutes les étapes. Il confie l'ensemble de la découverte de l'attaque à l'agent Builder et lui dit "de se débrouiller. "

Définition du flux de travail

Voici le flux de travail réel que nous avons utilisé et qui consiste en deux étapes, c'est tout :

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

Pourquoi ce flux de travail est-il si court ?

L'automatisation complète se fait en deux étapes :

1. initial_analysis: Envoyez la découverte de l'attaque à l'Agent Builder avec des instructions en langage naturel décrivant ce que vous voulez faire.
2. followup_analysis: Une sécurité qui reprend la même conversation et demande à l'agent de vérifier que toutes les tâches ont été accomplies. Étant donné que les agents appellent plusieurs outils en séquence et que chaque appel à un outil individuel peut être interrompu ou rencontrer une erreur transitoire, cette étape permet de s'assurer que rien ne passe à travers les mailles du filet.

Il s'agit là d'un changement fondamental : le flux de travail est le déclencheur et le filet de sécurité ; l'agent est le cerveau.

Sous le capot : comment nous avons étendu l'agent de chasse aux menaces

Avant de poursuivre avec les résultats, il convient de s'arrêter sur ce qui a rendu cela possible. L'une des capacités les plus puissantes d'Agent Builder est la possibilité d'ajouter des outils supplémentaires aux agents existants. Plutôt que de partir de zéro, nous avons pris l'agent de chasse aux menaces par défaut et ajouté des outils personnalisés basés sur le flux de travail pour lui donner les capacités spécifiques requises par ce scénario.

Ce que nous avons ajouté

Agent Builder est livré avec des outils de plate-forme intégrés tels que platform.core.generate_esql et platform.core.product_documentation. Mais le véritable pouvoir réside dans l'ajout des vôtres. Nous avons complété l'agent de recherche de menaces par des outils appartenant à plusieurs catégories :

Cinq outils personnalisés. Il n'en fallait pas plus pour que l'agent de chasse par défaut vérifie automatiquement les logiciels malveillants, recherche les journaux, trouve l'intervenant de garde, crée un cas et lance un canal d'incident - tout cela en accélérant le temps de détection d'une menace potentielle.

La chaîne de raisonnement de l'agent

Ce qui est remarquable, c'est qu'étant donné le contexte d'Attack Discovery, l'agent a automatiquement décidé quels outils appeler et dans quel ordre. Ces étapes n'ont pas été écrites par un être humain.

Étape 1 : Consultation de VirusTotal: vt.hash.lookup

• Première action de l'agent : vérifier le hachage du logiciel malveillant.

Étape 2 : Générer une requête ES|QL: platform.core.generate_esql

• Une fois le logiciel malveillant confirmé, l'agent a recherché toutes les activités connexes.

Étape 3 : Documentation sur le produit: platform.core.product_documentation

• L'agent s'est référé à la documentation d'Elastic Security pour générer des commandes de remédiation pour la console de réponse !

Étapes de raisonnement montrant quels outils ont été appelés dans l'ordre pour la transparence

Montre la chaîne de raisonnement supplémentaire : référence à la documentation du produit, puis vérification des informations relatives à l'horaire de garde avant de créer un cas avec toutes les informations pertinentes et de notifier l'analyste de garde sur Slack.

Étape 4 : Vérifier l'heure actuelle : get.time

Étape 5 : Vérifier le calendrier de garde: check.on.call.schedule

• L'agent a lancé une requête ES|QL sur l'index on-call-schedule pour trouver le répondeur actuel :

Étape 6 : Créer un dossier: create.case

Étape 7 : Créer un canal Slack: create.channel

Pourquoi c'est important

L'agent ne suivait pas un script. Il a réfléchi à la situation et a pris une décision :

1. Tout d'abord, vérifiez que le logiciel malveillant est bien réel (VirusTotal).
2. Ensuite, comprenez l'impact (ES|QL log search)
3. Ensuite, déterminez comment remédier à la situation (documentation sur le produit).
4. Ensuite, trouvez la bonne personne pour répondre (calendrier de garde).
5. Ensuite, créez des artefacts de suivi (cas)
6. Enfin, coordonnez l'équipe (canal Slack)

C'est la différence entre un flux de travail (qui suit une séquence fixe) et un agent (qui raisonne sur ce qu'il faut faire ensuite). Le flux de travail a déclenché l'agent, qui s'est chargé du reste.

Étape 3 : Réponse automatisée aux incidents

Avec une confirmation à haut niveau de confiance, le flux de travail s'effectue automatiquement :

1. Crée un cas d'incident

Un dossier structuré est créé, auquel sont jointes toutes les preuves pertinentes :

• Attaque Résultats de la découverte
• Résultats de l'analyse de VirusTotal
• Correspondance des renseignements sur les menaces
• Analyse de l'agent Builder
• Mesures de réponse recommandées

2. Notifie le SOC

Un message Slack est envoyé au bon canal pour informer les analystes de l'incident critique.

3. Activation des actions de réponse

Le flux de travail peut éventuellement déclencher des actions de réponse automatisées :

• Isolement de l'hôte : Isolez srv-win-defend-01 via Elastic Defend
• Suspension de l'utilisateur : Désactivez james_spiteri dans Active Directory
• Blocage du réseau : Ajoutez le domaine C2 à la liste de blocage du pare-feu
• Balayage du COI : Lancez un balayage à l'échelle de la flotte à la recherche d'indicateurs de Chrysalis

---

Délai de confirmation : Avant et après

---

L'autre voie : Demandez à l'agent

Tout ce qui précède décrit le pipeline automatisé - Attack Discovery trouve la menace, le flux de travail se déclenche, l'agent la trie et le(s) bon(s) analyste(s) est (sont) notifié(s).

Mais il existe un autre moyen tout aussi efficace de l'utiliser : adressez-vous directement à l'Agent Builder et posez-lui la question en termes simples.

Scénario : Vous avez d'abord pris connaissance de la menace

Imaginez que vous parcourez vos flux d'informations sur les menaces et que vous tombez sur le billet de Rapid7 concernant la porte dérobée Chrysalis. Vous voulez simplement savoir si nous sommes compromis.

C'est tout. Le même agent, avec les mêmes outils, fait le reste :

1. Lit le rapport sur les menaces à l'aide de l'outil web.search pour extraire les IOC et les TTP du blog Rapid7.
2. Génère des requêtes ES|QL pour rechercher des indicateurs Chrysalis dans les journaux d'événements de vos fichiers, de votre réseau et de vos processus.
3. Vérifie dans VirusTotal les hachages de fichiers correspondants trouvés dans votre environnement.
4. Il produit un résumé prêt à l'emploi pour le RSSI avec les résultats, le niveau de confiance et les actions recommandées.

L'agent appelle les mêmes outils que ceux qu'il utiliserait dans le pipeline automatisé. La différence réside dans le point d'entrée : au lieu d'une découverte programmée de l'attaque qui déclenche un flux de travail, vous déclenchez l'agent en lui posant une question.

Pourquoi cela change la donne pour les analystes

Il s'agit là d'un aspect qu'il est facile d'ignorer, mais qui est d'une importance capitale : l'analyste n'avait pas besoin de connaître un seul langage de requête, un seul modèle d'index ou un seul nom d'outil.

Ils n'ont pas écrit ES|QL. Ils n'ont pas besoin de se rappeler où se trouvent leurs différentes données. Ils n'avaient pas besoin de se souvenir de la syntaxe de l'API de VirusTotal ou de savoir quel index de renseignements sur les menaces interroger.

Ils ont posé une question en langage naturel. L'agent s'est occupé du reste, notamment des index à rechercher, des requêtes à rédiger, des outils à utiliser et de la manière de synthétiser les résultats.

Pour un analyste junior qui a rejoint l'équipe le mois dernier, il s'agit d'une transformation. Pour un analyste senior qui fait ce travail depuis une dizaine d'années, ce sont des heures de sa vie qui lui sont rendues. Pour un RSSI qui souhaite une mise à jour, il suffit d'une question.

L'obstacle à une chasse efficace aux menaces vient de tomber : "connaît ES|QL et 47 , les modèles d'index" à "peuvent décrire ce qu'ils recherchent."

Principaux points abordés dans cet article

1. La fonction Attack Discovery programmée vous permet de ne pas manquer d'attaques - elle analyse en permanence vos alertes, de sorte que les menaces coordonnées apparaissent même lorsque personne ne surveille la file d'attente.
2. Les flux de travail orchestrent la réponse, en déclenchant des découvertes, en invoquant des agents et en exécutant des actions.
3. Agent Builder vous permet de créer ou d'étendre des agents en fonction de vos besoins - que vous partiez de zéro ou que vous ajoutiez des outils personnalisés à un agent existant, vous façonnez les capacités en fonction de votre environnement.
4. Les agents raisonnent, les flux de travail s'exécutent - l'agent a décidé de manière autonome d'appeler VirusTotal, de rechercher des journaux, de vérifier le planning de garde et de créer un canal Slack. Aucun humain n'a scénarisé cette séquence.
5. Deux points d'entrée, même puissance - le pipeline automatisé et l'interface de chat utilisent le même agent et les mêmes outils. Qu'il s'agisse d'une découverte programmée ou d'une question posée par un analyste, le résultat est le même.
6. Le langage naturel est le nouveau langage d'interrogation - les analystes n'ont pas besoin de connaître ES|QL, les modèles d'index ou la syntaxe de l'API. Ils décrivent ce qu'ils recherchent et l'agent s'occupe du reste.

La campagne de la porte dérobée de Chrysalis montre pourquoi cela est important. Lorsque des acteurs étatiques peuvent compromettre votre chaîne d'approvisionnement et établir une persistance en 4 secondes, vous avez besoin de défenses capables de rivaliser avec cette vitesse - qu'il s'agisse d'un pipeline automatisé fonctionnant pendant votre sommeil ou d'une conversation directe avec un agent lorsque vous êtes le premier à repérer la menace.