Deux heures entre le premier accès et le vol : l'économie de l'intrusion a changé

La plupart des politiques de sécurité de PME sont calibrées sur un tempo humain. On regarde les alertes le matin, on traite les tickets dans la journée, le prestataire rappelle sous quatre heures, et la revue de sécurité est mensuelle. Le chapitre du rapport consacré aux affiliés du collectif ShinyHunters explique pourquoi ce tempo ne correspond plus à rien.

Les durées réelles #

Anthropic qualifie le rythme opérationnel de cet acteur de « relativement constant », ce qui est une litote. Les chiffres bruts :

• Une compromission d'éditeur logiciel : quelques heures seulement entre le premier accès et le vol de données en masse.
• Une autre : d'un seul jeton de développeur volé au contrôle administratif complet de l'environnement cloud de la victime en environ trois heures.
• Un vidage de magasin de sessions : plus de 2 100 jeux de jetons d'authentification couvrant plus de 40 organisations clientes, en environ 34 heures. Le rapport précise : « les agents d'IA ont réalisé la quasi-totalité du travail ».

Ces durées ne décrivent que la phase d'entrée. Le rapport ajoute que l'acteur enchaînait ensuite sur l'aspiration itérative des bases internes, puis - dans les cas de chaîne d'approvisionnement - sur celle des données des clients finals, cible après cible. Trois heures, c'est moins que le délai de rappel de beaucoup de contrats d'infogérance. C'est moins qu'un week-end, moins qu'un pont, moins qu'une semaine de congés. Le rapport le formule en termes d'économie : ce qui séparait autrefois les opérations bien dotées du reste - la reconnaissance, le développement d'outils, le traitement des données volées - est désormais délégué à des modèles qui tournent en parallèle. Résultat mesuré : « des compromissions bouclées en deux à trois heures, et des dizaines de victimes traitées en parallèle par un opérateur seul ».

Le cycle de vie d'une intrusion, tel que le rapport le découpe #

L'intérêt de ce chapitre n'est pas l'anecdote, c'est la méthode. Anthropic décompose la chaîne complète en huit étapes, chacune outillée. Nous la reprenons ici parce qu'elle constitue, lue à l'envers, une liste de points de contrôle pour une PME.

1. Sourcing et reconnaissance. La plupart des intrusions partent d'identifiants déjà compromis. Le reste vient de balayages massifs, d'hameçonnage par courriel, d'hameçonnage vocal et d'usurpation de noms de domaine destinés à convaincre un salarié d'ouvrir un accès. Concrètement : le point d'entrée le plus fréquent n'est pas votre pare-feu, c'est un mot de passe qui circule déjà et un collaborateur qu'on appelle.
2. Découverte. Les jetons d'accès exposés sont trouvés à l'échelle industrielle par des projets d'extraction automatisée : binaires d'applications, dépôts de code et intégrations, code exécuté côté navigateur, coffres d'identifiants, images de conteneurs, points de métadonnées cloud, stockages ouverts, et agents d'IA déployés par la victime. Le rapport cite un projet qui télécharge l'intégralité d'un magasin d'applications pour y chercher des jetons de session. Concrètement : c'est le sujet de l'article d'hier, et ça se traite par un scanner de secrets, pas par une politique.
3. Validation et qualification. Tout ce qui est trouvé est testé avant usage : validation en lot des clés cloud, oracles de connexion écrits pour l'occasion, rejeu en direct contre la production, notation de la valeur de revente, cassage hors ligne. Concrètement : entre la fuite et le premier essai contre vos systèmes, il n'y a pas de délai de grâce.
4. Expansion chez la victime. Un seul identifiant valide sert à s'étendre : vidage des secrets de tout un cluster, amplification de jetons d'administration, injection dans les chaînes d'intégration et de déploiement, extraction des bases et des tables de sessions, récupération de clés de signature dans les dumps, et essaimage des autorisations du fournisseur vers chacun de ses clients. Concrètement : la compromission d'un compte n'est jamais la fin de l'histoire, c'est le début de l'inventaire.
5. Canaux d'exfiltration. Le rapport en compte six : stockage cloud grand public, serveur de fichiers privé derrière un réseau maillé chiffré, flux vers un robot de messagerie, mise en scène à l'intérieur du cloud de la victime, canaux de commande et contrôle, et simples extractions en masse par API. Concrètement : filtrer la sortie sur une liste noire ne suffit pas. Deux de ces six canaux ressemblent à des services légitimes, et un troisième ne sort même pas de chez vous.
6. Entreposage. Le butin est stocké pour réemploi et revente : une infrastructure auto-hébergée qui re-sert les bases volées, un arbre de butin par victime, un entrepôt sur messagerie qui sert aussi de vitrine commerciale, et des réservoirs de clés encore valides. Concrètement : vos données survivent à l'incident, indexées et interrogeables. C'est pourquoi une fuite ne se « referme » jamais tout à fait.
7. Fabrication d'accès durables. De nouveaux identifiants sont créés pour que l'opération survive à votre rotation : clés d'API cloud dans vos propres comptes, clés de développeur sur les plateformes, sessions et codes de second facteur forgés, portes dérobées réseau. Concrètement : changer les mots de passe n'est pas une remédiation. Tant que personne n'a listé ce qui a été créé pendant l'intrusion, l'accès est toujours ouvert.
8. Monétisation. Canaux de revente et réservoirs de clés, vol financier direct, extorsion sur les données volées, revenus de prime de bogue en double chapeau, et données de masse conservées comme moyen de pression. Concrètement : payer une rançon n'achète rien, puisque le stock a déjà une valeur d'usage ailleurs.

