Depuis le 18 juillet 2025, la société Eye Security a observé une exploitation à grande échelle de la vulnérabilité zero-day CVE-2025-53770, affectant les serveurs on-premise SharePoint. Cette faille permet l'exécution de code à distance (RCE) non authentifié via une chaîne d'exploitation sophistiquée, surnommée ToolShell.

⚠️ Ces vulnérabilités s’appliquent uniquement aux serveurs SharePoint on premise. SharePoint Online dans Microsoft 365 n’est pas impacté. ⚠️

Microsoft a confirmé l'exploitation active de cette vulnérabilité qui permet à un acteur de la menace de prendre le contrôle de serveurs sans authentification. Eye Security rapporte qu'environ 100 organisations ont déjà été compromises à l'échelle mondiale suite à l'exploitation de cette vulnérabilité.

Nos recommandations

• Application des correctifs : Microsoft a publié des mises à jour de sécurité pour SharePoint Server 2016, 2019 et Subscription Edition. 
• Rotation des clés ASP.NET : Après l'application des correctifs, il est fortement recommandé de procéder à la rotation des clés machineKey pour prévenir toute exploitation future. Microsoft partage les commandes PowerShell suivantes 

1. Générer la clé machine dans PowerShell Set-SPMachineKey -WebApplication <SPWebApplicationPipeBind>
2. Déployer la clé machine à la ferme dans PowerShell Update-SPMachineKey -WebApplication <SPWebApplicationPipeBind>
   1. Redémarrer IIS sur tous les serveurs SharePoint avec iisreset.exe

• Activation de l'AMSI : Vérifier que l’interface de scan antimalware (AMSI) est activée et configurée correctement. Si l’analyse des "HTTP Request Body" est disponible, activez "Full Mode" qui offre la protection la plus complète et déployez Microsoft Defender Antivirus sur tous les serveurs SharePoint ce qui mitigera l'exploitation de la vulnérabilité.
• Surveillance accrue : Mettre en place une surveillance renforcée des serveurs SharePoint pour détecter toute activité suspecte ou non autorisée.
• Isolation des serveurs compromis : Si un serveur est suspecté d'être compromis, il doit être immédiatement isolé du réseau pour limiter la propagation de l'attaque.

Pour plus d'informations : 

• Eye Security : https://research.eye.security/sharepoint-under-siege/
• Crowdstrike : https://www.crowdstrike.com/en-us/blog/crowdstrike-detects-blocks-sharepoint-zero-day-exploitation/
• SentinelOne : https://www.sentinelone.com/blog/sharepoint-toolshell-zero-day-exploited-in-the-wild-targets-enterprise-servers/
• Microsoft : https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/
• ANSSI : https://www.cert.ssi.gouv.fr/alerte/CERTFR-2025-ALE-010/

Écrit par ELF

En 2023, Crowdstrike relève dans son rapport d'investigation sur les menaces que les attaques par Kerberoasting ont augmentées de 583%. Depuis, de nombreux organismes tentent de sonner le signal d'alarme sur cette attaque, comme Microsoft en octobre 2024 avec un article succinct sur leur blog. C'est à notre tour de vous présenter cette attaque et les impacts qu'elle peut avoir sur votre système d'information.

Dans les environnements modernes basés sur Active Directory, le protocole Kerberos est un pilier de l'authentification réseau. Il garantit des échanges sécurisés entre utilisateurs et services grâce à un système de tickets cryptographiques. Cependant, sa complexité et certaines de ses configurations peuvent être exploitées pour des attaques sophistiquées. Parmi elles, le Kerberoasting est particulièrement redoutable : il exploite les mécanismes internes de Kerberos pour compromettre des comptes de service. Cet article propose de démystifier le protocole Kerberos et d'expliquer les bases de cette attaque pour mieux comprendre ses enjeux et comment tenter de s'en protéger.

Protocole Kerberos - Métaphore du manège forrain

Afin d'expliquer de façon simple et claire le fonctionnement du protocole Kerberos, je vais utiliser une métaphore, celle du manège forain.

