Cas d'école IAM
Token OAuth compromis, compte de service détourné, habilitation trop large, privilège persistant, comportement anormal passé sous les radars… Les mécanismes changent, mais l'identité est souvent au centre de la chaîne d'attaque. Ariovis analyse ici des incidents documentés pour identifier les contrôles IAM qui auraient pu les prévenir ou en réduire l'impact.
Comprendre notre approche pour prévenir les fuites de donnéesUne analyse cyber classique cherche d'abord le vecteur d'entrée : la vulnérabilité exploitée, le message piégé, le service exposé. C'est nécessaire, mais insuffisant pour comprendre pourquoi un incident a produit une fuite de données de cette ampleur. Nous complétons cette lecture par les questions d'identité et d'habilitation qui viennent juste après l'intrusion.
Chaque cas est adressable directement par son ancre pour être cité ou partagé.
SaaS / supply chain · Mars – août 2025
Plus de 700 organisations affectées par des tokens OAuth volés associés aux intégrations Drift. Une application de confiance, un credential valide, et l'authentification humaine n'est plus la barrière pertinente.
Assurance / CRM cloud · Juillet 2025
Un utilisateur légitime, correctement authentifié, autorise au téléphone une Connected App contrôlée par l'attaquant. À partir de là, les appels API ressemblent à ceux d'une application approuvée.
SaaS / support externalisé · Septembre 2025
Un accès de support utilisé par un prestataire externe a permis d'atteindre l'environnement de support client de Discord. Moins une « faille Zendesk » qu'un problème de maîtrise des identités tierces, de leurs capacités et de leur comportement après authentification.
Automobile / industrie · Août – octobre 2025
À partir du 31 août 2025, une cyberattaque conduit Jaguar Land Rover à arrêter une partie de son système d'information. Conséquence immédiate : production et opérations commerciales paralysées. Le vecteur d'accès initial n'est pas publiquement établi.
Luxe / Retail · Accès initial revendiqué en avril 2025 · incident identifié par Kering en juin 2025 · rendu public en septembre 2025
Une campagne d'ingénierie sociale où une autorisation applicative légitime peut devenir un canal d'exfiltration.
Services financiers / Fintech · Juin – août 2025 · incident détecté le 1er septembre 2025
Prosper a établi qu'un tiers non autorisé avait accédé à ses systèmes et obtenu des informations au moyen de requêtes sur des bases contenant les données de clients et de candidats. Le vecteur initial n'est pas public : l'intérêt IAM du cas commence donc après l'accès, en regardant les privilèges capables d'atteindre directement la donnée et les signaux qui devraient accompagner un usage massif.
Microsoft Entra ID · IAM / Sécurité des identités / Cloud · Septembre 2025
Une vulnérabilité combinant les Actor Tokens de Microsoft et une validation insuffisante dans l'ancienne API Azure AD Graph permettait une impersonation cross-tenant pouvant aller jusqu'aux privilèges Global Administrator. Le cas montre pourquoi sécuriser uniquement le login et le MFA ne suffit plus.
Secteur : SaaS / supply chain · Période : Mars – août 2025
Plus de 700 organisations ont été affectées par une attaque supply-chain exploitant des tokens OAuth volés associés aux intégrations Drift. L'incident illustre un angle mort encore fréquent de l'IAM : les applications disposent elles aussi d'une identité, de droits et d'un cycle de vie qu'il faut gouverner.
Mars à juin 2025 — selon l'investigation Mandiant publiée par Salesloft, l'acteur malveillant a eu accès au compte GitHub de Salesloft, téléchargé le contenu de plusieurs repositories, ajouté un utilisateur invité et mis en place des workflows. Des activités de reconnaissance ont ensuite été observées dans les environnements Salesloft et Drift.
L'investigation a ensuite établi un accès à l'environnement AWS de Drift, depuis lequel l'attaquant a obtenu des tokens OAuth associés aux intégrations technologiques de clients.
8 au 18 août 2025 — ces credentials OAuth ont été utilisés pour accéder à des environnements clients via les intégrations Drift et exfiltrer des données. Salesloft documente cette fenêtre ; FINRA recommande également d'y rechercher les accès anormaux.
Précision de méthode : certaines publications initiales évoquaient des tokens obtenus lors de campagnes antérieures de phishing ou de social engineering. Nous retenons ici la chronologie postérieure et plus précise établie par l'investigation, et nous ne présentons pas les deux hypothèses comme démontrées simultanément.
Une attaque de la relation de confiance
Aucune étape de cette chaîne ne suppose qu'un utilisateur humain se reconnecte.
Le problème IAM : l'identité qui accédait aux données n'était pas humaine. Lorsqu'une personne se connecte, on peut lui demander un mot de passe, un facteur supplémentaire, une authentification adaptative, un terminal conforme, un contexte cohérent.
Une intégration OAuth fonctionne autrement. Une fois la relation de confiance établie et un credential délivré, l'application appelle les API dans la limite des autorisations qui lui ont été accordées. L'attaquant n'avait donc pas besoin de refaire le parcours d'un utilisateur humain : FINRA indique que les tokens volés permettaient d'usurper l'application Drift de confiance et de contourner le parcours traditionnel de MFA.
Le token est le credential de cette identité applicative, pas son identité. C'est cette distinction qui déplace le sujet : de l'authentification humaine vers la gouvernance de l'identité applicative, de ses credentials, de ses autorisations et de son comportement.
Le MFA n'a pas échoué
Il protégeait une autre étape de la chaîne. Une fois un credential OAuth valide compromis, le problème se déplace de l'authentification humaine vers la gouvernance de l'identité applicative, de ses credentials, de ses autorisations et de son comportement.
L'intégration SaaS est une identité
Une identité non-humaine peut être une application, une intégration SaaS, un compte de service, un workload, un bot ou un agent IA. Elle possède elle aussi :
Le fait qu'aucune personne physique ne se connecte ne retire pas le sujet du périmètre IAM : c'est précisément ce qui en fait un sujet de gouvernance des identités non-humaines. Précision utile : « identité non-humaine » ne signifie pas nécessairement flow OAuth client_credentials.
FINRA indique que la campagne a touché plus de 700 organisations et que les attaquants ont notamment accédé à des environnements Salesforce, Google Workspace et, dans certains cas, Slack. Les données exposées pouvaient inclure contacts, comptes, opportunités et cases, mais aussi des API keys, des credentials cloud, des mots de passe et des tokens présents dans les contenus.
Cloudflare, qui a publié sa réponse, explique que son environnement Salesforce contenait des informations issues des tickets de support susceptibles d'embarquer des tokens ou des mots de passe. L'entreprise a identifié 104 tokens API Cloudflare dans les données concernées et les a tous fait tourner, sans avoir identifié d'activité suspecte associée à ces tokens.
C'est là que la notion de blast radius devient concrète : la donnée volée peut devenir le credential de l'attaque suivante. Une intégration compromise donne accès au CRM, le CRM contient un token, ce token ouvre potentiellement un troisième système. Le rayon d'action dépasse alors largement le SaaS initialement concerné.
Les contrôles orientés utilisateur — mot de passe, MFA, authentification adaptative — encadraient une étape que l'attaquant n'avait pas besoin de franchir : il disposait d'un credential déjà accordé à une application de confiance.
À partir de là, seuls des contrôles portant sur l'identité applicative pouvaient encore agir : périmètre des autorisations accordées, durée de validité du credential, capacité de révocation, et surveillance de l'usage réel de l'intégration.
Aucun contrôle isolé n'aurait nécessairement empêché l'incident. L'enjeu est de réduire la marge de manœuvre à chaque étape.
Prévenir
Limiter
Détecter
Réagir
Ce ne sont pas « cinq erreurs commises » : les sources ne permettent pas d'affirmer que ces contrôles étaient absents. Ce sont les enseignements IAM que nous tirons du cas.
1 — Gouverner l'intégration comme une identité
Une intégration sensible doit avoir un propriétaire métier, un propriétaire technique, une finalité, un fournisseur, une liste des ressources accessibles, des permissions documentées, une procédure de révocation, une fréquence de revue et un événement de fin de vie.
C'est exactement le cycle de vie que l'on applique aux humains : onboard, modify, review, offboard.
Une identité non-humaine sans propriétaire doit être traitée comme une anomalie.
2 — Appliquer le moindre privilège à l'application
La question n'est pas seulement « cette application a-t-elle accès au CRM ? », mais « pour faire exactement quoi, sur quelles données et avec quelle profondeur ? ».
Concrètement : scopes OAuth, permission sets, objets accessibles, opérations autorisées, séparation des usages, droits réellement nécessaires. FINRA recommande explicitement le moindre privilège pour les applications tierces.
Une compromission ne peut pas toujours être empêchée. Son rayon d'action, lui, peut être conçu à l'avance.
3 — Gouverner les credentials dans le temps
Le credential d'une application a lui aussi un cycle de vie : émission, stockage, rotation lorsqu'elle est pertinente, expiration lorsqu'elle est supportée, révocation, procédure de rotation d'urgence, retrait lorsque l'intégration n'est plus utilisée.
Nous ne fixons pas de durée arbitraire : la bonne politique dépend du protocole et de la plateforme.
4 — Regarder ce que l'identité fait réellement
Un credential valide ne veut pas dire que son usage est normal. Il faut comparer le droit théorique à l'usage observé : nombre d'appels API, fréquence, volume de données, exports massifs, objets consultés, plages horaires, adresses IP, User-Agent, changement brutal de comportement. FINRA recommande précisément de rechercher les exports inhabituels et les patterns d'accès anormaux.
Une intégration CRM qui synchronise habituellement quelques centaines d'objets n'est plus dans son comportement normal lorsqu'elle parcourt soudainement des volumes massifs de données. Même si son token est parfaitement valide.
C'est ici que se rencontrent identité, autorisation, comportement et volumétrie.
5 — Ne pas considérer l'autorisation initiale comme éternelle
Sur une API ou une application maîtrisée par l'entreprise, la décision peut aller plus loin que « token valide = accès autorisé » : le point d'application demande une décision, le moteur de politique évalue identité, ressource, action, contexte et risque, puis autorise ou refuse.
Une intégration peut avoir le droit de lire une donnée, sans avoir le droit de lire cette catégorie de données, à ce volume, depuis ce contexte, à cet instant, ou après un signal de risque. Nous ne prétendons pas qu'un moteur d'autorisation aurait protégé cette architecture précise : c'est une capacité supplémentaire sur les ressources que l'organisation maîtrise, pas une remédiation universelle au SaaS tiers.
L'IAM ne peut plus gouverner uniquement les humains. Une application SaaS peut disposer de droits très puissants, agir sans authentification interactive et conserver une relation de confiance pendant des mois. Elle doit donc avoir, comme toute identité sensible, un propriétaire, une finalité, des droits minimaux, un cycle de vie et un comportement observable. L'objectif n'est pas de garantir qu'aucun credential ne sera jamais compromis, mais qu'un credential compromis ne devienne pas automatiquement un passe-partout vers les données de l'entreprise.
Une identité compromise ne devrait pas pouvoir extraire librement toutes les données auxquelles elle a théoriquement accès.
Voir comment Ariovis conçoit la prévention des fuites de donnéesSecteur : Assurance / CRM cloud · Période : Juillet 2025
En juillet 2025, Allianz Life a subi une fuite massive de données depuis son CRM cloud à la suite d'une opération de social engineering. Le cas s'inscrit dans une campagne où les attaquants convainquaient leurs victimes d'autoriser une Connected App Salesforce malveillante imitant Data Loader. Une fois cette confiance accordée, les appels API pouvaient ressembler à ceux d'une application autorisée.
16 juillet 2025 — un acteur malveillant obtient un accès au CRM cloud tiers utilisé par Allianz Life grâce à une technique de social engineering. Allianz Life détecte l'incident le 17 juillet, indique avoir agi pour contenir l'accès et avoir prévenu le FBI.
Périmètre : Allianz a explicitement indiqué ne disposer d'aucune preuve que le réseau Allianz Life ou ses autres systèmes internes, notamment le système d'administration des polices, aient été compromis. C'est le CRM cloud utilisé par Allianz Life qui a été compromis, pas l'ensemble du SI.
La déclaration publique initiale d'Allianz parlait d'un CRM tiers sans le nommer. Des investigations et sources spécialisées ont ensuite relié Allianz Life à la campagne de vol de données Salesforce documentée par Google.
La mécanique de cette campagne, suivie par Google Threat Intelligence sous le cluster UNC6040, est documentée : appel téléphonique, attaquant se faisant passer pour le support informatique, demande d'ouvrir la page Salesforce permettant de connecter une application, saisie par l'utilisateur d'un code fourni par l'attaquant, autorisation d'une Connected App contrôlée par l'attaquant — fréquemment une version modifiée de Salesforce Data Loader, non autorisée par Salesforce, ou une application au branding trompeur. L'application obtient alors des capacités OAuth permettant d'accéder aux données, de les rechercher et de les extraire via API.
Précision de méthode : nous relions l'incident Allianz à cette campagne parce que plusieurs sources spécialisées l'ont fait, mais Allianz n'a pas publié elle-même le déroulé technique Data Loader/OAuth. Google précise par ailleurs que ces attaques reposaient sur la manipulation des utilisateurs, non sur l'exploitation d'une vulnérabilité intrinsèque à Salesforce.
Comment une identité humaine crée une identité non-humaine hostile
Le passage se fait entre deux périmètres IAM généralement traités séparément : les utilisateurs d'un côté, les applications de l'autre.
Le problème IAM : l'utilisateur était légitime, l'application qu'il autorisait ne l'était pas. Nous avons tendance à poser une seule question à l'authentification : « est-ce vraiment cet utilisateur ? ». Ici, ce n'est pas suffisant.
L'utilisateur peut être correctement authentifié, protégé par MFA, réellement présent devant son écran — et prendre malgré tout une décision de sécurité dangereuse. L'attaquant cherche moins à usurper l'utilisateur qu'à lui faire déléguer ses capacités à une application.
Un humain légitime. Une action légitime. Une application malveillante. Et pourtant, une relation de confiance parfaitement valide du point de vue du protocole.
Conviction Ariovis
Le consentement OAuth est une décision d'autorisation. Une organisation doit donc gouverner non seulement les utilisateurs et leurs droits, mais aussi leur capacité à créer de nouvelles relations de confiance avec des applications.
Ce que cette technique ne dit pas
Deux formulations à éviter, parce que les sources ne les soutiennent pas :
La campagne UNC6040 comprenait plusieurs variantes, dont du phishing de credentials et de codes MFA. L'intérêt du scénario Connected App pour l'attaquant est de déplacer l'attaque hors du parcours d'authentification interactif classique : une fois l'application autorisée, ce sont les droits accordés à cette identité applicative et son comportement qu'il faut contrôler. Les sources ne permettent pas d'établir le type et la durée de vie du token utilisé chez Allianz : on parle donc d'un grant OAuth et d'un accès API accordé à l'application. Les scopes tels que refresh_token ou offline_access sont des permissions particulièrement sensibles à surveiller dans ce type de campagne, pas un fait démontré dans ce cas précis.
Le dépôt réglementaire auprès du Maine Attorney General indique 1 497 036 personnes affectées au total, une date de violation au 16 juillet 2025 et une découverte le 17 juillet 2025. Have I Been Pwned a de son côté intégré 1,1 million d'adresses e-mail uniques provenant des données Allianz Life : ces deux chiffres ne se contredisent pas, HIBP comptant des adresses e-mail uniques présentes dans son corpus quand le chiffre réglementaire représente le nombre total de personnes affectées déclaré par Allianz.
Les catégories de données publiquement documentées comprennent notamment des noms, adresses, dates de naissance, coordonnées et, pour certaines personnes, des Social Security Numbers.
Attribution : l'incident a été relié par plusieurs sources à la campagne Salesforce associée à UNC6040 et aux opérations d'extorsion utilisant la marque ShinyHunters, que Google suit sous un cluster distinct (UNC6240). Allianz Life n'a pas publiquement attribué elle-même l'incident à un groupe précis.
Les contrôles d'authentification faisaient exactement ce qu'on leur demandait : vérifier que l'utilisateur était bien celui qu'il prétendait être. Or l'attaquant n'a pas contesté cette réponse, il s'en est servi.
Ce qui manquait se situe après l'authentification : la capacité de décider qui, dans l'organisation, peut autoriser une nouvelle application sur des données sensibles, avec quels scopes, et la capacité de constater qu'une application inconnue vient d'être approuvée puis se met à parcourir le CRM.
Aucun contrôle isolé n'aurait nécessairement empêché l'incident. L'enjeu est de réduire la marge de manœuvre à chaque étape.
Prévenir
Limiter
Détecter
Réagir
Ce ne sont pas des manquements imputés à Allianz : les sources ne le permettent pas. Ce sont les contrôles que ce mode opératoire rend nécessaires.
Prévenir — gouverner qui peut autoriser une application
Une entreprise ne doit pas laisser automatiquement n'importe quel utilisateur connecter n'importe quelle application ayant accès aux données sensibles. Selon la plateforme : restreindre la création et l'autorisation de Connected Apps, limiter les utilisateurs pouvant approuver certaines applications, mettre en place une allowlist ou un mécanisme de confiance équivalent, imposer une validation administrative pour les applications à risque élevé, maintenir un catalogue des intégrations officiellement autorisées.
La question n'est plus seulement « quels droits possède Alice ? », mais « quels droits Alice peut-elle déléguer à un logiciel ? ».
Limiter — ne pas transmettre tous les droits de l'utilisateur
Appliquer le moindre privilège aux scopes OAuth, aux permissions API, aux objets, aux opérations et aux données accessibles. Une application de productivité n'a pas nécessairement besoin d'un accès permettant d'extraire l'intégralité d'un CRM.
Le blast radius d'un consentement OAuth dépend directement des autorisations que l'application peut obtenir.
Détecter — le comportement reste-t-il cohérent ?
Une fois l'application autorisée, son usage peut techniquement paraître valide. Surveiller : nouvelle Connected App, nom ou identifiant applicatif inhabituel, scopes sensibles, changement de politique de Connected App, première utilisation d'une application inconnue, IP ou ASN inhabituel, usage depuis VPN ou Tor.
Puis, côté données : volume brutal de requêtes API, appels Query, QueryMore et QueryAll, Bulk API, exports importants, grand nombre de records lus, téléchargement massif de fichiers ou de pièces jointes, écart important par rapport à l'usage normal de l'utilisateur ou de l'application. Google recommande explicitement de corréler les événements OAuth avec les événements d'extraction de données, et décrit les bursts d'API et les gros volumes comme des signaux utiles.
Un token valide prouve qu'une relation de confiance existe. Il ne prouve pas que l'usage actuel de cette relation est légitime.
Réagir — une procédure de révocation qui existe déjà
Pouvoir rapidement identifier la Connected App, révoquer son grant, révoquer les sessions et tokens associés, rechercher les autres utilisateurs ayant autorisé la même application, identifier les objets consultés, mesurer le volume exporté et vérifier les éventuels rebonds vers d'autres SaaS.
La procédure de révocation ne doit pas être inventée le jour de l'incident.
Après l'authentification, la sécurité de l'identité continue
L'authentification est un instant. Ensuite, il faut encore savoir quelles nouvelles permissions sont créées, quelles applications sont autorisées, quelles actions sont exécutées, quelles données sont lues, à quel volume et depuis quel contexte.
Le rapport SentinelOne Annual Threat Report 2026 formule le même déplacement : regarder le comportement après authentification et revoir les permissions des comptes de service, automatisations et autres non-human principals ; il décrit également l'exfiltration OAuth comme un problème de contexte, nécessitant de corréler identité, application, destination et volume.
Salesloft / Drift
Allianz Life
Intégration légitime
Application malveillante
Déjà approuvée
Approuvée sous manipulation
Fournisseur compromis
Utilisateur manipulé
Credential OAuth récupéré
Relation OAuth accordée
NHI légitime détournée
NHI hostile introduite
Contrôle clé : gouverner les credentials et les usages
Contrôle clé : gouverner le consentement et les applications
Dans un cas, l'attaquant vole la confiance. Dans l'autre, il convainc l'entreprise de la lui donner.
Une identité non-humaine peut être compromise. Elle peut aussi être créée par l'attaquant avec l'aide involontaire d'un utilisateur parfaitement légitime. Gouverner les NHI signifie donc contrôler tout leur cycle de vie : qui peut les créer ou les autoriser, pourquoi elles existent, quels droits elles obtiennent, combien de temps elles restent autorisées et ce qu'elles font réellement avec ces droits. Le MFA reste indispensable. Mais après l'authentification commence un deuxième problème : l'autorisation et l'usage réel de la confiance accordée.
La question IAM n'est plus seulement « qui peut accéder à Salesforce ? », mais « qui peut autoriser un logiciel à agir dans Salesforce, avec quels droits, et comment savons-nous que ce logiciel se comporte encore normalement ? ».
Voir comment Ariovis conçoit la prévention des fuites de donnéesSecteur : SaaS / support externalisé · Période : Septembre 2025
Septembre 2025 — un accès de support utilisé par un prestataire externe a permis à un attaquant d'atteindre l'environnement de support client de Discord. Le cas illustre moins une « faille Zendesk » qu'un problème de maîtrise des identités tierces, de leurs capacités et de leur comportement après authentification. Attribution non établie publiquement : le nom Scattered Lapsus$ Hunters a circulé après l'incident, mais le groupe a ensuite nié être à l'origine de la compromission du support Zendesk.
Discord a annoncé en octobre 2025 qu'un acteur non autorisé avait compromis l'accès d'un prestataire tiers utilisé pour son support client, puis a identifié ce prestataire comme étant 5CA.
La mécanique exacte de l'accès initial n'est pas totalement établie publiquement. 5CA affirme que ses propres systèmes n'ont pas été compromis et indique que son enquête préliminaire pointe vers une erreur humaine impliquant un seul employé travaillant comme agent de support pour le compte du client.
Selon les attaquants interrogés par BleepingComputer, ils auraient utilisé le compte d'un agent employé via un prestataire BPO pour accéder à l'instance de support utilisée par Discord, et affirment avoir conservé cet accès pendant environ 58 heures à partir du 20 septembre 2025 — une durée revendiquée par les attaquants, non confirmée par Discord.
Un abus d'accès légitimes
Le mécanisme précis de compromission de l'identité initiale n'est pas établi publiquement : ni un phishing, ni un vol de session, ni une compromission technique particulière ne sont confirmés.
Ce n'est pas seulement une fuite SaaS. C'est un incident d'identité : l'attaquant n'a pas nécessairement besoin de casser une application lorsqu'il peut emprunter le chemin d'une identité déjà autorisée.
Un agent de support externe peut légitimement avoir accès à des données sensibles. Le problème devient alors plus subtil : qui est cette personne, pourquoi dispose-t-elle encore de cet accès, à quelles données peut-elle accéder, quelles actions peut-elle réaliser, dans quel volume, depuis quel contexte — et son comportement reste-t-il cohérent avec celui d'un agent de support normal ?
L'authentification n'est donc que le début du contrôle.
L'authentification n'est que le début du contrôle
Une identité parfaitement authentifiée peut effectuer une action parfaitement illégitime.
Le SaaS visible… et les outils cachés derrière
Selon les attaquants, l'accès au support leur permettait également d'utiliser « Zenbar », un outil interne intégré au fonctionnement du support Discord. BleepingComputer rapporte que cet environnement permettait différentes actions de support et que certaines intégrations avec les systèmes internes auraient permis d'effectuer un grand nombre de requêtes API. Le point important n'est pas uniquement Zendesk : une application SaaS peut devenir la porte d'entrée vers tout un ensemble —
C'est cette chaîne de confiance qu'il faut gouverner. Zenbar et les millions de requêtes API sont des éléments issus du récit des attaquants rapporté par BleepingComputer ; ils ne sont pas présentés comme confirmés, et l'exfiltration de 1,6 To ne l'est pas non plus.
C'est justement l'une des particularités de cet incident. Discord a identifié 5CA comme le prestataire tiers impliqué. 5CA affirme pour sa part que ses propres systèmes n'ont pas été compromis et indique que son enquête préliminaire pointe vers une erreur humaine impliquant un seul employé, ayant permis l'accès au système de support tiers du client. Zendesk a également indiqué que l'incident ne résultait pas d'une vulnérabilité ou d'une compromission de sa plateforme.
Nous ne cherchons pas à départager artificiellement ces versions. Pour le RSSI, cette discussion sur la frontière exacte du système compromis ne change finalement pas le problème : une chaîne de confiance reliant donneur d'ordre, prestataire, identité humaine, SaaS et applications intégrées a permis d'atteindre des données sensibles.
Les contrôles classiques encadraient la connexion, pas l'usage. Une fois l'identité de support authentifiée, rien ne semble avoir borné le nombre de tickets consultés, le volume de pièces jointes téléchargées ou la quantité de requêtes effectuées via les outils et intégrations associés.
Un outil de support généraliste devenu entrepôt permanent de données très sensibles — dont des photos de pièces d'identité — augmentait mécaniquement la valeur du butin accessible à une seule identité compromise.
Aucun contrôle isolé n'aurait nécessairement empêché l'incident. L'enjeu est de réduire la marge de manœuvre à chaque étape.
Prévenir
Limiter
Détecter
Aucun contrôle isolé n'aurait nécessairement empêché l'incident. L'enjeu est de réduire la marge de manœuvre à chaque étape.
Gouvernance des identités tierces
Les identités de prestataires, BPO, partenaires et sous-traitants doivent disposer d'un sponsor, d'une durée de validité, d'un périmètre explicite, de revues régulières et d'une suppression automatique lorsque la mission s'arrête. C'est le cœur de la gouvernance des identités (IGA) appliquée aux tiers.
MFA résistant au phishing… mais pas seulement
Les comptes de support ayant accès à des données sensibles doivent bénéficier d'une authentification forte, idéalement résistante au phishing. Mais le mécanisme initial exact de cet incident n'étant pas confirmé, on ne peut pas affirmer que le MFA l'aurait nécessairement empêché : le contrôle doit continuer après l'authentification.
Contrôler les capacités, pas seulement le login
Un agent chargé de traiter quelques tickets ne devrait pas pouvoir, sans contrôle supplémentaire, parcourir des milliers de dossiers, télécharger massivement des pièces jointes, effectuer des volumes anormaux de recherches, accéder à des données sans rapport avec les tickets qu'il traite ou déclencher des opérations sensibles sans justification.
C'est la logique du moindre privilège et, lorsque c'est pertinent, de l'autorisation fine et contextuelle : ABAC / PBAC, Policy Decision Point, Policy Enforcement Point, step-up authentication ou approbation supplémentaire pour les opérations les plus sensibles.
Détecter l'usage anormal d'une identité légitime
Le comportement doit être observé après authentification : volume de tickets consultés, nombre de pièces jointes téléchargées, fréquence des recherches, appels API, horaires, contexte du terminal, destination des données, écart avec le comportement habituel du rôle.
Une identité autorisée peut devenir dangereuse lorsque son comportement ne correspond plus à ce pour quoi elle a été autorisée.
Réduire la valeur du butin
La sécurité IAM ne dispense pas de minimiser les données. Pour les documents très sensibles comme les pièces d'identité : limiter la conservation, définir un TTL lorsque le processus le permet, séparer les droits de consultation, tracer les accès, limiter les téléchargements et éviter qu'un outil de support généraliste devienne un entrepôt permanent de données sensibles. C'est une réduction d'impact, pas une mesure qui aurait empêché l'accès initial.
Ce que Discord confirme
Ce que revendiquent les attaquants
Incident impliquant un prestataire tiers de support client.
Environ 1,6 To de données, dont environ 1,5 To de pièces jointes et plus de 100 Go de transcriptions de tickets.
Environ 70 000 utilisateurs dans le monde susceptibles d'avoir eu une photo de pièce d'identité gouvernementale exposée.
Environ 8,4 millions de tickets et 5,5 millions d'utilisateurs uniques concernés.
Données potentiellement concernées : nom, nom d'utilisateur Discord, adresse e-mail et coordonnées communiquées au support, adresse IP, échanges avec les équipes Customer Support / Trust & Safety, informations de facturation limitées (moyen de paiement, quatre derniers chiffres de la carte), certaines données internes de l'entreprise.
Un accès conservé environ 58 heures à partir du 20 septembre 2025, avec utilisation de Zendesk, Zenbar et d'intégrations permettant de nombreuses requêtes API.
Les mots de passe, données d'authentification, numéros complets de carte bancaire et messages Discord hors conversations avec le support n'étaient pas concernés.
—
Les volumes de la colonne de droite n'ont pas été confirmés par Discord ; BleepingComputer précise ne pas avoir pu vérifier indépendamment les revendications des attaquants.
« L'identité est le nouveau périmètre » ne signifie pas seulement protéger un login : c'est savoir ce qu'une identité — interne, prestataire ou machine — est autorisée à faire une fois connectée, puis détecter lorsqu'elle sort de ce cadre. Dans le cas Discord, la question n'est pas seulement « comment empêcher le vol d'un compte de support ? », mais aussi « pourquoi une identité de support compromise peut-elle consulter ou extraire autant de données avant que son comportement devienne manifestement anormal ? ». C'est cette deuxième question qui fait le lien entre gouvernance des identités, autorisation fine et détection comportementale.
Cartographier les identités tierces, borner leurs capacités et surveiller leur comportement réel : c'est exactement le cœur de notre approche de prévention des fuites de données.
Voir comment Ariovis conçoit la prévention des fuites de donnéesSecteur : Automobile / industrie · Période : Août – octobre 2025
À partir du 31 août 2025, une cyberattaque contre Jaguar Land Rover a profondément perturbé les systèmes informatiques du constructeur. JLR a choisi d'arrêter une partie importante de son système d'information afin de contenir l'incident, avec une conséquence immédiate : la production automobile et plusieurs opérations commerciales ont été paralysées.
L'incident est intéressant pour l'IAM non pas parce que son point d'entrée serait aujourd'hui démontré, mais parce qu'il montre jusqu'où peut aller la compromission d'un environnement numérique de confiance. Quand les systèmes qui pilotent les utilisateurs, les opérations, la logistique et la production deviennent indisponibles ou ne peuvent plus être considérés comme sûrs, le risque cyber devient directement un risque industriel.
Le 2 septembre 2025, Jaguar Land Rover a confirmé avoir subi un incident cyber et avoir volontairement arrêté ses systèmes pour en limiter l'impact. La production et les activités retail ont été sévèrement perturbées.
Le 10 septembre, JLR a indiqué que certaines données avaient également été affectées et que les autorités compétentes avaient été informées.
La reprise s'est ensuite faite progressivement. Le 25 septembre, certaines briques du système d'information étaient remises en service : capacité de traitement des factures, logistique des pièces détachées et système financier nécessaire aux ventes de véhicules. La reprise de la production elle-même s'est poursuivie de manière contrôlée au cours des semaines suivantes.
Une entité utilisant le nom « Scattered Lapsus$ Hunters » a revendiqué l'opération et publié des captures présentées comme provenant de systèmes internes de JLR. Cette revendication n'équivaut pas à une attribution confirmée : un mois après les faits, le mode opératoire initial et l'attribution restaient non confirmés publiquement.
Chaîne d'impact
Nous parlons ici de chaîne d'impact et non de chaîne d'attaque : le vecteur d'accès initial exact n'est pas publiquement établi.
L'accès initial n'étant pas documenté publiquement, il serait incorrect de transformer l'incident JLR en démonstration certaine d'une faiblesse IAM.
En revanche, le cas illustre une question fondamentale : après l'authentification, sommes-nous encore capables de déterminer si une identité, une session ou une action reste légitime ?
Les groupes associés à l'écosystème Scattered Spider / ShinyHunters sont notamment connus pour utiliser l'ingénierie sociale et l'usurpation d'identité. Le scénario est donc crédible comme risque à traiter, mais il ne doit pas être présenté comme la cause démontrée de l'incident JLR.
Pour Ariovis, le véritable enseignement est plus large : une organisation industrielle ne peut pas protéger ses processus critiques uniquement en contrôlant le login. Elle doit aussi maîtriser les privilèges, les procédures de récupération de compte, les changements de facteurs MFA, les sessions et les comportements qui suivent l'authentification.
L'authentification n'est que le début du contrôle
Un MFA peut empêcher le vol direct d'un mot de passe. Il ne répond pas à lui seul à toutes les situations dans lesquelles une identité légitime est détournée. La sécurité doit donc continuer après le login : changement de privilèges, récupération de compte, enrôlement d'un nouvel authentificateur, accès à une ressource critique, volumes inhabituels ou action incohérente avec le rôle attendu doivent pouvoir devenir des signaux de risque. C'est cette continuité entre identité, privilège et usage réel qui réduit le blast radius lorsqu'un compte finit malgré tout par être compromis.
Le Help Desk est une interface d'administration
Un support capable de réinitialiser un mot de passe, modifier un MFA ou restaurer l'accès à un compte exerce indirectement une fonction privilégiée. Une procédure de récupération de compte trop faible peut donc neutraliser les protections mises en place au moment de l'authentification. Pour les comptes sensibles, une organisation devrait notamment prévoir :
Ces éléments sont des recommandations tirées du risque, pas un diagnostic du système d'information de JLR : rien n'indique publiquement que ces contrôles étaient absents.
Production : plusieurs semaines de perturbation majeure et arrêt de sites de production.
Supply chain : plus de 5 000 organisations britanniques estimées comme affectées par le Cyber Monitoring Centre.
Impact économique : environ 1,9 milliard £ selon l'estimation de l'impact économique britannique publiée par le Cyber Monitoring Centre. Il s'agit d'une estimation d'impact pour l'économie du Royaume-Uni, et non d'une perte publiée par JLR.
Données : JLR a confirmé que certaines données avaient été affectées, sans publier à ce stade un périmètre exhaustif permettant d'affirmer une exfiltration complète de ses données internes.
Quand l'IT devient une dépendance physique de la production.
Le cas JLR montre que, dans une industrie fortement numérisée, il n'est pas nécessaire de compromettre directement un automate industriel pour arrêter une usine.
Si la logistique, les flux financiers, l'approvisionnement, les systèmes de vente ou les applications nécessaires à la fabrication deviennent indisponibles ou non fiables, l'organisation peut être contrainte d'arrêter physiquement sa production.
Le blast radius d'une compromission IT peut donc devenir industriel. Cette lecture ne suppose aucune défaillance identifiée chez JLR : elle décrit une dépendance structurelle que partagent la plupart des industriels.
Aucun contrôle isolé n'aurait nécessairement empêché l'incident. L'enjeu est de réduire la marge de manœuvre à chaque étape.
Prévenir
Limiter
Détecter
Pour approfondir
Ces mesures sont présentées comme des réducteurs de risque applicables à toute organisation industrielle. Elles ne signifient pas qu'elles étaient absentes chez JLR.
MFA résistant au phishing
FIDO2 / WebAuthn pour les populations et administrateurs sensibles, plutôt que des facteurs interceptables ou relayables.
Récupération de compte renforcée
Processus distinct pour les comptes privilégiés, avec vérification supplémentaire et éventuellement validation par un tiers.
Protection de l'enrôlement MFA
Considérer l'ajout ou le remplacement d'un authentificateur comme une opération sensible, journalisée et notifiée.
PAM et privilèges temporaires
Réduire les droits administratifs permanents et limiter la capacité d'un compte compromis à progresser dans le SI.
Détection post-authentification
Ne pas considérer une session comme légitime uniquement parce que l'utilisateur a réussi son authentification.
Segmentation des systèmes critiques
Limiter la possibilité qu'une compromission du SI bureautique ou d'administration puisse atteindre les processus nécessaires à la production.
Un attaquant n'a pas besoin de casser votre MFA s'il peut détourner le processus qui permet de le réinitialiser. La sécurité des identités ne s'arrête donc pas au login : c'est la continuité entre identité, privilège et usage réel qui détermine ce qu'une compromission pourra atteindre — et, dans l'industrie, jusqu'où le blast radius d'un incident IT peut aller dans le monde physique.
Maîtriser les privilèges, les procédures de récupération de compte et les comportements qui suivent l'authentification : c'est le cœur de notre approche de prévention des fuites de données.
Voir comment Ariovis conçoit la prévention des fuites de donnéesSecteur : Luxe / Retail · Période : Accès initial revendiqué en avril 2025 · incident identifié par Kering en juin 2025 · rendu public en septembre 2025
Une campagne d'ingénierie sociale où une autorisation applicative légitime peut devenir un canal d'exfiltration. L'organisation concernée est Kering, les maisons rapportées étant notamment Gucci, Balenciaga et Alexander McQueen.
En juin 2025, Kering a identifié qu'un tiers non autorisé avait obtenu un accès temporaire à ses systèmes et consulté des données clients appartenant à certaines de ses maisons. L'incident a été rendu public en septembre. Les données rapportées comprennent notamment des noms, adresses e-mail, numéros de téléphone, adresses postales ainsi que le montant total dépensé par certains clients. Kering a précisé qu'aucune donnée financière telle qu'un numéro de carte bancaire ou de compte bancaire n'avait été compromise. L'accès initial d'avril 2025 relève, lui, d'une revendication des attaquants auprès de la presse, et non d'une chronologie publiée par Kering.
L'incident a été rapproché de la vaste campagne menée en 2025 contre des environnements Salesforce. Dans cette campagne, suivie par Google Threat Intelligence sous le nom UNC6040, les attaquants appelaient des employés en se faisant passer pour le support informatique. Leur objectif n'était pas nécessairement de voler immédiatement un mot de passe : ils cherchaient notamment à convaincre la victime d'autoriser une Connected App contrôlée par l'attaquant, parfois présentée comme une variante de Salesforce Data Loader.
Cette autorisation crée ensuite un accès OAuth exploitable par l'application pour interroger Salesforce et extraire des données via les API. Le trafic peut ainsi provenir d'un mécanisme techniquement autorisé. Le problème de sécurité ne se situe plus seulement au moment de l'authentification de l'utilisateur, mais dans la délégation de droits accordée à une application et dans l'usage qui en est fait après cette autorisation.
Kering n'a toutefois pas publié le détail technique permettant d'affirmer que cette chaîne précise a été utilisée dans son environnement. Elle doit donc être présentée comme la mécanique de campagne à laquelle l'incident a été publiquement associé, et non comme une reconstitution officielle de l'intrusion Kering. L'attribution à UNC6040, et aux opérations d'extorsion associées utilisant la marque ShinyHunters, est rapportée par les analyses de menace et la presse spécialisée : Google Threat Intelligence suit les intrusions Salesforce sous UNC6040 et les phases d'extorsion sous UNC6240, sans que ces désignations recouvrent une entité unique formellement établie avec ShinyHunters ou Scattered Spider.
De l'appel téléphonique à l'extraction CRM
Chaîne technique documentée pour la campagne UNC6040 à laquelle l'incident a été associé ; Kering n'a pas confirmé publiquement chaque étape de cette séquence.
Réduire ce cas à « un mot de passe volé » ferait manquer l'essentiel. Le point intéressant est qu'une identité humaine parfaitement légitime peut être manipulée afin d'accorder des droits à une application. OAuth n'intervient pas ici comme un mécanisme d'authentification mais comme un mécanisme de délégation d'autorisation : une application reçoit le droit d'accéder à des ressources au nom d'un utilisateur ou dans un contexte autorisé.
Une Connected App, un service principal, un token OAuth ou une intégration SaaS doivent dès lors être traités comme des objets de gouvernance à part entière : qui en est propriétaire, qui peut les autoriser, quels scopes leur sont accordés, quelles données ils peuvent consulter, depuis quels environnements ils sont normalement utilisés, combien de temps les tokens restent valides, comment ils sont révoqués et quelle activité est considérée comme normale pour eux.
Ce mode opératoire déplace aussi le modèle de confiance vers la fonction support. Le support informatique fait désormais partie du modèle de confiance identitaire : un attaquant n'a pas besoin de compromettre le support s'il réussit à convaincre l'utilisateur qu'il est le support. Les campagnes UNC6040 exploitaient précisément la confiance accordée à cette fonction, en se faisant passer pour des techniciens ou agents IT auprès des utilisateurs.
Conviction Ariovis
L'identité ne s'arrête plus à l'utilisateur qui se connecte. Dès qu'un humain peut déléguer des droits à une application, cette application entre elle aussi dans le périmètre de confiance. Gouverner l'identité moderne, c'est contrôler à la fois l'utilisateur, la délégation qu'il accorde et le comportement de l'identité applicative qui en résulte.
Singularité du cas : la donnée de dépenses
Le caractère particulièrement sensible de la fuite tient à la présence du montant total dépensé par certains clients. Une donnée CRM apparemment commerciale devient ainsi un élément de segmentation pour un attaquant : elle peut permettre d'identifier les clients les plus intéressants pour des campagnes ultérieures de phishing, d'usurpation ou d'extorsion ciblée. Ce risque est une conséquence possible de la donnée exposée, et non une fraude secondaire dont la réalisation serait établie.
Les attaquants ont affirmé détenir des données associées à environ 7,4 millions d'adresses e-mail uniques. Ce chiffre n'a pas été confirmé par Kering et ne doit donc pas être présenté comme le nombre officiel de victimes.
Les informations rapportées comprennent des coordonnées personnelles et des données relatives aux dépenses de certains clients. Kering a indiqué qu'aucun numéro de carte bancaire, numéro de compte bancaire ou document d'identité officiel n'avait été compromis.
Cet incident montre une évolution importante du risque identité. Un utilisateur peut être correctement authentifié et néanmoins déclencher une chaîne dangereuse en accordant des droits à une application. Une fois l'autorisation OAuth obtenue, l'activité peut ressembler à celle d'une intégration SaaS légitime.
La défense doit donc dépasser le contrôle du login. Il faut gouverner les applications connectées, les tokens et les identités non humaines, puis surveiller ce qu'ils font après leur autorisation. La bonne question n'est plus seulement « qui s'est connecté ? », mais également « quelle application a reçu quels droits, de qui, et que fait-elle maintenant avec ces droits ? »
Aucun contrôle isolé n'aurait nécessairement empêché l'incident. L'enjeu est de réduire la marge de manœuvre à chaque étape.
Prévenir
Limiter
Détecter
Réagir
Aucune mesure isolée ne suffit ici : une clé FIDO2 et une authentification résistante au phishing réduisent le risque de vol de credentials, mais ne bloquent pas nécessairement un utilisateur qui autorise volontairement une application malveillante. C'est une défense en profondeur qui réduit la marge de manœuvre.
Gouverner les Connected Apps et les droits de délégation
Une gouvernance stricte des Connected Apps, en logique deny-by-default, impose une approbation explicite des applications autorisées et un catalogue tenu à jour. Elle s'accompagne d'une limitation du droit « API Enabled » et des droits permettant de gérer ou d'autoriser des applications connectées, afin que la capacité de créer une nouvelle relation de confiance ne soit pas distribuée à l'ensemble des utilisateurs.
Appliquer le moindre privilège aux scopes et aux identités techniques
Le moindre privilège doit s'appliquer aux scopes OAuth, aux comptes techniques, aux intégrations et aux identités non humaines. Une application n'a pas besoin d'un périmètre lui permettant d'interroger et d'exporter l'intégralité d'un CRM pour rendre le service attendu, et c'est ce périmètre qui détermine le volume de données réellement atteignable en cas d'abus.
Sécuriser les demandes attribuées au support informatique
Un processus de vérification robuste doit encadrer toute sollicitation d'un prétendu support IT demandant une action ayant un impact sur l'identité d'un utilisateur, ses facteurs d'authentification ou ses autorisations. Cette exigence se complète d'une authentification résistante au phishing et d'un contrôle renforcé des comptes administratifs et des opérations sensibles.
Détecter après l'autorisation, révoquer vite
La détection comportementale porte sur ce qui suit l'autorisation : apparition d'une nouvelle Connected App, accès depuis une infrastructure inhabituelle, forte augmentation des requêtes API, export massif ou accès à des volumes de données incompatibles avec le comportement habituel. Elle n'a de valeur opérationnelle que si l'organisation peut révoquer rapidement les tokens OAuth et les sessions associés à une application compromise.
Gouverner les applications connectées revient à gouverner des identités : leur propriétaire, leur autorisation, leurs scopes, leur durée de vie et leur comportement observé après le consentement.
Les données commerciales d'un CRM valent parfois autant qu'un identifiant : leur exposition se prévient avec les mêmes contrôles d'identité, d'habilitation et de surveillance.
Voir comment Ariovis conçoit la prévention des fuites de donnéesSecteur : Services financiers / Fintech · Période : Juin – août 2025 · incident détecté le 1er septembre 2025
La fuite de données Prosper Marketplace de 2025 ne documente ni le vecteur initial ni l'identité utilisée. Elle permet en revanche d'examiner ce qu'une identité ou un principal technique peut réellement faire une fois qu'un accès aux bases de données est obtenu.
Entre juin et août 2025, selon la notification officielle publiée ultérieurement par Prosper, un tiers non autorisé a obtenu des données personnelles au moyen de requêtes sur les bases de données de l'entreprise contenant des informations sur les clients et candidats.
Le 1er septembre 2025, Prosper détecte une activité non autorisée, déclenche son dispositif de réponse à incident, engage des spécialistes en cybersécurité et informe les autorités. L'incident est rendu public le 17 septembre dans un dépôt auprès de la SEC.
Prosper précise n'avoir trouvé aucune preuve d'accès non autorisé aux comptes clients ou aux fonds et indique que ses opérations destinées aux clients n'ont pas été interrompues.
L'analyse des données affectées est achevée le 26 novembre 2025, avant l'envoi des notifications individuelles en décembre.
Précision de méthode : les publications publiques ne décrivent pas le mécanisme ayant permis au tiers d'obtenir son accès initial, ni l'identité ou le principal technique utilisé. Il serait donc incorrect de transformer cet incident en scénario de phishing, de credential stuffing, de compromission d'un compte administrateur ou d'intervention d'un DBA sans source. Les documents parlent de requêtes sur des bases, sans établir qu'il s'agissait nécessairement de requêtes SQL.
Une chaîne d'attaque limitée à ce que nous savons
La chaîne commence volontairement au premier fait établi. Aucun compte administrateur compromis ni aucun mécanisme d'accès initial n'est ajouté par hypothèse.
Le problème IAM : que peut faire une identité une fois l'accès obtenu ? Nous ne savons pas quelle identité ou quel principal a permis l'accès initial. En revanche, l'incident montre qu'une fois présent dans l'environnement, le tiers disposait d'un chemin permettant d'interroger directement des bases contenant des informations particulièrement sensibles.
L'angle IAM ne consiste donc pas à affirmer qu'un PAM aurait « empêché Prosper ». Il consiste à poser les questions que toute organisation devrait pouvoir résoudre : quelles identités humaines ou techniques peuvent interroger ces bases, avec quel périmètre, pendant combien de temps, à partir de quels contextes et avec quelle capacité réelle d'extraction ?
L'authentification et l'autorisation ne répondent pas à la même question. Une identité techniquement acceptée ne devrait pas automatiquement pouvoir exploiter l'intégralité d'un privilège théorique sans restriction de périmètre, de durée ou de contexte, ni sans surveillance de son usage.
Conviction Ariovis
« L'identité est le nouveau périmètre » ne signifie pas seulement protéger le login. Il faut aussi maîtriser ce qu'une identité privilégiée peut réellement faire une fois connectée : quelles données elle peut atteindre, quelles opérations elle peut exécuter, pendant combien de temps et dans quelles proportions. Le chiffrement, la segmentation et les contrôles périmétriques restent nécessaires, mais ils sont insuffisants à eux seuls lorsqu'un accès autorisé permet déjà d'atteindre la donnée. La maîtrise du privilège et de son usage devient alors une couche de défense supplémentaire.
Données exposées
La notification de Prosper mentionne, selon les personnes concernées, les catégories suivantes :
Toutes ces catégories ne concernent pas nécessairement chaque personne notifiée.
Prosper a officiellement confirmé l'exposition de données personnelles et financières. Sa notification de décembre détaille notamment des identifiants officiels, des coordonnées bancaires, des informations fiscales, des données de paiement et des éléments issus de demandes de crédit.
Have I Been Pwned référence de son côté 17,6 millions d'adresses e-mail uniques dans le corpus associé à Prosper. La fiche documente également des noms, adresses, dates de naissance, données d'emploi, niveaux de revenus, statuts de crédit, adresses IP et User-Agents. Ce chiffre décrit le volume d'adresses uniques du corpus HIBP ; il ne constitue pas un nombre de victimes officiellement confirmé par Prosper.
Les deux sources ne mesurent donc pas nécessairement exactement la même chose : la notification de Prosper qualifie les personnes et catégories de données affectées, tandis que HIBP dénombre les adresses e-mail uniques présentes dans le corpus reçu.
Ces contrôles ne sont pas présentés comme des dispositifs qui étaient absents chez Prosper. Ce sont les enseignements que ce mode opératoire permet de tirer pour toute organisation exposant des données sensibles à des identités privilégiées.
La question utile n'est pas de déduire le contrôle manquant à partir d'informations qui ne sont pas publiques, mais de vérifier si un accès aux données peut être borné, observé et révoqué avant que son usage ne produise un blast radius disproportionné.
Aucun contrôle isolé n'aurait nécessairement empêché l'incident. L'enjeu est de réduire la marge de manœuvre à chaque étape.
Prévenir
Limiter
Détecter
Réagir
Pour approfondir
Le cas Prosper déplace la question de « comment l'attaquant est-il entré ? » vers « qu'a-t-il pu faire une fois entré ? ».
Réduire le pouvoir permanent
Lorsqu'un accès à une donnée critique repose sur un privilège très large et permanent, la compromission d'une seule identité potentiellement capable de l'exercer peut créer un blast radius considérable. La priorité est de réduire ce pouvoir disponible en continu et de le rendre temporaire lorsque c'est réaliste.
Superviser l'usage, pas seulement le secret
Une stratégie PAM moderne ne cherche pas uniquement à protéger des mots de passe d'administration. Elle rend les opérations sensibles traçables et permet de détecter lorsqu'un accès techniquement légitime n'est plus utilisé d'une manière cohérente avec sa finalité.
La protection de l'identité ne s'arrête pas au login : elle doit borner, tracer et surveiller ce qu'un privilège permet réellement de faire sur la donnée.
Prévenir une fuite de données suppose de connaître les identités qui peuvent atteindre la donnée, mais aussi le volume qu'elles peuvent réellement extraire.
Voir comment Ariovis conçoit la prévention des fuites de donnéesSecteur : Microsoft Entra ID · IAM / Sécurité des identités / Cloud · Période : Septembre 2025
Microsoft Entra ID — CVE-2025-55241. Un cas technique sur la chaîne de confiance entre services, Azure AD Graph et Microsoft Graph, et sur ce qu'il enseigne à la gouvernance des identités privilégiées.
En septembre 2025, la publication de CVE-2025-55241 a révélé une vulnérabilité particulièrement instructive pour les équipes IAM et de sécurité Cloud. Découverte par le chercheur Dirk-jan Mollema, elle combinait un mécanisme interne de délégation appelé Actor Token et une erreur de validation dans l'ancienne API Azure AD Graph, accessible via graph.windows.net. Cette combinaison permettait théoriquement d'usurper une identité appartenant à un autre tenant Microsoft Entra ID, jusqu'à un compte disposant du rôle Global Administrator.
La vulnérabilité avait été signalée à Microsoft le 14 juillet 2025. Microsoft a déployé une correction mondiale le 17 juillet. CVE-2025-55241 a ensuite été publiée le 4 septembre, avant que Dirk-jan Mollema ne détaille publiquement ses recherches le 17 septembre.
Le cas est important parce qu'il ne repose ni sur le vol du mot de passe d'un administrateur, ni sur un phishing MFA, ni sur une mauvaise configuration particulière du tenant victime. La faille se trouvait dans la chaîne de confiance elle-même : un mécanisme légitime de communication entre services pouvait être présenté à un composant historique qui ne vérifiait pas correctement l'origine du tenant.
La chaîne de confiance en jeu
Schéma explicatif de la chaîne de confiance, pas une procédure d'exploitation.
Des Actor Tokens conçus pour les communications entre services. Les Actor Tokens sont des jetons utilisés par certains services Microsoft pour communiquer entre eux et agir au nom d'un utilisateur. Dirk-jan Mollema les a rencontrés en étudiant des mécanismes liés à Exchange et aux communications service-to-service. Leur fonctionnement permettait à un service de disposer d'un Actor Token puis de construire un jeton d'impersonation représentant l'utilisateur au nom duquel il devait agir.
Une validation cross-tenant défaillante dans Azure AD Graph. Le problème critique se trouvait ensuite dans Azure AD Graph. Lors des recherches, l'API a accepté un jeton dont le tenant d'origine ne correspondait pas au tenant interrogé. Une fois un identifiant utilisateur valable obtenu dans le tenant cible, le chercheur a démontré dans ses environnements de test qu'il était possible d'usurper cet utilisateur, d'identifier un Global Administrator puis d'agir avec ses droits.
La portée potentielle concernait les tenants Entra ID du cloud public. Ce résultat ne s'étend pas aux environnements de cloud nationaux, que le chercheur n'avait pas testés.
Pourquoi MFA et Conditional Access ne suffisaient pas
Il serait incorrect de présenter cette vulnérabilité comme un « cassage du MFA » : dans ce scénario, le MFA n'était simplement pas placé sur le chemin de décision. Les Actor Tokens servaient à des communications service-to-service et n'étaient pas soumis aux stratégies de Conditional Access comme l'aurait été une authentification utilisateur interactive. Cet incident montre ainsi qu'une stratégie IAM ne peut plus protéger uniquement l'authentification interactive : elle doit également contrôler les sessions, les applications, les identités non humaines, les délégations et les actions privilégiées.
Azure AD Graph permettait d'interroger les utilisateurs, groupes, rôles, applications, Service Principals, certaines configurations du tenant et les politiques d'accès conditionnel. En usurpant un Global Administrator, un attaquant aurait également pu modifier ces objets, créer de nouvelles identités, ajouter des privilèges ou préparer des accès vers d'autres ressources associées au tenant.
La difficulté défensive venait notamment de la visibilité disponible. L'émission et l'utilisation des Actor Tokens ne produisaient pas les traces classiques d'une authentification utilisateur, et les opérations de lecture réalisées via Azure AD Graph disposaient de moins de télémétrie que Microsoft Graph.
Les opérations d'écriture pouvaient en revanche produire des événements d'audit. Elles risquaient cependant d'apparaître comme ayant été réalisées par le Global Administrator usurpé et par un service Microsoft. La question défensive devient donc plus complexe que « avons-nous un log ? » : elle devient « cette action attribuée à une identité légitime correspond-elle réellement à une utilisation légitime de cette identité ? ».
1. Sortir réellement d'Azure AD Graph
Microsoft a corrigé CVE-2025-55241 côté service : migrer vers Microsoft Graph n'est donc pas le correctif de cette CVE. En revanche, Azure AD Graph est une technologie legacy en retrait, et une organisation qui possède encore des applications ou des Service Principals utilisant graph.windows.net doit les identifier et préparer leur migration vers Microsoft Graph.
La modernisation doit examiner toute la chaîne et pas seulement remplacer une URL : bibliothèques d'authentification, permissions, Service Principals, dépendances applicatives, télémétrie et exploitation.
2. Réduire les privilèges permanents
Microsoft Entra Privileged Identity Management permet de rendre un utilisateur éligible à un rôle privilégié et de n'activer ce rôle que lorsque la tâche le nécessite, avec des mécanismes supplémentaires comme une durée limitée, une justification, une authentification renforcée ou une approbation.
PIM n'aurait pas supprimé CVE-2025-55241. Il réduit en revanche la quantité de privilèges disponibles en permanence et améliore la gouvernance des identités administratives, conformément à une logique que nous appliquons ailleurs : réduire le privilège à la source avant d'empiler des mécanismes techniques supplémentaires.
3. Surveiller l'usage des identités après authentification
Un SIEM externe ne peut pas inventer une télémétrie que la plateforme source ne génère pas. En revanche, la centralisation des événements devient particulièrement importante dès qu'une identité réalise des changements de rôles, ajoute des credentials, modifie des applications, change des politiques ou effectue des opérations administratives inhabituelles.
L'objectif n'est donc pas seulement de surveiller les connexions. Il faut corréler les événements d'identité, les modifications de privilèges, les opérations réalisées par les Service Principals et les comportements post-authentification afin d'identifier une identité techniquement valide dont l'usage est devenu incohérent.
Notre lecture IAM. CVE-2025-55241 rappelle qu'un dispositif IAM ne peut pas être évalué uniquement à partir de la robustesse de son écran de connexion. Une organisation peut disposer de MFA, d'accès conditionnel et de politiques d'authentification exigeantes tout en restant exposée lorsqu'une API historique, une relation de délégation ou une identité de service permet d'emprunter un autre chemin.
La gouvernance des identités doit couvrir toute la chaîne de confiance : utilisateurs, administrateurs, applications, Service Principals, tokens, délégations, API et privilèges effectivement exercés. La bonne question n'est donc plus seulement « qui vient de s'authentifier ? », mais également « au nom de qui cette action est-elle exécutée, pourquoi cette identité possède-t-elle ce privilège et cette action est-elle cohérente avec ce que nous attendons d'elle ? ».
Votre sécurité Entra ID va au-delà du MFA ?
Une architecture d'identité robuste doit aussi maîtriser les privilèges, les applications, les Service Principals, les délégations et les chemins d'administration. Nous pouvons auditer l'existant, identifier les zones de confiance excessives et construire une trajectoire de sécurisation adaptée au SI.
Évaluer notre architecture IAMAriovis vous aide à cartographier les identités humaines et non-humaines, leurs droits, leurs usages réels et les contrôles permettant de réduire le risque d'exfiltration.
