Les attaquants n’ont plus besoin de faire du bruit pour compromettre une entreprise. Ils n’entrent pas toujours en déployant un malware ou en exploitant une vulnérabilité critique. Souvent, ils utilisent un compte valide, un mot de passe volé, un accès VPN oublié, une session cloud sans MFA ou un appel convaincant au helpdesk. Et quand ça se produit, une grande partie des défenses traditionnelles arrive trop tard.
Le rapport mondial de Kaspersky Security Services le confirme sur données 2025 : les techniques basées sur les identifiants et l’authentification figurent parmi les plus efficaces observées. Deviner un mot de passe aboutit à un incident confirmé dans 34,8 % des cas, suivi 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 %.
Pourquoi l’abus de crédentiels est si difficile à détecter
Un EDR peut repérer un binaire suspect, un antivirus peut bloquer un échantillon connu, un pare-feu peut couper une connexion inhabituelle. Mais quand un attaquant se connecte avec un utilisateur réel, depuis un service d’entreprise, en utilisant des outils administratifs légitimes, les signaux sont bien plus ténus.
Cette technique n’est pas nouvelle, mais elle reste efficace parce que beaucoup d’entreprises présentent les mêmes failles : mots de passe réutilisés, comptes anciens encore actifs, MFA incomplet, services exposés, utilisateurs avec trop de privilèges, faible visibilité sur les changements d’identité. Kaspersky y voit une évolution stratégique : moins de malware bruyant, plus d’accès légitime réutilisé pour éviter la détection.
MITRE ATT&CK décrit exactement cette technique : utiliser des comptes valides pour obtenir un accès initial, maintenir la persistance, escalader les privilèges ou contourner la détection. Le danger tient précisément dans le fait que l’attaquant n’a pas toujours besoin de casser quoi que ce soit. Il s’authentifie, se déplace, consulte des ressources et étend son contrôle avec des identifiants que le système accepte comme valides.
| Technique signalée par Kaspersky | Taux de conversion en incident |
|---|---|
| Deviner les mots de passe | 34,8 % |
| Créer des comptes locaux | 34,7 % |
| Abus de comptes valides | 34,5 % |
| Manipulation de comptes | 32,0 % |
| Découverte de services réseau | 31,2 % |
La création de comptes locaux illustre parfaitement la persistance. Une fois à l’intérieur, l’attaquant génère un nouveau compte pour ne plus dépendre de l’accès initial. Si le compte compromis est désactivé, la porte de sortie reste ouverte. La manipulation de comptes suit la même logique : réactiver des comptes désactivés, ajouter des membres à des groupes privilégiés, modifier des droits, sans outil externe.
Quatre incidents réels qui éclairent les risques
Colonial Pipeline reste la référence. En 2021, son PDG expliquait devant le Sénat américain que les attaquants avaient accédé au système via un mot de passe volé associé à un ancien VPN sans authentification multifacteur. Pas d’exploit sophistiqué, pas de vulnérabilité zero-day : juste un compte doté d’un seul facteur dans une infrastructure critique.
En 2024, Microsoft a connu Midnight Blizzard (aussi connu sous le nom Nobelium ou APT29). Les attaquants ont testé un password spraying contre un compte hérité d’un environnement de test non productif, sans MFA. De là, ils ont accédé aux emails d’entreprise. La leçon : les environnements « non productifs » font partie de la surface d’attaque.
L’incident Snowflake en 2024 montre une autre facette du problème. Mandiant a détecté une campagne de vol de données et d’extorsion contre des clients Snowflake, attribuée à UNC5537, utilisant des identifiants volés via des malwares infostealers. Ces comptes n’avaient généralement pas de MFA activé, et il n’y avait aucune preuve d’une faille dans la plateforme Snowflake elle-même. Dans le SaaS, la sécurité du fournisseur ne suffit pas si l’identité du client est mal protégée.
Quatrième cas : Okta en 2023. Des attaquants appelaient le support pour convaincre les agents de réinitialiser tous les facteurs MFA de comptes privilégiés. Après avoir obtenu l’accès à des comptes superadmin, ils exploitaient des fonctions légitimes de fédération d’identité pour usurper des utilisateurs. Aucun besoin de compromettre Okta directement : manipuler le processus de support suffisait.
Ces quatre cas ont un point commun : l’attaquant n’entre pas toujours où le personnel s’y attend. Un vieux compte, un tenant oublié, une crédentiale filtrée, un portable infecté par un infostealer, un agent helpdesk sous pression. C’est pourquoi la sécurité de l’identité ne peut plus être une couche optionnelle dans l’architecture de défense.
Ce que le SOC doit surveiller en priorité
L’abus de crédentiels ne se présente que rarement comme un événement spectaculaire unique. Il construit une chaîne : tentatives d’accès infructueuses, authentification réussie depuis un nouvel emplacement, exploration de services internes, modifications de groupes, création d’utilisateurs, enregistrement de nouveaux appareils MFA, 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 alarmer si c’est un administrateur de confiance en maintenance. Mais s’il apparaît après plusieurs tentatives échouées, depuis une IP inhabituelle, suivi de requêtes sur des ressources internes, le contexte change tout.
Les modifications d’identité méritent une attention particulière : réinitialisation MFA, ajout de nouveaux appareils, réactivation de comptes désactivés, modifications de rôles privilégiés, création d’applications OAuth, génération de tokens API, changements dans les règles de messagerie, accès à des consoles cloud depuis des emplacements inconnus. Dans un environnement hybride combinant Active Directory, Entra ID, Okta, Google Workspace, AWS IAM et VPN, si chaque système journalise indépendamment sans corrélation, l’attaquant peut progresser à travers ces angles morts.
Cinq contrôles pour réduire l’exposition
La première étape : traiter l’identité comme une surface d’attaque à part entière. 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 : les processus de réinitialisation, d’ajout d’appareils et de récupération de comptes doivent être aussi sécurisés que l’authentification initiale.
Deuxième contrôle : réduire les privilèges. Les comptes administratifs permanents doivent rester exceptionnels. L’accès privilégié devrait être limité dans le temps, justifié, enregistré et soumis à des revues régulières. Les comptes inactifs doivent être réellement désactivés, pas seulement marqués.
Troisième axe : contrôler le comportement, pas seulement l’authentification. Une connexion réussie peut être malveillante. Des règles de détection basées sur le risque couvrent les cas que la vérification simple rate : localisation inhabituelle, ASN inconnu, impossibilité de voyager, changement d’appareil, activité hors horaires, comportement suspect après une réinitialisation MFA.
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 livrer des tokens de session, des clés stockées dans le navigateur, des identifiants pour des outils cloud. La défense de l’endpoint reste nécessaire, mais elle doit s’intégrer dans une stratégie de protection de l’identité, et non fonctionner en silo. Les bots et agents automatisés représentent un vecteur supplémentaire que les systèmes de détection doivent désormais distinguer du trafic humain légitime.
Cinquième recommandation : tester les procédures humaines. Le support helpdesk ne doit pas être une porte dérobée qui contourne tous les contrôles techniques. Les processus de récupération de comptes exigent 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 sur les comptes sensibles.
La défense moderne part d’un constat inconfortable : une crédentiale valide ne prouve pas que l’utilisateur est légitime. Elle montre juste qu’il a réussi à franchir une porte. La vraie intelligence de détection réside dans la compréhension de qui agit, d’où, avec quelle intention, sur quelles ressources, et dans quel contexte.
Questions fréquemment posées
Qu’est-ce que l’abus de crédentiels en cybersécurité ?
C’est l’utilisation de comptes légitimes, volés ou compromis, pour accéder aux systèmes de l’entreprise en se faisant passer pour un utilisateur autorisé. L’attaquant exploite des identifiants valides pour accéder, se déplacer latéralement et exfiltrer des données sans déclencher les alertes classiques.
Pourquoi est-il difficile de détecter cette menace ?
Parce que les actions de l’attaquant semblent normales : connexion réussie, accès aux applications, changements de permissions, utilisation d’outils administratifs légitimes. La détection exige une analyse contextuelle et une corrélation d’événements plutôt que des signatures statiques.
Le MFA élimine-t-il totalement ces risques ?
Non. Le MFA réduit considérablement l’exposition, mais il doit être complété par une sécurisation du helpdesk, un contrôle des appareils, la détection d’anomalies comportementales, le principe du moindre privilège et une revue régulière des comptes inactifs. Les techniques de social engineering contournent le MFA sans jamais toucher à la technologie.
Quels sont les exemples les plus marquants de cette menace ?
Colonial Pipeline (VPN sans MFA, 2021), Microsoft Midnight Blizzard (password spraying sur compte hérité, 2024), Snowflake (infostealers + pas de MFA, 2024) et Okta (ingenierie sociale sur le helpdesk, 2023) illustrent comment des identifiants compromis ou des processus de support faibles ouvrent la porte à des incidents majeurs.
via : Open Security