Pour accéder au manège, il faut d'abord aller acheter un ticket, cela correspond à la demande de TGT dans Kerberos. Après avoir payé on récupère le ticket et va dans la file d'attente. Quand on souhaite accéder au manège, une personne va récupérer notre ticket pour vérifier qu'on a le droit de monter sur le manège. Cela correspond à la demande de TGS. Quand le forain récupère notre ticket, il nous donne l'accès au manège et nous avons donc le droit de faire le tour de manège. Cela correspond au droit d'accéder et d'utiliser le service que nous souhaitons.

Attaque Kerberoasting

L'attaque Kerberoasting repose sur l'exploitation du protocole Kerberos. Elle consiste en un attaquant disposant d'un compte utilisateur valide dans le domaine qui demande un ticket Kerberos. Ce ticket contient des informations chiffrées avec le mot de passe du compte de service ciblé, et il permet d'accéder au service ciblé par l'attaquant. Ce dernier va ensuite chercher à récupérer le mot de passe du compte de service, en hors-ligne, afin de ne pas être détecté.

Il est possible de retrouver le mot de passe dans un cas particulier, celui où le compte de service est un compte utilisateur et non un compte machine. Ce dernier détail est important, car les comptes machine possèdent des mots de passe très complexes (120 caractères générés aléatoirement) alors que les comptes utilisateur sont créés manuellement et le mot de passe défini est beaucoup plus facile à retrouver.

Explication Technique du protocole Kerberos

Rentrons un petit plus dans les détails techniques de ce protocole et de cette attaque pour en avoir une meilleure compréhension afin de se protéger de façon efficace par la suite. Je vous promets qu'après deux trois relectures, vous finirez par être des experts 😉

Fonctionnement du protocole Kerberos

Le protocole Kerberos utilise des tickets pour permettre une authentification sécurisée sans transmettre de mots de passe en clair. Le processus d'authentification Kerberos comprend trois parties principales :

• Le Centre de Distribution de Clé (KDC) : Composé de deux services principaux — le Service d'Authentification (AS) et le Service de Délivrance de Tickets (TGS).
• Le client : L'utilisateur ou la machine cherchant à accéder à un service.
• Le serveur : Le service auquel l'utilisateur souhaite accéder.

Authentification initiale et obtention du TGT

L'authentification commence lorsqu'un utilisateur tente de se connecter à un domaine Active Directory. Le client envoie une requête d'authentification au Service d'Authentification du KDC. Si l'utilisateur est authentifié avec succès (en utilisant par exemple un mot de passe), l'AS renvoie un Ticket Granting Ticket (TGT), qui est chiffré avec la clé secrète de l'utilisateur (généralement dérivée de son mot de passe).

Ce TGT est utilisé pour obtenir des tickets de service (TGS) auprès du Service de Délivrance de Tickets (TGS). Le TGT permet à l'utilisateur de demander un accès à des services spécifiques sans avoir à s'authentifier de nouveau avec son mot de passe.

Demande de Ticket de Service (TGS)

Une fois en possession du TGT, le client peut envoyer une demande au TGS pour obtenir un Ticket de Service (TGS) pour un service spécifique. Cette demande comprend :

