Une attaque par « password spray » est un procédé bien connu : il s'agit d'essayer plusieurs mots de passe courants sur un grand nombre de comptes dans l'espoir que l'un d'entre eux fonctionne. En octobre 2026, Wiz Research en a observé une où l'intervalle médian entre les tentatives était exactement d'une seconde. Les sessions duraient entre 24 et 30 heures, et les adresses bloquées étaient remplacées en quelques minutes. Aucun être humain ne tape de cette manière. Ce schéma provient d'un agent d'IA et renvoie à un outil appelé ARTEX.
Qu'est-ce qu'ARTEX et qui l'utilise ?
ARTEX est un framework open source capable d'effectuer de manière autonome des tests d'intrusion. Un opérateur définit une cible et un objectif, puis les agents planifient et exécutent les différentes étapes. Depuis fin août, le Threat Intelligence Group de Google et Mandiant ont constaté son utilisation dans des cas de réponse aux incidents, tant par des groupes de chantage que par des opérateurs soupçonnés d’espionnage. Microsoft suit l’une de ces campagnes sous le nom de Storm-0940. Le développeur a cessé de proposer le code librement en octobre, mais celui-ci avait déjà été copié plus de 12 000 fois.
Ces techniques sont anciennes, et le temps qui les séparait a disparu
Rien de ce qu’a fait cet agent n’est nouveau : attaque par « password spraying », exploitation abusive des pages de réinitialisation de mot de passe, clés d’ cloud s volées, passage d’un système à l’autre. Google le formule ainsi : « Les outils offensifs basés sur les modèles de langage à grande échelle (LLM) ne modifient pas fondamentalement les techniques utilisées par les attaquants. Ils réduisent simplement le temps nécessaire pour les combiner. »
C'est le temps qui fait la différence. Google indique qu'un pirate est généralement passé, en moyenne, d'un premier compte compromis à un accès approfondi en environ quatre heures, et qu'il y est même parvenu en 15 minutes dans un cas. Les différentes étapes se sont enchaînées en quelques secondes : 27 événements en 23 secondes, le temps que l'agent teste les possibilités offertes par une clé « cloud » volée.
Trois fossés, franchis en quelques secondes
C'est là que les trois failles de détection décrites dans mon livre blanc se manifestent dans des incidents réels. Dans plusieurs cas, les opérateurs ont transmis à ARTEX des identifiants qu'ils avaient déjà volés. L'agent s'est alors connecté avec ces identifiants ; l'authentification a donc abouti, et le journal des actions indique des connexions normales (faille n° 2). Il a également réutilisé des fonctionnalités déjà existantes, telles que le système de notification d’une application métier pour envoyer un e-mail à plus de 1 300 employés, de sorte que rien ne semblait anormal (lacune n° 1). Et il a transité des annuaires vers le stockage d’ cloud s, puis vers les services d’identité, qui sont généralement surveillés par des équipes et des outils distincts, ce qui rend ses mouvements invisibles (lacune n° 3).
Un opérateur humain qui franchit ces limites laisse derrière lui des traces éparses et espacées dans le temps. Un agent laisse les mêmes traces, mais condensées en quelques minutes, dans une fenêtre temporelle où trois tickets distincts pourraient ne jamais être mis en relation.
C'est le rythme qui est l'indice, mais le repérer ne suffit pas pour atteindre l'objectif
La vitesse est également le signal le plus facile à interpréter. Un rythme d’une seconde, un test d’autorisation toutes les secondes environ et une rafale de 27 événements en 23 secondes ressortent clairement dès lors que l’on examine simultanément le timing et la séquence, plutôt que chaque événement pris isolément.
Mais Google va plus loin : la détection et la réaction sont deux tâches distinctes, et « le simple fait de détecter l’attaque à temps ne suffit pas à empêcher la réalisation de l’objectif ». Si un agent parvient à accéder à des zones sensibles en 15 minutes, une alerte qui se transforme en ticket le lendemain matin arrive trop tard, une fois l’objectif déjà atteint. La rapidité de la réaction doit être à la hauteur de celle de l’attaquant.
La version « bruyante » est la première version.
Google qualifie l'utilisation actuelle de « phase initiale » : des outils open source utilisés sans grande rigueur, générant des campagnes de grande envergure et bruyantes, mais qui s'avèrent néanmoins efficaces. Selon ses propres estimations, des attaques plus discrètes et entièrement autonomes devraient suivre d'ici trois à six mois. Il s'agit là d'une prévision, et non d'une constatation. Si cette prévision se confirme, les indices mentionnés ci-dessus constituent la version la plus simple, et la fenêtre d'opportunité pour mettre en place une détection basée sur le timing et une réponse plus rapide est désormais ouverte.
Vectra AI
Chez Vectra AI, c'est là le problème autour duquel s'articule notre travail de détection : une connexion que le journal d'audit enregistre comme réussie, suivie d'un comportement qui ne correspond pas à l'identité de la personne qui s'est connectée. Les recommandations de Google en matière de sécurité aboutissent à la même conclusion, à savoir que la détection d'un changement de comportement repose sur l'analyse conjointe de l'identité, de l'cloud et de l'activité réseau. Un agent agissant à ce rythme aura déjà franchi ces trois étapes avant que les différents outils n'aient fini de déclencher leurs alertes.
Le livre blanc intitulé « Mind Your Gaps in the Age of AI-Powered Attacks » passe en revue les trois failles de détection de bout en bout. Ses sections consacrées à la faille n° 1 (rien ne semble anormal), à la faille n° 2 (l’authentification aboutit) et à la faille n° 3 (les mouvements ne sont pas visibles) couvrent le schéma décrit ici.