Automatisation de GOAD et de Live Malware Labs

Introduction : La nécessité d'une gamme de simulation évolutive et automatisée

Dans les opérations de sécurité modernes, l'ingénierie de détection n'est plus une discipline qui se règle d'elle-même. Le défi principal pour toute équipe de sécurité - et la question qui sous-tend toute l'approche de l'équipe violette - est simple : comment savoir si vos règles de détection fonctionnent réellement ? La validation continue de la logique de détection par rapport à un ensemble d'outils d'adversaires en constante évolution est désormais une exigence fondamentale.

On peut dire que le plus grand obstacle à cet exercice a toujours été la mise en place du laboratoire. Le provisionnement manuel d'une forêt Active Directory multi-domaines, sa configuration avec des vulnérabilités spécifiques et le déploiement d'un environnement d'analyse des logiciels malveillants séparé et confiné est un processus complexe et chronophage. Ce travail de configuration répétitif pèse lourdement sur la ressource la plus précieuse d'une organisation : le temps de ses analystes de sécurité principaux. Les discussions au sein de la communauté se font l'écho de cette frustration, soulignant les heures perdues en configuration manuelle avant qu'un seul test puisse être exécuté.

Ce blog présente une solution moderne qui élimine ce goulot d'étranglement en combinant l'automatisation rapide de l'infrastructure avec une plateforme unifiée d'analyse de la sécurité. La solution s'appuie sur deux éléments clés :

1. Ludus: Une superposition d'automatisation open-source qui déploie et configure des cyber-gammes complexes, multi-VM, à partir d'une seule commande.
2. Elastic Security: La plateforme qui unifie la gestion des informations et des événements de sécurité (SIEM), la détection et la réponse étendues (XDR) et la sécurité dans le nuage, fournissant une solution consolidée pour l'ingestion, la détection et la réponse aux menaces. Il offre à "la visibilité illimitée" nécessaire pour observer chaque action dans l'environnement simulé.

L'objectif de ce guide est de fournir un plan définitif, étape par étape, pour la mise en place de ce système intégré. Il montrera comment passer de tests de laboratoire lents, manuels et incohérents à un flux de travail d'ingénierie de détection continu, automatisé et évolutif, au-delà de ce que propose Elastic Cortado.

L'architecture de la solution : Ludus + Elastic

Cette architecture représente une simulation haute fidélité d'une entreprise hybride moderne. La gamme Ludus fait office de "centre de données sur site" ou IaaS, tandis que le déploiement Elastic Cloud représente la pile de sécurité "SaaS". Ce modèle reflète parfaitement les environnements hybrides et multiclouds qu'Elastic Security est conçu pour protéger, rendant l'architecture du test aussi précieuse que les attaques elles-mêmes.

La construction se compose des éléments de base suivants.

Volet 1 : La fondation (Ludus)

Ludus sert de couche d'infrastructure en tant que service (IaaS). Conçu pour fonctionner sur Proxmox 8/9 ou Debian 12/13, il utilise des fichiers de configuration YAML pour définir des réseaux virtuels complexes, supportant jusqu'à 255 VLANs distincts. En coulisses, Ludus tire facilement parti de Packer et d'Ansible pour construire, configurer et déployer les modèles de machines virtuelles à partir de ce seul fichier.
Passez en revue et suivez les étapes d'installation et les exigences en matière de matériel dans le guide de démarrage rapide de Ludus.

Volet 2 : Les cibles (les laboratoires)

Ce guide fusionne deux environnements Ludus distincts en une seule gamme complète permettant de tester un plus large éventail de menaces :

• Jeu de l'Active Directory (GOAD): Un laboratoire Active Directory spécialement conçu par les chercheurs en sécurité d'Orange Cyberdefense. Il est préconfiguré avec les fausses configurations et les vulnérabilités spécifiques nécessaires pour simuler les voies d'attaque courantes basées sur l'identité, telles que Kerberoasting, NTLM Relay et Active Directory Certificate Services (ADCS).
• XZbot Malware Lab: Un environnement à haut risque et à haute fidélité pour les logiciels malveillants. Ce laboratoire contient la porte dérobée CVE-2024-3094 réelle et fonctionnelle. Il s'agit là d'un test parfait et moderne pour une attaque sophistiquée de la chaîne d'approvisionnement en logiciels.

Avis de non-responsabilité important

La manipulation de logiciels malveillants vivants, même à des fins de recherche, peut constituer une violation des politiques d'utilisation acceptable (AUP) des fournisseurs d'accès à Internet ou des fournisseurs de services en nuage. Assurez-vous que vous possédez l'infrastructure (Ludus est sur site) et que votre fournisseur d'accès en amont autorise ce type de recherche, ou acheminez le trafic par l'intermédiaire d'un VPN.

Composant 3 : La grille de capteurs (agent élastique & Defend)

Pour obtenir une meilleure visibilité, chaque machine virtuelle de la gamme Ludus dans les laboratoires GOAD et XZbot sera instrumentée avec Elastic Agent, un agent unique et unifié pour la collecte et la protection des données (via Elastic Defend).

Cette instrumentation est automatisée via le rôle Ansible badsectorlabs/ludus_elastic_agent. Ce rôle est le pivot critique qui relie de manière programmatique la phase d'approvisionnement de l'infrastructure (Ludus/Ansible) à la phase d'instrumentation de la sécurité (Elastic), permettant un véritable flux de travail "infrastructure-as-code".

Il est essentiel que la politique de l'agent élastique soit configurée avec l'intégration d'Elastic Defend. L'agent passe ainsi d'un simple collecteur de journaux à une solution complète de détection des points finaux & Response (EDR)/eXtended Detection & Response (XDR), offrant des détections basées sur l'hôte (y compris la détection des logiciels malveillants et des ransomwares basée sur l'apprentissage automatique) et la télémétrie approfondie au niveau du noyau, essentielle à la détection.

Remarque : pour l'approche de l'équipe violette décrite dans ce blog, définissez les politiques en mode détection.

Composant 4 : Le cerveau (Elastic Cloud Hosted / Elastic Serverless)

Toutes les télémétries et alertes de sécurité des agents Elastic de la gamme Ludus sont transmises à un déploiement centralisé Elastic Cloud Hosted (ECH) ou Elastic Serverless. C'est là que la puissance analytique de la plateforme unifiée prend tout son sens. L'utilisation d'une plateforme cloud-native n'est pas seulement une question d'hébergement ; c'est ce qui permet de débloquer les fonctionnalités les plus avancées et les plus puissantes d'Elastic, y compris la découverte d'attaques et l'assistant IA. Cliquez ici pour commencer un essai sur Elastic Cloud.

Le diagramme ci-dessous donne un aperçu de la construction, qui est basée sur le laboratoire GOAD.

Phase 1 : Construction et instrumentation du champ de tir

Cette section fournit un guide technique, étape par étape, pour la configuration et le déploiement de la gamme automatisée. Le processus suit un modèle clair "infrastructure-as-code" (IaC), où l'instrumentation de sécurité est définie en même temps que l'infrastructure elle-même, ce qui garantit une posture de surveillance cohérente et reproductible pour chaque déploiement. L'instance Elastic Cloud et ses configurations peuvent être gérées avec le fournisseur Elastic Cloud et Elastic Stack Terraform pour un modèle IaC complet de la gamme et du SIEM.

3.1 Configuration de la politique de l'agent élastique (dans Kibana)

Avant d'exécuter le déploiement de la gamme Ludus, la politique de l'agent doit être créée dans l'instance Elastic Cloud. C'est cette politique qui permet la puissante télémétrie EDR/XDR.

Le flux opérationnel est le suivant :

1. Connectez-vous à l'instance Elastic Cloud (ECH) ou Elastic Serverless Kibana.
2. Naviguez vers Management > Fleet.
3. Créez une nouvelle politique d'agent (par exemple, "ludus-range-policy"). Le rôle ludus_elastic_agent inscrit les agents dans la politique que vous spécifiez dans votre personnalisation au niveau de la VM ou dans la politique par défaut liée à la variable globale.
4. Ajoutez l'intégration Elastic Defend à cette politique.
5. Configurez l'intégration Elastic Defend pour qu'elle s'exécute en mode détection. Cela active l'ensemble des télémétries EDR.
6. Enregistrez la politique et cliquez sur "Add agent." Cela fournira le jeton d'inscription (pour ludus_elastic_enrollment_token) et l'URL du serveur de flotte (pour ludus_elastic_fleet_server) nécessaires pour le fichier ludus.yml.
7. (Facultatif) Répétez les étapes 3 à 6 pour créer des stratégies personnalisées en fonction des fonctions et des capacités de l'hôte pour la personnalisation des stratégies au niveau de la VM.

Une fois que cette politique est créée et que le jeton est collé dans le fichier ludus.yml, le déploiement de la gamme Ludus exécute le flux de travail complet et automatisé. Ludus approvisionne les machines virtuelles et Ansible installe l'agent Elastic, qui s'inscrit ensuite dans Fleet et extrait automatiquement la politique contenant l'intégration d'Elastic Defend. Cela permet de disposer d'une riche télémétrie EDR - processus au niveau du noyau, fichiers, réseau et événements de registre - dès la naissance du laboratoire.

3.2 Configuration YAML de Ludus (ludus.yml)

Ludus fournit ici la marche à suivre pour déployer la gamme GOAD. La configuration de la plage est stockée dans le fichier de configuration ludus.yml. En ce qui concerne la gamme GOAD, elle est située à l'adresse ad/GOAD/providers/ludus/config.yml.
La configuration complète en annexe est un exemple basé sur un exemple de configuration en cours d'exécution qui fusionne un laboratoire GOAD complet (sur le VLAN 10) avec le laboratoire XZbot (sur le VLAN 20).

Pour déployer une version personnalisée pendant l'installation, mettez à jour le fichier ad/GOAD/providers/ludus/config.yml avant d'exécuter le script goad.sh à l'étape 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

Deux options de configuration clés permettent de personnaliser la gamme :

1. Variables globales : Pour simplifier la configuration et éviter les répétitions, les variables Elastic Agent sont définies une seule fois au niveau supérieur dans un bloc global Ansible.vars et sont héritées par toutes les VM.

   Le jeton d'enrôlement détermine la politique de l'agent élastique utilisée.

# 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 au niveau de la VM : Les variables de l'agent élastique peuvent être configurées au niveau de la VM pour personnaliser la politique appliquée. Celles-ci peuvent être combinées avec la variable globale, par exemple lorsque la version de l'agent et fleet_server sont définis via des variables globales et que les jetons d'enrôlement sont définis au niveau de la VM afin d'appliquer différentes politiques aux VM.

# --- 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)

Automatiser le déploiement des agents élastiques

L'extrait ludus.yml ci-dessus illustre l'automatisation. En ajoutant le rôle badsectorlabs.ludus_elastic_agent à la section ansible.roles de chaque définition de VM, Ludus installera et configurera automatiquement l'agent lors du déploiement.

Ce rôle Ansible unique est compatible avec tous les systèmes d'exploitation de notre laboratoire hétérogène, y compris Windows (pour GOAD), Kali et Debian (pour XZbot).

Comme le montre le fichier YAML simplifié, le bloc ansible.vars au niveau supérieur transmet les paramètres critiques au rôle :

• ludus_elastic_fleet_server : L'URL et le port du serveur Fleet pour votre déploiement Elastic Cloud (par exemple, your-fleet.example.com:443).
• ludus_elastic_enrollment_token : Le jeton qui inscrit l'agent.
  L'exemple complet définit le ludus_elastic_enrollment_token au niveau de la VM pour démontrer la possibilité d'utiliser différentes politiques.
• ludus_elastic_agent_version : La version spécifique de l'agent à installer (par exemple, 9.2.1).

Note : L'hôte Kali aura également Elastic Defend déployé pour surveiller le comportement des attaquants, ce qui ne sera pas possible dans un scénario réel.

La sécurité d'abord : isolement, OPSEC et logiciels malveillants vivants

Cette section contient un avertissement critique en matière de sécurité et de sûreté opérationnelle (OPSEC). Cette configuration implique un risque important et non négligeable qui doit être géré de manière professionnelle.

4.1 La menace : Ceci n'est pas une simulation

Il faut le dire sans équivoque : Le guide de laboratoire Ludus XZbot et son rôle Ansible associé installent la porte dérobée CVE-2024-3094 réelle et fonctionnelle. Il ne s'agit pas d'un code bénin et simulé. La documentation du laboratoire indique ce qui suit : "Danger : Ce rôle contient des logiciels malveillants (volontairement)."

Bien qu'il soit décrit comme une porte dérobée "passive" (ce qui signifie qu'il faut qu'un attaquant la déclenche activement), toute machine virtuelle exécutant ce code et disposant d'une connexion internet ouverte constitue une responsabilité catastrophique. Il peut être scanné, exploité par des acteurs inconnus ou utilisé comme point d'appui pour attaquer d'autres réseaux.

4.2 La contradiction : Isolement et connectivité au nuage

Cette architecture crée un conflit opérationnel direct et critique :

1. Exigence 1 (sécurité) : Le laboratoire de lutte contre les logiciels malveillants doit être isolé de l'internet public afin d'éviter tout risque de compromission ou d'intrusion.
2. Exigence 2 (Fonction) : L'agent Elastic doit disposer d'une connectivité internet sortante pour atteindre les points de terminaison Elastic Cloud Hosted / Elastic Serverless pour l'inscription et le streaming de données.

Un utilisateur novice échouerait ici, soit en exposant son laboratoire infecté au monde entier, soit en l'isolant si complètement qu'aucune télémétrie de sécurité ne pourrait être collectée.

4.3 La solution : Sortie par trou d'épingle via le mode d'essai Ludus

Le conflit est résolu à l'aide du mode detestintégré de Ludus "" , qui permet un contrôle granulaire de la sortie du réseau. Cette fonction est utilisée pour la sortie du trou d'épingle, qui permet le contrôle de l'agent, la télémétrie et la sortie du journal.

# 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

Cette configuration offre une solution de niveau expert : le logiciel malveillant est confiné en toute sécurité, tandis que l'agent Elastic ne dispose que de la connectivité minimale requise pour effectuer des mises à jour de politiques (via la communication avec le point d'extrémité fleet ) et pour ingérer des données (via la communication avec le point d'extrémité ES ).

4.4 Accès à la gamme en mode test (WireGuard)

Lorsque le mode test est activé, le routage standard échoue. Vous ne pouvez pas simplement vous connecter en SSH à votre VM Kali depuis votre LAN local car le routeur bloque le trafic. Ludus fournit un canal de gestion hors bande à l'aide de WireGuard.

Ludus configure une interface WireGuard (wg0) sur le routeur VM (198.51.100.1) et vous attribue une IP client statique (par exemple, 198.51.100.2).

• Règles d'autorisation persistantes : La configuration du pare-feu du routeur inclut des règles spécifiques dans la chaîne LUDUS_DEFAULTS. Ces règles ACCEPTENT explicitement le trafic provenant ou destiné au sous-réseau WireGuard (198.51.100.0/24).
• Priorité : Comme ces règles existent dans la chaîne LUDUS_DEFAULTS, elles prévalent sur les règles DROP appliquées par le mode de test.

Comment se connecter :

1. Générer votre configuration: ludus user wireguard > ludus.conf
2. Importez-le dans votre client WireGuard local et activez le tunnel.
3. Connectez-vous directement aux IP privées de vos VM (par exemple, 10.10.10.11) via le tunnel.

Phase 2 : Exécution des attaques

Une fois le champ de tir haute fidélité et entièrement instrumenté déployé, la phase de l'équipe rouge "" peut commencer. Il s'agit de se connecter à une VM dédiée à l'attaque (comme la VM Kali incluse ou une VM remnux-analyzer) et d'exécuter les attaques. Cette activité génère une télémétrie riche et malveillante qu'Elastic Defend capturera.

Cette gamme combinée permet de tester les défenses contre les deux principaux vecteurs de menace au niveau macro : les attaques basées sur l'identité "living-off-the-land" (LotL) et les intrusions dans la chaîne d'approvisionnement basées sur la vulnérabilité.

5.1 Simulation Active Directory (GOAD)

• L'accès initial (le "Credential Stuffing")
  1. L'attaquant cible le périmètre externe. À l'aide d'une liste d'identifiants violés, vous exécutez une attaque de bourrage de mot de passe contre le domaine Essos.local. Vous validez avec succès les informations d'identification de l'utilisateur khal.drogo.
  2. Exemple d'outil : kerbrute ou smartbrute
  3. Résultat : Informations d'identification valides pour un utilisateur de domaine à faible privilège.
• Escalade de privilèges (PrintNightmare)
  1. khal.drogo a des droits limités. Pour prendre pied sur le serveur CastelBlack, vous exploitez PrintNightmare (CVE-2021-34527). Cette vulnérabilité dans le service Windows Print Spooler permet à tout utilisateur authentifié d'installer un pilote d'impression malveillant. Vous téléchargez un pilote qui ajoute un nouvel utilisateur administrateur local à la boîte.
  2. Exemple d'outil : Script d'exploitation CVE-2021-34527.py
  3. Résultat : Accès au SYSTÈME local sur CastelBlack.
• Credential Dump (Préparation DCSync)
  1. En tant que SYSTEM/Admin sur CastelBlack, vous inspectez la machine à la recherche d'informations d'identification mises en cache. Vous exécutez secretsdump d'Impacket pour extraire les hachages de la base de données SAM et de la mémoire LSASS. Vous découvrez le hachage NTLM pour le compte Administrateur intégré, qui a été laissé en mémoire lors d'une session d'assistance précédente.
  2. Exemple d'outil : impacket-secretsdump
  3. Résultat : NTLM Hash d'un Admin de domaine ou d'un compte à privilèges élevés.
• La kermesse
  1. Avec des identifiants de domaine valides, vous pivotez vers le réseau interne. Vous demandez des tickets de service Kerberos (TGS) pour des Service Principal Names (SPN) dans l'environnement. Vous ciblez le compte MSSQLSvc. Vous prenez le ticket crypté hors ligne et le craquez pour révéler le mot de passe en clair du compte de service SQL.
  2. Exemple d'outil : Rubeus ou GetUserSPNs.py
  3. Résultat : Mot de passe en clair pour le compte de service MSSQL.
• Attaques MSSQL
  1. Vous utilisez les identifiants SQL craqués pour vous authentifier directement auprès du serveur SQL de Braavos. Étant donné que le compte de service dispose de droits d'administrateur système, vous abusez de la procédure stockée xp_cmdshell. Cette fonction vous permet de lancer un shell de commande Windows directement à partir d'une requête SQL, ce qui vous permet d'exécuter un code à distance (RCE) sur le serveur de base de données.
  2. Exemple d'outil : mssqlclient.py
  3. Résultat : RCE sur le serveur de base de données.
• Persistance (tâche programmée)
  1. Pour vous assurer que vous ne perdrez pas l'accès si le mot de passe SQL change, vous établissez la persistance. Vous créez une tâche planifiée Windows sur le serveur SQL compromis. Cette tâche est configurée pour exécuter un binaire de balise tous les jours, en tant que SYSTEM.
  2. Exemple d'outil : schtasks.exe ou PowerShell
  3. Résultat : Persistance à long terme.

5.2 Simulation de laboratoire de logiciels malveillants (XZbot)

• Étape 7 : Pivot de la chaîne d'approvisionnement (porte dérobée XZ)
• Simultanément, vous ciblez l'infrastructure Linux dans la zone démilitarisée. Vous déclenchez la porte dérobée XZ préimplantée (CVE-2024-3094) sur la VM xz-backdoor-dect. En manipulant la poignée de main SSH à l'aide d'une clé cryptographique spécifique, vous contournez entièrement l'authentification et exécutez des commandes en tant que root sans laisser de journaux SSH standard.
• Outil : xzbot
• Résultat : Accès à la racine de l'infrastructure Linux grâce à la compromission de la chaîne d'approvisionnement.
• L'attaquant utilise le client xzbot fourni par le laboratoire Ludus.
• Depuis la VM de l'attaquant, la commande suivante est exécutée pour déclencher la porte dérobée sur l'hôte Debian vulnérable :
  xzbot --ssh-addr '10.X.X.X:22' -cmd 'setsid sh -c "echo test"' 2>& 1
• Cette action provoque l'apparition anormale d'un shell dans le processus sshd sur la cible et l'exécution de la commande en tant que root, créant ainsi une preuve définitive de l'exécution.

Phase 3 : Détection unifiée & Investigation avec Elastic Security

Il s'agit de la récompense de l'équipe bleue "" . La télémétrie et les alertes générées dans la phase 2 sont maintenant disponibles pour analyse au sein de la plateforme unifiée Elastic Security.

6.1 Le "Powerful SIEM": Visibilité centralisée & Détections pré-intégrées

La puissance du SIEM Elastic ne réside pas seulement dans sa capacité à collecter passivement des journaux. Sa puissance provient de l'analyse active qu'il effectue sur les données contextuelles approfondies fournies par Elastic Defend. Le site "Complete Endpoint Visibility" de Defend fournit non seulement des journaux de base, mais aussi une télémétrie au niveau du noyau - créations de processus, modifications de fichiers, connexions réseau et changements de registre.

Ces données riches, toutes normalisées selon le schéma commun Elastic (ECS), alimentent la vaste bibliothèque d'Elastic de plus de 1500 règles de détection préconstruites et mappées par MITRE. Ces règles sont recherchées, développées et maintenues par l'équipe d'Elastic Security Labs, offrant ainsi une valeur de détection prête à l'emploi.

La gamme Ludus constitue la plateforme de validation parfaite de cette valeur. Les attaques exécutées au cours de la phase 2 ne sont pas théoriques ; elles sont directement mises en correspondance avec des artefacts spécifiques attendus ("smoking gun"). Une combinaison de règles prédéfinies et de règles personnalisées est intentionnellement utilisée dans l'exemple pour alerter sur des comportements spécifiques.

Remarque : les règles de détection élastiques sont ouvertes et transparentes. Vous pouvez consulter la logique, contribuer ou soulever des questions directement sur le site(https://github.com/elastic/detection-rules).

6.2 Approfondissement : Traçage des chaînes de processus avec l'analyseur d'événements

Les deux laboratoires (GOAD et XZbot) offrent une occasion parfaite d'utiliser les outils d'investigation spécialisés d'Elastic. L'interface utilisateur de l'analyseur d'événements est conçue pour abstraire la complexité des journaux JSON dans un modèle cognitif qui s'aligne sur le mode de pensée des analystes de la sécurité : Chaînes de processus. L'interface se compose de trois zones d'interaction principales : le canevas graphique, le panneau de détail et l'intégration de la ligne de temps.

Que voyons-nous ?

Le canevas graphique (l'arbre de processus)

La vue centrale est un graphe acyclique dirigé où :

• Nœuds (cubes) : Chaque cube représente l'exécution d'un processus distinct. La visualisation fait la distinction entre l'événement "Anchor" (mis en évidence par un halo bleu) et le contexte environnant.
• Les arêtes (lignes) : Les lignes représentent la relation parent-enfant. La directionnalité est implicite (de haut en bas ou de gauche à droite), indiquant le flux d'exécution.
• Badge visuel : Les nœuds ne sont pas des icônes statiques, mais des indicateurs dynamiques.
  • Badges d'alerte : Si un processus spécifique a déclenché une règle de détection (par exemple, "Malware Detected"), un badge de couleur apparaît sur le cube. Cela permet à un analyste d'identifier instantanément l'étape de la chaîne qui a été signalée par le moteur de détection.
  • Contexte de l'utilisateur : Des indices visuels peuvent indiquer si un processus a changé de contexte utilisateur (par exemple, d'un utilisateur local à SYSTEM), signalant ainsi une escalade des privilèges.

Le panneau des détails (métadonnées médico-légales)

Un clic sur n'importe quel nœud déclenche l'ouverture du panneau de détail, qui s'ouvre généralement par la droite. Ce panneau est la source principale de "Ce que vous pouvez voir" à un niveau granulaire. Il expose les champs essentiels à la vérification :

• Arguments de la ligne de commande : Il s'agit sans doute de l'artefact médico-légal le plus précieux. L'analyseur affiche la chaîne complète, révélant les drapeaux, les scripts et les charges utiles codées (par exemple, powershell.exe -w hidden -enc Base64).
• Chemin d'accès et hachage du processus : Le chemin d'accès complet au fichier permet d'identifier les masques (par exemple, svchost.exe s'exécute à partir de C:Temp au lieu de C:\NWindows\NSystem32). Les hachages de fichiers (MD5, SHA-1, SHA-256) sont présentés pour permettre le recoupement avec les renseignements sur les menaces.
• Informations sur le signataire : Les informations relatives à la signature numérique du binaire permettent de distinguer les binaires Microsoft fiables des logiciels malveillants non signés.
• Nombre d'événements connexes : Au lieu d'encombrer le graphique avec des milliers de modifications de fichiers, le nœud affiche des statistiques sommaires (par exemple, "15 événements de fichiers," " 3 connexions réseau"). En cliquant sur ces statistiques, vous accédez généralement à une liste ou à une chronologie de ces actions spécifiques.

La dimension temporelle (filtre temporel)

Un aspect essentiel et souvent négligé de l'analyseur est sa gestion du temps. Les attaques peuvent durer longtemps "." Un processus parent peut avoir démarré il y a plusieurs semaines (par exemple, un service légitime), alors que l'enfant malveillant est né aujourd'hui. L'analyseur comprend un curseur de temps qui permet à l'analyste d'élargir la fenêtre d'interrogation. "Par défaut, il peut s'agir d'une fenêtre étroite autour de l'alerte, mais l'extension de cette fenêtre permet au graphique de remonter jusqu'à" dans les niveaux de données chaudes ou froides afin de trouver le processus parent qui s'exécute depuis longtemps.

Comment fonctionne-t-elle ?

La capacité opérationnelle de l'analyseur d'événements s'appuie sur l'Elastic Common Schema (ECS). Dans un environnement de sécurité hétérogène, les journaux proviennent de diverses sources - terminaux Windows, serveurs Linux, pare-feu de réseau et fournisseurs de services en nuage - chacune ayant une taxonomie unique. Un agent CrowdStrike peut étiqueter l'ID d'un processus comme TargetProcessId, tandis qu'un événement Sysmon utilise ProcessId. Sans normalisation, la corrélation de ces événements en une seule chaîne est algorithmiquement impossible.
Le SCE résout ce problème en appliquant une hiérarchie stricte des champs. L'analyseur d'événements s'appuie sur des champs ECS spécifiques et de haute fidélité pour construire le graphique visuel :

• process.entity_id: C'est la pierre angulaire de la logique de l'analyseur. Les systèmes d'exploitation recyclent les identifiants de processus (PID). Un PID de 1234 peut appartenir à svchost.exe à 09:00 et à malware.exe à 14:00. S'appuyer sur le PID pour une analyse historique à long terme introduit des collisions qui corrompent le graphique visuel, en reliant des événements sans rapport entre eux. Le process.entity_id est une chaîne unique générée par l'agent Elastic (ou par des bêtes conformes à ECS) qui persiste de manière unique dans l'index, garantissant que le graphique représente une instance d'exécution distincte, indépendamment de la réutilisation du PID.
• process.parent.entity_id : Ce champ établit l'arête dirigée entre les nœuds. En recherchant de manière récursive les événements pour lesquels le process.entity_id d'un événement correspond au process.parent.entity_id d'un autre, l'analyseur reconstruit la lignée.

event.sequence: Dans les environnements à haute vitesse, l'ordre des événements (par exemple, la modification du fichier a-t-elle eu lieu avant ou après la connexion au réseau ? Les horodatages et les numéros de séquence ECS permettent à l'analyseur d'ordonner les événements par ordre chronologique dans les détails du nœud visuel.

6.3 Approfondissement : Reconstruction de l'activité de l'utilisateur avec Session Viewer

Pour l'attaque XZbot (Linux), le Session Viewer est l'outil le plus performant. Il est spécialement conçu pour "surveiller et étudier l'activité des sessions sur l'infrastructure Linux".

Lorsque l'alerte d'exécution potentielle via XZBackdoor se déclenche, l'analyste examine le processus sshd associé. Le Session Viewer présente un format"très lisible, inspiré du terminal". Il reconstruit la session de l'attaquant, en montrant le processus sshd et son processus enfant anormal (sh).

En outre, il indique la commande exacte qui a été exécutée (sh -c setsid sh -c "usermod -aG sudo sysadmin_backup") et peut même afficher la sortie de cette commande. Il s'agit de la preuve irréfutable "" , présentée à l'analyste sous la forme d'un texte clair et lisible par l'homme, ce qui lui permet d'observer après coup la session ATS de l'attaquant.

Que voyons-nous ?

L'interface utilisateur du Session Viewer est explicitement conçue pour combler le fossé entre l'analyse abstraite des journaux et l'expérience du terminal natif d'un administrateur Linux. Contrairement à l'analyseur d'événements, qui se concentre sur les chaînes de processus des logiciels malveillants, la visionneuse de sessions présente une visualisation arborescente et ordonnée dans le temps qui reconstitue la narration linéaire d'une session shell.

L'arborescence et la chronologie du processus

L'élément central de la vue est un graphe acyclique dirigé (DAG) affiché sous la forme d'une liste hiérarchique.

• Flux vertical : le visualiseur de session organise les processus verticalement, imitant le flux d'un fichier historique de terminal tout en préservant la hiérarchie. Les processus enfants sont indentés par rapport à leurs parents. Cela permet à un analyste de faire immédiatement la distinction entre une commande exécutée directement par l'utilisateur (par exemple, curl) et un processus généré par l'exécution d'un script (par exemple, curl s'exécutant dans un script setup.sh).
• Mode Verbeux : Une bascule permet aux analystes de basculer entre une vue filtrée (montrant l'activité significative de l'utilisateur) et le mode Verbose de "." Lorsqu'il est activé, ce mode révèle des événements typiquement bruyants tels que les scripts de démarrage de l'interpréteur de commandes (.bashrc), les aides à la complétion de l'interpréteur de commandes et les bifurcations causées par les commandes intégrées. Ceci est crucial pour détecter les mécanismes de persistance cachés dans les scripts de profil.

Badges et indicateurs visuels

L'interface utilisateur utilise un système sophistiqué de badges et d'icônes pour fournir un contexte immédiat sans exiger de l'analyste qu'il se plonge dans chaque nœud. Ces repères visuels sont essentiels pour un triage rapide.

Indicateurs visuels dans Elastic Session Viewer

Vue de la sortie du terminal

En survolant le bouton Terminal Output sur un nœud de processus, vous verrez apparaître un badge indiquant la taille de la sortie capturée. En cliquant sur ce bouton, vous ouvrez la vue Terminal Output, qui affiche les données process.io.text. Il s'agit de la fonction "Smoking Gun" pour les enquêtes sur Linux.

• Capacité de relecture : Elle permet à l'analyste de voir exactement ce que l'utilisateur a vu. Si un attaquant a exécuté cat /etc/passwd, l'arborescence des processus montre l'exécution ; la vue Terminal Output montre le contenu du fichier passwd tel qu'il a été affiché à l'attaquant.
• Reconstruction de l'entrée : Comme le visualiseur capture les E/S TTY, il capture non seulement l'exécution de la commande, mais aussi la frappe. Cela peut révéler des espaces, des fautes de frappe et des corrections (par exemple, taper sdo [espacement arrière] sudo), qui sont des indicateurs comportementaux forts d'un adversaire humain plutôt que d'un script automatisé.

L'avantage Elastic : La chasse automatisée alimentée par l'IA

Le processus décrit dans la phase 3 est une enquête puissante, menée par un analyste. Cependant, le principal avantage de l'utilisation d'Elastic Cloud Hosted (ECH) ou d'Elastic Serverless est l'accès programmatique à une pile d'IA générative intégrée. Cette pile permet de passer d'une corrélation manuelle à une chasse automatisée pilotée par l'IA.

Remarque : les fonctions d'IA d'Elastic fonctionnent avec les LLM Elastic Managed prêts à l'emploi ou avec des LLM tiers configurés à l'aide de l'un des connecteurs disponibles.

7.1 Des alertes aux attaques : Corrélation automatisée et découverte d'attaques

Les laboratoires GOAD + XZbot génèrent plusieurs alertes discrètes, comme le montre le tableau ci-dessus. Un analyste débutant serait confronté à une file d'attente d'alertes : Kerberoasting potentiel, demande de certificat suspecte et porte XZBackdoor potentielle, et il devrait assembler manuellement "" cette attaque complexe et transdomaine.

C'est le problème que résout Attack Discovery. Cette fonctionnalité GenAI, disponible dans les niveaux Enterprise et Serverless, "offre une chasse aux menaces entièrement automatisée à l'échelle". Il "AI analyse chaque alerte pour découvrir les menaces cachées", en corrélant automatiquement les signaux disparates du laboratoire Ludus en une seule enquête de haute fidélité "Attack".

La principale valeur de l'Attack Discovery pour un analyste médico-légal est la compression du temps. Il automatise l'assemblage mental "" qui définit l'analyse de niveau 1 et 2.

Déconstruction du site "Mental Stitching"

Prenons un exemple d'enquête sans découverte d'attaque.

1. Déclencheur : Vous voyez une alerte : "Exécution PowerShell suspecte."
2. Requête : Vous pivotez vers la ligne temporelle de l'hôte.
3. Balayez : Vous faites défiler 15 minutes. Vous voyez un événement "File Download".
4. Hypothèse : "L'utilisateur a peut-être téléchargé un mauvais fichier, qui a lancé PowerShell."
5. Vérification : Vous vérifiez le nom du fichier. Il s'agit de invoice.js.
6. Conclusion : "Téléchargement d'un logiciel malveillant confirmé."

Ce processus prend entre 10 et 30 minutes, en fonction des compétences de l'analyste et de sa familiarité avec l'environnement. Attack Discovery exécute cette séquence complète en quelques secondes. Il examine l'alerte PowerShell, voit l'événement de téléchargement de fichier dans le contexte correspondant et présente une déclaration de découverte : "L'utilisateur a exécuté un script PowerShell suspect provenant probablement du fichier téléchargé "invoice.js"."

Cette fonctionnalité comprend la persistance des données (les résultats sont sauvegardés pour un suivi historique) et la programmation des actions & (elles s'exécutent automatiquement et peuvent déclencher des réponses ou des flux de travail Elastic ultérieurs), faisant passer le SOC d'une posture réactive à une posture proactive.

Exemple

Dans notre exemple, au fur et à mesure que l'attaque se produit, nous commençons à voir apparaître des alertes. Au lieu de trier les alertes individuellement, nous utilisons Attack Discovery pour le triage.
Compression du temps moyen de traitement en quelques secondes et identification rapide des attaques 2 .

7.2 Accélérer le triage avec l'assistant IA

L'assistant de sécurité Elastic utilise l'IA générative pour vous aider à trouver, réparer et comprendre les menaces de sécurité. Il fonctionne directement au sein d'Elastic Security. Vous interagissez avec lui par le biais d'une interface de discussion pour examiner les alertes et écrire du code.

Dans notre exemple, une fois qu'Attack Discovery a identifié une attaque corrélée, nous utilisons l'assistant IA pour enquêter. L'assistant offre deux fonctions essentielles :

1. Investigations en langage naturel : L'analyste peut poser des questions en langage clair telles que : "Résumez cette attaque", "Quelle est la tactique de MITRE pour ce processus ?", "Qu'est-ce que le spouleur d'impression ?" ou "Fournissez des suggestions de remédiation".

2. Flux de travail de validation des requêtes agentiques : Cette fonction avancée permet à l'IA de "de générer des requêtes ES|QL validées sur mesure". Un analyste peut demander : "Trouvez toutes les connexions réseau de l'hôte impliqué dans l'alerte XZbot", et l'assistant rédigera, validera et corrigera lui-même la requête avant de la présenter, abaissant ainsi considérablement la barrière des compétences pour la chasse aux menaces haut de gamme.
   

Fonctionnement

L'assistant connecte votre pile Elastic à un LLM de votre choix (par exemple, GPT-5, Claude, Gemini). Il utilise la méthode RAG (Retrieval Augmented Generation) pour extraire les données pertinentes (journaux, alertes et documentation interne) de votre environnement. Vous pouvez le configurer pour qu'il anonymise les champs sensibles (PII ou métadonnées hôte/IP) avant d'envoyer l'invite au modèle, ce qui garantit la confidentialité de vos données pendant que le modèle raisonne sur les modèles de comportement.

7.3 Automatisation intelligente avec des flux de travail élastiques

Les attaques décrites ci-dessus génèrent des alertes complexes en plusieurs étapes. Leur traitement manuel est lent. Elastic s'est attaqué à ce problème en rachetant Keep, une plateforme open-source de gestion des alertes et des AIOps. Dans Elastic 9.3, cette technologie est intégrée directement dans Kibana en Technical Preview sous le nom d'Elastic Workflows.

Qu'est-ce qu'un flux de travail ?

Elastic Workflows est un moteur d'automatisation intégré à la plateforme Elasticsearch. Vous définissez les flux de travail en YAML - ce qui les déclenche, les étapes qu'ils suivent, les actions qu'ils effectuent - et la plateforme se charge de l'exécution. Un flux de travail peut interroger votre environnement, transformer et enrichir les données de sécurité, se brancher en fonction de conditions, appeler des API externes et s'intégrer à des services tels que Slack, Jira, PagerDuty et bien d'autres grâce à des connecteurs que vous avez déjà configurés. Les flux de travail peuvent également faire appel à des agents d'intelligence artificielle pour raisonner dans le cadre d'enquêtes complexes, puis poursuivre les actions de réponse en fonction de ce que l'agent découvre. Elastic Workflows combine l'automatisation par scripts avec le raisonnement de l'IA, nativement dans votre SIEM, là où se trouvent déjà vos données de sécurité.

Comment cela fonctionne-t-il ? L'agrégateur d'alertes " & Moteur de flux de travail"

Les flux de travail constituent la couche intermédiaire entre la détection et la remédiation, et fonctionnent selon trois mécanismes principaux :

• Ingestion de sources multiples : Les flux de travail s'étendent au-delà d'Elastic. L'extraction de données supplémentaires à des fins d'enrichissement, d'analyse ou de triage initial.
• Workflow-as-Code (YAML) : Les flux de travail sont définis dans des fichiers YAML. Cela permet aux équipes de contrôler la version de leurs procédures de réponse aux incidents en tant que code.
• Le moteur de workflow : Lorsqu'une alerte se déclenche dans Elastic (ou dans un outil externe), le moteur de workflow exécute une série d'étapes :
  1. Enrichissement : Interrogation d'une API (comme VirusTotal ou Active Directory) pour ajouter du contexte.
  2. Logique : Utilisation d'instructions if/else pour déterminer la gravité.
  3. Action : Envoi d'un message Slack, création d'un ticket Jira ou déclenchement d'une action de réponse Elastic Defend.

Prenons un exemple de flux d'alertes et d'actions.

• Déclencheur : Vous reliez le flux de travail à une règle spécifique, telle que "Alerte de détection de malveillance".
• Les étapes : Vous définissez une séquence d'actions.
  1. Triage (Agentic) : Transmettez l'alerte à l'assistant IA. Posez les questions : "Comment remédier et répondre à l'alerte ci-dessous ?"
  2. Enrichissez: Joignez la réponse de l'assistant d'intelligence artificielle à l'alerte sous forme de note.
  3. Réagissez : Créez un cas avec un lien vers la note d'alerte.

Exemple

Dans notre exemple, nous avons des alertes qui déclenchent notre flux de travail - Enrichissement des alertes & Création de cas.
Nous le déclencherons également directement à partir de l'interface utilisateur des flux de travail afin de démontrer les différentes étapes.

• Le contexte d'alerte est fourni en tant qu'entrée à l'assistant AI de sécurité.
• La réponse est ajoutée en tant que note aux alertes de sécurité.
• Un cas est créé avec les métadonnées de l'alerte (horodatage, gravité, nom de la règle et motif de l'alerte).
• Un lien vers l'affaire est ajouté à l'affaire en tant que commentaire. Note : ceci n'apparaît pas dans le GIF.

Conclusion : De la configuration manuelle à l'émulation continue

Ce blog a fourni un plan complet pour une gamme de simulation avancée, évolutive et, surtout, sûre.

1. Nous avons construit : Une gamme complexe de laboratoires multiples (GOAD + XZbot) a été déployée avec une seule commande à l'aide de Ludus.
2. Nous avons instrumenté : L'ensemble de la gamme a été instrumenté de manière transparente avec Elastic Agent et Defend dans le cadre du déploiement automatisé, en utilisant le rôle Ansible ludus_elastic_agent.
3. Nous avons sécurisé : Le conflit critique entre l'isolation des logiciels malveillants et la connectivité des agents en nuage a été résolu grâce aux contrôles de réseau granulaires de Ludus "OPSEC".
4. Nous avons validé : Les puissantes capacités SIEM de la plateforme ont été prouvées en validant les règles de détection préconstruites et prêtes à l'emploi d'Elastic contre des attaques réelles et connues.
5. Nous avons enquêté : Les outils d'investigation spécialisés, Event Analyzer et Session Viewer, ont été utilisés pour retracer les chemins exacts de l'attaque sur les hôtes Windows et Linux.
6. Nous avons automatisé : " Le multiplicateur de force "de la pile GenAI d'Elastic a été démontré, avec Attack Discovery corrélant automatiquement des alertes disparates en une seule attaque et l'assistant IA accélérant l'enquête finale.
7. Nous avons répondu: La puissance des flux de travail élastiques fournit les cerveaux et l'automatisation pour les actions de réponse complexes et les flux de remédiation.

Cette architecture n'est pas une construction unique. Il s'agit d'un schéma directeur pour la mise en place d'une filière d'ingénierie de détection continue. "modernise les opérations de sécurité" en permettant aux équipes purple de démanteler, reconstruire et tester à nouveau leurs défenses à la demande, en veillant à ce que leur posture de détection évolue aussi vite que les menaces.

Passez à l'étape suivante : Activez votre équipe de sécurité

L'architecture décrite dans ce blog est plus qu'un exercice technique ; il s'agit d'un plan de validation continue de la sécurité. En associant cette gamme automatisée à la plateforme SIEM et XDR unifiée d'Elastic, vous pouvez passer de tests périodiques à un état de préparation constant.

Nous vous invitons à lancer votre propre essai, à vous appuyer sur ce guide pour tester et évaluer la plateforme face aux menaces du monde réel, et à doter votre équipe de sécurité des outils nécessaires pour garder une longueur d'avance sur l'adversaire.

Utiliser un autre SIEM ?

Il n'y a pas de problème. Vous pouvez tirer parti d'Elastic Serverless et augmenter votre SIEM existant, puis obtenir toutes les informations ci-dessus tout en utilisant les données sous-jacentes de votre SIEM natif. Commencez dès aujourd'hui avec un déploiement Elastic Serverless. Le packageElastic AI SOC Engine (EASE) offre ces capacités axées sur l'IA, permettant aux organisations d'ajouter rapidement des analyses puissantes et une couche d'IA à leurs outils existants avant la migration complète.

Annexe

Exemple Gamme complète

Note : Le VLAN de Kali VM est en dehors des hôtes GOAD et XZ backdoor pour simuler un réseau segmenté ou un attaquant distant. Le VLAN de Kali VM peut être modifié en 10/20 pour simuler des scénarios d'attaque interne ou de "brèche supposée".

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>"

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.