Les attaquants n’ont plus besoin de faire du bruit pour compromettre une entreprise. Souvent, ils ne pénètrent pas en déployant un malware, en exploitant une vulnérabilité critique ou en lançant une campagne de ransomware visible dès le début. Ils entrent en utilisant un compte valide, un mot de passe volé, un accès VPN oublié, une session cloud sans MFA ou en passant par un appel convaincant au helpdesk. Et lorsque cela se produit, une grande partie de la sécurité traditionnelle arrive trop tard.

Le dernier rapport mondial de Kaspersky Security Services souligne à nouveau cette tendance : en 2025, les techniques basées sur les identifiants et l’authentification ont été parmi les plus efficaces observées. Leur analyse montre que la tentative de deviner un mot de passe aboutit à un incident confirmé dans 34,8 % des cas, suivie de près par la création de comptes locaux (34,7 %) et l’abus de comptes valides (34,5 %). La manipulation de comptes atteint 32 % et la découverte de services réseau, 31,2 %.

Le problème : un compte légitime ressemble à un compte légitime

L’abus d’identifiants fonctionne car il ressemble trop à une activité normale. Un EDR peut détecter un fichier binary suspect, un antivirus peut bloquer un échantillon connu, et un pare-feu peut couper une connexion inhabituelle. Mais lorsqu’un attaquant se connecte avec un utilisateur réel, depuis un service d’entreprise, en utilisant des outils administratifs légitimes, la signalisation est bien plus ténue.

Ce n’est pas une technique nouvelle, mais son efficacité reste élevée car beaucoup d’entreprises présentent les mêmes vulnérabilités : mots de passe réutilisés, comptes anciens encore actifs, MFA incomplet, services exposés, utilisateurs avec plus de privilèges que nécessaires, et faible visibilité sur les changements d’identité. Kaspersky interprète ce schéma comme une évolution stratégique : moins de malware bruyant, et plus d’accès légitime réutilisé pour éviter la détection.

MITRE ATT&CK décrit cette technique comme l’utilisation de comptes valides pour obtenir un accès initial, maintenir la persistance, escalader les privilèges ou se soustraire à la détection. Le danger réside précisément dans le fait que l’attaquant n’a pas toujours besoin de casser quoi que ce soit. Il peut s’authentifier, se déplacer, consulter des ressources et étendre son contrôle avec des identifiants que le système accepte comme valides.

La création de comptes locaux illustre parfaitement la notion de persistance. Une fois à l’intérieur, l’attaquant peut générer un nouveau compte pour ne pas dépendre de l’accès initial. Si le compte compromis est désactivé, le malfaiteur dispose toujours d’une autre porte dérobée. La manipulation de comptes suit la même logique : réactiver des comptes désactivés, ajouter des membres à des groupes avec privilèges, ou modifier des droits, tout cela sans nécessité d’utiliser des outils externes.

Quatre exemples concrets illustrant le risque

L’affaire Colonial Pipeline reste une leçon essentielle pour toute équipe de sécurité. En 2021, son PDG expliquait devant le Sénat américain que les attaquants avaient eu accès via un mot de passe volé associé à un ancien système VPN dépourvu d’authentification multifacteur. Ce n’était pas une exploitation sophistiquée contre une technologie inédite, mais une simple compromission d’un compte doté d’un seul facteur d’authentification dans une infrastructure critique.

Microsoft a connu un autre exemple en 2024 avec Midnight Blizzard, un groupe aussi connu sous le nom de Nobelium ou APT29. D’après la société elle-même, les attaquants ont testé une technique de password spraying contre un compte hérité d’un environnement de test non productif sans MFA. Depuis cet incident, ils ont pu accéder aux emails d’entreprise. La leçon ici : même les environnements « non productifs » font partie de la surface d’attaque.

L’incident Snowflake en 2024 illustre une autre facette de ce problème. Mandiant a détecté une campagne de vol de données et d’extorsion contre des clients de Snowflake, attribuée à UNC5537, utilisant des identifiants volés, souvent obtenus par malware infostealer. La société indique que ces comptes n’avaient généralement pas MFA activé et qu’il n’y avait pas de preuve d’une faille dans la plateforme Snowflake. La conclusion éducative est claire : dans le SaaS, la sécurité du fournisseur ne suffit pas si l’identité du client est mal protégée.

Les attaques par ingénierie sociale ciblant les helpdesk augmentent la difficulté supplémentaire. En 2023, Okta a signalé une campagne où des attaquants appelaient le support pour convaincre de réinitialiser tous les facteurs MFA de comptes privilégiés. Une fois qu’ils avaient obtenu l’accès à des comptes de superadmin, ils exploitaient des fonctions légitimes de fédération d’identité pour usurper des utilisateurs. Aucun besoin de compromettre directement Okta ; manipuler le processus de support suffisait.

Ces exemples ont un point commun : l’attaquant ne pénètre pas toujours par là où le personnel s’y attend. Il peut exploiter un vieux compte, un tenant oublié, une crédentiale filtrée, un portable infecté par un infostealer ou un agent helpdesk sous pression. C’est pourquoi la défense ne peut plus se limiter aux endpoints et au périmètre traditionnel.

Signaux que le SOC ne doit pas ignorer

L’abus d’identifiants ne se présente que rarement comme un événement spectaculaire unique. Il construit plutôt une chaîne d’événements : tentatives d’accès infructueuses, authentification réussie depuis une nouvelle localisation, exploration de services internes, modifications de groupes, création d’utilisateurs, enregistrement de nouveaux appareils MFA ou comportements anormaux avec des outils d’administration.

Un SOC doit traiter ces signaux comme les éléments d’une même histoire. Un compte local créé en dehors des heures peut ne pas être alarmant si c’est un administrateur de confiance durant une période de maintenance. Mais s’il apparaît après plusieurs tentatives échouées, provenant d’une IP inhabituelle, et suivi de requêtes sur des ressources internes, tout change.

Il est également crucial de surveiller de près toute modification d’identité : réinitialisation MFA, ajout de nouveaux appareils, réactivation de comptes désactivés, modifications des rôles privilégiés, création d’applications OAuth, génération de tokens API, changements dans les règles de messagerie, nouveaux secrets SSH, accès à des consoles cloud depuis des endroits inhabituels, etc.

Dans un environnement hybride, la complexité augmente. Une entreprise utilise souvent Active Directory, Entra ID, Okta, Google Workspace, AWS IAM, des comptes SaaS critiques, VPN et outils d’administration à distance. Si chaque système enregistre des événements séparément sans corrélation, l’attaquant peut se frayer un chemin à travers ces brèches de visibilité.

Quels contrôles apportent une véritable protection

La première étape consiste à reconnaître que l’identité constitue une surface d’attaque majeure. Le MFA doit être obligatoire, en particulier pour les accès distants, comptes privilégiés, consoles cloud, SaaS critiques et outils d’administration. Mais le MFA seul ne suffit pas : il faut aussi sécuriser les processus de réinitialisation, d’ajout d’appareils et de récupération de comptes.

La deuxième recommandation : réduire les privilèges. Les comptes administratifs permanents doivent rester exceptionnels. L’accès privilégié doit être limité dans le temps, justifié, enregistré et soumis à des revues régulières. Les comptes locaux doivent être inventoriés et surveillés. Les comptes inactifs doivent être réellement désactivés, et leur activité vérifiée périodiquement.

Troisièmement, il faut contrôler le comportement, pas seulement l’authentification. Une authentification réussie peut être malveillante. C’est pourquoi il faut mettre en place des règles de détection basées sur le risque : localisation inhabituelle, ASN inconnu, impossibilité de voyager, changement d’appareil, activité hors horaire, comportement suspect après une réinitialisation MFA ou utilisation abusive d’outils d’administration par des utilisateurs n’étant pas familiers avec ceux-ci.

Quatrième levier : sécuriser les identifiants sur les postes utilisateurs. Les campagnes de type Snowflake montrent l’impact des infostealers : un poste compromis peut fournir des tokens de session, des clés stockées dans le navigateur, des identifiants pour des outils cloud, ou encore des accès à des plateformes d’entreprise. La hygiène des endpoints doit continuer à être une priorité, mais elle doit être intégrée à une démarche de protection de l’identité.

La cinquième recommandation consiste à tester les procédures humaines. Le support helpdesk ne doit pas constituer un dodgy qui contourne tous les contrôles techniques. Les processus de récupération de comptes doivent inclure une vérification d’identité forte, une approbation supplémentaire pour les utilisateurs privilégiés, un blocage temporaire en cas de signaux suspects, et des alertes lors des réinitialisations de facteurs MFA pour les comptes sensibles.

La conclusion est claire pour les administrateurs, les équipes SOC, et les responsables sécurité : si un attaquant peut entrer avec une seule identité, créer un nouveau compte, augmenter ses privilèges et circuler dans le réseau sans être détecté, le problème ne réside pas uniquement dans les mots de passe. Il concerne aussi l’architecture d’identité, la télémétrie et la capacité d’y répondre.

La défense moderne doit partir d’un principe pas toujours confortable : une crédentiale valide ne prouve pas que l’utilisateur soit légitime. Elle ne fait que montrer qu’il a réussi à franchir une porte. La véritable intelligence réside dans la compréhension de qui agit, d’où, selon quel motif, sur quels ressources, et avec quelle intention.

Questions fréquentes

Qu’est-ce que l’abus d’identifiants en cybersécurité ?
Il s’agit de l’utilisation de comptes légitimes, volés ou compromis, pour accéder aux systèmes de l’entreprise et agir comme si l’attaquant était un utilisateur autorisé.

Pourquoi est-il difficile de détecter l’abus d’identifiants ?
Parce que beaucoup d’actions sembleront normales : connexion, accès à des applications, changements de permissions ou utilisation d’outils administratifs. La détection exige une analyse contextuelle et une corrélation précise.

Le MFA élimine-t-il totalement ces risques ?
Non. Le MFA réduit considérablement ces risques, mais doit être complété par une sécurité renforcée du helpdesk, un contrôle accru des appareils, la détection d’anomalies, le principe du moindre privilège, et une revue régulière des comptes.

Quels exemples concrets illustrent cette problématique ?
Colonial Pipeline, Microsoft avec Midnight Blizzard, les campagnes contre les clients Snowflake, et les attaques de phishing ciblant Okta, démontrent comment des identifiants volés, comptes obsolètes ou processus de support faibles peuvent ouvrir la porte à des incidents majeurs.

via : Open Security