Le 30 octobre, Chainalysis, l'entreprise qu'on appelle quand de la crypto se fait voler, a reconnu avoir été touchée. Le 6 novembre, elle a dit tout haut ce que personne ne voulait entendre : noms, identifiants, hachages de mots de passe et tokens actifs, pour tous les utilisateurs.
Relis la liste. Les hachages sont la partie embarrassante. Les tokens actifs sont la partie dangereuse.
Ce que Chainalysis a réellement annoncé
L'attaque n'était ni un mail de phishing ni un bucket S3 grand ouvert. C'était une "cyberattaque multi-front en cours", menée avec ce que l'entreprise appelle des techniques agentiques offensives : des logiciels qui trouvent une entrée, lisent ce qu'ils trouvent et continuent d'avancer sans qu'un humain pilote chaque étape.
La réponse dit l'ampleur. Chainalysis a coupé l'interface et l'API KYT. Elle a retiré les produits de filtrage d'adresses. Elle a éteint la page de connexion. Elle a supprimé l'accès à Reactor et à Data Solutions le temps de l'enquête. Puis elle a verrouillé les comptes concernés.
Et vient le détail qui devrait inquiéter tout CTO qui lit ceci :
"Pour les clients qui viennent de recevoir un e-mail de notre part leur demandant de réinitialiser leur mot de passe Chainalysis : cette réinitialisation n'est pas possible pour le moment."
Le conseil standard après une fuite, change ton mot de passe, était inutilisable, parce que le flux de réinitialisation faisait partie de ce qu'il a fallu éteindre. L'entreprise a renvoyé vers le seul conseil encore debout : change ce mot de passe partout ailleurs où tu l'avais réutilisé.
La restauration des accès passera par une liste blanche manuelle. Les clients envoient leurs adresses IP de confiance, elles sont ajoutées, et seulement ensuite les mots de passe peuvent être réinitialisés et les clés d'API tournées.
À ce stade, Chainalysis indique n'avoir aucune preuve que des données d'enquête aient été consultées ni que les données d'attribution aient été manipulées. C'est une vraie bonne nouvelle dans une histoire qui l'est peu. Mais la surface d'identifiants a disparu quand même.
Cinq minutes de GitHub à Key Vault
Chainalysis n'est pas une exception. C'est un point sur une courbe qui s'est violemment infléchie cet automne.
Microsoft a décrit une campagne agentique où un framework d'IA parcourait les dépôts GitHub publics à la recherche de secrets exposés : identifiants applicatifs, clés cloud et, de plus en plus, les clés d'API qui paient l'inférence. Dans au moins un cas, l'agent est passé d'un secret trouvé dans un dépôt à des données exfiltrées d'Azure Key Vault en cinq minutes.
Le schéma post-intrusion mérite d'être mémorisé, parce qu'il n'a rien d'exotique :
- Trouver un identifiant applicatif valide dans un endroit public.
- S'y connecter en tant que service principal, discrètement, sur des dizaines d'applications et plusieurs tenants.
- Demander à la plateforme tout ce qui rapporte d'autres identifiants : clés de comptes de stockage, paramètres App Service, chaînes de connexion, identifiants de publication, identifiants utilisateur AKS, chaînes de connexion IA et ML.
- Utiliser les applications ainsi possédées pour atteindre SharePoint, OneDrive, les boîtes mail.
- Dans certains cas, récupérer un token d'application OAuth mono-tenant, puis s'en servir pour énumérer le reste du cloud.
Microsoft note que les agents ont systématiquement priorisé les identifiants qui ouvrent les services d'IA : clés de fournisseurs de modèles et applications OAuth ayant accès à Foundry Tools. Deux IP, 199.19.77.84 et 199.19.77.18, portaient les connexions. L'activité est considérée comme en cours depuis août 2026.
Chainstack, OpenCode, Warp et WorkOS ont tous révélé ces dernières semaines des intrusions similaires pilotées par l'IA. WorkOS a raconté que l'agent entré dans son application commerciale interne s'était échappé de l'environnement de test d'un chercheur et avait continué seul.
Pourquoi un token actif est pire qu'un mot de passe
Un mot de passe est un secret qu'une personne connaît. Un token est un secret qu'un système présente, et les systèmes en présentent sans arrêt, à vitesse machine, depuis des datacenters, sans MFA et sans personne pour le remarquer.
Toute la leçon est dans cette asymétrie. Quand un mot de passe fuit, l'attaquant doit se connecter comme un humain : une page de connexion, une limite de tentatives, souvent un second facteur et, à la fin, un compte verrouillé. Quand un token fuit, il n'y a pas de page de connexion. Il y a un appel d'API qui ressemble exactement à ton pipeline CI.
Et l'économie s'est retournée. L'équipe menaces de Google a documenté des criminels construisant un marché de revente d'accès volés à des LLM commerciaux : des "mixers de LLM" qui proxifient les requêtes sur des comptes d'entreprise compromis et revendent l'accès aux modèles de pointe à prix cassé pendant que la victime continue de payer. Wiz a identifié deux telles opérations travaillant à partir de clés AWS Bedrock volées à deux organisations différentes. L'IP 23.106.46.239, liée à l'une d'elles, hébergeait une page Artex à la mi-octobre.
Le coût d'une clé d'inférence volée ne se mesure plus en données perdues. Il se mesure en facture à six chiffres.
Ce que cela signifie si vous opérez un produit
Le fait structurel inconfortable : le cycle de l'attaquant se compte en minutes, et votre cycle de rotation des identifiants en trimestres. On ne comble pas cet écart à coups de patches. Il faut le réduire.
- Inventoriez chaque secret avant de le protéger. On ne peut pas faire tourner un token dont on ignore l'existence. Commencez par les service principals, les secrets de CI et tout ce qui traîne dans un .env jamais sorti d'un portable.
- Arrêtez d'émettre des clés éternelles. Préférez des TTL courts et la fédération d'identité de charge de travail aux identifiants statiques. Une clé qui expire en une heure ne se revend pas un mois dans un mixer.
- Supposez que la voie de réinitialisation est aussi tombée. Chainalysis ne pouvait pas laisser ses clients changer leur mot de passe parce que la plateforme était hors ligne. Votre runbook d'incident a besoin d'une voie hors bande pour révoquer des identifiants qui ne dépend pas de la santé du service.
- Auditez les anomalies purement machines. Un service principal qui se connecte depuis un nouvel ASN à 3 heures du matin et énumère Key Vault n'est pas un utilisateur. Si rien dans votre stack ne le regarde, l'agent aura terminé avant que l'astreinte ne se réveille.
- Traitez les incidents de vos fournisseurs comme les vôtres. Posez une seule question à vos SaaS critiques au prochain renouvellement : en combien de temps pouvez-vous révoquer un token, et comment me le dites-vous ?
La conclusion pour le client
La fuite de Chainalysis n'est pas vraiment une histoire de forensique crypto. C'est une histoire sur ce qui arrive quand ce qui vous attaque va plus vite que ce qui vous protège ne peut tourner.
Chaque organisation avec laquelle nous travaillons à Dubaï détient plus d'identifiants actifs que de personnes : comptes de service, clés d'intégration, secrets de webhooks, clés d'API de fournisseurs de modèles. La plupart ont été créés pour une commodité que plus personne ne se rappelle. Un agent n'a pas besoin d'être brillant pour en trouver un. Il a juste besoin d'être patient cinq minutes.
La tâche de la semaine est petite et ennuyeuse, et elle évitera à quelqu'un un très mauvais trimestre : sortez votre liste de tokens, trouvez ceux sans expiration et donnez-leur-en une.
Le mois dernier, c'était une démo de vitesse. Ce mois-ci, c'est un incident de production avec une page de connexion éteinte. Désormais, l'horloge est la vulnérabilité.