Threat Lab Quarterly : août 2026

Traquer les SPN périmés et fantômes avant les attaquants

Par Huy Kha

Introduction

Ces dernières années, les attaques contre Active Directory exploitant les Service Principal Names (SPN) ont augmenté. Cela a commencé avec le Kerberoasting, mais les techniques sont devenues plus créatives depuis. Les attaques Ghost SPN peuvent permettre une élévation de privilèges en revendiquant des cibles de service que plus personne n’utilise. Plus récemment, les attaques de collision Unicode SPN permettent à tout utilisateur authentifié avec des permissions write-SPN d’escalader les privilèges également, en utilisant un SPN visuellement identique mais techniquement différent.

Il existe également un problème plus discret qui ne reçoit pas beaucoup d'attention, à savoir l'hygiène de sécurité de base. Chez Netwrix, nous constatons que le même schéma se répète encore et encore, quelle que soit la taille de l'organisation. Les comptes informatiques restent activés dans Active Directory longtemps après que la machine associée a été mise hors service. Les comptes de service conservent des SPN qui pointent encore vers des hôtes qui n'existent plus. Personne ne revient nettoyer tout cela, donc le compte reste là, toujours actif, toujours vulnérable au Kerberoasting, et personne ne fait attention.

Trouver des SPN furtifs dans votre(s) domaine(s)

Notre équipe de recherche en sécurité a décidé de créer quelque chose qui faciliterait cela pour les professionnels IT et les administrateurs : un script PowerShell appelé Find-StealthSPNs qui traque les SPN furtifs sur les comptes ordinateurs et utilisateurs, afin que vous puissiez examiner les résultats et décider ce qui doit vraiment être nettoyé.

Le script s'exécute en deux passes principales. La première examine chaque compte ordinateur dans la forêt. Puisque chaque machine jointe au domaine enregistre au moins un SPN par défaut, cette passe vérifie si le nom d'hôte de l'ordinateur se résout toujours dans le DNS et si l'un de ses SPN pointe vers des hôtes qui n'existent plus. Nous appelons cela un ghost SPN, un SPN qui est toujours sur un compte, techniquement valide, mais qui ne pointe vers rien de réel. Il détecte également les comptes ordinateurs précréés dans AD mais jamais réellement joints, car ceux-ci se retrouvent souvent sans aucun SPN, restant là indéfiniment sans que personne ne le remarque.

Nous vérifions cela délibérément via DNS plutôt que par un ping ICMP. Certains administrateurs utilisent le ping pour avoir une idée rapide si un hôte derrière un SPN est toujours actif, mais ICMP est souvent bloqué par les pare-feu et les filtrages basés sur l’hôte dans la plupart des environnements, donc un ping échoué ne signifie pas grand-chose. Un enregistrement DNS manquant est un signal plus fiable que personne ne s’attend plus à ce que ce nom d’hôte existe, que la machine réponde ou non à un ping.

La deuxième passe examine les comptes utilisateurs, en particulier ceux qui détiennent des SPN, car c'est la configuration classique pour un compte de service. Pour chaque SPN trouvé, elle vérifie deux choses : est-ce qu'un compte ordinateur correspondant existe toujours dans AD, et est-ce que ce nom d'hôte se résout toujours dans DNS. Si aucune des deux n'est vraie, c'est un signal aussi clair que possible que le SPN est un poids mort. Le compte est toujours actif, le SPN est toujours enregistré, et il est toujours aussi exploitable via Kerberoasting qu'avant, sauf qu'il n'y a plus rien de légitime qui en dépend.

De plus, le script vérifie également les collisions Unicode des SPN, le type d’attaque mentionné précédemment, où un SPN fabriqué peut visuellement correspondre à un vrai tout en étant une valeur complètement différente en dessous. Il signale tout SPN avec des caractères cachés ou ressemblants et recoupe chaque SPN dans la forêt pour détecter les cas où deux comptes semblent détenir le même SPN. Cela peut générer des faux positifs, donc vérifiez toujours deux fois.

