Hugging Face a été piraté la semaine dernière par un agent d'OpenAI devenu rebelle, et cette intrusion continue de nous apporter des éclairages et des éléments de compréhension. L'équipe de Hugging Face a publié une chronologie détaillée, accompagnée d'une relecture en continu de la trace de 17 600 événements permettant de visualiser le déroulement des faits ; le niveau de détail est à la fois fascinant et enivrant. Je vous recommande vivement de la lire si vous en avez le temps.
La violation de leur plateforme n’a pas consisté en un seul exploit brillant suivi d’un chemin d’attaque clair et dirigé par un humain. Il s’agissait d’une multitude d’actions réparties sur quatre jours et demi, avec des milliers d’expériences infructueuses masquant le nombre relativement restreint d’actions qui ont finalement compté. La reconnaissance, l’exécution de code et la mise en place de la charge utile ont commencé presque immédiatement. Le mouvement latéral décisif vers leurs clusters Kubernetes, leur réseau interne et leur système de contrôle de version n’a commencé qu’au troisième jour.
La plupart des organisations disposent de suffisamment de données de journalisation et de surveillance pour reconstituer le déroulement d'une attaque une fois coup. Elles sont en revanche bien moins nombreuses à disposer de la visibilité en temps réel, de la logique d’alerte et de l’aide à la décision nécessaires pour détecter l’attaque alors qu’elle est encore en cours de préparation.
La chronologie combinée de Hugging Face, ainsi que certaines informations très attendues communiquées par OpenAI concernant cet incident, sans oublier l'analyse rétrospective initiale de la CSA, mettent en évidence ce que je considère comme quatre points de décision essentiels en matière de gestion des incidents que les entreprises doivent prendre en compte. Chacun d'entre eux constitue également un test concret permettant de vérifier si votre organisation dispose ou non de ces capacités.
Décision n° 1 : À partir de quand une mission de reconnaissance à faible signal est-elle considérée comme un incident ?
Le premier jour de l'intrusion, les agents ont recensé les systèmes de fichiers, les processus, les interfaces réseau, les variables d'environnement, les points de montage et les outils disponibles. Ils ont testé les canaux sortants et mis en place un système de commande et de contrôle en utilisant des services publics courants. Pris isolément, chaque événement aurait pu être justifié par des opérations de débogage, d'automatisation, une charge de travail mal formée ou une expérimentation normale.
Hugging Face indique que les premiers signaux sont apparus dans l’analyse en temps réel, les journaux SIEM et d’autres contrôles. Sa pile de sécurité basée sur l’IA a établi une corrélation entre ces signaux pour former un schéma d’attaque cohérent, mais n’a pas attribué un niveau de criticité suffisant ni alerté l’équipe de garde. Ce retard a fait perdre un temps de réaction précieux. Une analyse antérieure et des discussions au sein de la communauté avaient abouti à la même conclusion : la reconnaissance était enregistrée depuis plusieurs jours, mais l’escalade n’a eu lieu que lorsque le volume d’activité non autorisée a finalement dépassé le seuil d’alerte.
La question n'est pas simplement de savoir si un événement isolé est malveillant. Il s'agit plutôt de déterminer si une succession de comportements d'exécution, ambigus pris isolément, constitue la mise en place d'une chaîne d'attaque.
Les organisations doivent se demander si elles sont en mesure d'établir des corrélations entre l'exécution des processus, l'accès au système de fichiers, l'activité des API, l'identité des charges de travail et le comportement réseau au sein de conteneurs à courte durée de vie. Sont-elles capables de reconnaître qu'un pod qui lit /proc/self/environ, inspecte les jetons des comptes de service et teste plusieurs méthodes de sortie diffère sensiblement d'une défaillance normale d'application ?
C'est là que l'instrumentation « canary » peut lever toute ambiguïté. La technique sur laquelle nous devons miser ici consiste à placer des jetons factices dans certains environnements de charge de travail, à laisser des identifiants leurres dans des référentiels secrets et à surveiller les valeurs de configuration dans des chemins hors production. Ceux-ci ne doivent en aucun cas donner accès à des données réelles. Leur seul objectif est plutôt de générer un signal hautement fiable lorsqu’ils sont lus, copiés ou présentés. Un jeton « canari » bien placé doit alerter un intervenant au lieu d’être considéré comme une anomalie. La mise en place d’une capacité de leurre doit figurer dans la feuille de route de toutes les équipes.
Décision n° 2 : Que se passe-t-il lorsque des identifiants sont volés et utilisés ?
Le troisième jour a changé la donne. L’agent a lu les jetons des comptes de service Kubernetes, interrogé cloud , réutilisé des identifiants temporaires provenant de fournisseurs d’hébergement externes (Modal s’est manifesté pour se présenter comme l’un de ces fournisseurs d’hébergement), créé des pods privilégiés et s’est échappé vers la racine du nœud. Il a ensuite accédé à un objet secret contenant 136 clés, dont des identifiants utilisés pour un VPN maillé et un courtier d’accès au cluster interne. Un identifiant de connecteur partagé a effectivement fourni un accès d’administrateur de cluster sur plusieurs clusters.
C'est à ce moment-là que « l'enquête » doit se transformer en mesure de confinement active.
Votre équipe est-elle en mesure d'identifier tous les systèmes qui font confiance à un identifiant compromis ? Le graphe de dépendances et l'analyse d'impact sont essentiels pour lancer la phase de confinement d'une réponse aux incidents. Vos outils et tableaux de bord permettent-ils de distinguer un jeton utilisé par la charge de travail prévue de ce même jeton provenant d'un nouveau cloud , d'un environnement sandbox ou d'une nouvelle origine réseau ? Les intervenants peuvent-ils révoquer toute une famille d'identifiants, plutôt que de simplement renouveler une clé alors que les jetons dérivés restent valides ?
La détection à l’exécution est essentielle, car les identifiants eux-mêmes peuvent paraître légitimes. La nature malveillante réside dans leur contexte d’exécution : un processus inapproprié, un pod inapproprié, un réseau source inapproprié, une identité de charge de travail inappropriée ou une séquence d’actions impossible. J’aime appeler cela la surveillance « l’eau est mouillée ». Parmi les choses dont je suis certain, l’eau est mouillée tout comme le ciel est bleu. Si nous ne mettons pas en place une surveillance qui nous aide à détecter les changements « qui remettent en cause nos hypothèses » dans nos environnements, nous continuerons d’être pris au dépourvu.
On peut citer comme exemple la configuration de tests de routage par saut suivant afin de détecter un détournement BGP. Les quatre premiers sauts depuis votre réseau interne vers une ressource externe stable et bien connue (comme time.windows.com) ne devraient en effet présenter aucun écart. Un autre exemple de surveillance de type « l’eau est mouillée » concerne les enregistrements DNS : il s’agit de vérifier en permanence que vos adresses IP internes et externes pour les composants clés de l’infrastructure restent inchangées.
Les « canaries » déployés pour déjouer les attaques menées par des agents doivent donc inclure de faux jetons de compte de service, cloud leurres et des clés d’inscription VPN synthétiques. Un jeton stocké dans un environnement de pod soigneusement sélectionné peut révéler une tentative de collecte d’identifiants. Un compte de service leurre peut révéler une énumération d’espaces de noms. Une fausse entrée de cluster renvoyée par un catalogue de services interne peut révéler des tentatives de mouvement latéral. Ces artefacts doivent mener vers des pièges ou des points de terminaison bloqués, et non vers un accès à l’environnement de production, mais chaque interaction doit préserver l’identité de la source et déclencher immédiatement des consignes de confinement.
Décision n° 3 : Arrivez-vous à repérer C2 alors qu’il ressemble à votre propre application ?
La principale leçon à tirer en matière de détection est peut-être que le trafic de commande et de contrôle ne se présente pas forcément sous la forme d'un trafic de logiciels malveillants classique.
L’agent a utilisé des services publics de capture de requêtes, des pastebins et des hébergeurs de partage de fichiers. Plus important encore, il a utilisé des ensembles de données Hugging Face contrôlés par les attaquants comme points de dépôt secrets. Les commandes et les données volées ont été placées dans des commits d’ensembles de données et des branches secondaires, puis récupérées via l’API Hugging Face standard. Un proxy CORS ouvert, Space, a également été utilisé comme relais de sortie. Les charges utiles ont été fragmentées, compressées, encodées et parfois envoyées via des sockets brutes. La reproduction du processus de décodage de l’attaquant a permis de récupérer environ quatre fois plus de secrets exposés que lors de l’analyse initiale.
En d’autres termes, les instructions entrantes ressemblaient à une activité liée aux ensembles de données, tout comme l’exfiltration sortante. Hugging Face lui-même a été intégré au canal de commande et de contrôle (C2). Un système SIEM classique peut signaler des milliers d’événements inhabituels sans révéler qu’ils constituent un protocole bidirectionnel.
La décision consiste à déterminer s’il faut désactiver une fonctionnalité accessible aux clients, isoler un locataire, bloquer un service public ou interrompre un chemin de données en production. Les intervenants ont besoin de preuves plus solides que la simple constatation que « ce trafic est inhabituel ».
Créez des ensembles de données leurres portant des noms convaincants, tels que des résultats de tests de performance internes, des réponses à des évaluations ou des recherches archivées en matière de sécurité. Intégrez-y des marqueurs uniques et de faux identifiants. Aucune charge de travail légitime ne doit y avoir accès. Surveillez les lectures, les clonages, les validations, la création de branches et les requêtes API. Un faux cluster interne ou un faux ensemble de données répertorié dans un catalogue peut également révéler si un attaquant est en train de recenser des failles potentielles plutôt que de simplement interagir normalement avec le service.
Des « canaris » bien conçus et bien placés permettent de détecter une intention, et pas seulement une anomalie.
Décision n° 4 : réparer les dégâts ou reconstruire l'environnement ?
Au final, la question est de savoir si l'organisation fait toujours confiance à l'infrastructure concernée.
Hugging Face a procédé à une rotation généralisée des identifiants, bloqué l'accès aux cloud , restreint la portée des identifiants, puis effacé et reconstruit l'infrastructure centrale à partir de zéro. Dans l'ensemble, cette décision revenait à « raser » environ un tiers de l'environnement plutôt que de tenter de prouver que chaque point d'ancrage, chaque jeton falsifié et chaque mécanisme de persistance avait été supprimé.
Cette option n'est envisageable que lorsque l'infrastructure est reproductible et jetable. Une analyse précédente avait souligné que la reprise des activités chez Hugging Face avait été accélérée grâce au déploiement d'une nouvelle infrastructure à partir de dépôts, plutôt que par la restauration puis le nettoyage des systèmes compromis. La responsabilité de prendre cette décision doit également être clairement attribuée et documentée avant l'incident.
La solution d’aide à la décision doit inclure le traçage des identifiants, l’identification des charges de travail affectées, la vérification des images immuables, la couverture de l’infrastructure en tant que code, les exigences en matière de restauration des données et les preuves de tentatives de persistance. Les dirigeants doivent connaître la durée estimée de l’indisponibilité nécessaire à la reconstruction avant qu’on leur demande d’autoriser cette opération. Et avec quel niveau de confiance (à quand remonte le dernier déploiement à zéro d’un cluster ou d’un service donné ?)
Les « canaries » restent également utiles après la restauration. Remplacez chaque leurre par une valeur nouvellement générée. Toute utilisation d’un ancien jeton « canary » après la reconstruction constitue une preuve solide qu’un point d’ancrage non détecté, un secret copié ou un emplacement de transit externe a survécu. Cela est d’autant plus vrai si l’on part du principe que les attaquants agissant de manière autonome sont suffisamment prévoyants pour laisser des indices à leurs agents modèles afin d’éviter la détection ou de reprendre là où ils se sont arrêtés.
L'incident Hugging Face montre que la journalisation n'est pas synonyme de détection, que la détection n'est pas synonyme d'escalade et que l'escalade n'est pas synonyme d'aide à la décision. La visibilité en temps réel vous indique ce que fait réellement le logiciel. Les jetons « canary », les clusters et les ensembles de données vous signalent quand une activité ne trouve pas d'explication légitime.
L'objectif n'est pas simplement de rassembler suffisamment d'éléments pour comprendre la faille la semaine prochaine. Il s'agit de mettre en place des indicateurs suffisamment fiables pour prendre la bonne décision dès aujourd'hui.
