En résumé
À partir du 31 juillet 2026, un acteur malveillant connu sous le nom de « TheHatman » a commencé à vendre des bases de données d'employés prétendument exfiltrées depuis les tenants Microsoft Azure et Entra ID de plusieurs entreprises du Fortune 500, dont McDonald's, Vodafone, Tata Consultancy Services et HCL Technologies. Le volume total revendiqué est de 3,64 millions de fiches. Hudson Rock, qui a examiné des échantillons, a qualifié les données de « très probablement authentiques » et identifié des identifiants Azure compromis par des infostealers liés à plusieurs des organisations nommées, circulant sur les marchés souterrains. L'attaque ne semble pas exploiter une vulnérabilité dans Azure lui-même — elle a utilisé des identifiants valides volés pour se connecter en tant qu'utilisateurs légitimes et exporter les données du répertoire.
L'incident a été signalé pour la première fois par The Register le 17 août 2026 et repris par BleepingComputer et Help Net Security le lendemain. TCS a publiquement déclaré n'avoir trouvé aucune preuve crédible d'une violation de ses propres systèmes ; les autres entreprises nommées n'avaient pas publié de déclaration officielle au moment de la publication.
Ce qui s'est passé : de l'infostealer au répertoire Azure
La chaîne d'attaque comporte deux maillons. Premièrement, des logiciels malveillants de type infostealer — une catégorie de logiciels de collecte d'identifiants qui extraient silencieusement les mots de passe enregistrés, les cookies de navigation et les jetons de session depuis les terminaux infectés — ont compromis des appareils appartenant à des employés des entreprises ciblées. Une fois actifs sur un terminal, les infostealers collectent tous les identifiants cloud qu'ils trouvent : jetons Microsoft 365, accès au portail d'administration Azure, comptes administrateurs Entra ID. Ces identifiants volés sont ensuite vendus ou échangés sur les marchés souterrains.
Deuxièmement, l'attaquant a utilisé ces identifiants collectés pour s'authentifier directement auprès des tenants Microsoft Azure et Entra ID des victimes en tant qu'utilisateurs légitimes. Une fois à l'intérieur du tenant, l'export du répertoire d'employés — qu'Azure expose via son API Graph et son portail d'administration aux utilisateurs authentifiés disposant de permissions suffisantes — est une opération peu complexe qui ne laisse des traces que si les bons journaux d'audit sont surveillés. Hudson Rock indique avoir « identifié des identifiants Azure compromis liés à une activité d'infostealer » dans plusieurs entreprises nommées, corroborant le vecteur revendiqué sans pouvoir confirmer quel identifiant spécifique a été utilisé pour chaque export individuel.
La raison pour laquelle cette chaîne d'attaque est si efficace est qu'elle contourne entièrement les défenses périmètriques. Il n'y a pas d'exploit, pas de charge malveillante livrée à l'infrastructure Azure, pas d'intrusion réseau au sens traditionnel. L'attaquant se connecte avec un vrai mot de passe et un jeton de session valide (ou récemment invalidé), navigue jusqu'au répertoire et l'exporte. Du point de vue d'Azure, la session ressemble à une action d'administration ordinaire.
Qui a été touché et quelles données ont été dérobées
La portée revendiquée est large. McDonald's arrive en tête de liste avec un volume allégué de 1,7 million de fiches, suivi de Tata Consultancy Services avec environ 800 000, Vodafone avec roughly 425 000 et HCL Technologies avec environ 250 000. Le reste des 3,64 millions au total est réparti entre Gap Inc., InterContinental Hotels Group, Kyndryl, Hexaware Technologies et Wyndham Hotels.
Ce qui rend les données particulièrement sensibles, c'est non seulement leur volume mais aussi la richesse du schéma de répertoire. Les échantillons examinés par Hudson Rock comprenaient apparemment des adresses e-mail professionnelles, des numéros de téléphone, des adresses de bureau physiques, des identifiants d'employés, des intitulés de poste, des organigrammes montrant qui rapporte à qui, des appartenances aux groupes Active Directory et des détails de comptes de service. De manière critique, certaines fiches identifiaient apparemment des comptes portant des privilèges d'administrateur général dans Entra ID. Cette dernière catégorie constitue une liste de ciblage : un attaquant qui sait quels comptes détiennent les rôles les plus privilégiés dans un tenant dispose d'une carte toute faite pour la prochaine phase d'une intrusion plus large.
TCS a déposé une déclaration à la Bourse de Bombay le 10 août après avoir reçu des alertes de renseignement sur les menaces, indiquant n'avoir « trouvé aucune preuve crédible d'une violation » de ses propres systèmes ou des environnements de ses clients. Aucune des autres entreprises nommées n'avait publié de déclaration officielle au moment des premiers reportages.
Pourquoi cela va au-delà des chiffres
Les répertoires d'employés divulgués sont souvent traités comme des incidents de gravité moindre par rapport aux violations de données financières ou de santé — une classification qui sous-estime leur valeur en aval pour les attaquants. Un organigramme complet avec adresses e-mail et structures hiérarchiques constitue la base de campagnes de spear-phishing ciblées et de compromission de messagerie professionnelle (BEC). Savoir qu'« Alice en Finance rapporte à Bob, le directeur financier » permet à un attaquant de construire une usurpation très convaincante de Bob demandant un virement urgent à Alice.
L'inclusion de comptes de service et de leurs appartenances aux groupes Entra ID aggrave encore la sévérité. Les comptes de service portent souvent des permissions élevées et sont rarement surveillés aussi étroitement que les comptes humains. Si l'un de ces comptes de service utilisait des mots de passe qui apparaissent ailleurs dans des dumps d'infostealers, ils deviennent des points de pivot immédiats vers l'infrastructure de production, les pipelines CI/CD ou les entrepôts de données.
Pour les organisations couvertes par le Règlement général sur la protection des données (RGPD) de l'UE, toute exfiltration confirmée de données personnelles d'employés déclenche une obligation de notification de violation sous 72 heures à l'autorité de contrôle compétente, qu'elle que soit la cause — faille de plateforme ou identifiant volé. L'article 33 du RGPD ne distingue pas les méthodes d'intrusion. Les expositions de Vodafone et d'IHG, si elles sont confirmées, activeront des obligations de notification dans plusieurs États membres de l'UE.
Ce que cela signifie pour les équipes cloud américaines et européennes
Le problème systémique que cet incident met en lumière est le fossé entre la sécurité du tenant cloud et la sécurité des terminaux. Les équipes qui ont investi massivement dans l'accès conditionnel Entra ID, la détection des menaces et l'architecture Zero Trust peuvent quand même être compromises si un infostealer s'exécute sans être détecté sur l'ordinateur portable d'un développeur suffisamment longtemps pour collecter un jeton de session valide. Dans les systèmes d'identité modernes, les jetons de session peuvent rester valides pendant des heures à des jours, et de nombreux infostealers les ciblent spécifiquement plutôt que les mots de passe, car les jetons contournent entièrement l'AMF.
Les équipes logicielles construisant sur Azure sont particulièrement exposées à ce schéma car les environnements de développement ont tendance à accumuler des permissions étendues. Un développeur qui s'est vu accorder le rôle de lecteur de répertoire Entra ID (Directory Reader), ou qui est membre d'un groupe avec des permissions élevées sur les ressources Azure, devient une cible de grande valeur pour toute campagne d'infostealer. Le principe du moindre privilège — bien compris au niveau de l'infrastructure — est fréquemment violé au niveau des rôles développeurs parce qu'il crée des frictions dans le travail quotidien.
La conclusion pratique pour les responsables ingénierie est de traiter l'hygiène des terminaux comme un contrôle de sécurité cloud de premier plan, et non comme une préoccupation informatique distincte. Les infections par infostealer se propagent via des e-mails de phishing, des extensions de navigateur malveillantes, des outils de développement trojanisés et des logiciels piratés. Une équipe qui déploie un accès réseau Zero Trust mais permet aux développeurs d'installer des extensions de navigateur non vérifiées présente une lacune que les attaquants trouveront.
Que faire maintenant : liste de contrôle pratique
- Auditez les journaux de connexion Entra ID pour les opérations d'export massif de répertoire. Dans le centre d'administration Microsoft Entra, accédez à Identité → Surveillance & intégrité → Journaux d'audit et filtrez les opérations telles que « Exporter le répertoire », « Obtenir les utilisateurs » à grande échelle, ou les appels à l'API Graph ayant renvoyé de grands ensembles de résultats. Remontez au moins 90 jours en arrière. Les connexions anormales depuis de nouvelles géographies, des appareils inconnus ou en dehors des heures de bureau pendant cette fenêtre justifient une enquête immédiate.
- Appliquez une AMF résistante au phishing pour tous les comptes privilégiés, en particulier les administrateurs généraux et les comptes de service. L'authentification par mot de passe seul et l'AMF par SMS sont toutes deux inadéquates. Exigez des clés matérielles FIDO2 ou Microsoft Authenticator avec correspondance de numéro (qui déjoue le push-bombing) pour tout compte disposant de permissions au niveau du répertoire. Appliquez des politiques d'accès conditionnel bloquant les protocoles d'authentification hérités, qui ne peuvent pas prendre en charge l'AMF.
- Renouvelez les identifiants des comptes de service susceptibles d'avoir été accessibles depuis des sessions compromises. Si un compte humain dans votre tenant avait accès aux identifiants de compte de service, aux clés API ou aux secrets pendant la fenêtre suspecte, renouvelez ces identifiants immédiatement. Priorisez les secrets stockés dans les variables d'environnement, les configurations de pipeline CI/CD et les entrées Azure Key Vault accessibles aux comptes concernés.
- Examinez la portée des permissions des développeurs dans Entra ID. Vérifiez quels comptes développeurs détiennent les rôles Lecteur de répertoire, Administrateur des utilisateurs ou Administrateur général, et si les appartenances aux groupes accordent un accès implicite à des ressources Azure sensibles. Appliquez le principe du moindre privilège : les développeurs construisant sur Azure ont rarement besoin de permissions de lecture au niveau du répertoire pour leur travail quotidien. Supprimez ce qui n'est pas nécessaire.
- Évaluez votre exposition aux infostealers au niveau des terminaux. Examinez la télémétrie EDR pour les comportements de collecte d'identifiants dans les navigateurs, les injections de processus inattendues dans les processus de navigateur et les connexions réseau vers l'infrastructure C2 connue des infostealers. Si vous n'avez pas de solution EDR couvrant les postes de travail des développeurs, cette lacune constitue désormais un risque de sécurité cloud documenté, et non simplement un oubli de gestion des terminaux.
- Si vous êtes couvert par le RGPD, évaluez vos obligations de notification. En vertu de l'article 33 du RGPD, une violation de données personnelles impliquant des données d'employés déclenche une obligation de notification sous 72 heures à votre autorité de contrôle principale s'il existe un risque pour les droits et libertés des personnes. Consultez immédiatement votre délégué à la protection des données si votre organisation figure parmi les entreprises nommées ou si une enquête interne révèle une exposition similaire des identifiants.
Questions fréquentes
Comment la campagne de vol d'identifiants Azure a-t-elle fonctionné ?
L'attaquant a utilisé des identifiants collectés par des logiciels malveillants de type infostealer depuis les terminaux infectés des employés des entreprises ciblées. Ces identifiants ont accordé l'accès aux tenants Microsoft Azure et Entra ID des entreprises, depuis lesquels l'attaquant a exporté les données du répertoire d'employés. Hudson Rock a identifié des identifiants Azure compromis liés à des infections par infostealer dans plusieurs entreprises nommées, corroborant le vecteur revendiqué.
Quelles entreprises ont été touchées ?
L'acteur malveillant a revendiqué des données provenant de McDonald's (~1,7 M de fiches), TCS (~800 K), Vodafone (~425 K), HCL Technologies (~250 K), Gap Inc., IHG, Kyndryl, Hexaware Technologies et Wyndham Hotels — soit 3,64 millions de fiches au total. TCS a publiquement nié avoir trouvé une preuve crédible d'une violation de ses propres systèmes. Les autres entreprises n'avaient pas publié de déclaration officielle au moment des premiers reportages.
Quelles données ont été exposées ?
Les échantillons examinés par Hudson Rock comprenaient apparemment des e-mails professionnels, des numéros de téléphone, des adresses physiques, des identifiants d'employés, des intitulés de poste, des départements, des organigrammes de reporting, des appartenances aux groupes Active Directory et des détails de comptes de service. Notamment, certaines fiches identifiaient des comptes dotés de privilèges d'administrateur général dans Entra ID, ce qui fournirait une liste de ciblage de grande valeur pour des attaques ultérieures.
Qu'est-ce qu'un infostealer et comment permet-il ce type d'attaque ?
Un infostealer est un logiciel malveillant qui extrait silencieusement les identifiants enregistrés, les jetons de session et les mots de passe sauvegardés dans le navigateur depuis les appareils infectés. Lorsque l'appareil d'un employé est infecté, l'infostealer collecte les jetons Azure et Microsoft 365 et les transmet à l'attaquant. Comme la connexion utilise des identifiants valides, elle contourne souvent les défenses périmètriques. Si un jeton de session récemment valide est capturé, il peut contourner entièrement l'AMF.
Cela signifie-t-il qu'Azure lui-même présente une faille de sécurité ?
Non. Les chercheurs ont conclu que l'attaque a utilisé des identifiants collectés par des infostealers, et non une vulnérabilité systémique de la plateforme Azure ou Entra ID. Une faille généralisée de la plateforme affecterait indistinctement les petites entreprises également. Microsoft n'a pas publié d'avis de sécurité attribuant cet incident à un défaut de la plateforme. La cause profonde est le vol d'identifiants au niveau du terminal.
Que doivent faire les équipes d'ingénierie pour protéger leurs tenants Azure ?
Appliquez une AMF résistante au phishing (FIDO2 ou Authenticator avec correspondance de numéro) pour tous les comptes. Auditez les journaux de connexion Entra ID pour détecter des exports massifs de répertoire anormaux au cours des 90 derniers jours. Bloquez les protocoles d'authentification hérités via l'accès conditionnel. Renouvelez les identifiants des comptes de service et les clés API en cas de doute. Examinez les permissions des rôles développeurs pour appliquer le principe du moindre privilège. Et traitez l'hygiène des terminaux face aux infostealers comme un contrôle de sécurité cloud de premier plan, et non comme une préoccupation informatique distincte.
Sources
The Register — Crook hawks millions of records allegedly plundered from corporate Azure tenants (17 août 2026)
BleepingComputer — Hacker claims 3.6 million Azure account records stolen from major companies
Help Net Security — Hacker claims millions of records stolen from corporate Azure tenants (18 août 2026)
SC Media — McDonald’s employee records allegedly stolen from Azure