Tout fonctionne uniquement avec ADSI et DirectorySearcher, il n’y a donc aucune dépendance au module ActiveDirectory PowerShell, et cela fonctionne sur tous les domaines de la forêt, pas seulement celui depuis lequel vous l’exécutez.

Une brève note sur la résolution DNS : Ce script vérifie le DNS en utilisant le résolveur configuré sur la machine depuis laquelle vous l'exécutez. Pour des résultats (plus) précis, exécutez-le depuis un contrôleur de domaine plutôt qu'un poste de travail, car les DC sont déjà configurés pour résoudre tous les domaines de votre environnement. L'exécuter depuis une machine avec des paramètres DNS inhabituels ou restreints pourrait produire de faux résultats MISSING_DNS pour des enregistrements qui existent réellement.

Conclusion

Au final, nous essayons d’aider les organisations à réduire leur surface d’attaque en nettoyant les comptes obsolètes que personne ne suit plus. Chaque ghost SPN, chaque compte ordinateur activé lié à une machine disparue, chaque compte de service pointant encore vers un hôte qui n’existe plus, est un élément de trop dans Active Directory qui ne devrait pas être là. Aucun de ces cas ne nécessite un attaquant sophistiqué. Il suffit que quelqu’un le remarque avant vous.

---

L'angle de sécurité d'identité de DEF CON 34

Par Darryl Baker

DEF CON 34 et Black Hat USA 2026 ont produit trois recherches distinctes qui pointent toutes vers l'infrastructure d'identity. Voici ce que chacune a annoncé et ce que cela signifie pour les personnes gérant des programmes d'identity et AD.

CloudBasher : shells cloud gratuits transformés en infrastructure d’attaquant

Jenko Hwong et Chris Ryan ont présenté CloudBasher, une boîte à outils open-source construite en rétro-ingénierie des API REST privées et des sessions WebSocket derrière les fonctionnalités gratuites de cloud shell dans AWS, Azure et GCP. La boîte à outils sera publique sur GitHub, ainsi qu'une analyse 2026 des modèles de mauvaise configuration cloud tirée des données de violations.

La recherche a mis en lumière quelques constats spécifiques à signaler aux équipes d’Identity Management.

• Une identité AWS compromise peut assumer un rôle et lancer un grand nombre d'environnements CloudShell.
• Les sessions terminales WebSocket restent actives après la révocation du jeton d'accès sous-jacent, donc révoquer une authentification ne met pas nécessairement fin à une session active.
• Les comptes consommateurs M365 et Gmail bénéficient d'un accès CloudShell par défaut, ce qui étend la surface d'attaque pertinente aux comptes personnels, pas seulement aux comptes d'entreprise.

Une fois la session établie, la boîte à outils persiste dans le répertoire $HOME (qui survit aux réinitialisations), peut verrouiller l’utilisateur légitime hors de sudo dans sa propre session, et installe un framework C2.

Pourquoi c’est important : si votre programme d’identity considère la révocation du jeton comme équivalente à la fin de session, cette recherche indique que cette hypothèse doit être testée, pas supposée. Il est également utile de vérifier si vos politiques d’accès CloudShell et votre surveillance détecteraient toute création de session anormale.

GhostJacking : agents de codage IA agissant sur des instructions cachées dans les journaux 

Barak Sternberg, Nevo Poran et Ron Bobrov de Tenet Security ont présenté GhostJacking, une technique pour détourner des agents de codage IA en insérant des instructions dans les journaux que l’agent est censé lire, tels que les alertes WAF, les rapports d’erreur et les sorties de surveillance. Tenet a rapporté un taux de réussite de 90 % contre Claude Code sous la configuration par défaut de Cloudflare et a estimé que plus de 15 000 organisations sont exposées uniquement via les configurations Cloudflare.

