Sécurité Active Directory – Comment détecter les attaques par brute force dans un domaine ?

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.

Nous allons plus précisément étudier les évènements qui sont générés par défaut dans un Active Directory lors d'une attaque par brute force, mais aussi comment et pourquoi il est nécessaire d'améliorer la stratégie d'audit par défaut de l'Active Directory pour une meilleure détection.

Enfin, je vous partagerai quelques éléments et requêtes permettant détecter et visualiser une attaque par brute force dans un SIEM tel qu'ELK (ElasticSearch, Logstash, Kibana).

Si vous souhaitez en savoir plus sur ce qu'est une attaque par brute force avant de commencer la lecture de cet article, je vous oriente vers notre article à ce sujet :

• Qu'est-ce qu'une attaque par brute force ?

II. Les évènements générés lors d'une brute force

A. Les journaux par défaut de l’Active Directory

Commençons par nous intéresser aux évènements générés par l'Active Directory lors de l'exécution de telles attaques dans une configuration par défaut.

Au sein d’un lab composé d’un Active Directory en configuration par défaut, d’une machine d’attaque sous Kali Linux et d’un SIEM ELK chargé de collecter les journaux d’évènements, j’ai commencé par opéré une attaque par brute force classique sur le service Kerberos de mon Active Directory, puis 5 minutes plus tard via SMB, et enfin 5 minutes plus tard via LDAP.

Dans ma configuration actuelle, je remonte sur mon ELK tous les évènements du journal “security” ("Sécurité"), c’est ici que l’on s’attend à pouvoir découvrir un évènement de sécurité relatif à notre domaine.

Chaque opération a ciblé 2500 comptes utilisateurs (dont certains valides) et 2 mots de passe (dont certains valides aussi) :

# 21:15 - password spraying Kerberos
kerbrute passwordspray -d it-connect.tech --dc 192.168.56.102 list_domainUsers.txt 'Abcd1234!!'
kerbrute passwordspray -d it-connect.tech --dc 192.168.56.102 list_domainUsers.txt 'Abcd1234!'

# 21:20 - Brute force service SMB
netexec smb 192.168.56.102 -u list_domainUsers.txt -p /tmp/2passwords.txt -d it-connect.tech

# 21:25 - Brute force service SMB
hydra -L list_domainUsers.txt -P /tmp/2passwords.txt 192.168.56.102 ldap2

Voici les journaux récupérés immédiatement après l’attaque via le service Kerberos :

Il semble que ne soient journalisées uniquement les tentatives d’authentification réussies (plus précisément les demandes de TGT). Voici les journaux récupérés immédiatement après l’attaque via le service SMB :

Aucun nouvel évènement n’est présent alors que l’attaquant vient d’opérer plus de 5 000 tentatives d’authentification directement sur l’Active Directory. Le résultat sera le même côté LDAP.

Dans le cas où l’on regarderait uniquement nos journaux via le SIEM ELK, nous pourrions nous attendre en toute logique à voir 3 * (2500*2) = 15 000 évènements (au moins) sur le quart d’heure de réalisation des tests, cependant :

Il n’en est rien. Dans mon ELK, à peine une soixantaine d’évènements de sécurité sont journalisés.

On peut donc affirmer que les journaux de sécurité par défaut d’un Active Directory Windows ne permettent pas d’identifier une attaque par brute force. Les demandes réussies de TGT sur le service Kerberos sont bien journalisées, mais en dehors de cela concernant les évènements du journal “security”, nous sommes parfaitement à l’aveugle. Il va falloir une fois de plus suivre les bonnes pratiques des guides de sécurité !

Pour être tout à fait précis, lors de la réalisation de l’attaque par brute force sur le service SMB, des logs sont bien produits et permettent effectivement d’identifier une potentielle attaque, néanmoins ces logs sont bien cachés et pas vraiment surveillés la plupart du temps. Il s’agit des logs du service SMB du serveur qui héberge le service (qui peut donc être différent de l’Active Directory, même si les tentatives d’authentification concernent des utilisateurs du domaine) :