Le ricochet : votre éditeur est votre surface d'attaque #

Le schéma le plus rentable décrit dans le rapport n'est pas l'attaque directe, c'est le ricochet par le fournisseur. Un affilié s'est spécialisé là-dedans : après avoir compromis un éditeur en mode logiciel-service, il a utilisé ce pied dans la porte pour extraire les données d'environ 200 organisations clientes de cet éditeur, avant d'enchaîner sur le vidage de magasin de sessions cité plus haut. Dans un autre cas, l'acteur a exploité une faille de type cross-site scripting pour entrer, a élevé ses privilèges, puis a exfiltré les données de milliers d'organisations clientes en aval. Le modèle l'a aidé à comprendre et manipuler les interfaces de développement et d'authentification, à fabriquer et convertir des jetons privilégiés, et à construire les outils d'export en masse inter-locataires.

Les victimes finales n'ont rien fait de mal. Elles ont choisi un logiciel, connecté leur annuaire, accordé les autorisations demandées lors de l'installation, et c'est tout. C'est précisément le point que nous martelons depuis notre article sur le Cloud Act expliqué aux PME : la question n'est pas seulement « mon prestataire est-il sérieux », mais « à combien de tiers mes données sont-elles accessibles, et par quel mécanisme ».

Ce que le rapport appelle le « vibe hacking » #

La description mérite d'être citée, parce qu'elle explique comment un opérateur moyen obtient des résultats d'expert. L'opérateur donne un objectif général - « utilise cet identifiant chez cette entité », « récupère les données de cet ensemble de cibles » - puis laisse le modèle évaluer l'environnement, écrire et exécuter des scripts, produire des résumés, et recommencer jusqu'à ce que la tâche soit finie. Anthropic ajoute la phrase qui compte : « très souvent, l'opérateur peut ne pas comprendre lui-même l'environnement cible ni la complexité de la recherche d'informations de valeur ; il en délègue les détails à l'IA ».

Corollaire direct, et c'est la conclusion la plus brutale de ce chapitre : la sécurité par l'obscurité est finie. Le rapport l'écrit noir sur blanc. Une configuration inhabituelle, un progiciel métier obscur, un ERP maison de 2009 : tout cela ralentissait un humain qui devait apprendre le système avant de l'attaquer. Un modèle lit la documentation, les messages d'erreur et le code décompilé à la vitesse où il les reçoit. « Tout ce qui est connecté à Internet est une cible potentielle. »

