Nous avons utilisé OpenClaw sur un de nos réseaux internes : voici ce qu'il a trouvé

Dans mon précédent article sur OpenClaw, j'écrivais :

« Même les organisations les plus à même de prendre des risques, dotées d'une solide expérience en IA et en sécurité, auront probablement du mal à configurer OpenClaw de manière à mitiger efficacement le risque de compromission ou de perte de données, tout en préservant leur productivité ».

La Red Team de Sophos a pris cela comme un « défi à relever », nous avons donc défini un objectif : doter OpenClaw d'un ensemble standard d'outils red-team, lui donner accès à l'un de nos anciens réseaux sur-site (on-prem) et le laisser faire pour trouver et exploiter toutes les failles. Sans oublier la sécurité !

Approche

Cible

Nous avons choisi un réseau sur-site (on-prem) traditionnel pour plusieurs raisons :

1. Mitigation des risques : bien qu’il s’agisse de véritables réseaux de production et non d’environnements de test, la majorité des charges de travail critiques se trouvent dans des environnements Cloud natifs isolés. Nous souhaitions maintenir une distance saine entre l'outil et nos ressources critiques.
2. Contrôle : les systèmes distribués modernes Cloud-Natifs sont complexes à surveiller. Nous avons estimé qu'une approche axée sur le réseau, avec des contrôles stricts d'entrée et de sortie, était la bonne approche pour surveiller, comprendre et, le cas échéant, contrôler l'activité. Ce n’est pas impossible dans les systèmes Cloud-Natifs, c’est juste plus difficile, et nous voulions contrôler la portée.
3. Pour optimiser nos chances de succès, nous avons choisi un ancien réseau que notre programme de pentest n'avait pas ciblé depuis un certain temps. Nous voulions que l'outil ait une chance raisonnable de trouver quelque chose !

Furtivité

Nous n'avons pas cherché à être discrets. Il s'agissait d'un pentest volontairement bruyant, et non d'une mission red-team secrète : nous avons privilégié la couverture, la vitesse et la reproductibilité plutôt que l'évasion. Par conséquent, cette activité a généré un grand nombre de détections et d'alertes internes dans notre système de surveillance, ce qui, dans ce contexte, était une fonctionnalité plutôt qu'un bug. Un engagement furtif de type « Red Team » aurait nécessité une architecture différente et aurait probablement été largement incompatible en matière de sécurité avec les nombreux garde-fous du modèle.

Sécurité

Les aspects les plus importants du test étaient sans aucun doute les protections et les compétences que nous avons développées. L'équipe a consacré la majeure partie de son temps à la création du framework opérationnel afin de garantir que notre agent ne détruise pas complètement l'environnement et, plus important encore, qu'il ne supprime pas tous nos emails.

Notre principal modèle mental ici était le « tiercé létal » Nous devions éviter de donner à l'agent la possibilité a) de recevoir du contenu non fiable, b) d'accéder à des données sensibles et c) d'exfiltrer ces données vers l'extérieur.

Notre première ligne de défense se basait sur des contrôles stricts entrée/sortie mentionnés précédemment. Bien que l'agent puisse potentiellement accéder à des données sensibles (ce qui est le but d'un pentest !), nous pouvions gérer le risque d'injection de prompt et d'exfiltration.

Nous devions également nous prémunir contre les conséquences imprévues découlant du comportement de type goal-seeking de l'agent. Notre objectif ultime était de sécuriser l'environnement, mais un agent poursuivant cet objectif unique pourrait conclure que le meilleur moyen d'y parvenir serait de prendre le contrôle du domaine, de tout chiffrer et de se débarrasser de la clé. Bien que techniquement impressionnant, un incident de ransomware auto-infligé ne serait pas un résultat optimal.

Pour atteindre le niveau de sécurité et de contrôle souhaité, nous avons finalement eu recours exclusivement à des compétences sur mesure, développées en interne, pour l'évaluation.

