Comptes et authentification
Particuliers et entreprisesAttaque par force brute
Brute-force attack
De nombreuses combinaisons sont essayées pour découvrir un secret.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
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
La force brute consiste à essayer des possibilités jusqu’à trouver celle qui fonctionne. Elle peut être ciblée par des listes de mots probables plutôt qu’énumérer toutes les combinaisons. Une phrase de passe longue et unique augmente fortement l’effort nécessaire. Les limitations de tentatives protègent les essais en ligne ; elles ne freinent pas les tests effectués sur une copie de données déjà volée.
- 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.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous 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 origine sans permettre un blocage permanent de la victime. Protégez aussi les empreintes stockées : un attaquant qui les copie teste ses candidats hors ligne.
Un blocage après plusieurs échecs ne protège pas contre le cassage hors ligne d’un fichier de mots de passe volé.
À 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 ?
Choisissez votre réponse et expliquez pourquoi avant de lire 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
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
De nombreux échecs précèdent une connexion réussie
Dans l’extrait, u1 reçoit 180 tentatives bloquées. Le cas u3 est différent : 48 sources totalisent 192 échecs, puis une connexion réussit. Cette connexion peut appartenir à l’attaquant, mais aussi au titulaire qui se connecte pendant les essais. L’appareil utilisé et les actions de la session permettent de départager ces possibilités.
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.
Éléments à croiser
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é.
Limites de l’interprétation
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
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- 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 ?
Formulez votre décision et l’élément qui la justifie 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
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-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
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des 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
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- àGroupePawn Storm
Repères de nommage : APT28 / Fancy Bear
Des messageries ciblées pour l’espionnage
Trend Micro suit des campagnes de vol d’identifiants visant notamment des organisations de défense. Le groupe exploite aussi des sites piégés et l’abus d’autorisations OAuth dans son éventail de méthodes d’accès 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
Repères de nommage : NOBELIUM / APT29
Quelques mots de passe essayés sur plusieurs comptes
Une attaque par pulvérisation de mots de passe compromet un ancien compte de test sans MFA. Microsoft décrit ensuite l’abus d’applications OAuth pour accéder à des messageries. Le faible nombre d’essais par compte contribue à la discrétion de l’attaque.
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
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à 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 qualifier votre situation et être orienté : 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
