Comptes et authentification
Particuliers et entreprisesAttaque par force brute
Brute-force attack
L’attaquant multiplie les essais pour trouver un mot de passe ou un autre secret.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
Un service reçoit de nombreuses tentatives de connexion avec des mots de passe différents. L’attaquant cherche la bonne combinaison. Dans un autre cas, il possède une copie protégée d’un secret et teste les possibilités sur ses propres machines, sans interroger votre compte à chaque essai.
Comment cela fonctionne
Une attaque par force brute essaie des possibilités jusqu’à trouver celle qui fonctionne. Elle peut parcourir toutes les combinaisons ou se concentrer sur une liste de mots probables. Une phrase de passe longue et unique rend la recherche beaucoup plus difficile. Limiter le nombre de tentatives protège les connexions au service, mais ne freine pas les essais faits hors ligne sur une copie de données volées.
- Des possibilités sont essayées
L’attaquant cherche le bon secret.
- Le service compare chaque essai
Les tentatives se poursuivent tant qu’elles sont autorisées.
- Un secret faible peut céder
Le compte devient accessible.
Les signes qui doivent attirer l’attention
- Des échecs de connexion inhabituels sont signalés.
- Un compte se verrouille sans explication connue.
- Un service exposé reçoit des tentatives répétées de nombreuses adresses.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Créez des mots de passe longs et différents avec un gestionnaire. Activez un second facteur et vérifiez les alertes de connexion depuis les paramètres du service.
Si vous êtes responsable du service ou de l’organisation
Limitez les essais par compte et par source, sans qu’un attaquant puisse bloquer définitivement la victime. Protégez aussi les empreintes de mots de passe stockées : s’il en vole une copie, il peut faire ses essais hors ligne.
Bloquer les connexions après plusieurs échecs ne freine pas les essais faits sur une copie volée de la base de mots de passe.
À vous de décider
Vous recevez dix alertes de connexion refusée. Cela veut-il dire que quelqu’un a déjà ouvert votre compte ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Ces alertes décrivent des essais refusés, pas des accès réussis. Vérifiez les connexions et appareils reconnus depuis les paramètres officiels du service. Signalez les anomalies et renforcez un mot de passe faible ou réutilisé, sans suivre un lien d’alerte non vérifié.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
De nombreux échecs précèdent une connexion réussie
Les 180 tentatives visant u1 sont bloquées. Pour u3, les traces montrent 192 échecs répartis entre 48 sources, puis une connexion réussie. Il reste à savoir qui s’est connecté : l’attaquant ou le titulaire pendant les essais. Vérifiez l’appareil et les actions effectuées dans cette session.
Une limitation par adresse IP laisse passer une attaque distribuée. À l’inverse, bloquer définitivement un compte après quelques échecs permet à n’importe qui d’empêcher son propriétaire de travailler. Il faut combiner ralentissement progressif, signaux par compte et par source, MFA et récupération de compte, puis mesurer les blocages légitimes.
Le cassage hors ligne est un autre problème. Si l’attaquant a volé une base d’empreintes de mots de passe, ses calculs ne passent plus par le portail. Les limitations de connexion n’ont alors aucun effet. La résistance dépend du stockage des mots de passe, du coût de dérivation et de la solidité des secrets. L’enquête doit aussi retrouver comment la base a été extraite.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Essais distribués
Sources d’essais vers Limiteur
Trace u3 / 48 sources
- Action
Essais non bloqués
Limiteur vers Vérification secret
Trace Décision du limiteur
- Réponse
Échecs ou succès
Vérification secret vers Limiteur
- Action
Création d’une session après succès
Vérification secret vers Session / hash
Trace À qualifier
- Action
Cas hors ligne : matériau déjà volé
Sources d’essais vers Session / hash
Trace Pas de requête au portail
- Refus / blocage
Ralentissement ou challenge
Limiteur vers Sources d’essais
Trace Sans verrouillage abusif
Comment repérer cette attaque
Indices à rechercher
Repérer les séries d’échecs de connexion et les réussites qui les suivent, par compte, source et application. Examiner plusieurs durées pour faire apparaître les essais espacés.
Quelles informations comparer
Rechercher une réussite après les échecs, puis les actions réalisées dans cette session. Séparer les comptes et services : un total global peut masquer une attaque lente ou un logiciel mal configuré.
Ce que ces indices ne permettent pas de conclure
Le cassage hors ligne d’empreintes volées ne génère pas de tentatives de connexion sur votre service. Une hausse d’échecs n’est pas, à elle seule, la preuve qu’un mot de passe a été découvert.
Comment réagir
Ralentir les essais sans permettre le verrouillage abusif d’un compte. Examiner les connexions réussies et révoquer les sessions compromises. Si une base d’empreintes a été volée, corriger l’accès initial et le stockage des mots de passe, puis traiter les secrets exposés ; la limitation des connexions ne protège pas contre les calculs hors ligne.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- Vérifier une attaque distribuée de test sans bloquer durablement le compte victime.
- Mesurer le délai de récupération et les faux positifs d’un client dont le secret a expiré.
- Tester que les logs ne contiennent jamais les candidats ni le secret soumis.
À vous de raisonner
Une base d’empreintes a été volée. Renforcer la limitation des connexions arrête-t-il les essais sur cette copie ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Non : ces calculs se font hors ligne. Leur résistance dépend du stockage des mots de passe et de la solidité des secrets. Il faut aussi traiter la fuite et les comptes exposés. La limitation reste utile contre les tentatives en ligne, mais ne protège pas rétroactivement la copie volée.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
failures- Compteur calculé sur une fenêtre de temps, pas événement individuel. Conserver les lignes sources et la durée du regroupement.
hash_case- Le scénario distingue une recherche hors ligne : aucun journal réseau du service ne permet de compter ces essais.
Deux distributions qui demandent des conclusions différentes
JournalAgrégats synthétiques sur cinq minutes.
window=10:00 actor=u1 sources=1 failures=180 successes=0 outcome=rate_limited
window=10:00 actor=u2 sources=1 failures=4 successes=1 outcome=allowed
window=10:05 actor=u3 sources=48 failures=192 successes=1 outcome=allowed
hash_case artifact=password_hashes network_auth_events=nonePréparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Microsoft Entra ID — Sign-in logs
- Où les trouver
- Centre d’administration Entra → Entra ID → Monitoring & health → Sign-in logs. Examiner séparément les connexions interactives, non interactives et celles des applications si elles sont concernées.
- Quoi relever
- Exporter les réussites et les échecs du service exposé. Compter les tentatives par compte, adresse source et intervalle ; examiner les motifs d’échec et la limitation éventuelle.
- Accès et prérequis
- Rôle de lecture adapté, par exemple Reports Reader. Vérifier la période conservée et les exports disponibles ; une session applicative n’engendre pas nécessairement une nouvelle connexion Entra.
Windows — échecs d’ouverture de session 4625
- Où les trouver
- Dans le journal Sécurité de la machine où la connexion a été tentée ; exporter la période concernée et les machines réellement exposées.
- Quoi relever
- Pour un service Windows, relever TargetUserName, IpAddress, LogonType, Status et SubStatus. Comparer les refus à une connexion réussie sur la même cible.
- Accès et prérequis
- L’audit des échecs doit être actif. Status et SubStatus distinguent notamment des motifs d’échec : ne pas compter chaque refus comme un mauvais mot de passe.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- àGroupePawn Storm
Noms et appellations : APT28 / Fancy Bear
Des messageries ciblées pour l’espionnage
Trend Micro décrit des campagnes qui cherchent à voler des identifiants, notamment dans des organisations de défense. Parmi les méthodes du groupe figurent les sites piégés et l’abus d’autorisations OAuth pour accéder aux comptes.
Ce qu’établit la source. Activités attribuées à Pawn Storm par Trend Micro. Le rapport récapitule plusieurs opérations et plusieurs méthodes ; elles ne constituent pas une seule chaîne d’attaque.
Consulter le rapport Probing Pawn Storm: Cyberespionage Campaign Through Scanning, Credential Phishing and MoreTrend Micro · Publié le
- àGroupeMidnight Blizzard
Noms et appellations : NOBELIUM / APT29
Quelques mots de passe essayés sur plusieurs comptes
Une attaque par pulvérisation de mots de passe atteint un ancien compte de test sans MFA. Microsoft décrit ensuite des autorisations OAuth détournées pour accéder à des messageries. En limitant les essais sur chaque compte, les attaquants rendent leur activité moins visible.
Ce qu’établit la source. Microsoft attribue l’intrusion à Midnight Blizzard après sa détection en janvier 2024. Les premiers accès remontent à novembre 2023.
Consulter le rapport Midnight Blizzard: Guidance for responders on nation-state attackMicrosoft · Publié le
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’aucun de ces groupes.
Si vous pensez être concerné
- Vérifiez si des tentatives ont réellement abouti, sans confondre échecs et accès.
- Remplacez les secrets faibles ou exposés et contrôlez les sessions.
- Si des empreintes de mots de passe ont été volées, traitez l’incident de données et les secrets réutilisés.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Brute Force — attack.mitre.org
- OWASP — Password Storage — cheatsheetseries.owasp.org
- OWASP — Authentication — cheatsheetseries.owasp.org