L'équipe disposant déjà de procédures bien documentées pour mener ce type d'évaluation, la transformation de ces procédures en compétences a été en fait assez rapide (avec l'aide de quelques agents). Cette approche s'est avérée plus facile que de rechercher et d'évaluer les compétences externes (généralement de faible qualité) disponibles publiquement.

Cette approche nous a également permis d'intégrer un mécanisme d'approbation léger avec intervention humaine, nous offrant un équilibre raisonnable entre autonomie et contrôle pour l'expérience. Vous trouverez ci-dessous quelques extraits (figures 1 à 3), et nous avons également publié notre prompt pour le système principal et les compétences associées sur GitHub, ainsi que les résultats correspondants.

Figure 1 : Garde-fous pour l’agent Red-Team d'OpenClaw

Figure 2 : Extrait du champ d'application des compétences en matière de reconnaissance Active Directory

Figure 3 : Extrait des limites en termes de sécurité des compétences en matière de reconnaissance Active Directory

Principaux enseignements 

Globalement, l'expérience a dépassé nos attentes :

1. L'agent a respecté les limites configurées pendant toute la durée du test ; nous n'avons constaté aucun problème lié à la poursuite d'objectifs pouvant entraîner des conséquences imprévues.
2. L'équipe a pu réaliser d'énormes gains d'efficacité tout au long du processus, en réduisant par exemple la phase de reconnaissance Active Directory de trois jours à trois heures.
3. L'évaluation a permis de dégager 23 conclusions exploitables et de grande qualité (une répartition des conclusions figure en annexe).
4. La méthodologie d'évaluation a permis de constituer une piste d'audit de haute qualité, d'un niveau de détail impossible à atteindre manuellement, simplifiant ainsi considérablement la rédaction des rapports.
5. L'agent a fait preuve de créativité et d'autonomie. Par exemple, lorsqu'une voie d'attaque prometteuse a été bloquée, l'agent a suggéré et (après autorisation) a procédé au lancement d'un nouvelle instance GPU EC2 pour cracker un hachage récupéré.
6. Les modèles que nous utilisions régulièrement ont refusé de coopérer en raison de craintes liées à une utilisation malveillante. L'équipe a pu contourner ces garde-fous dans l'ensemble, mais ceux-ci ont néanmoins introduit des frictions dans le processus.
7. Les pentesteurs sont particulièrement bien placés pour tirer parti des nouveaux outils, potentiellement risqués. Les pentests impliquent souvent des outils open source potentiellement dangereux et des preuves de concept d'exploit précoces, créant ainsi un environnement de supply chain logicielle complexe. L'équipe avait donc déjà mis en place un framework permettant d'exécuter des outils non fiables dans des environnements sensibles avec un haut degré de confiance. De plus amples informations sur cette infrastructure sous-jacente sont fournies en annexe.

Dernières remarques

Cette expérience réussie a clairement démontré de manière directe le compromis complexe que les équipes de cybersécurité vont devoir faire. Oui, ces outils sont dangereux, mais ne pas les adopter pourrait être encore plus dangereux. Le monde évolue à grands pas et la sécurisation de l'IA agentique devient rapidement le défi majeur de notre époque pour la communauté de la cybersécurité.

Cela m'a également montré que les équipes de cybersécurité sont en réalité mieux placées que quiconque pour être à l'avant-garde de cette adoption. Tout d'abord, qui de mieux placé pour manipuler un outil dangereux et puissant que des opérateurs qui pensent naturellement à la sécurité à chaque étape ? Deuxièmement, plus les professionnels de la cybersécurité ont d'expérience pratique dans ce domaine, plus ils ont de chances de prédire l'évolution de la situation, d'identifier les points de contrôle pertinents et, comme je l'ai mentionné dans mon article précédent, de comprendre concrètement à quoi ressemble la gestion des risques.

Billet inspiré de We let OpenClaw loose on an internal network. Here’s what it found, sur le Blog Sophos.