• Le TGT (obtenu lors de l'authentification initiale).
• Le nom du service auquel l'utilisateur souhaite accéder.
• La clé de session générée par le KDC, utilisée pour sécuriser la communication.

Le TGS contient un ticket d'authentification pour le service cible chiffré avec un dérivé du mot de passe du compte de service et un algorithme de chiffrement, souvent le RC4 pour un compte utilisateur. Ce ticket peut être utilisé par le client pour accéder au service demandé.

Voici un schéma qui récapitule ce que je viens d'expliquer pour que cela soit plus clair.

Explication technique du Kerberoasting

Passons à l'attaque kerberoasting !

Prérequis

• Avoir accès à un compte utilisateur valide dans le domaine.

Listing des SPNs

L'attaquant peut lister les SPNs pour identifier des services susceptibles d'être attaqués. Cette étape peut être réalisée avec des outils comme Impacket ou Rubeus.

Exemple de commande pour lister les SPNs avec Impacket :

"python3 examples/GetUserSPNs.py domaine.local/utilisateur:motdepasse -dc-ip 192.168.1.1 -request > hash_spn.txt" Cette commande permet d'obtenir une liste des SPNs associés à un domaine et à un utilisateur, et de tenter une demande de TGT pour chaque SPN.

Récupérer un TGT

L'attaquant doit récupérer ensuite un TGT pour demander un TGS grâce au SPN identifié dans l'étape précédente.

Demander un TGS

Après avoir récupéré un TGT, l'attaquant peut utiliser ce dernier pour demander un TGS valide. Il va ensuite extraire le ticket de la mémoire pour l'utiliser hors-ligne.

Cracker les mots de passe récupérés dans le TGS

Une fois que l'attaquant dispose du TGS et de quelques informations comme le nom de service, il peut utiliser des outils comme John the Ripper ou Hashcat pour tenter de cracker en mode hors-ligne le mot de passe utilisé pour chiffrer le ticket. Et ensuite, il va se connecter au compte de service et avoir tous les accès qui lui sont associés.

Voici une petite liste des outils pouvant être utilisés pour mener à bien cette attaque :

• Impacket : Utilisé pour énumérer les SPNs et récupérer des TGTs.
• Rubeus : Outil pour récupérer et manipuler des tickets Kerberos (TGT, TGS).
• Scripts Powershell : Script pour lister les SPNs d'un domaine.
• John the Ripper / Hashcat : Utilisés pour cracker les mots de passe des TGS récupérés.

Détection du Kerberoasting

Maintenant que nous avons plus d'éléments, voyons comment nous pouvons détecter le kerberoasting. Partons d'abord sur les stratégies à activer au sein de votre Active Directory.

Stratégies AD

• Stratégies locales
  • Événements de connexion : Ouverture de session pour l'utilisateur du domaine et Fermeture de session du même compte à la même heure.
  • Événements de connexion aux comptes : Demande de TGT au service d'authentification et Demande de TGS au Centre de Distribution de clés​.
  • Accès au service d’annuaire : Accès à des objets sécurisés, comme des comptes utilisateurs, des groupes, ou d'autres objets AD.​
• Configuration avancée de la stratégie d’audit
  • Connexion de compte : Validation des informations d'identification, Service d’authentification Kerberos et Opérations de ticket du service Kerberos
  • Suivi détaillé : Création de processus

Ensuite, voici un tableau des événements qui nous intéressent.

Événements Windows liés

Éléments à détecter

Les éléments suivants sont nécessaires pour détecter une attaque Kerberoasting :

• Demande excessive de TGS : Un nombre élevé de demandes de tickets pour différents comptes de service peut indiquer une attaque.
• Exécution d'outils pour cracker des mots de passe : Les outils comme Impacket ou Rubeus peuvent générer des processus suspects.
• Utilisation de commandes Powershell : L'exécution de scripts Powershell pour effectuer l'énumération des SPNs ou récupérer des tickets peut être détectée.

Moyens de détection

Pour détecter ces événements liés au Kerberoasting dans l'environnement Active Directory, plusieurs moyens peuvent être mis en place :

1. Surveiller l'installation d'outils d'attaque : Utiliser l'événement ID 4688 pour détecter des outils téléchargés comme Impacket.
2. Surveiller la connexion de compte utilisateur de SPN : Utiliser l'ID 4624 et l'ID 4634 pour détecter des connexions réussies, souvent liées à la demande de TGT initiale si les événements ont lieu en même temps.
3. Surveiller l'exécution de commandes Powershell : Utiliser les événements ID 4103 et 4104 pour détecter des scripts Powershell suspects.
4. Surveiller les demandes de TGS : Utiliser l'événement ID 4769 pour détecter une demande anormale ou un volume élevé de TGS qui peut être un indicateur de l'attaque.

⚠️ Cependant, il faut faire attention car ces événements font beaucoup de bruits et peuvent provenir d'actions légitimes. ⚠️

Voici une liste non exhaustive de faux positifs potentiels.

Faux positifs possibles

• Demandes de TGS ou TGT effectuées par un administrateur ou des services ​légitimes
• Connexion légitime de l'utilisateur (pas pour une attaque Kerberos)​
• Détection d'outils comme Impacket ou Rubeus mais pas liée à une attaque kerberoasting​
• Détection d'outils, johntheripper etc pour cracker les mots de passe, mais pas liée au kerberoasting​

Pour les réduire, le mieux serait de corréler les événements et de détecter un grand nombre sur une durée limitée.

Démonstration

Afin de vous donner plus de visibilité sur cette attaque, nous allons en simuler une.

Environnement

Pour pouvoir exécuter une attaque Kerberoasting, nous avons besoin de deux machines virtuelles :

• Un serveur AD, ici un Windows Server 2016, en tant que contrôleur de domaine
• Une machine pour l'attaquant, ici une machine avec le système d'exploitation Kali Linux

Nous utilisons une machine Kali Linux pour l'attaquant car elle possède déjà des outils d'attaque Kerberoasting comme Impacket. Pour le serveur AD, nous avons activé les stratégies citées plus haut.

Exécution

Utilisation de l'outil GetUserSPNs d'Impacket : impacket-GetUserSPNs domain/user_ad -dc-ip IP_DC -request > hash_spn.txt

Dans ce cas-là, l'outil est utilisé pour obtenir un hash de mot de passe des comptes utilisateur qui possèdent un SPN (Service Principal Name). On ajoute la -request pour que le script récupère le hash à cracker. Sans cette option, le script va seulement afficher les comptes SPN vulnérables et ne va pas demander le TGS. Dans la capture, vous retrouvez le hash entre les crochets rouges et c'est celui-ci que l'attaquant tentera de cracker avec un outil comme John The Ripper afin de retrouver le mot de passe du compte svc_SQL.

Observations dans Event Viewer

Maintenant, nous allons dans le contrôleur de domaine et nous recherchons les événements qui résultent de l'exécution précédente. On retrouve bien les événements cités plus tôt et qui donnent des indications qui vous permettront de déterminer la légitimité de la demande de TGS.

Nos recommandations

Même si vous êtes maintenant des experts sur le Kerberoasting, nous avons quand même quelques recommandations pour vous 😉

• Détecter dès l'énumération des SPN afin de prévenir l'attaque au plus tôt
• Pour l'event ID 4769, filtrer sur le type de chiffrement et sur le code de réussite
• Éviter de créer des comptes utilisateurs associés à des SPN
• Si nécessité de créer des comptes utilisateurs liés à des SPN, mettre en place des mots de passe très complexes

Lexique

Ticket de Service (TGS)

Un ticket Kerberos généré par le TGS (Ticket Granting Service) pour accéder à un service particulier. Ce ticket est chiffré avec la clé du service cible.

Ticket Granting Ticket (TGT)

Un ticket délivré par le Service d'Authentification (AS) permettant de demander des TGS sans réauthentification.

Centre de distribution de clé (KDC)

Composant central de Kerberos qui authentifie les utilisateurs et délivre les tickets. Il inclut le Service d'Authentification (AS) et le Service de Délivrance de Tickets (TGS).

SPN

Nom unique identifiant un service spécifique dans un domaine, utilisé dans les demandes de TGS.

Authentification Service (AS)

Il s’agit du service sur lequel l’utilisateur s’authentifie. Il délivre un TGT (Ticket Granting Ticket) en cas d’authentification réussie. Ce ticket est en fait une demande d’accès au TGS.

Références

• Kerberos (protocole)
• Kerberoast | The Hacker Recipes
• Kerberos : Le KRBTGT | Néosoft
• DFIR Breakdown: Kerberoasting
• CrowdStrike 2023 Threat Hunting Report Reveals Identity-Based Attacks and Hands-on-Keyboard Activity on the Rise as Adversaries Look to Bypass Defenses | CrowdStrike Holdings, Inc.
• Microsoft's guidance to help mitigate Kerberoasting   | Microsoft Security Blog

Écrit par Elise CHABENIUK