---
title: "Kerberoasting dans Active Directory : attaque et défense"
description: "Le Kerberoasting exploite Active Directory pour craquer hors ligne les mots de passe des comptes de service. Découvrez comment fonctionne l'attaque et comment défendre votre environnement AD."
locale: "fr"
updated_at: "2026-07-30T11:52:36.362Z"
canonical: "https://www.isdecisions.com/fr/blog/active-directory/kerberoasting-active-directory"
---

# Le Kerberoasting dans Active Directory : fonctionnement et moyens de défense

_Le Kerberoasting est l'une des techniques post-compromission les plus efficaces utilisées contre Active Directory. Voici comment il fonctionne et ce que les défenseurs peuvent faire._

**Le Kerberoasting est l'une des techniques d'attaque les plus dangereuses et les plus exploitées contre Active Directory. En partant d'un simple compte utilisateur à faibles privilèges, un attaquant peut extraire le hash du mot de passe d'un compte de service et le craquer hors ligne. Aucun accès élevé n'est requis, et le contrôleur de domaine n'est plus sollicité après la demande initiale de ticket. Cet article explique le fonctionnement de l'attaque, pourquoi Active Directory y est structurellement vulnérable, et ce que les défenseurs peuvent faire pour protéger leur environnement.**

L'objectif premier des réseaux à l'ère des LAN était de faciliter la découverte et la connexion aux ressources réseau, une philosophie qui privilégiait la facilité et la rapidité de connexion. En matière de sécurité, le LAN était considéré comme un simple périmètre gardé par des identifiants utilisateur. Si vous disposiez du bon identifiant, vous étiez réputé digne de confiance.

Avec le recul plus pessimiste d'aujourd'hui, cette approche est perçue comme naïvement vulnérable aux abus. Bien sûr, le vol d'identifiants a commencé dès l'apparition d'Active Directory.

Malheureusement, les hypothèses de sécurité défaillantes allaient plus loin que la simple sous-estimation de la faiblesse des mots de passe. Active Directory était, et demeure, très permissif dans sa conception interne. Une fois qu'un attaquant a franchi le périmètre de sécurité en compromettant un compte utilisateur ordinaire, la conception ouverte de l'annuaire lui permet de progresser vers des niveaux plus profonds du système plus facilement qu'il ne le devrait.

## La faille Kerberos

La clé pour les attaquants est de trouver un point d'appui pour le [mouvement latéral](/blog/mfa/how-to-prevent-lateral-movement-with-mfa) : d'un compte utilisateur à faibles privilèges dont ils ont compromis les identifiants, vers un compte à privilèges plus élevés et aux pouvoirs étendus. Le Kerberoasting, documenté pour la première fois lors d'une présentation de recherche en 2014 par le chercheur Tim Medin, est l'une des techniques les plus exploitées et les mieux connues pour y parvenir.

En théorie, la cible pourrait être n'importe quel compte à hauts privilèges, mais les plus convoités sont généralement les comptes de service.

Les comptes de service sont des comptes machine non humains utilisés pour exécuter des applications Active Directory en arrière-plan : SQL Server, Exchange, IIS Web Server ou une application de sauvegarde, par exemple. Cet accès en fait des cibles évidentes.

Si un attaquant parvient à prendre le contrôle d'un compte de service, il peut accéder aux applications et les contrôler directement. Mieux encore, parce que les comptes de service sont des identités machine, ils ne font souvent pas l'objet du même niveau de surveillance que les identités humaines, ce qui en fait un angle mort en matière de sécurité.

## Reconnaissance et exploitation

Le ciblage des comptes de service dans le Kerberoasting est un processus en deux étapes, dont la première est la reconnaissance et la découverte à l'aide d'outils de hacking et de requêtes LDAP permettant de lister les comptes de service disposant d'un attribut Service Principal Name (SPN) enregistré. Stockés dans Active Directory, les SPN sont des étiquettes permettant au protocole d'authentification Kerberos d'identifier et d'authentifier les services réseau auxquels les utilisateurs tentent d'accéder.

Cette énumération des SPN est utile pour plusieurs raisons. Premièrement, parce que seuls les comptes de service possèdent des SPN, elle permet aux attaquants d'identifier ces comptes parmi des milliers de comptes utilisateur à faible valeur. Deuxièmement, elle fournit la chaîne précise nécessaire pour lancer une attaque Kerberoasting à grande échelle sur les comptes de service auxquels ont été accordés des droits d'administrateur de domaine.

Cela souligne une faiblesse plus large d'Active Directory : n'importe quel compte utilisateur, même à faibles privilèges, peut exécuter ces requêtes LDAP. On comprend pourquoi les attaquants commencent par des comptes à faible valeur ; aussi limités que soient ses privilèges, dans Active Directory, n'importe quel compte peut être exploité comme point faible.

Après avoir identifié un SPN de valeur, la deuxième étape du Kerberoasting consiste à demander un Ticket-Granting Ticket (TGT) auprès du Ticket Granting Service (TGS) exécuté sur le contrôleur de domaine. Cet aspect d'Active Directory est une fonctionnalité de commodité, similaire dans son principe au fonctionnement des tokens persistants : un utilisateur s'authentifie auprès d'Active Directory, après quoi le TGT chiffré émis par le Key Distribution Center (KDC) lui permet de continuer à accéder à une application sans avoir à se réauthentifier constamment.

## Le bénéfice du Kerberoasting

Le TGT capturé étant chiffré à l'aide du hash du mot de passe du compte de service, les attaquants ont encore du travail devant eux. Ils doivent récupérer le ticket hors ligne et tenter de le craquer avec un outil dédié tel que Hashcat. La durée de cette opération dépend de la longueur et de la complexité du mot de passe ainsi que de l'algorithme de chiffrement utilisé : RC4_HMAC est faible et craquable rapidement, tandis qu'AES-256 rend le craquage hors ligne considérablement plus difficile.

En théorie, c'est à cette étape que le Kerberoasting devrait être stoppé, un mot de passe robuste et un algorithme de chiffrement fort constituant les barrières. Malheureusement, dans des conditions réelles, c'est souvent loin d'être le cas, ce qui explique pourquoi la technique est devenue si populaire dans le cadre des [attaques par ransomware](/blog/securite-des-donnees/comment-proteger-active-directory-contre-ransomwares).

La suite dépend des tickets que les attaquants ont réussi à craquer. Mais il leur suffit de craquer le mot de passe d'une seule application importante pour en prendre le contrôle et celui de ses données.

## Comment protéger Active Directory contre le Kerberoasting

On est tenté d'attribuer cette technique uniquement aux faiblesses d'Active Directory et de Kerberos. C'est vrai dans une certaine mesure. La conception sécuritaire accorde trop d'importance à la sécurité périmétrique fondée sur des identifiants par mots de passe, ce qui la rend vulnérable aux attaquants qui franchissent cette couche.

Mais Active Directory peut être renforcé si les défenseurs prennent le temps de le faire. La mise en œuvre commence généralement par s'assurer que tous les comptes appliquent des politiques de mots de passe robustes. Les équipes IT doivent également appliquer l'[authentification multifacteur (MFA)](/userlock/fonctionnalites/authentification-multi-facteurs-active-directory) aux comptes utilisateurs, ainsi qu'une forme de surveillance en temps réel de l'activité des accès pour détecter les schémas d'accès inhabituels.

Pour les comptes de service, l'erreur humaine peut être éliminée en s'assurant qu'ils sont tous des Group Managed Service Accounts (GMSA) plutôt que gérés manuellement. Ces derniers appliquent automatiquement des politiques de mots de passe robustes et une rotation des mots de passe. Les demandes de tickets Kerberos doivent être surveillées pour repérer des schémas inhabituels, tels que des pics dans le nombre de demandes.

Comme Microsoft le recommande depuis un certain temps, les organisations qui soupçonnent utiliser encore RC4_HMAC sur leur réseau doivent prioritairement migrer vers AES-128 ou AES-256 dès que possible.

## Pourquoi l'architecture de votre stack de sécurité est importante

Toutes les solutions de sécurité tierces n'abordent pas Active Directory de la même façon. Pour la défense contre le Kerberoasting en particulier, il vaut la peine de comprendre la relation architecturale entre un outil et le contrôleur de domaine avant de faire un choix.

