L’essentiel sur les attaques brute force : principes, types d’attaques et mesures de protection
Sommaire
I. Présentation
Dans cet article, nous allons nous intéresser aux attaques par brute force qui peuvent être menées sur les comptes utilisateurs d'un Active Directory, d’une application web ou de tout autre service réseau.
Nous verrons en quoi consistent ces attaques et quel est le but recherché par l'attaquant, nous parcourrons les différents types de brute force qui existent et peuvent être exploités lors d'une cyberattaque en fonction de l’objectif et du niveau de discrétion recherchés. Nous aborderons enfin les principales mesures à prendre pour s'en protéger.
II. Qu'est-ce qu'une attaque par brute force ?
Une attaque par brute force, appelée aussi "bruteforce attack" ou attaque par force brute, consiste pour un attaquant à tenter d’obtenir les identifiants d’un compte utilisateur en essayant une multitude de mots de passe sur un même login. Une telle attaque se caractérise surtout par le nombre d’essais que l’attaquant va réaliser afin de tenter de compromettre un compte. Le plus souvent, il va utiliser des dictionnaires de mots de passe (appelés “wordlist”), composés de plusieurs milliers ou millions de lignes, chacune étant un mot de passe potentiel.
Dans le cadre d'une cyberattaque, l'attaquant va utiliser le brute force afin de compromettre facilement des comptes utilisateurs qui possèdent un mot de passe faible. Cette opération peut être menée en tant que première étape d'une intrusion (par exemple, sur les services de l'entreprise exposés sur Internet) ou alors en visant des services internes à l'entreprise après une première compromission.
Un “identifiant” étant composé d’un login (nom d'utilisateur) et d’un mot de passe, le fait de connaître le login est déjà une information intéressante pour un attaquant, puisqu’il va déjà être en possession de 50% de l’information nécessaire à la compromission d’un compte.
Plus concrètement pour compromettre le compte ayant le login "admin", un attaquant va essayer le couple “admin : password”, puis “admin : admin”, puis “admin : superMDP123!”, etc. Pour qu’une attaque digne de ce nom soit menée, l’attaquant automatisera le processus grâce à des programmes conçus pour ce genre d’opérations et adaptés au contexte (application web, service SSH, SMB, etc.), lui permettant de réitérer son opération d'authentification rapidement et sans effort.
Imaginez avoir en énorme trousseau de clés en main et une serrure verrouillée en face de vous. Le fait de tester toutes les clés une à une est précisément la définition d'un brute force.
Certains outils permettent aujourd’hui de tenter des milliers de combinaisons par seconde depuis un simple ordinateur. Parmi ces outils, on peut notamment citer “hydra”, “netexec” ou “metasploit”.
Le brute force est une technique d’attaque connue et fréquemment utilisée. Elle est référencée dans le framework MITRE ATT&CK sous le TTP T1110 :
Cette page vous permettra notamment de trouver de nombreux cas réels d’utilisation du brute force dans des attaques étatiques ou d’envergures :
Par exemple, les attaques par brute force font partie de la méthodologie du groupe APT29 (groupe d’espionnage affilié à la Russie et ciblant les pays de l’OTAN) d’après le framework MITRE ATT&CK :
III. Les différents types d’attaques par brute force
A. Le brute force "classique"
La plupart du temps, une attaque par brute force va cibler plusieurs comptes utilisateur, cela afin de maximiser les chances de trouver un compte ayant un mot de passe faible. L’attaquant disposera alors d’une wordlist de login (vérifiés ou potentiels) et d’une wordlist de mots de passe. Il va donc tenter chaque combinaison “login : mot de passe” :
Dans les faits, les attaque par brute force peuvent cibler tout service ou application utilisant le login et le mot de passe comme facteurs d’authentification et étant insuffisamment protégé. Cela concerna donc aussi bien les applications web et leur page de login classique, les services SSH ou encore au sein d’un système d’information l’Active Directory, qui propose à lui seul de nombreux services permettant une authentification (Kerberos, SMB, RPC, LDAP, WinRM, RDP, etc.) et joue, entre autres, le rôle d'autorité d'authentification au sein d'un domaine.
Il faut ici se représenter le nombre de tentatives d’authentification que génère ce type d’attaque. Si je dispose d’une liste de 100 logins sur lesquels je souhaite tester 20 000 mots de passe. Cela signifie que mon attaque va générer 2 millions de tentatives d’authentification.
Pour être plus précis, ce type de brute force est décrit le framework MITRE ATT&CK en tant que "Bruteforce: password guessing", car l'on tente de deviner le mot de passe d'un utilisateur de façon agressive :
B. Le brute force ciblé
Il existe également des cas où l’attaquant va vouloir cibler un compte bien identifié, on parle alors d’attaque ciblée. Ce cas de figure s’observe notamment quand l’attaquant a identifié un compte particulièrement sensible ou hautement privilégié.
Également, ces attaques sont utilisées lorsque les services ou applications utilisent encore un compte d’administration par défaut. Par exemple, le compte “admin” d’une application web qui est le premier compte existant sur toutes les instances de celle-ci. On peut également mentionner le compte “administrateur/administrator” dans les environnements Windows (local ou au niveau du domaine).
Lors d’une attaque par brute force ciblée, l’attaquant ne va cibler qu’un seul (ou un nombre réduit) compte utilisateur, mais toujours utiliser un dictionnaire de mot de passe. Il mise alors sur le fait que ce compte précis possède un mot de passe faible, présent dans sa wordlist :
Ce type d’attaque génère naturellement moins de requêtes (cela dépend toujours du dictionnaire de mot de passe utilisé), mais n’en est pas moins efficace si le compte ciblé possède effectivement un mot de passe faible. Voici la démonstration d’une attaque par brute force ciblée sur un service SMB dans un environnement Windows Active Directory, le compte ciblé est toujours le même “IT-CONNCET.TECH\KATY_CRAFT”, mais le mot de passe change à chaque essai :
Comme vous le voyez dans cet exemple, l’outil utilisé va tenter plusieurs mots de passe et cibler le compte “IT-CONNECT.TECH\KATY_CRAFT”, jusqu’à trouver la bonne combinaison.
C. Le password spraying
Un troisième type d’attaque par brute force existe et est notamment utilisée dans le cadre des intrusions en environnement Active Directory : le password spraying.
Cette attaque consiste à tenter de s’authentifier sur de multiples comptes à l’aide d’un seul mot de passe (ou une liste très réduite de mots de passe). Le cas le plus parlant est celui où l’attaquant parvient à obtenir le fameux “premier mot de passe par défaut” qu’un administrateur peut assigner à chaque nouvel utilisateur et qu’il doit changer au plus vite, un mot de passe en général très complexe tel que “Bienvenue01.” ou “ChangezMoi!”.
En tombant sur de tels mots de passe, un attaquant peut se dire que d’autres comptes, nouvellement créés ou jamais utilisés, ont également ce mot de passe, il va donc tenter de s’authentifier sur chaque compte de l’Active Directory avec celui-ci.
Pour un attaquant, le password spraying possède un grand avantage : il évite le blocage de compte.
En effet, par défaut, certains mécanismes sont présents en environnement Active Directoy (et aussi sur certains services et applications web) et consistent à verrouiller temporairement un compte utilisateur ayant subi de trop nombreuses tentatives d’authentification infructueuses. Dès lors, les attaques de type brute force classique vont avoir pour effet de bloquer tous les comptes, ce qui bloquera l'attaque, mais perturbera les utilisateurs, et donc lèvera l’alerte.
Via le password spraying, aucun risque de blocage. Cette opération va donc utiliser un dictionnaire d’utilisateurs là où l’attaque par brute force classique va utiliser un dictionnaire de mots de passe.
Pour une description plus formelle, je vous oriente vers le TTP du MITRE dédié à ce type d’attaque :
D. Autres techniques dérivées
Bien sûr, d’autres méthodologies plus subtiles existent dans ce contexte des attaques par brute force. Il existe, par exemple, des listes de login “communs” qui sont susceptibles d’être présents sur tous les gros Active Directory d’entreprise. Un ensemble de listes que j’utilise fréquemment et qui donne de bons résultats est situé sur ce dépôt Github :
Si vous avez déjà travaillé sur de gros Active Directory, il y a fort à parier que des comptes avec des logins tels que ceux-ci existent dans votre Active Directory :
- svc-backup
- ldapsvc
- formateur
- accueil
- imprimante
- scan
- etc.
Dès lors, et sans connaissance d’aucun login valide, un attaquant peut utiliser ce genre de dictionnaire pour tenter des attaques en “user as pass”, c’est-à-dire ciblant des comptes qui ont un login “commun” ainsi qu’un mot de passe égal à leur login (exemple “scan:scan”).
Dans ces cas de figure, l’attaquant tente un mot de passe par login également, mais avec un mot de passe “différent” (car dépendant du login utilisé).
Cela peut paraître totalement absurde, mais c’est loin d’être rare et c’est généralement un moyen très rapide et simple d’obtenir un premier accès authentifié à un Active Directory. On peut également retrouver ce type d’opérations dans un contexte web visant des services et applications/frameworks connus. Il existe, par exemple, des listes de couples login/mot de passe connus pour l’accès à un Tomcat Manager qui serait un peu trop exposé, ou d'autres contenant des identifiants fréquemment utilisés pour les services SSH (“root:root”, “root:toor”, etc.)
IV. Où l’attaquant trouve-t-il des mots de passe ?
On peut naturellement se poser la question de la provenance des dictionnaires de mots de passe utilisés par les attaquants lors d’un brute force. Comment l’attaquant choisit les mots de passe qu’il va tenter ?
Nous avons vu qu'une attaque par brute force, l’attaquant se constitue donc une liste de logins à partir de différentes sources, puis il utilisera des dictionnaires de mots de passe déjà constitués. Ces dictionnaires de mots de passe sont la plupart du temps récupérés publiquement. Il existe des dépôts GitHub publics qui référencent de nombreuses wordlist, la plupart étant issues :
- D’un travail de référencement des mots de passe par défaut d’application web, d’équipements en tout genre (switch, routeur) ou de services (mssql, mysql, etc.).
- De fuites de données dont le contenu finit par être publié sur Internet (cas de l’entreprise Rockyou, dont la fuite de données à entrainé la création d'une wordlist contenant 14 344 391 mots de passe).
Voici, en exemple, l’un des dépôt GitHub les plus connus :
D'autres sources de liste de mots de passe existent, dont certaines totalement illégales. On peut notamment mentionner les sites qui proposent l'achat du contenu des fuites de données récentes.
Pour des attaques plus précises, l’attaquant peut lui-même construire sa propre wordlist en fonction de son contexte d’attaque. Il utilisera alors une base de mots probables (nom de l’entreprise, nom et numéro de département) ainsi que des outils comme "hashcat" ou "johntheripper", qui permettent de construire des dérivés de mots de passe ("IT-Connect" deviendra "IT-C0nnect", "IT-Connect01!", "ItConnect2024!", etc.) à partir d’une liste initiale. Voici un exemple :
V. Comment se protéger d'une attaque par brute force ?
A. Politique de mot de passe
La première et principale mesure à prendre afin de se protéger des attaques par bruteforce est de renforcer la robustesse de tous les mots de passe. Il convient de mettre en place une politique de mot de passe robuste afin de limiter les chances de succès d’une attaque par brute force basée sur des mots de passe triviaux. Plus les mots de passe sont longs et aléatoires, moins un attaquant aura de chance de les découvrir via ce type d’attaque.
Je vous oriente vers le guide de l’ANSSI sur le sujet pour définir une politique de mot de passe efficace :
- ANSSI - Recommandations relatives à l'authentification multifacteur et aux mots de passe
- Active Directory : comment configurer une stratégie de mots de passe affinée ?
- Utiliser des passphrases à la place des mots de passe
En plus des éléments habituels que sont la longueur, la complexité et le nombre d’alphabets utilisés, la politique doit aussi s’assurer que, dans son mot de passe, l’utilisateur n’utilise pas de mots issus d’informations “publiques” (son nom, nom d’un proche, nom de l’entreprise, d’un projet, région, lieu de vacances de l’année dernière…). Pour cela, différentes techniques et outils existent en fonction des contextes. On peut notamment citer :
- Azure AD Password Protection : IT-Connect - Active Directory : configuration d’Azure AD Password Protection on-premise
- L’outil Specops Password Policy : IT-Connect - Active Directory : améliorez la gestion des mots de passe avec Specops Password Policy
- Il peut aussi être envisagé des contrôles d’entropie, notamment dans le cadre d’application web.
Attention, il ne faut pas oublier que la politique de mot de passe doit être appliquée à la création d’un compte, mais aussi lors des phases de changement de mot de passe.
B. Politique de verrouillage/quota
Nous avons vu que la politique de verrouillage a aussi son importance. Celle-ci permet de définir le seuil de verrouillage d’un compte, mais aussi la durée du verrouillage et la fenêtre de temps observation.
Grâce à ces paramètres, il est possible de grandement ralentir l’opération de l’attaquant, voire de le détecter si un pic de verrouillage de compte est observé. Attention toutefois aux effets de bords (blocage d’un grand nombre de comptes utilisateur). À nouveau, je vous invite à lire notre article sur le sujet :
Ces politiques de verrouillage de compte peuvent parfois plutôt prendre la forme d’un quota ou d’un bannissement temporaire d’IP. C’est notamment le cas pour les applications web exposées sur Internet. Dans de tels cas, un attaquant pourrait très facilement exploiter la politique de verrouillage des comptes afin de bloquer temporairement ou définitivement (en fonction de sévérité de la politique) les comptes utilisateurs de la plateforme visée.
Il est, en effet, tout à fait envisageable pour un attaquant d’atteindre le seuil de verrouillage pour un compte qu’il sait existant sur l’application web visée afin de rendre indisponible l’application pour le ou les utilisateurs ciblés. Puis, de recommencer son opération de blocage dès que le verrouillage aura expiré, entraînant de fait un déni de service.
Pour empêcher cette exploitation du seuil de verrouillage, il est en général préféré de bannir l’adresse IP de l’attaquant ou de n’autoriser une même adresse IP à faire uniquement quelques requêtes d’authentification par minute.
C. Authentification multifacteurs
La troisième principale méthode pour se protéger des attaques par brute force est de faire en sorte que la connaissance du mot de passe ne suffise pas à se connecter à un compte. On y ajoutera alors un second facteur d’authentification, comme un OTP (One Time Password) envoyé par SMS, e-mail ou via une application spécialisée sur smartphone.
En fonction de la réponse du service visé, l’attaquant pourra certainement savoir si le mot de passe tenté est correct (redirection vers la phase “second facteur”), mais cette information ne sera pas suffisante pour compromettre les comptes ciblés.
Pour aller plus loin, je vous recommande vivement de consulter l’excellent document de l’ANSSI à ce sujet :
VI. Conclusion
Dans cet article, nous avons vu ce que sont les attaques par brute force et dans quel but elles sont utilisées lors d’une cyberattaque, que ce soit dans un environnement Active Directory, une application web ou tout autre service réseau dont la sécurité repose sur le couple login/mot de passe.
Nous avons également vu les principaux moyens de protection des comptes utilisateurs contre ces attaques. Pour aller plus loin, il faudrait s’intéresser au moyen de détection d’une telle attaque, mais cela dépend beaucoup de l’environnement ciblé et sera différent, qu’il s’agisse d’un service SSH isolé, d’une application web, ou d’une opération ciblant les comptes d’un Active Directory.
Dans tous les cas, un élément commun sera à utiliser : les journaux d’évènements, leur bonne configuration, leur centralisation et leur surveillance active !
N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !
Article très intéressant, merci pour ce partage!!!