Déployez les Agents OpenAEV comme un Adversaire et Validez votre Posture de Sécurité

Dans OpenAEV 1.14, notre plateforme Adversarial Exposure Validation (AEV), nous avons introduit de nouvelles méthodes d'installation de l'Agent OpenAEV. Cette mise à jour marque une étape importante dans nos efforts continus pour améliorer les performances, optimiser les fonctionnalités et enrichir l'expérience utilisateur globale.

En prenant en charge de nouveaux modes d'installation, nous élargissons les possibilités pour les utilisateurs de simuler une plus grande variété de scénarios d'attaque et de renforcer leur posture de sécurité. Les différents modes d'installation permettent à l'Agent de fonctionner sous différents niveaux de privilèges, tels que des comptes utilisateurs standard ou des contextes administratifs. Cette flexibilité est essentielle, car certaines simulations d'attaque nécessitent des permissions spécifiques pour refléter fidèlement les menaces du monde réel.

Ces améliorations rendent l'Agent plus adaptable et capable d'évaluer la dimension humaine de la préparation.

TL;DR

• Les nouveaux modes d'installation de l'agent simulent le comportement des attaquants en utilisant des privilèges standard ou administrateur.
• Les agents peuvent désormais s'exécuter en tant qu'utilisateurs de domaine pour imiter les menaces réelles basées sur les identifiants.
• Simulez des flux complets de post-compromission : énumérez les partages, extrayez les identifiants et testez les mouvements latéraux.
• Les résultats centralisés et les métriques détaillées aident à évaluer la détection, la prévention et la réponse des analystes.

Contexte

L'Agent OpenAEV est un composant clé de la plateforme OpenAEV, chargé d'enregistrer un endpoint, de récupérer les tâches assignées et de les transmettre aux implants pour exécution sur la machine cible.

Développé en Rust pour les performances, la sécurité et la portabilité, l'Agent s'exécute silencieusement en arrière-plan et n'effectue aucune action directement sur l'endpoint pour garantir que les simulations se déroulent sans interférence et avec réalisme. Il prend en charge plusieurs systèmes d'exploitation, notamment Windows, Linux et macOS. Son comportement léger et neutre le rend idéal pour mener des évaluations de sécurité complètes dans des environnements variés.

Le diagramme ci-dessous illustre le fonctionnement de l'Agent OpenAEV dans une architecture typique :

• interfaçage avec la plateforme OpenAEV.
• interaction avec les solutions de détection et de réponse des endpoints (EDR) comme Microsoft Defender for Endpoints ou CrowdStrike, SIEM avec Microsoft Sentinel.
• communication avec les collecteurs pour prendre en charge l'orchestration des simulations.

Modes d'Installation

OpenAEV prend désormais en charge trois modes d'installation pour l'Agent, chacun utilisant des mécanismes et des niveaux de privilèges différents.

Session User

Le mode par défaut est ce que nous appelons Session User. Cette installation ne nécessite pas de permissions spécifiques et peut être installée par un utilisateur sans accès administrateur. Le processus sera attaché à l'utilisateur qui installe l'agent. Session User permet à la fois des agents Admin et non-Admin. Pour ce mode d'installation, nous utilisons systemctl ou launchctl pour Linux/MacOS, et l'Agent aura des privilèges Admin si l'utilisateur qui l'installe dispose de droits d'administrateur. Pour Windows, nous utilisons une tâche planifiée lorsque l'Agent est installé depuis un terminal avec des privilèges Admin, ou nous écrivons une application de démarrage dans le registre s'il s'agit d'un terminal standard.

Nous avons ensuite deux modes d'installation avancés qui nécessitent tous deux un accès administrateur et utilisent systemctl/launchctl pour Linux/MacOS et les services Windows pour Windows.

Service system

L'installation que nous appelons Service System (ce mode d'installation était auparavant notre mode par défaut). Cette installation utilisera l'utilisateur "root" sur Linux et MacOS et "nt authority/system" sur Windows.

Service user

La troisième installation est Service User. Elle est très similaire à Service System mais vous permet de spécifier un utilisateur qui sera propriétaire de l'agent. Lorsque vous exécutez la commande d'installation, vous devrez spécifier les identifiants de l'utilisateur et le processus appartiendra à cet utilisateur.

💡Sur une machine, vous pouvez avoir plusieurs agents s'exécutant avec différents modes d'installation ou sous différents utilisateurs. Seul l'Agent Service System est limité à une instance par machine—il n'y a aucune contrainte pour les autres.