Certains outils se déploient directement sur les contrôleurs de domaine ou s'insèrent dans la chaîne d'authentification Kerberos. L'attrait réside dans la visibilité et la couverture : être proche de l'authentification signifie voir et contrôler tout ce qui s'y passe. L'inconvénient est que cela concentre le rayon d'impact. Un outil positionné à l'intérieur de la chaîne d'authentification devient une cible. S'il est compromis, l'attaquant hérite de cette position, ce qui pourrait signifier hériter de l'accès à l'infrastructure d'authentification elle-même.

Pour certains environnements, une conception plus défendable est une solution qui se situe en dehors de la chaîne d'authentification. Elle communique avec Active Directory en lisant les attributs des utilisateurs, les appartenances aux groupes et les conditions d'accès via LDAP, et applique les politiques au niveau de la couche de session plutôt qu'en interceptant l'émission de tickets. La compromission de l'outil ne se répercute pas sur l'infrastructure Kerberos. La chaîne d'authentification continue de fonctionner et le rayon d'impact est contenu.

Des solutions telles que UserLock sont conçues de cette façon. [UserLock](/userlock/) communique avec les contrôleurs de domaine via LDAP pour lire les données relatives aux politiques, tandis que l'agent Desktop applique les contrôles d'accès au niveau de la couche d'ouverture de session Windows. Aucun de ces composants ne s'insère dans le flux d'émission de tickets Kerberos, ce qui signifie que UserLock ne constitue pas un point de défaillance unique pour l'authentification.

C'est un choix architectural délibéré, et non une limitation. La valeur sécuritaire d'une solution tierce ne devrait pas avoir pour coût la création d'un nouveau vecteur d'attaque. Pour les organisations qui évaluent des options pour renforcer leur environnement AD, ce compromis mérite d'être pesé explicitement.

## Ce que le Kerberoasting nous révèle

Les reportages en cybersécurité tendent à se concentrer davantage sur la façon dont les attaquants pénètrent dans les réseaux que sur les techniques qu'ils déploient ensuite. C'est presque comme si le mouvement latéral était ignoré.

Dans le cas d'Active Directory, c'est la mauvaise approche. Compte tenu de la vulnérabilité bien connue des identifiants non protégés par des facteurs d'authentification supplémentaires, ce sont les techniques et outils de second niveau utilisés dans des attaques comme le Kerberoasting qui rendent la compromission initiale si utile.

La conclusion est que défendre Active Directory, c'est sécuriser l'ensemble.

Aucun élément, interne ou externe, ne doit être négligé. Cela commence par le déploiement d'une authentification et de contrôles d'accès robustes : la MFA, l'[authentification unique (SSO)](/userlock/fonctionnalites/single-sign-on-sso-active-directory) et la visibilité sur les schémas d'accès pour tous les comptes. Mais cela va au-delà, jusqu'aux couches plus profondes d'Active Directory.

L'âge et les hypothèses de conception d'Active Directory signifient qu'il lui manque aujourd'hui de nombreux contrôles modernes qui rendraient les attaques beaucoup plus difficiles. Y remédier n'est pas simplement une question d'ajouter une couche de la MFA.

Active Directory stocke les événements et les données de journalisation d'une façon qui rend la découverte et le triage des schémas d'accès ou des requêtes inhabituels particulièrement fastidieux.** Dans quelle mesure est-il facile de détecter qu'un attaquant a déployé le Kerberoasting ? Sans outil tiers pour traiter ces journaux, la tâche est loin d'être aisée.** Les équipes de sécurité doivent trier laborieusement un volume important de bruit.

C'est ce manque de visibilité qui a rendu le Kerberoasting si populaire.

**C'est l'une des autres ironies déplaisantes auxquelles se heurte quiconque tente de défendre Active Directory : les attaquants peuvent finir par en savoir plus sur le réseau de leur victime que ses propres défenseurs.**

Et pourtant, moderniser la sécurité d'Active Directory est à portée de main avec les bons outils. Le principe essentiel est simple : tenir compte des avertissements.