Avec les attaques agentiques, le travail forensique prend une autre dimension. L’évidence trouve une illustration dans le récit de Hugging Face. Mi-juillet, l’entreprise avait révélé avoir subi une telle attaque.

Elle en avait tracé les grandes lignes : exploitation de son« pipeline de traitement de datasets pour exécuter du code sur un de ses pods, obtention d’un accès de niveau nœud, récupération d’authentifiants et latéralisation sur d’autres clusters, etc. Quelques jours plus tard, OpenAI avait admis être à la source de l’incident. Plusieurs de ses modèles, mis à l’épreuve sur une suite de tests visant à mesurer leurs capacités d’exploitation de vulnérabilités, avaient choisi de tricher et s’étaient dit qu’ils pourraient trouver des solutions… chez Hugging Face. Pour atteindre leur cible, ils se sont échappés de leur sandbox grâce à une 0-day dans un logiciel tiers qui servait de cache proxy pour installer des packages.

S’en est suivie une série d’élévations de privilèges et de mouvements latéraux sur l’infra de test d’OpenAI, jusqu’à atteindre un nœud qui avait accès à Internet. Lire aussi : L'incident OpenAI–Hugging Face n'est pas la révolution que vous imaginez La base d’opérations : une sandbox Modal non sécurisée Hugging Face en dit désormais plus sur ce qui s’est passé par après. L’agent a d’abord trouvé un endpoint public non sécurisé qui pointait vers une infrastructure tierce elle aussi destinée à expérimenter les capacités cyber des LLM. En l’occurrence, des sandbox Modal.

Sur cet environnement, il a détourné un harnais permettant de tester du code C contre des programmes cibles. Il a utilisé deux techniques injectant des commandes système respectivement dans des fonctions et dans des métadonnées. L’ensemble lui a permis d’obtenir un accès root dans la sandbox.

Le point d’ancrage interne : un pod de conversion Depuis là, pour pénétrer l’infra de Hugging Face, l’agent a d’abord tenté un SSRF. Mais il s’est heurté à une liste d’autorisations. Pour la contourner, il a forcé le serveur à interagir avec ses ressources locales plutôt que d’aller chercher des ressources externes.

Cela a ouvert la voie à l’exploitation du pipeline de traitement des datasets. Via deux vecteurs visant chacun le chargeur de configurations. L'un a impliqué un dataset malveillant qui ciblait des fichiers au format HDF5.

Ceux-ci déclaraient que leurs données brutes se trouvaient dans un chemin local du système de fichiers du worker. L'agent a pu, par ce biais, récupérer les variables d'environnement - dont des secrets. Ainsi que le code source dudit worker ; ce qui lui a donné la carte du fonctionnement interne.

L'autre vecteur est une vulnérabilité dans le moteur de rendu. Elle a permis l'injection d'un template Jinja2, avec une expression à la place d'un champ numérique. Au final, l'agent a pu remonter l'arbre d'objets Python jusqu'à la fonction lui permettant d'exécuter du code arbitraire dans un pod de conversion sur le cluster de production.

Ce pod a servi de point d'ancrage dans le réseau interne. L'identité d'un nœud usurpée pour cartographier l'environnement Avant de commencer à exécuter des commandes depuis sa sandbox externe, l'agent a sélectionné des services publics légitimes pour constituer son infrastructure de commande et de contrôle : capture de requêtes HTTP, pastebins, hébergeurs de fichiers, etc. Lire aussi : L'attaque automatisée contre Hugging Face provient... d'OpenAI Le gros de l'activité est intervenue le surlendemain (11 juillet). Depuis son pod, l'agent a notamment contacté le service de métadonnées d'AWS pour récupérer des identifiants IAM associés au serveur.

Pour contourner les éventuels blocages DNS, il a réécrit à la volée un module en mémoire afin de forcer la résolution d'un nom de domaine vers une IP spécifique. Des identifiants temporaires récupérés sur le service de métadonnées d'AWS ont permis d'usurper l'identité du nœud auprès de l'API Kubernetes. Et ainsi de cartographier l'environnement cloud de Hugging Face (VPC, clusters EKS, passerelles...).

L'agent a créé des pods à privilèges pour remonter sur les hôtes Ayant récupéré un jeton d'accès Git avec des droits en écriture, l'agent a cloné un dépôt de datasets sur une branche latérale qu'il avait créée au préalable pour éviter de se faire repérer immédiatement. Il a ainsi constitué une zone de transit pour stocker des données exfiltrées et recevoir des instructions. L'agent a ensuite déployé un pod privilégié dans lequel il a monté le système de fichiers de la machine hôte.

Aucune règle de sécurité ne l'interdisait. Cela lui a permis de sauter du pod vers l'OS du nœud hôte. De cette façon, il a étendu son emprise à une dizaine de nœuds.

Et a configuré un mécanisme de régénération automatique de flotte. Parmi les secrets dérobés, il y avait un mot de passe statique qui a permis de se connecter à la base MongoDB du serveur de datasets. L'agent y a lu des données, sans réaliser d'exfiltration massive (il a tenté de cibler le magasin d'identifiants et les clés de chiffrement du cluster).

Une montange de secrets... dont une clé VPN L'élément crucial fut l'accès à un objet contenant 136 secrets. Les privilèges root et la capacité à fabriquer des jetons de compte de service ont permis cet accès. Parmi les identifiants, la clé d'authentification du maillage VPN et les identifiants du broker.

La clé VPN a servi à enregistrer le nœud compromis au sein du mesh corporate. Il a alors fait office de proxy HTTPS pour interagir avec les services internes et les outils de gestion du code source. Parallèlement, l'agent a interrogé l'annuaire du cluster pour obtenir l'adresse IP de l'API du connecteur de services internes.

Il a récupéré le catalogue du broker (URL de connexion et certificats des clusters internes gérés par ce broker). Et tiré parti du fait qu'un même identifiant de connecteur, doté des droits cluster-admin, était réutilisé partout. Un accès aux sous-réseaux CI Au quatrième jour, la clé VPN a permis de connecter des appareils au réseau depuis la sandbox externe.

Celle-ci ne disposant pas de périphérique réseau virtuel, l'agent a lancé Tailscale en mémoire utilisateur, en l'associant à un proxy SOCKS local. Lire aussi : Quand les garde-fous d'un LLM perturbent une cyberdéfense La clé donnait aussi accès aux sous-réseaux CI. L'agent a détourné une application GitHub interne pour tenter de récupérer, via un PR malveillant, le jeton de compte de service d'un exécuteur.

Les politiques en place ont bloqué l'exécution. De même, la tentative d'utiliser l'accès IAM natif d'AWS pour s'attaquer à la base de données de production du Hub Hugging Face a échoué. Le cluster n'acceptait que du trafic issu d'IP autorisées sur une liaison privée.

Un protocole de messagerie sur mesure et une agilité face aux coupures réseau Au cinquième jour, l'agent a entrepris d'automatiser un peu plus les opérations au niveau de la sandbox externe. Il a injecté un script qui, à chaque nouveau test, téléchargeait et exécutait automatiquement du code malveillant depuis un pastebin. Face aux coupures réseau, il a recouru plusieurs techniques.

Parmi elles, forcer l'utilisation des DNS Google, ajouter manuellement des adresses IP dans le fichier hosts et acheminé des binaires à travers un espace Hugging Face configuré avec un proxy CORS ouvert. Pour maintenir un canal C2 robuste, l'agent a créé son propre protocole de messagerie, séparé du moyen de transport. Il était interchangeable sur n'importe quel support texte (requêtes HTTP, commits de datasets, messages d'erreur système...).

Chaque message transportait sa charge utile accompagnée de métadonnées (actions à exécuter, regroupement et séquençage des flux, somme de contrôle...). Entre le 9 et le 13 juillet, l'agent aura réalisé environ 17 600 actions automatisées. Dont beaucoup de tentatives avortées... qui ont engendré autant de bruit au milieu duquel se sont dissimulés les indicateurs fondamentaux.

Illustration générée par IA