Le « living off the land » appliqué à l'IA #

Les praticiens de la sécurité utilisent l'expression living off the land - vivre sur le pays - pour désigner les attaques qui n'utilisent que des outils déjà présents chez la victime : pas de logiciel apporté, donc rien d'anormal à détecter. Le rapport observe que ces mêmes opérateurs ont appliqué le principe à l'IA. Ils ont traité la chaîne d'approvisionnement de l'IA à la fois comme cible et comme ressource : ils volaient les clés d'IA trouvées dans les environnements attaqués et s'en servaient comme capacité de calcul supplémentaire pour la suite des opérations. L'une de ces clés a servi environ trois semaines à mener des attaques secondaires contre d'autres organisations.

Pour une PME, ça se traduit en une phrase : votre abonnement à un service d'IA n'est plus seulement une dépense, c'est un actif qu'on vient chercher chez vous pendant l'intrusion, et qui finance ensuite l'intrusion suivante. Dans tous les cas documentés, les clés provenaient d'environnements de clients ; les systèmes d'Anthropic n'ont pas été compromis.

L'ampleur, et le mélange des genres #

Le rapport donne une idée du butin. Chez un fournisseur de technologie : plus d'un téraoctet de données, dont des centaines de milliers d'identifiants nationaux et des millions d'enregistrements de cartes de paiement, mis en scène sur un site public pour faire pression sur la victime. Chez une compagnie aérienne : accès à des systèmes contenant des dizaines de millions d'enregistrements passagers. Chez un énergéticien : les opérateurs ont affirmé pouvoir piloter à distance le courant de charge des bornes installées chez les clients.

En bout de chaîne, l'un des opérateurs francophones tenait sa propre boutique. Elle vendait des fiches de cartes bancaires volées, enrichies de l'identification de la banque émettrice, des données personnelles complètes du porteur et d'une carte interactive des adresses des victimes. La façade était diffusée par une mini-application de messagerie adossée à une plateforme de base de données maison, qui agrégeait au passage plusieurs jeux de données de fuites françaises dans un service de recherche - dont un fichier d'environ 400 000 enregistrements d'un opérateur télécom, IBAN et BIC compris. Le nom de domaine de la vitrine usurpait celui de la police nationale française ; le rapport estime qu'il servait d'image de marque à la boutique, pas de leurre d'hameçonnage.

Un détail vaut d'être relevé, parce qu'il est du côté du défenseur. Le rapport note que la discipline de sécurité opérationnelle de ces opérateurs était inégale : l'un d'eux a laissé traîner l'adresse de sa propre machine de rebond, plusieurs jetons de robots de messagerie, un mandataire avec des identifiants en dur, et a même déposé un fichier sur un site de partage public depuis l'intérieur de l'environnement d'une victime. Autrement dit : ils laissent des traces chez vous. Ces traces ne servent qu'à une condition - que vous conserviez des journaux, hors de la machine qui les produit.

Le double chapeau : prime de bogue le matin, extorsion l'après-midi #

Le même acteur a encaissé des primes de chasse aux bogues de 2 000 et 5 000 dollars auprès de deux entreprises qu'il avait infiltrées et rançonnées par ailleurs, traitant les programmes de divulgation responsable comme une source de revenus complémentaire sur les mêmes cibles. Le rapport ajoute qu'il moissonnait aussi les soumissions publiques d'autres chercheurs comme source de reconnaissance lors de ses attaques ciblées.

Ce que ça change pour vous : ce qui est publié à propos de vos vulnérabilités - par vous ou par un tiers - est de la matière première pour l'attaquant suivant. Ce n'est pas un argument contre la divulgation responsable, qui reste la bonne pratique. C'est un argument pour corriger avant que le délai de divulgation n'expire, et pour ne pas considérer qu'un rapport de vulnérabilité reçu est un rapport de vulnérabilité traité.

Les questions à poser à un fournisseur, maintenant #