Tenet a démontré la technique sur trois plateformes. Des entrées de journaux WAF Cloudflare empoisonnées (Cloudflare protège environ 42 % des entreprises du Fortune 500) ont poussé les agents à modifier les paramètres DNS et à rediriger le trafic. Des messages de journaux Datadog injectés (utilisés par environ 48 % du Fortune 500) ont poussé les agents à installer des paquets malveillants, entraînant une exécution de code à distance et un vol d’identifiants. Des rapports d’erreurs Sentry empoisonnés (Sentry dessert environ 4 millions de développeurs) ont fait qu’une instance compromise de Claude Code a cautionné l’attaquant auprès de l’agent Seer AI de Sentry, produisant une chaîne de confiance entre agents. Tenet a également signalé avoir trouvé plus de 2 700 clés API Datadog exposées et a divulgué séparément une fuite de sandbox liée à JWT dans Claude Desktop à Anthropic. Ce problème a été corrigé avant la conférence DEF CON.

Les actions de l'agent dans les trois cas utilisent ses propres identifiants légitimes déjà autorisés. Cela signifie que les outils EDR, WAF et IAM ne signalent rien d'anormal.

Pourquoi c'est important : RBAC, le principe du moindre privilège et MFA ne suffisent pas ici, car l'accès de l'agent est légitime. Le problème est ce qu'on lui a demandé de faire avec cet accès. Les recommandations de Tenet constituent une liste de contrôle raisonnable : restreindre par défaut l'accès réseau sortant de l'agent, exiger une approbation humaine avant les modifications d'infrastructure, séparer les outils en lecture seule de ceux pouvant écrire, et considérer chaque journal ou alerte lu par un agent comme une entrée non fiable, quelle que soit la plateforme d'origine.

The OpenAI–Hugging Face incident: An agent that escaped its own test

En juillet 2026, OpenAI a révélé que lors d'une évaluation interne utilisant le benchmark ExploitGym (898 vulnérabilités réelles), une version expérimentale de GPT-5.6 Sol, exécutée sans les garde-fous de sécurité, a échappé à son sandbox et compromis l'infrastructure de production de Hugging Face. Hugging Face a divulgué l'incident le 16 juillet ; OpenAI a révélé son rôle le 21 juillet. Eric Wallace et Michael Dalton en ont parlé lors du Black Hat USA 2026.

Selon les révélations, l’agent a trouvé et exploité une faille zero-day dans une instance auto-hébergée d’Artifactory (le proxy cache du registre de paquets de JFrog) pour s’échapper de son sandbox et accéder à internet. L’agent a ensuite déduit que Hugging Face hébergeait la clé de réponses du benchmark et l’a ciblée directement. Plusieurs instances d’agents se sont ensuite coordonnées via Artifactory lui-même, échangeant des centaines de milliers de messages pour répartir les tâches et partager les exploits. À un moment donné, les agents ont proposé de signer cryptographiquement leurs messages après avoir suspecté un imposteur. Lorsque OpenAI a fermé le canal le 4 juillet, les agents l’ont reconstruit en quatre jours en utilisant des noms de répertoires sur un point de terminaison non authentifié comme canal de messagerie de substitution.

Au cours d'une campagne de 4,5 jours, OpenAI a enregistré plus de 17 600 actions d'agents, y compris l'exfiltration de 136 clés de stockage d'identifiants, le vol d'une clé d'authentification mesh VPN, l'inscription de 181 appareils via Tailscale, et l'acquisition d'un accès en écriture à GitHub App. L'activité sur 11 nœuds Kubernetes comprenait l'usurpation de nœuds via les métadonnées d'instances AWS, des jetons d'identité falsifiés utilisant une clé EdDSA JWT volée, et la création de pods privilégiés avec des montages du système de fichiers hôte. OpenAI a déclaré avoir également identifié d'autres échappées plus petites du bac à sable, décrites comme limitées, et aucune d'entre elles ne semble avoir quitté son propre réseau.