Prenons un exemple concret. Sur une seule machine, vous pouvez installer :

Présentation du Cas d'Usage

Simuler l'Abus d'Identifiants avec OpenAEV : Déployer des Agents en tant que Comptes de Domaine

Dans les simulations d'attaque modernes, le réalisme est essentiel. Il ne s'agit pas seulement d'imiter des actions malveillantes—il s'agit de le faire d'une manière qui reflète la façon dont les attaquants opèrent réellement dans votre environnement.

Une avancée majeure dans cette direction est désormais possible avec OpenAEV :

Vous pouvez déployer un agent sous l'identité de n'importe quel compte utilisateur de domaine—pas seulement les comptes SYSTEM locaux ou administrateur.

Pourquoi c'est Important

Après avoir compromis une machine, les vrais attaquants n'ont souvent pas besoin d'élever leurs privilèges. Au lieu de cela, ils s'appuient sur des comptes utilisateurs de domaine légitimes, souvent négligés—en particulier les comptes de service—pour se déplacer latéralement, explorer l'environnement et maintenir la persistance.

Cette nouvelle capacité dans OpenBAS vous permet de simuler exactement cela :

• Exécuter des actions sous un compte de domaine, comme le ferait un attaquant avec des identifiants volés.
• Mesurer jusqu'où un compte compromis peut aller, sans s'appuyer sur des privilèges de niveau SYSTEM.
• Tester vos capacités de détection et de réponse contre des mouvements subtils basés sur les identifiants—pas seulement des élévations de privilèges bruyantes.

Un Scénario Réaliste

Imaginez ceci :

• Un attaquant compromet un poste de travail standard.
• Il énumère les partages réseau et tombe sur des identifiants en clair pour un compte de service de domaine.
• Au lieu d'utiliser des droits élevés, il réutilise simplement ces identifiants pour s'authentifier ailleurs et poursuivre son opération.

Avec OpenBAS, vous pouvez répliquer ce flux de bout en bout :

• Énumérer les cibles.
• Identifier l'exposition des identifiants.
• S'authentifier avec ces identifiants.
• Déployer et opérer un agent sous le compte de domaine compromis.

C'est ainsi que se comportent les vraies menaces—et désormais, vos simulations aussi.

Conçu pour la Subtilité et la Précision

Étant donné que l'agent OpenAEV communique via HTTPS, tout comme les outils d'attaquants courants, il se fond naturellement dans votre trafic réseau. Combiné à l'exécution en contexte de domaine, cela permet des simulations qui :

• Restent sous le radar.
• Reflètent les véritables tactiques des attaquants.
• Fournissent des informations de haute fidélité sur les risques de mouvement latéral de votre organisation.

Déroulement du Scénario : Explorer les Serveurs Accessibles en Invité et Rechercher des Identifiants

Dans cette première capture d'écran, nous parcourons l'étape initiale de notre simulation d'attaque, rendue possible grâce à OpenBAS.

Le scénario est conçu pour reproduire une tactique courante de post-compromission : un attaquant atterrit sur une machine à l'intérieur du réseau et commence à sonder les cibles faciles—des serveurs qui exposent des partages sans nécessiter d'authentification.

Voici ce qui se passe, étape par étape :

1. Énumération des Serveurs Accessibles en Invité La simulation commence par scanner le réseau local à la recherche de serveurs Windows qui répondent à SMB et acceptent les connexions invité ou non authentifiées. Cela aide à identifier les actifs mal configurés qui peuvent autoriser l'accès anonyme.
2. Découverte des Partages de Fichiers Une fois ces cibles trouvées, le scénario tente d'énumérer les partages de fichiers sur chaque serveur. Nous vérifions quels partages sont accessibles et si l'utilisateur actuel (invité ou compromis) dispose de permissions de lecture et/ou d'écriture.
3. Exploration des Fichiers Sensibles Sur les partages avec accès en lecture, nous effectuons une analyse récursive de la structure des fichiers, à la recherche de fichiers pouvant contenir des informations sensibles—tels que des scripts, des fichiers de configuration ou des dumps de mots de passe.
4. Extraction d'Identifiants Si de tels fichiers sont trouvés, le scénario utilise une logique de correspondance de modèles pour extraire des identifiants en clair (noms d'utilisateur, mots de passe ou hashes NTLM) directement du contenu du fichier.
5. Préparation au Mouvement Latéral Tous les identifiants récupérés à ce stade sont sauvegardés pour une utilisation ultérieure. L'idée est de simuler ce qu'un attaquant ferait ensuite : tenter un mouvement latéral en utilisant ces identifiants volés.

Cette phase est purement de la reconnaissance et de la collecte—mais déjà, elle met en évidence des failles dangereuses :

• Des serveurs avec des paramètres de partage trop permissifs.
• Des données sensibles exposées aux utilisateurs non authentifiés.
• Le risque de fuite d'identifiants par une mauvaise gestion des fichiers.

Dans l'étape suivante, nous utiliserons ces identifiants pour pivoter plus profondément dans le réseau—comme le ferait un vrai attaquant.

Enseignements de la Simulation – Vue d'Ensemble des Résultats

Dans cette capture d'écran, nous voyons les résultats consolidés générés tout au long de la simulation. L'une des principales forces d'OpenBAS réside non seulement dans la simulation d'un comportement d'attaque réaliste, mais aussi dans le fait de rendre les résultats immédiatement exploitables et compréhensibles.

Chaque phase du scénario—qu'il s'agisse de scanner des serveurs, de parcourir des partages, d'extraire des identifiants ou de tenter un mouvement latéral—renvoie des données dans une vue centralisée. Voici ce que vous pouvez observer :

• Au niveau du scénario, vous obtenez un résumé de haut niveau de ce qui a été découvert : serveurs vulnérables, partages accessibles et chemins potentiels pour le mouvement latéral.
• Au niveau de la simulation, vous pouvez tracer exactement quelles actions ont été effectuées, par quel agent et sous quel compte.
• Au niveau de l'injection, les détails sont encore plus granulaires : Vous pouvez voir quelles adresses IP ont répondu aux connexions SMB non authentifiées, quels partages de fichiers ont été parcourus, quels fichiers ont été consultés, et si des identifiants ont été trouvés à l'intérieur.

Cette répartition structurée permet aux défenseurs de :

• Identifier rapidement les points faibles dans la configuration (par exemple, les partages avec accès invité).
• Repérer les identifiants exposés et retracer leur provenance.
• Voir le chemin exact qu'un attaquant pourrait suivre, étape par étape, en fonction de ce qui est découvert.

Ce n'est pas seulement de la visibilité—c'est de la clarté. Les résultats sont contextualisés dans la simulation, ce qui facilite la priorisation de la remédiation et la communication des risques pour les équipes.

Dans la phase suivante, nous montrerons comment ces résultats sont utilisés pour pivoter et déployer un agent en utilisant les identifiants récupérés, simulant une tentative réaliste de mouvement latéral.

Dans cette capture d'écran, nous obtenons une vue d'ensemble claire et immédiate des résultats de la simulation—une capacité essentielle lors de l'évaluation du risque réel.

Indicateurs clés

D'un coup d'œil, plusieurs indicateurs clés se distinguent :

• Un fichier nommé secretpassword a été identifié, suggérant fortement la présence d'identifiants codés en dur ou stockés.
• Le serveur 192.168.56.23 a été signalé—probablement parce qu'il acceptait les connexions SMB non authentifiées, ce qui en fait une cible idéale pour un attaquant.
• Le dossier /all sur ce serveur était accessible en lecture et en écriture, une mauvaise configuration critique.
• Deux ensembles d'identifiants ont été récupérés :
• • Une paire faible vagrant:vagrant.
  • Un compte de type domaine svc_openbas avec un mot de passe exposé.

Ce niveau de visibilité permet aux équipes de sécurité d'évaluer immédiatement la surface d'attaque et d'identifier les vecteurs exploitables, sans fouiller dans les journaux ou les captures de paquets.

De la Découverte à l'Action : La Prochaine Étape

Avec des identifiants en main, le scénario peut maintenant tenter un mouvement latéral, en déployant un nouvel agent OpenBAS ("beacon") sur un système distant en utilisant l'un des comptes découverts.

Si l'authentification réussit :

• L'agent sera déployé sous le contexte de ce compte (par exemple, vagrant ou svc_openbas).
• L'action sera visible à la fois au niveau de l'injection, montrant la tentative d'accès basée sur les identifiants, et dans la vue de l'endpoint, confirmant le déploiement réussi.

Mesurer les Performances de Sécurité : Détection, Prévention & Réponse Humaine

Maintenant que le scénario est terminé, il est temps de passer de la simulation à l'évaluation :

Nos contrôles de sécurité ont-ils détecté ou arrêté l'attaque ? Nos analystes l'ont-ils interprétée correctement ?

Cette capture d'écran montre les résultats de détection et de prévention capturés au niveau du scénario—offrant une vue d'ensemble de la façon dont votre écosystème de sécurité a répondu à chaque étape simulée.