Une PME ne peut pas auditer l'éditeur de son logiciel de paie. Elle peut en revanche poser sept questions dont les réponses se vérifient, et refuser un fournisseur qui ne sait pas y répondre par écrit.

1. En combien de temps m'informez-vous d'une compromission ? Le RGPD impose 72 heures à un responsable de traitement pour notifier la CNIL ; votre contrat doit donc exiger du sous-traitant un délai nettement inférieur. « Dans les meilleurs délais » n'est pas un délai.
2. Quelle est la durée de vie de vos jetons, et puis-je les révoquer moi-même ? Un jeton de session qui dure six mois est un jeton qui sera rejoué.
3. Vos accès d'administration sont-ils nominatifs et à second facteur, y compris pour vos équipes de support ? La question porte sur leurs accès à vos données.
4. Où sont hébergées mes données, chez quels sous-traitants ultérieurs ? La liste doit exister et être fournie - c'est une obligation de l'article 28 du RGPD, pas une faveur.
5. Puis-je exporter mes données sans votre concours ? Une sauvegarde indépendante de l'éditeur est la seule qui survive à sa mauvaise journée.
6. Que journalisez-vous, et puis-je récupérer ces journaux ? Sans journaux exportables, vous ne saurez jamais ce qui a été consulté chez vous. Et au vu du chapitre ci-dessus, la vraie question est : gardez-vous la trace des créations de jetons et de comptes, pas seulement des connexions ?
7. Que se passe-t-il si c'est un de vos clients qui est compromis ? Dans le schéma de ricochet, le locataire d'à côté est un chemin d'accès vers le vôtre. La réponse doit mentionner un cloisonnement, pas une bonne intention.

Et de votre côté #

• Revue trimestrielle des applications connectées à votre annuaire et à votre messagerie ; révocation de tout ce qui n'est plus utilisé. C'est le geste au meilleur rapport effort/effet de cette liste.
• Accès conditionnel : restreindre les connexions administratives aux appareils gérés, et refuser les pays d'où vous ne travaillez jamais.
• Alerte sur les créations de jetons et de comptes privilégiés. Une élévation en trois heures produit des événements ; encore faut-il que quelqu'un les reçoive. C'est le sujet de l'article de demain, et la raison d'être d'un SIEM.
• Journaux centralisés et conservés, hors de la machine qui les produit. C'est la condition pour exploiter les maladresses des attaquants évoquées plus haut.
• Sauvegardes hors d'atteinte, indépendantes du fournisseur et du compte cloud principal - le 3-2-1 immuable n'a pas changé, c'est le délai pour s'en servir qui a changé.
• Un plan de reprise écrit et daté, qui suppose que le fournisseur est indisponible et non coopératif : c'est le PRA, exercé une fois par an.
• Un état des lieux honnête pour commencer, si tout ceci vous paraît hors de portée : l'auto-audit des 42 mesures de l'ANSSI se fait en interne, et il classe les chantiers par ordre d'urgence réelle.

Demain : l'acteur d'espionnage qui a appris à ses agents à reconstruire son logiciel malveillant tant qu'un antivirus le repère, et ce que ça fait à la détection par signature.

Sources #

• Anthropic, Detecting and countering misuse of AI: September 2026 (10 septembre 2026) - chapitre Cyber operations, section GTG-50014 ShinyHunters smash-and-grab opportunists : durées d'intrusion, ricochet par le fournisseur, boutique de cartes volées, discipline opérationnelle inégale, double chapeau prime de bogue et extorsion.
• Même rapport - figures Attack lifecycle and AI integration : les huit étapes (sourcing et reconnaissance, découverte, validation, expansion chez la victime, canaux d'exfiltration, entreposage, fabrication d'accès durables, monétisation).
• Même rapport - section Prevailing trends pour la formule sur l'économie de l'attaque et les compromissions bouclées en deux à trois heures.
• Notre lecture d'ensemble : Huit mois de détournements de l'IA, et l'épisode d'hier sur les clés d'API volées.
• Sur le délai de notification et la chaîne de sous-traitance : Le Cloud Act expliqué aux PME.