On peut ici voir plusieurs évènements relatifs à des tentatives d’authentification. Ils sont assez peu précis puisque le login de l’utilisateur concerné n’est pas journalisé. Ces évènements sont journalisés localement par le service SMB, et non directement par le service Active Directory.

Dans les faits, les journaux des services SMB des serveurs du domaine sont loin d’être les premiers auxquels on va s’intéresser. Dans la configuration par défaut des principaux agents de collecte de logs, ces journaux ne sont pas collectés pour centralisation.

Cela signifie que, dans le cas d’une attaque ciblant le service SMB d’un serveur intégré au domaine (hors contrôleur de domaine), le service SMB de ce serveur journalisera localement les évènements de tentative d’authentification, mais l’Active Directory, qui est l’autorité à qui est déléguée l’authentification, ne journalisera lui rien du tout à cause de sa configuration par défaut. Autrement dit, les journaux produits par le service SMB restent sur le serveur qui héberge le service SMB. Les potentiels journaux que l’on pourrait s’attendre à voir concernant l’Active Directory et son rôle d’autorité d’authentification (ici dans le cadre du NTLM), ne sont toujours pas produits.

L'authentification NTLM est un protocole d'authentification challenge/response utilisé pour authentifier un utilisateur sans envoyer son mot de passe sur le réseau. Lorsque vous vous authentifiez auprès d’un ordinateur intégré au domaine (qui n'est pas un contrôleur de domaine), ce serveur délègue la vérification de l’identité au contrôleur de domaine. Dans le cas de NTLM, il transmet les informations de challenge/réponse au contrôleur de domaine pour validation.

Dans un tel cas et si l’attaquant a connaissance de cette configuration, il peut donc cibler un service SMB d’un serveur autre que l’Active Directory mais quand même intégré au domaine. Son attaque produira des journaux locaux concernant le service SMB (non surveillés), mais les demandes de validation de l’identité de l’utilisateur que le serveur visé transmettra à l’AD ne seront eux pas journalisés.

B. Durcissement de la stratégie d’audit

Heureusement pour nous, il existe un moyen de faire en sorte que l’Active Directory génère les évènements relatifs aux tentatives d’authentification (réussies ou non). Il faut pour cela paramétrer la stratégie d’audit selon les bonnes pratiques de sécurité, c'est-à-dire tel que recommandé par les guides de l’ANSSI ou du CIS :

Ces recommandations visent à rendre les logs plus complets en activant la journalisation d'évènements de sécurité d'importance. Concernant l’audit de l’authentification, nous allons nous rendre dans l’éditeur de gestion des stratégies de groupe et plus précisément dans la GPO qui s’applique aux contrôleurs de domaine. Pour l’exemple, j’opère directement sur la GPO “Default Domain Controllers Policy”.

Il faut ensuite aller dans “Configuration ordinateur > Paramètres Windows > Configuration avancée de la stratégie d’audit > Stratégie d’audit > Connexion de compte” :

Il faut ici sélectionner la stratégie “Auditeur le service d’authentification Kerberos” et activer “Succès” et “Echecs” :

Comme nous l’avons vu, cela permet d’aller plus loin que la configuration par défaut qui ne journalise que les succès. Il faut également sélectionner la stratégie “Auditer la validation des informations d’identification” et également cocher “Succès” et “Échec” :

Cette seconde configuration nous permettra de journaliser les succès et échecs d’authentification passant par NTLM, pour lequel l’Active Directory est l’autorité de référence au sein d’un domaine.

Ainsi, même si l’on tente de s’authentifier sur le service SMB d’un serveur intégré au domaine (autre que l’Active Directory), celui-ci passera par l’Active Directory afin de valider l’identité de l’utilisateur. Celui-ci pourra alors journaliser cette demande de validation d’identité. Suite à ces modifications, il faut attendre que la GPO se déploie sur nos contrôleurs de domaine ou forcer la mise à jour via “gpupdate /force” :

Dès lors, voici à quoi ressemblent les journaux d’évènements de sécurité de l’Active Directory lors d’une attaque par brute force sur le service SMB (ciblant lui-même ou une machine intégrée au domaine) :

Voilà qui est plus intéressant ! Si l’on regarde plus en détail le contenu de l’évènement dans l’Observateur d’évènement, nous pouvons comprendre qu’il s’agit bien d’évènements en relation avec une tentative échouée d’authentification :

Bon, les détails techniques peuvent certes manquer (adresse IP source). Mais le nombre d’évènements et surtout leur présence dans le journal “Security” nous permettent déjà d’envisager la détection d’une telle attaque.

L’évènement ID 4776 (The domain controller attempted to validate the credentials for an account) apparaît lorsqu’un ordinateur du domaine tente de valider les identifiants qu’un utilisateur lui a envoyés. On peut notamment s’intéresser au code d’erreur pour comprendre le résultat précis de cette demande de validation :

Dans l’exemple ci-dessous, le code d’erreur nous apprend qu’il s’agit d’un compte existant, mais pour lequel le mot de passe saisi est incorrect :

Voici à présent les évènements que l’on peut visualiser lors d’une attaque par brute force sur le service Kerberos lorsque la stratégie d’audit est correctement configurée :

Ici aussi, nous comprenons rapidement qu’il s’agit d’un échec d’authentification si l’on regarde le contenu de l'évènement, le message et le type d’entrée :

L’évènement 4771 (Kerberos pre-authentication failed) est journalisé lorsqu’un utilisateur qui tente de s’authentifier sur le service Kerberos échoue à le faire (compte expiré, mauvais mots de passe, mauvaise version du protocole, etc.). On remarquera à nouveau le code d’échec (“0x18”) qui indique encore une fois un mauvais mot de passe saisi :

Concernant une attaque via le protocole LDAP, l’authentification repose également sur NTLM dans un environnement Active Directory classique, les évènements journalisés sont donc les mêmes qu’une attaque sur le protocole SMB (4776). À noter qu’il en est de même pour d’autres services dont l’authentification repose sur l’Active Directory si Kerberos n’est pas celui utilisé (MSSQL, RDP, etc.).

C. Surveiller le verrouillage des comptes utilisateur

À défaut d’avoir une stratégie d’audit correctement configurée au moment de la réalisation de l’attaque, notamment si vous êtes dans un contexte d’analyse “post mortem” (c’est-à-dire après constatation de l’incident), nous pouvons tenter de nous baser sur l’évènement relatif au verrouillage d’un compte utilisateur.

Dans un environnement Active Directory, la valeur par défaut du seuil de verrouillage d'un compte est 0 tentative échouée. Cette configuration signifie que le verrouillage de compte est désactivé. Il est fortement recommandé de mettre en place une valeur différente de 0, mais tout de même raisonnablement élevée afin d’éviter que l’utilisateur ne se bloque lui-même.

À titre d’exemple, les recommandations de Microsoft intégrées au Microsoft Security Compliance Toolkit proposent un seuil de 10 tentatives.

Pour en savoir plus sur la stratégie de verrouillage des comptes, je vous oriente vers notre article à ce sujet :

• IT-Connect - Active Directory et le verrouillage des comptes

Dans le cas où un seuil de verrouillage des comptes est effectivement en place, il est possible qu’une attaque par brute force entraîne le verrouillage temporaire des comptes ciblés. Cela va alors générer des évènements tels que ceux-ci (dans la configuration par défaut des stratégies d’audit) :

En surveillant activement ce type d’évènement et surtout leur nombre d’apparitions dans le temps, il devient possible de détecter une attaque par brute force.

Attention, dans les faits, si l’attaquant possède déjà un accès au domaine, il peut très facilement récupérer la politique de mot de passe en place (incluant le seuil de verrouillage) et calibrer son attaque pour rester en dessous du seuil de verrouillage. Cela ralentira grandement son attaque (c’est le but !), mais évitera l’apparition de tels évènements dans les journaux de sécurité.

III. Détection d'une attaque par brute force avec ELK

Bien ! Maintenant que nous en savons plus sur ce qu'est une attaque par brute force et notamment quels sont les évènements qui peuvent être générés lors d'une telle attaque (si la stratégie d’audit est bien configurée), nous allons nous intéresser aux possibilités de détection active via le SIEM ELK. J’ai réitéré mon trio d’attaque (Kerberos, LDAP, SMB) sur une période de 15 minutes :

Voilà qui est beaucoup plus parlant ! J’obtiens bien mes 15 000 évènements et peux même identifier clairement sur le graphique l’heure d’exécution de mes différentes attaques. Pour être plus précis, nous pouvons utiliser une requête KQL ciblant uniquement les évènements vus précédemment, ceux relatifs aux échecs d’authentification :

# Requête KQL qui filtre les event.code 4771 et 4776
event.provider: Microsoft-Windows-Security-Auditing and (event.code:4776 or event.code: 4771)

Sur un environnement classique avec des milliers d’utilisateurs qui se trompent parfois de mot de passe, voici le résultat que peut donner un tel filtre si une attaque par brute force à eu lieu :

Nous voyons clairement qu’au milieu des échecs d’authentification habituels assez peu nombreux, un pic de tentatives infructueuses d’authentification est présent. Enfin, nous pouvons en complément utiliser une requête KQL qui nous permet de visualiser les verrouillages des comptes :

# Requête KQL qui filtre les event.code 4771 et 4776
event.provider: Microsoft-Windows-Security-Auditing and event.code:4740

Voici alors l’effet qu’aura une attaque par brute force dans le résultat de cette requête KQL :

A 15h22, plus de 200 comptes utilisateur ont été verrouillés, ce qui apparait comme anormal au regard de l'occurrence habituelle de cet évènement. Attention toutefois, nous avons vu les limites de cette technique de détection :

• L’attaquant peut prendre connaissance du seuil de verrouillage en place et configurer son attaque pour ne pas l’atteindre.
• Le seuil de verrouillage par défaut est à 0, donc aucun événement de ce type n’apparaîtra sans un durcissement préalable de ce paramètre.

IV. Conclusion

Dans cet article, nous avons vu que les possibilités de détection d’une attaque par brute force avec la configuration par défaut de la stratégie d’audit du domaine sont limitées. Grâce aux durcissements de configuration proposés par de nombreux guides de bonnes pratiques, il est possible de journaliser chaque tentative d’authentification (en succès ou en échec) et donc de se donner la possibilité de détecter ce type d’attaque. Au travers quelques requêtes basiques dans un SIEM (ELK dans cet article), nous sommes parvenus à identifier une attaque par brute force.

Bien sûr, l’attaquant peut toujours étaler son attaque dans le temps afin de passer sous les radars (éviter un pic d’évènement dans un SIEM ou le déclenchement du seuil de verrouillage). Dès lors, son attaque sera beaucoup moins efficace, d’autant plus si des mots de passe robustes sont en place (imaginez tester 5000 mots de passe avec un ratio de 5 tentatives par compte toutes les 30 minutes).

Différents guides de l’ANSSI ont été cités dans cet article. Je vous recommande leur lecture pour aller plus loin concernant la sécurité d’un environnement Active Directory :

• ANSSI – Recommandations pour l’administration sécurisée des SI reposant sur l’Active Directory
• ANSSI – Recommandations de sécurité pour la journalisation des systèmes Microsoft Windows
• ANSSI – Points de contrôle Active Directory
• ANSSI – Recommandations relatives à l'authentification multifacteur et aux mots de passe

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !