La chaîne de destruction d'identité : une histoire complète de la sécurité de l'identité, des mots de passe aux agents d'IA

Par Serge-Olivier Paquette, directeur des produits

Comment six décennies de décisions architecturales ont créé, et continuent de façonner, la principale surface d'attaque de l'entreprise moderne.

En 1962, Allan Scherr, doctorant au MIT, a imprimé le fichier de mots de passe du système CTSS (Compatible Time-Sharing System) afin de détourner du temps de calcul. Soixante-trois ans plus tard, un ver npm autoréplicatif nommé Shai-Hulud a exploité des jetons d'authentification volés pour infecter plus de 500 paquets et collecter toutes les données d'identité présentes sur les machines des développeurs. La technologie est méconnaissable, mais la logique opérationnelle reste identique : voler des identifiants, étendre son emprise, se propager latéralement et persister.

Voici l'histoire de la façon dont l'identité est devenue la principale surface d'attaque de l'entreprise, racontée à travers les décisions architecturales, les failles qui les ont exposées et la chaîne d'attaque en quatre étapes qui unifie chaque époque.

La chaîne de destruction d'identité en quatre étapes

Avant de retracer l'historique, le cadre : chaque violation majeure d'identité suit les mêmes quatre étapes, quelle que soit la technologie de l'époque.

Étape 1 : Obtenir les documents de certification

Acquérir un élément d'authentification : un mot de passe, un hachage, un ticket, un jeton, un cookie de session, un certificat de signature ou une clé API.

Étape 2 : Étendre les privilèges

Utilisez ce point d'appui initial pour obtenir des identifiants ou des autorisations de plus grande valeur grâce à des techniques telles que le Kerberoasting, le DCSync, l'abus du consentement OAuth ou l'ingénierie sociale du service d'assistance.

Étape 3 : Déplacement latéral via les artefacts d’authentification

Présenter des artefacts volés ou falsifiés à d'autres systèmes. Les techniques Pass-the-Hash, Pass-the-Ticket, les assertions SAML falsifiées et la relecture de session SSO sont autant de variantes d'une même opération : L'artefact constitue le justificatif d'identité, et celui qui le détient est authentifié.

Étape 4 : Persister dans le plan d’identité

Intégrez un accès qui résiste aux réinitialisations de mot de passe, aux révocations de jetons et aux réponses aux incidents : Golden Tickets, approbations de fédération non officielles, enregistrements d’applications OAuth malveillants et nouveaux principaux de service.

Les artefacts spécifiques changent à chaque époque. La chaîne d'élimination, elle, reste la même.

Ère 0 : La préhistoire, des machines locales à l’identité en réseau (1961-1999)

Le mot de passe a été inventé au MIT en 1961 pour le système de temps partagé compatible et compromis l'année suivante. Cela a donné le ton.

Unix (1969) a introduit le modèle UID/GID : élégant, minimal et fondé sur une hypothèse fondamentale selon laquelle L'identité est localeUn utilisateur existe sur une machine. Le fichier /etc/passwd associait les noms d'utilisateur à des UID et stockait initialement les mots de passe hachés dans ce même fichier accessible à tous.

Cette hypothèse s'est avérée erronée dès le premier contact avec les réseaux. L'essor d'ARPANET à la fin des années 1970 a nécessité un accès inter-machines, et les commandes r de BSD (rlogin, rsh, rexec) l'ont fourni grâce à une confiance implicite basée sur l'adresse IP : une fédération par emplacement réseau. FTP et Telnet, quant à eux, transmettaient les identifiants en clair. 

Kerberos, issu du projet Athena du MIT en 1984 (v4) et 1988 (v5), visait précisément à résoudre ce problème : un centre de distribution de clés (KDC) tiers de confiance émettant des tickets à durée de validité limitée et signés cryptographiquement. Les mots de passe ne transitent plus sur le réseau après l’authentification initiale. L’authentification unique (SSO) devient ainsi une réalité. Cependant, Kerberos centralise toute la confiance en un seul endroit, le KDC, créant ainsi les conditions propices aux attaques par « Golden Ticket » des décennies plus tard.

Parallèlement, la norme d'annuaire X.500 (ISO/UIT, 1988) prévoyait un annuaire hiérarchique global de toutes les entités du réseau. Trop lourde pour la production (elle nécessitait l'intégralité du modèle OSI), elle a été rendue plus accessible par LDAP (Université du Michigan, 1993), qui a conservé la structure de noms distinctifs et le modèle basé sur les attributs de X.500, contrairement au protocole TCP/IP standard. Les forêts, les arbres, les unités organisationnelles et le schéma d'Active Directory sont des descendants directs de X.500.

Il est important de noter que tous ces outils ont été développés par souci de commodité, en tant que solutions administratives, sans réelle prise en compte de la sécurité. Le mouvement d'architecture zéro confiance des années 2020 représente la première tentative concertée du secteur pour déconstruire ce modèle de conception persistant.

Et puis il y a eu le LM Hash… 

LAN Manager (1987) a introduit un système de hachage de mots de passe qui convertissait les mots de passe en majuscules, les divisait en deux moitiés de sept caractères et hachait chaque moitié indépendamment avec DES. L'espace de recherche maximal effectif était constitué de deux mots de passe indépendants de sept caractères (majuscules et chiffres), cassables en quelques minutes sur du matériel des années 1990. NTLM (Windows) NT Lan Manager), fourni avec Windows NT 3.1 en 1993, a amélioré le hachage mais a conservé une propriété fondamentale : le hachage is L'identifiant. Authentification par hachage ; aucun mot de passe requis. Les attaques par relais NTLM restent exploitables dans les environnements Active Directory de production en 2026. Le hachage LM, toujours présent dans les réseaux Windows, n'a été désactivé par défaut qu'avec Windows Vista. vingt ans plus tard.

Les catalyseurs : les hackers qui ont forcé la main de l’industrie

Le piratage de Citibank en 1994 a été la première preuve retentissante que le vol d'identifiants constituait une méthode d'attaque viable contre les grandes institutions, avant même l'existence des annuaires d'entreprise. Vladimir Levin n'a pas compromis les systèmes de Citibank par des failles techniques. Selon des témoignages ultérieurs de la communauté des hackers de Saint-Pétersbourg, un groupe de hackers (opérant sous les pseudonymes « ArkanoiD » et « Bukazoid ») avait passé des mois à explorer le réseau interne de Citibank par simple curiosité et avait découvert que de nombreux systèmes étaient totalement vulnérables. Levin leur aurait acheté les identifiants d'accès cruciaux pour seulement 100 dollars. Cent dollars pour les clés d'une banque. L'économie du vol d'identifiants était établie depuis trente ans. courtiers en accès initial et infostealer Les plateformes de marché ont formalisé ce même modèle à l'échelle industrielle.

Quatre ans plus tard, deux événements ont contraint les instances politiques et économiques à reconnaître ce que la communauté des chercheurs et des hackers savait déjà.

Lors de la DEF CON 6 en août 1998, le groupe Cult of the Dead Cow a présenté Back Orifice, un outil d'administration à distance de 124 Ko démontrant l'absence de modèle de sécurité efficace sous Windows 95/98. Microsoft l'a rejeté, estimant qu'il nécessitait une installation volontaire de l'utilisateur.

Des mois auparavant, L0pht Heavy Industries (sept membres témoignant sous pseudonyme de hackers devant le Sénat américain) avait démontré que son outil L0phtCrack pouvait casser les hachages NTLM de Windows avec une efficacité redoutable. L'affirmation de Mudge selon laquelle L0pht pouvait paralyser Internet en 30 minutes a provoqué une prise de conscience. L'audition a légitimé la communauté de la recherche en sécurité, a catalysé la politique fédérale de cybersécurité, a jeté les bases du système de divulgation des vulnérabilités CVE et, surtout pour la sécurité des identités, a contraint Microsoft à accélérer le développement de NTLMv2 et à adopter Kerberos comme protocole d'authentification par défaut pour le futur Active Directory de Windows 2000.

Un fil conducteur relie Citibank (1994), L0pht (1998) et toutes les crises d'identité qui ont suivi : L'écart entre ce que les institutions pensent de leur posture de sécurité et ce qui est réellement vrai est énorme.Un schéma bien établi s'est formé : un chercheur découvre une faille fondamentale → le fournisseur la rejette → le chercheur la rend publique → la faille est exploitée → le fournisseur est contraint de la corriger, des années et des milliards de dollars de dommages plus tard. 

Ère 1 : Active Directory et l’ère des artefacts d’identification (2000–2015)

Windows 2000 a livré (une grande quantité) d'Active Directory (AD), et avec lui la convergence de toute la dette de conception antérieure dans un seul système : Kerberos v5 pour l'authentification (avec les extensions de délégation non contraintes de Microsoft), LDAP/X.500 pour l'accès à l'annuaire, le modèle organisationnel DCE/Novell NDS pour les forêts et les approbations transitives, et NTLM/LM conservé pour la rétrocompatibilité.

Avant Active Directory, chaque application gérait sa propre base de données utilisateurs : identifiants distincts, contrôles d’accès séparés et une procédure de désactivation qui consistait essentiellement à espérer que l’on se souvienne de désactiver chaque compte (ce qui était rarement le cas). Active Directory a résolu ce problème en fournissant un référentiel d’identités unique et centralisé. Il s’agissait en réalité d’un outil d’administration informatique puissant, avec très peu de considérations de sécurité. Il a ainsi créé une cible unique et d’une valeur inestimable.

Le catalyseur réglementaire

Parallèlement et sans aucun lien apparent, suite aux révélations d'une fraude comptable massive et systémique commise par plusieurs niveaux de direction chez Enron, la loi Sarbanes-Oxley (SOX) de 2002 a catalysé la première vague significative de dépenses en matière de sécurité des identités. Les exigences de contrôle interne de l'article 404 ont de facto imposé des mesures qui ont conduit à la création, du jour au lendemain, des premiers programmes de gestion des identités et des accès (IAM) dans toutes les sociétés cotées. La séparation des tâches a favorisé l'adoption du contrôle d'accès basé sur les rôles (RBAC). L'impératif de traçabilité a créé la gestion des accès privilégiés en tant que catégorie de marché distincte (la croissance de CyberArk est fortement liée à la loi SOX). La gouvernance et l'administration des identités ont émergé pour effectuer des revues d'accès trimestrielles sur des milliers de droits. La visibilité de l'IAM au niveau du conseil d'administration, permise par les dispositions relatives à la responsabilité pénale personnelle, a créé la première véritable justification budgétaire qui n'existait pas auparavant. Il est important de noter que la loi SOX ne mentionne ni la mise en œuvre technologique ni la notion de sécurité des identités ; pourtant, les solutions développées ont été le moteur de la création de ce marché. pour la conformité réglementaire et l'auditabilité, pas pour la sécurité des informations proprement dite.

Mais la surface d'attaque était déjà grande ouverte.

Mimikatz : Le point d'inflexion

Mimikatz (2011) Tout a changé. Benjamin Delpy, un responsable informatique français, a découvert que Windows stockait les mots de passe chiffrés dans la mémoire LSASS avec les clés de déchiffrement. Il l'a signalé à Microsoft. Réponse de Microsoft : Ce n'est pas un véritable problème car l'attaquant a déjà besoin d'un accès administrateur. La réponse de Delpy était sans équivoque : dans un environnement d'entreprise, une seule machine compromise ouvre la voie à toutes les autres. Il publia Mimikatz, terme argotique français désignant des « chats mignons », sur GitHub. Dans les deux années qui suivirent, plus de vingt groupes APT l'adoptèrent. Il demeure l'outil de sécurité d'identité le plus déterminant jamais créé.

Grâce aux informations d'identification extractibles de la mémoire, la chaîne de destruction de l'ère AD s'est cristallisée :

• Étape 1: Hachages NTLM, tickets Kerberos, secrets de domaine mis en cache, journaux de voleurs d'informations, extractions d'identifiants de LSASS, SAM et NTDS.dit.
• Étape 2Kerberoasting (demande d'un ticket de service pour n'importe quel compte SPN, crack hors ligne — aucun bruit, aucune tentative de connexion infructueuse), DCSync (imitation du protocole de réplication d'un contrôleur de domaine pour extraire les hachages de mot de passe de n'importe quel compte, y compris KRBTGT, à partir d'un poste de travail), abus d'ACL, exploitation de l'imbrication de groupes.
• Étape 3: Pass-the-Hash (hash NTLM = identifiant, utilisable contre tout service NTLM), Pass-the-Ticket (injection d'un TGT ou d'un ticket de service volé), Overpass-the-Hash (conversion du hachage NTLM en ticket Kerberos).
• Étape 4: Golden Ticket (compromettez le hachage KRBTGT pour forger des TGT pour n'importe quel utilisateur à n'importe quel niveau de privilège — mode dieu fonctionnel jusqu'à la rotation de KRBTGT) deux fois), nouveaux comptes d'administrateur de domaine, modification de AdminSDHolder.

BloodHound : Rendre la chaîne de mise à mort calculable

BloodHound (DEF CON 24, 2016) Ils ont rendu cette chaîne d'attaque visible ! Robbins, Vazarkar et Schroeder ont constaté qu'Active Directory est un graphe : utilisateurs, groupes, ordinateurs, sessions, listes de contrôle d'accès (ACL) et approbations forment des arêtes que les algorithmes de recherche de plus court chemin peuvent parcourir. SharpHound collecte ce graphe pour tout utilisateur de domaine authentifié, sans privilèges d'administrateur. Neo4j l'ingère. La requête « chemin le plus court de cet utilisateur vers Administrateur de domaine » révèle des chaînes d'escalade à plusieurs sauts, invisibles dans un tableur. Le nombre d'utilisateurs ayant accès au statut d'Administrateur de domaine est, dans la plupart des environnements, alarmant.

BloodHound est désormais un outil standard dans la panoplie de tout professionnel de la sécurité sérieux.

NotPetya : La preuve à 10 milliards de dollars

Le 27 juin 2017, NotPetya a démontré à grande échelle ce que signifie une compromission du plan d'identité.

Point d'entrée : compromission de la chaîne d'approvisionnement de MEDoc, logiciel fiscal ukrainien. Propagation : EternalBlue et EternalRomance (vulnérabilités SMB de la NSA divulguées) combinés à l'attaque par transmission de hachage Mimikatz. Le dimanche précédant l'attaque, un administrateur de domaine s'était connecté au serveur MEDoc pour un inventaire de routine. Ces identifiants mis en cache ont été la première chose que Mimikatz a extraite.

En sept minutes, Maersk a perdu 49 000 ordinateurs portables, 3 500 de ses 6 200 serveurs et tous ses contrôleurs de domaine Active Directory. L'entreprise a reconstruit ses systèmes à partir d'un unique contrôleur de domaine hors ligne au Ghana, maintenu hors service uniquement en raison d'une coupure de courant accidentelle. Les équipes ont été transférées par avion à Copenhague pour la récupération des données. Le coût total des dégâts à l'échelle mondiale s'élève à plus de 10 milliards de dollars (estimation de la Maison Blanche). La seule opération de récupération de Maersk a coûté 300 millions de dollars.

La leçon à retenir : compromettre le plan d’identité ne vous donne pas seulement accès, cela vous donne la possibilité de refuser l’accès à tous les autres.

La réponse défensive

L'ère de la défense antiaérienne a produit des systèmes de défense qui ciblaient directement les étapes de la chaîne de destruction : 

• Protection des identifiants : secrets LSASS isolés dans des conteneurs VBS, empêchant Mimikatz de les lire facilement.
• Groupe d'utilisateurs protégés : (Pas de NTLM, pas de DES, pas de RC4, pas de mise en cache des informations d'identification, suppression de PtH)
• LAPS : mots de passe d’administrateur local aléatoires par machine, éliminant le problème du « hachage unique pour les gouverner tous »
• Administration hiérarchisée : Niveau 0 pour les contrôleurs de domaine/KRBTGT, Niveau 1 pour les serveurs, Niveau 2 pour les postes de travail 
• Chiffrement AES Kerberos avec comptes de service gérés de groupe pour rotation automatique
• Gestion des vecteurs d'attaque via BloodHound CE et d'autres solutions de gestion de la posture de sécurité des identités.

Ère 2 : La Fédération et l'explosion des jetons (2005-2020)

La chaîne de mort a franchi le périmètre.

Avec la migration des entreprises vers le web via les SaaS et les portails partenaires au milieu des années 2000, un nouveau problème est apparu : les utilisateurs avaient besoin d’un accès authentifié aux applications hébergées hors du réseau d’entreprise, mais personne ne souhaitait transmettre les identifiants Active Directory sur Internet. SAML (Security Assertion Markup Language) a résolu ce problème grâce à un modèle de délégation de confiance. Un fournisseur d’identité (IdP) – généralement les services de fédération Active Directory (ADFS) de Microsoft, qui font le lien entre l’Active Directory local et le monde extérieur – authentifie l’utilisateur une seule fois et émet un fichier XML signé. affirmation, Imaginez un certificat médical signé autorisant l'absence scolaire. Le fournisseur de services externe (FSE) fait confiance à cette autorisation car il fait confiance au certificat de signature (la signature du médecin). Les cours sont terminés, l'utilisateur bénéficie d'un accès inter-domaines transparent ; le mot de passe reste confidentiel. Élégant, puissant et, comme on l'a découvert par la suite, fatalement dépendant de la confidentialité d'une unique clé de signature.

SAML 2.0 et ADFS permettent concrètement au fournisseur d'identité d'une organisation d'émettre une authentification. affirmation aux fournisseurs de services externes. Les identifiants ne quittent jamais l'organisation. Cependant, les clés de signature et les configurations d'approbation de fédération deviennent les nouvelles cibles des attaques, et les conséquences de leur compromission sont d'une ampleur bien plus importante que tout ce qui s'est produit à l'ère Kerberos.

Golden SAML et SolarWinds

En 2017, les chercheurs de CyberArk ont ​​publié la technique Golden SAML, une technique qui semblait au mieux théorique : si un attaquant compromet le certificat de signature de jeton ADFS, il peut falsifier une réponse SAML pour n’importe quel utilisateur disposant de n’importe quel droit d’accès à n’importe quel service fédéré, contournant ainsi complètement l’authentification multifacteur (MFA), car celle-ci est parfois utilisée. avant L'assertion est validée. L'attaquant contourne complètement le fournisseur d'identité.

L'idée a germé 3 ans plus tard… SolarWinds/Solorigate (découvert en décembre 2020) était une attaque Golden SAML exécutée à l'échelle d'un État. La chaîne d'attaque, cartographiée : 

• Étape 0 : Entrée dans la chaîne d'approvisionnement via une mise à jour SolarWinds Orion infectée par un cheval de Troie (précurseur).
• Étape 1: Passez au niveau d'administrateur de domaine et extrayez le certificat de signature ADFS.
• Étape 2 : Fabriquer des affirmations à partir de prétentions arbitraires.
• Étape 3 : Accédez à M365, Azure et AWS via un certificat SAML falsifié.
• Étape 4 : Ajouter des approbations de fédération non autorisées pour une réentrée persistante.

La correction s'est avérée extrêmement difficile. Les assertions falsifiées sont cryptographiquement indiscernables des assertions légitimes et persistent même après la suppression de la porte dérobée. La restauration a nécessité le renouvellement de tous les certificats et la reconstruction complète de chaque fédération d'approbation. Le test Silver SAML (2024), ciblant les certificats externes d'Entra ID, a démontré que la migration vers le cloud n'éliminait pas totalement cette vulnérabilité.

OAuth, OIDC et jetons partout

Alors que SAML fédérait l'authentification humaine au-delà des frontières organisationnelles, un autre problème se développait en interne : les applications tierces avaient besoin d'accéder aux données utilisateur sans que ces derniers aient à divulguer leurs mots de passe (par exemple, les intégrations SaaS et de services web). OAuth 2.0 (formalisé dans la RFC 6749, 2012) a introduit une solution… autorisation Ce cadre repose sur des jetons d'accès limités dans le temps et à portée restreinte : un utilisateur accorde à une application des autorisations spécifiques, et celle-ci reçoit un jeton porteur plutôt qu'une authentification. OpenID Connect (OIDC) ajoute une couche d'authentification supplémentaire, en intégrant des jetons Web JSON (JWT) signés qui contiennent des informations d'identité : qui vous êtes, et pas seulement ce que vous êtes autorisé à faire. Ensemble, ils sont devenus l'infrastructure sous-jacente à chaque bouton « Se connecter avec Google », à chaque intégration SaaS-à-SaaS et à chaque appel d'API dans l'entreprise moderne.  

Il en a résulté une explosion d'identifiants porteurs : jetons d'accès, jetons d'actualisation, cookies de session, jetons d'identification et clés API dispersés dans le stockage du navigateur, les trousseaux mobiles, les appels d'API, les pipelines CI/CD, les intégrations SaaS et bien sûr, les référentiels techniques (Github, Dockerhub, etc.). 

Cela surpasse de loin tout ce que l'ère Active Directory a produit. Avec Kerberos, tous les éléments résidaient au sein du réseau. À l'ère d'OAuth, ils sont omniprésents et nombre d'entre eux sont accessibles à quiconque les possède.

AiTM (adversaire du milieu – kits d'hameçonnage) Le phishing a rendu cela concret. Des outils comme Evilginx2 servent de proxy entre la victime et la véritable page de connexion ; l’utilisateur effectue l’authentification multifacteur (MFA) normalement, et le proxy capture le cookie de session et les jetons OAuth. L’authentification multifacteur par notification push est désormais efficacement contournée face aux attaques ciblées. AiTM est une technique de première étape qui capture… post-authentification des artefacts, rendant l'authentification multifacteur inutile pour la session enregistrée.

Tempête de neige nocturne : une masterclass OAuth

Fin 2023, les services de renseignement russes (Midnight Blizzard) ont compromis la messagerie d'entreprise de Microsoft, non pas par le biais d'une faille zero-day ou d'un implant de logiciel malveillant, mais par le biais de la chaîne d'attaque d'identité exécutée entièrement dans le plan OAuth.

• Étape 1: Réinitialiser un compte de test oublié grâce à un mot de passe.
• Étape 2: Découvrir une application OAuth dormante avec full_access_as_app — abus de consentement pour l'extension des privilèges.
• Étape 3: Créez des jetons d'accès pour lire n'importe quelle boîte aux lettres.
• Étape 4: Créer de nouvelles applications OAuth malveillantes pour assurer leur persistance.

Aucune compromission sur site n'a été nécessaire. L'intégralité de la faille reposait sur une identité non humaine, une application OAuth inactive et dotée de privilèges excessifs, non surveillée par un humain. La détection aurait pu être effectuée à l'étape 2 grâce à la gouvernance NHI. Celle-ci n'était cependant pas en place.

Ère 3 : Échelle des matières premières et économie du vol d’informations (2022-présent)

Scattered Spider (UNC3944) a industrialisé la chaîne de destruction d'identité. Son modèle opérationnel : 

• Étape 1: bûches de voleur Des fichiers contenant les identifiants SSO d'entreprise et les cookies de session sont disponibles pour quelques dollars sur les marchés du dark web. 
• Étape 2: Utilisation de techniques d'ingénierie sociale par le service d'assistance pour contourner l'authentification multifacteur et inscrire les appareils des attaquants. 
• Étape 3Une seule session Okta ouvre toutes les applications SaaS en aval, exploitant ainsi la portée de l'authentification unique (SSO). 
• Étape 4Les nouvelles brèches sont exécutées plus rapidement que les mesures correctives, remplaçant la persistance sophistiquée par la vitesse.

Les résultats sont éloquents : MGM a subi plus de 100 millions de dollars de dommages suite à un seul appel téléphonique. Caesars a versé une rançon de 15 millions de dollars. L’opération Snowflake a touché environ 165 victimes. Parmi les autres organisations affectées figurent des détaillants britanniques et des compagnies aériennes internationales. Des opérateurs de Scattered Spider ont même participé en temps réel aux appels d’assistance aux victimes ! 

Ce groupe, réunissant d'anciens membres de ShinyHunters et de Lapsus$ au sein de la marque d'extorsion SLSH, a démontré que la chaîne d'usurpation d'identité à grande échelle est aussi dévastatrice que les opérations d'États. Il s'agit d'un Rançongiciels sans chiffrement.

Ère 4 : Prolifération des identités non humaines et frontière des agents IA (présent et futur)

Les identités non humaines (INH) sont désormais 45 fois plus nombreuses que les humains : comptes de service, conteneurs cloud, applications OAuth, clés API, identifiants CI/CD, jetons d'agents d'IA, avec des identifiants à longue durée de vie, surprivilégiés et sans propriétaire, invisibles pour les outils IAM traditionnels.

Chaque agent d'IA nécessite un accès via des jetons et des clés. Les agents fantômes s'affranchissent totalement de la gouvernance. Les applications codées avec Vibe (prototypage rapide assisté par IA) intègrent des secrets directement dans les modules frontaux. À prévoir en 2025. analyse de 5 600 applications de ce type Plus de 2 000 vulnérabilités et plus de 400 secrets exposés ont été découverts.

Le ver npm Shai-Hulud (septembre 2025) a unifié la chaîne d'approvisionnement et les récits relatifs à l'assurance maladie nationale. Il a utilisé des jetons de publication volés pour infecter plus de 500 paquets, a collecté toutes les données d'identité présentes sur les machines des développeurs et a publié automatiquement des versions infectées sous l'identité des victimes, exécutant ainsi la chaîne d'attaque complète en quatre étapes dans une boucle automatisée et auto-réplicative.

Les identifiants non déclarés (NHI) constituent des cibles de niveau 1 que la plupart des organisations ne recensent pas, des vecteurs de niveau 2 présentant des privilèges excessifs et des mécanismes de persistance de niveau 4 qui survivent aux changements d'identifiants humains. Ce sont des identifiants fantômes : des comptes qui persistent indéfiniment car aucun événement lié au cycle de vie humain (départ, changement de rôle, renouvellement du mot de passe) ne déclenche leur vérification.

Architecture IdP moderne à travers le prisme de la chaîne d'attaque

Les fournisseurs d'identité contemporains (Entra ID, Okta) partagent cinq modèles de risques architecturaux qui correspondent directement aux vulnérabilités de la chaîne d'interruption :

• Le Le fournisseur d'identité comme fondement de la confiance crée un point de défaillance unique. 
• Le jeton-comme-monnaie Ce modèle implique que chaque justificatif d'identité est susceptible d'être volé. 
• Le Registre d'applications en tant que plan de contrôle NHI c'est là que les artefacts de l'étape 1 (identifiants NHI) s'accumulent sans surveillance, selon le modèle de la tempête de neige de minuit. 
• Le moteur de politique comme frontière de sécurité évalue les conditions lors de l'émission du jeton, et non lors de sa présentation — un jeton volé conserve ses autorisations jusqu'à son expiration. 
• Le pont hybride La connexion de l'AD local aux IdP cloud relie directement la chaîne d'attaque de l'ère Kerberos à la chaîne d'attaque de l'ère cloud.

Les signaux les plus fiables de l'activité de l'étape 4, ceux qui détectent la persistance en cours, sont les modifications apportées aux approbations de fédération, les nouveaux enregistrements d'applications OAuth, les activations de rôles privilégiés, les modifications d'accès conditionnel et les anomalies d'utilisation des jetons SCIM.

Briser la chaîne de destruction : l'image miroir défensive

Chaque étape de la chaîne de destruction comporte une contre-mesure structurelle :

Étape 1 : Réduire la valeur des identifiants. L'authentification résistante au phishing (WebAuthn/clés d'accès) crée des identifiants liés à l'origine que les sites de phishing ne peuvent pas physiquement exploiter. L'élimination structurelle du phishing d'identifiants est la technique la plus courante de la première étape.

Étape 3 : Réduire la réutilisation des artefacts. Le protocole DPoP (RFC 9449) associe les jetons à des paires de clés client. Le protocole CAEP permet une révocation quasi instantanée. Le protocole Device Trust vérifie en permanence la conformité. Un jeton volé devient inutilisable hors de son contexte d'utilisation prévu.

Étape 4 : Renforcer les limites de la confiance. Surveillez et limitez les modifications apportées aux relations d'approbation de fédération, aux enregistrements d'applications OAuth et aux politiques d'accès conditionnel. Considérez chaque modification du plan de contrôle des identités comme une alerte de haute fiabilité.

Étapes 1, 2 et 4 : Gouvernance de l'assurance maladie nationale. Découverte automatisée, application du principe du moindre privilège, identifiants éphémères, registres d'agents IA et surveillance comportementale. Traitez chaque NHIi comme un élément essentiel de la gouvernance des identités.

Étape 4 de détection en cours : Détection de la dérive du plan d’identité. Surveillance continue des signaux spécifiques de persistance : approbations de fédération non autorisées, applications OAuth malveillantes, règles d’accès conditionnel modifiées, comptes inactifs disposant de privilèges permanents.

Liste de contrôle de démarrage rapide pour la sécurité de l'identité : Plan d'action par étapes pour les praticiens

Consultez ci-dessous la version téléchargeable de la liste de contrôle (et vous pouvez cliquer pour cocher les éléments que vous avez complétés), ou continuez à lire pour découvrir le même plan.

0. Sachez si vous êtes déjà compromis

Avant toute mesure de sécurité, vérifiez si vos identifiants circulent déjà. Abonnez-vous à un service externe de surveillance des fuites d'identité (flux de journaux de vol d'informations, bases de données de violations d'identifiants, données techniques d'exposition) et comparez immédiatement les identifiants exposés avec votre annuaire. Si des comptes compromis existent, corrigez-les en priorité. Ensuite, suivez les quatre niveaux ci-dessous :

1. Réduire la valeur des diplômes

Objectif : Les artefacts volés devraient expirer avant que les attaquants puissent les utiliser.

1. Auditez les comptes dont les mots de passe n'expirent pas. Priorisez les comptes de service disposant de privilèges similaires à ceux d'un administrateur.
2. Imposer l'authentification multifacteur (MFA) à tous les comptes d'administrateur des fournisseurs d'identité. Aucune exception ne sera faite sans clés matérielles.
3. Réduisez la durée de vie des jetons d'accès OAuth à ≤ 1 heure pour les applications sensibles. Renouvelez les clés API de plus de 90 jours.

2. Réduire la réutilisation des artefacts

Objectif : Une certification obtenue dans un contexte donné ne devrait avoir aucune valeur dans un autre.

1. Bloquer les connexions administrateur depuis des appareils non gérés via les politiques d'accès conditionnel/d'authentification.
2. Exigez la conformité des appareils pour vos cinq principales applications SaaS sensibles.
3. Activez l'évaluation continue des accès (CAE) afin que les sessions soient révoquées en temps quasi réel en cas de changement des signaux de risque.

3. Renforcer les limites de la confiance

Objectif : Protéger l'infrastructure qui émet et valide les identités.

1. Dressez la liste de tous les domaines fédérés et des fournisseurs d'identité externes que vous approuvez. Examinez ceux que vous ne reconnaissez pas.
2. Limiter l'enregistrement des applications OAuth et l'octroi des autorisations d'administrateur aux seuls administrateurs approuvés.
3. Recenser toutes les identités non humaines (principaux de service, clés API, jetons CI/CD, jetons d'enregistrement de packages). Attribuer un propriétaire vivant à chacune.

4. Détection de la dérive du plan d'identité

Objectif : C’est dans l’écart entre ce que dit l’audit et la réalité que se situent les infractions.

1. Activez les alertes concernant les nouvelles attributions de rôles d'administrateur, les modifications d'accès conditionnel, les ajouts de domaines fédérés et les enregistrements d'applications OAuth à privilèges élevés.
2. Exécutez BloodHound/AzureHound. Comptez les utilisateurs ayant un chemin vers le niveau 0. Cela constitue votre référence.
3. Mettre en place un examen mensuel de la posture d'identité : comptes privilégiés inactifs, identifiants NHI non renouvelés, tendances des vecteurs d'attaque, dérive des autorisations OAuth.

L'identité numérique est désormais la cible de collecte de données la plus précieuse, tant pour les attaquants que pour les défenseurs. Sécuriser votre organisation en suivant ces étapes sera crucial pour garder une longueur d'avance sur les acteurs malveillants à l'ère de la vérification d'identité plutôt que du piratage. 

Les artefacts ont évolué, passant des hachages NTLM aux assertions SAML, puis aux jetons OAuth et enfin aux identifiants d'agents d'IA, mais la logique opérationnelle est restée la même depuis qu'Allan Scherr a imprimé ce fichier de mots de passe en 1962.

Les adversaires n'exploitent pas la négligence. Ils exploitent des décisions historiques.

______

Cet article s'appuie sur des éléments de l'atelier de Flare sur la sécurité des identités, une formation en deux parties destinée aux praticiens et couvrant l'évolution de la sécurité des identités, des annuaires aux agents d'IA.