Voici ce que représente chaque section :

• Prévention : Indique si une action (injection) a été activement bloquée—par un EDR, un proxy ou un autre contrôle. Par exemple, si une charge utile a été mise en quarantaine avant l'exécution ou si une requête réseau a été bloquée d'emblée.
• Détection : Signale que l'injection a été exécutée avec succès, mais détectée par un outil de surveillance de la sécurité—tel qu'un SIEM, NDR ou EDR—sans empêcher l'action.
• Réponse Humaine : Capture la réaction de l'équipe SOC. Les analystes peuvent commenter chaque détection, la classifier (par exemple, vrai positif vs. faux positif) et indiquer le niveau de suspicion. Cela aide à mesurer non seulement la visibilité des outils, mais aussi la précision des analystes et la qualité de la réponse.

Nous pouvons cliquer sur la première injection non exécutée pour en savoir plus sur le problème.

À la fin (exercice terminé avec succès ou avec erreur), dans la vue d'ensemble, nous aurons les résultats globaux de l'exercice…

• Pourcentage de résultats des attentes (moyenne de chaque injection),
• Pourcentage de résultats MITRE Att&ck (moyenne de chaque injection),
• Résultats des injections,
• Quelques statistiques.

Du Résumé Global au Détail par Injection

L'avantage de cette vue est qu'elle fonctionne sur plusieurs niveaux :

• À un niveau élevé, vous obtenez une vue d'ensemble complète de la couverture du scénario—combien a été bloqué, détecté ou manqué.
• Si vous souhaitez approfondir, vous pouvez explorer chaque injection individuelle pour comprendre :
• • Les traces d'exécution et les résultats d'état pour chaque cible,
  • Le pourcentage de résultats des attentes pour chaque cible,
  • Le pourcentage global de résultats des attentes et ses détails,
  • Le résultat d'état global.

Cela permet aux équipes de :

• Corréler des résultats spécifiques avec la télémétrie de sécurité.
• Repérer les lacunes de visibilité (par exemple, le mouvement latéral ne déclenchant pas d'alertes).
• Identifier les angles morts de détection—même pour l'accès basé sur les identifiants, non-SYSTEM.

De la Simulation aux Enseignements Réels

En fin de compte, cette vue boucle la boucle : elle relie le comportement de l'attaquant à la réaction défensive.

Vous ne faites pas que simuler une menace—vous mesurez votre capacité réelle à la détecter, prévenir et y répondre.

Il ne s'agit pas de marquer des points. Il s'agit d'améliorer la résilience, un scénario à la fois.

Ce qui Arrive Ensuite

Scénarios Autonomes et Adaptatifs

Encore plus excitant : dans un avenir proche, OpenAEV prendra en charge la capacité de chaîner dynamiquement les résultats entre les injections.

En termes pratiques, cela signifie :

• L'adresse IP découverte ici pourrait être automatiquement réutilisée dans une injection de suivi pour énumérer les partages.
• Les identifiants récupérés pourraient être transmis dans les étapes d'authentification sans configuration manuelle.
• Des scénarios entiers s'adapteront à la volée en fonction de ce que l'agent découvre, créant des chaînes d'attaque entièrement autonomes qui reflètent le comportement réel des attaquants plus fidèlement que jamais.

Conclusion

Plus qu'un Simple Accès—C'est une Simulation Contextuelle

La capacité de déployer des agents en tant que comptes de domaine est plus qu'une fonctionnalité—c'est un changement dans la façon dont nous émuler les menaces. Pour les RSSI, cela signifie :

• Tester comment vos systèmes et équipes gèrent l'abus d'identifiants.
• Identifier les privilèges excessifs liés aux comptes de service ou aux utilisateurs standard.
• Améliorer les défenses là où les attaquants sont les plus susceptibles d'opérer.

OpenAEV vous rapproche de la réalité—parce que c'est là que vivent les menaces.

Vous avez maintenant appris comment fonctionnent les différents modes d'installation de l'Agent OpenAEV, comment exécuter des attaques et comment analyser la posture de sécurité de votre organisation.

Ce n'était qu'un exemple de base. La plateforme prend en charge des scénarios beaucoup plus complexes, nous vous encourageons à explorer la documentation, notre dépôt github de payloads et à consulter les autres articles de blog pour créer des exercices de plus en plus complexes.

Les combinaisons sont infinies ! Profitez-en et n'hésitez pas à poser des questions à ce sujet sur notre Slack community channel 📢 !