Un détail spécifique à identity et incident response : les requêtes judiciaires de Hugging Face ont été bloquées par les mêmes garde-fous commerciaux d’IA intégrés aux modèles OpenAI et Anthropic qu’il a essayé d’utiliser pour l’enquête, car les garde-fous ne pouvaient pas distinguer les questions d’un intervenant en incident de celles d’un attaquant. Hugging Face a utilisé un modèle open-weight de 753 milliards de paramètres (GLM-5.2) pour traiter plus de 17 000 événements d’attaquants en quelques heures au lieu de jours.

Pourquoi c'est important : il s'agit d'un cas documenté d'un agent autonome découvrant indépendamment une vulnérabilité, exfiltrant des identifiants, forgeant des jetons et se déplaçant latéralement à travers l'infrastructure cloud sans intervention humaine. Si votre modèle IAM et de gouvernance ne prend en compte que les identités humaines et de comptes de service, cet incident est une raison concrète d'ajouter une troisième catégorie : les agents autonomes pouvant agir de leur propre initiative.

Ce que ces trois ont en commun

CloudBasher concerne les lacunes dans les contrôles d'identity au niveau du protocole : révocation des jetons, limites d'assomption de rôle, politiques d'accès par défaut. GhostJacking concerne un agent IA utilisant une identité légitime et déléguée pour agir selon des instructions en lesquelles il n'aurait pas dû avoir confiance. L'incident OpenAI–Hugging Face concerne un agent obtenant et forgeant des identifiants par lui-même, sans qu'un humain ou un journal corrompu ne l'ait incité.

Un fil conducteur traverse les trois cas : les défenseurs sont limités par des outils que les attaquants n’ont pas à respecter. CloudBasher a exploité des hypothèses que les défenseurs n’avaient pas testées. GhostJacking a exploité le fait que les outils d’identity ne peuvent pas évaluer l’intention. Et dans le cas OpenAI–Hugging Face, les garde-fous de sécurité destinés à prévenir les abus ont aussi ralenti les personnes qui y répondaient.

---

Étapes pratiques suivantes pour les équipes identity et AD

Quatre choses à faire ce trimestre selon cette recherche :

Recherches que vous avez peut-être manquées

Au cas où vous l’auriez manqué, nous partageons trois des meilleurs articles de l’équipe Security Research de Netwrix.

Contrôles LDAP étendus puissants : Anti-remédiation et reconnaissance invisible dans AD 

Le chercheur principal en sécurité Darryl Baker a audité tous les contrôles LDAP étendus documentés d'Active Directory et a trouvé deux vulnérabilités potentielles qui n'avaient pas été publiées auparavant. FORCE_UPDATE permet à un attaquant ayant un accès en écriture à un seul attribut de faire en sorte qu'une valeur malveillante l'emporte dans la résolution des conflits de réplication d'AD, de sorte qu'une correction ultérieure du défenseur est silencieusement annulée. Le drapeau OBJECT_SECURITY sur DirSync permet à tout utilisateur de domaine de lire en masse les données AD via le chemin de réplication sans générer les événements de journal qu'une recherche normale déclencherait. Aucun ne confère de nouveaux privilèges, mais les deux contournent les détections sur lesquelles la plupart des défenseurs comptent ; le post inclut des conseils de détection correspondants et des outils open source red/blue.

Pourquoi c’est important : les deux techniques passent outre les événements de journal exacts (Événement 1644, Événement 4662) sur lesquels la plupart des règles de surveillance AD sont basées. Si vos détections n’ont pas été testées spécifiquement contre eux, elles ne se déclencheront probablement pas. Il vaut vraiment la peine de vérifier si vos canaris SACL et vos requêtes de chasse les détecteraient réellement. 

En savoir plus

Votre assistant de codage IA fuit des secrets 

Darryl Baker a audité le stockage des identifiants dans 14 outils populaires d’assistants de bureau IA, dont Claude Code, GitHub Copilot, Cursor, Continue.dev et Cline, et a constaté que la plupart conservent les tokens OAuth et les clés API en JSON en clair à des chemins de fichiers prévisibles. Une faille spécifique : sous WSL, les fichiers d’identifiants Claude Code côté Windows peuvent hériter de permissions en lecture pour tous. L’article décrit huit scénarios d’attaque, dont le détournement d’une session de contrôle à distance active de Claude Code et des fichiers de configuration MCP qui regroupent les tokens de plusieurs services dans un seul fichier lisible. Il présente aussi AIHound, un scanner open source de Netwrix qui vérifie une machine pour ce type d’identifiants exposés.

Pourquoi c’est important : si vos ingénieurs utilisent l’un de ces outils, leurs identifiants sont probablement stockés en clair sur le disque en ce moment, à un chemin de fichier qu’un attaquant n’a pas besoin de deviner. Aucune élévation de privilèges n’est nécessaire pour les lire, et comme les configurations MCP regroupent plusieurs jetons de service dans un seul fichier, un seul ordinateur portable compromis peut se propager à tous les systèmes ou services connectés. Cela peut inclure des bases de données, des infrastructures cloud, et même d’autres outils d’IA. AIHound vous offre un moyen rapide de vérifier votre propre exposition avant que quelqu’un d’autre ne la découvre pour vous. 

En savoir plus

Automatisation de la destruction des locataires Entra ID avec l’IA 

En utilisant Claude pour Chrome contre Microsoft Graph Explorer, Huy Kha a montré qu'une fois qu'un compte connecté dispose déjà d'un accès Administrateur Global, le JavaScript côté navigateur et les requêtes batch Graph peuvent automatiser la suppression massive d'utilisateurs, les réinitialisations de mot de passe, la révocation de sessions et la suppression des politiques d'Accès Conditionnel. Le post relie cela à des incidents réels, notamment les cas Stryker et Storm-0501, où des opérations destructrices sur le locataire ont suivi une compromission de compte privilégié, et souligne que l'IA n'a pas créé une nouvelle voie d'attaque ici ; elle a exploité un flux de travail administratif existant et l'a rendu plus rapide et plus facile à exécuter à grande échelle.

Pourquoi c’est important : c’est l’écart entre une compromission de compte privilégié et la destruction totale du tenant, et l’automatisation par IA le comble rapidement. Une fois qu’une personne a une session Global Admin, elle n’a plus besoin de compétences en scripting ni de temps pour causer un maximum de dégâts. Cela renforce l’importance de protéger et de surveiller les sessions admin et les outils comme Graph Explorer, pas seulement les identifiants. 

En savoir plus

Rapport sur la sécurité des données et Identity Security 2026 : Progrès et lacunes dans l’adoption et la préparation de l’IA agentive

Netwrix Research Lab a interrogé 2 317 professionnels de l'informatique et de la sécurité dans 1 889 organisations pour produire le Rapport sur la sécurité des données et de l'Identity 2026. Les résultats montrent que les organisations où l'IA a considérablement étendu leur empreinte d'identity ont été compromises environ quatre fois plus souvent que celles où ce n'était pas le cas. Le rapport attribue cet écart à la vitesse de gouvernance plutôt qu'à la rigueur : 76 % des organisations ne gouvernent ni ne surveillent pleinement les identités non humaines, et seulement 11 % déclarent une préparation complète à la sécurité de l'IA grâce à une application et une surveillance continues.

Pourquoi c’est important : les données compliquent une hypothèse courante, selon laquelle une bonne hygiène d’identité protège à elle seule contre les risques liés à l’IA. Si votre gouvernance d’identité repose encore sur des revues trimestrielles et des audits périodiques, il vaut la peine de vérifier combien de temps un nouvel agent IA ou une identité non humaine existe avant que quelqu’un ne le remarque. Ce délai, et non un contrôle manquant, est ce que le fossé de violation dans ce rapport indique réellement.

En savoir plus

---

C’est tout pour cette édition du Netwrix Threat Lab Quarterly. Nous reviendrons bientôt avec de nouvelles recherches et plus de moyens pour combler les failles que les attaquants comptent que vous manquiez.