Anatomie d'une campagne de
credential stuffing

Un mardi à 02h41, l'analytique d'identité de notre SOC signale une anomalie sur le tenant d'un client genevois : une vague lente et distribuée d'échecs de connexion sur trente boîtes aux lettres, provenant de proxys résidentiels répartis sur quatre continents. Aucune source ne déclenche seule un verrouillage. Ensemble, elles forment la signature caractéristique du credential stuffing — le test de couples identifiant/mot de passe issus de fuites tierces.

La chronologie

• 02h41 — Détection : les heuristiques de voyage impossible et de password spray corrèlent à l'échelle du tenant ; un incident s'ouvre automatiquement.
• 02h43 — Confinement : la politique d'accès conditionnel se durcit pour exiger le MFA sur toute connexion depuis un réseau inconnu ; les plages ASN attaquantes sont bloquées au niveau identité.
• 02h45 — Une seule réussite : un compte renvoie une authentification de premier facteur valide. Le défi MFA n'est pas complété. Les sessions du compte sont révoquées et son mot de passe réinitialisé d'office.
• 03h10 — Chasse : une recherche rétroactive sur 30 jours confirme l'absence d'accès antérieur depuis l'infrastructure de la campagne ; le couple d'identifiants provient d'une fuite tierce de 2024.
• Au matin — Débrief client : une page, quatre actions, aucune donnée consultée.

Ce qui l'a réellement arrêtée

Rien ici n'exige d'outillage exotique. Trois contrôles ont fait le travail : le MFA sur chaque compte, sans exception pour les protocoles hérités ; une télémétrie d'identité qui alimente un SOC qui la regarde à 02h41 et pas seulement à 09h00 ; et un accès conditionnel durcissable en quelques minutes quand la situation change. Les quatre minutes affichées sur notre page d'accueil ne sont pas du marketing — c'est l'écart entre détection et confinement dans des incidents comme celui-ci.

La leçon inconfortable

Le mot de passe testé était valide. Il avait été réutilisé sur un service tiers compromis un an plus tôt. Les programmes d'hygiène des mots de passe comptent, mais la conclusion honnête est plus simple : partez du principe que certains identifiants circulent déjà, et construisez la couche d'identité pour qu'un mot de passe valide seul ne suffise jamais.

Si vous ne savez pas qui surveillait votre tenant à 02h41 la nuit dernière, c'est exactement l'écart que comble notre SOC-as-a-Service. Les détails ont été modifiés pour protéger le client ; le schéma et la réponse sont fidèles à la réalité.

Article de démonstration pour la maquette — relecture technique par l'équipe InterHyve avant publication.