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.
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.
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.
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.
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.
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éesAriovis 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.
