Securite Active Directory & IA : Detecter Kerberoasting, DCSync et Golden Ticket avec des LLMs Fine-tunes

#1
by AYI-NEDJIMI - opened

Securite Active Directory & IA : Detecter Kerberoasting, DCSync et Golden Ticket avec des LLMs Fine-tunes

Auteur : AYI-NEDJIMI | Fevrier 2026


1. Introduction : Active Directory, la cible numero un

Active Directory (AD) demeure l'infrastructure d'identite la plus deployee dans le monde de l'entreprise. Selon les analyses recentes, plus de 95 % des entreprises du Fortune 500 s'appuient sur Active Directory pour gerer l'authentification, les autorisations et les politiques de securite de leurs environnements Windows. Cette omni-presence en fait, de facto, la cible privilegiee des attaquants.

Les statistiques sont eloquentes : dans plus de 80 % des incidents de securite impliquant une compromission du reseau interne, Active Directory est exploite a un moment ou un autre de la chaine d'attaque. Les techniques d'attaque telles que le Kerberoasting, le DCSync, le Golden Ticket, le Pass-the-Hash ou encore le DCShadow permettent aux attaquants de se deplacer lateralement, d'elever leurs privileges et, in fine, de prendre le controle total du domaine.

Comme nous l'expliquons dans notre guide complet de securisation Active Directory, la securisation d'AD necessite une approche multi-couches combinant le durcissement des configurations, la surveillance continue et, desormais, l'intelligence artificielle.

Notre Top 10 des attaques Active Directory presente un panorama complet des menaces les plus critiques ciblant les environnements AD. Dans cet article, nous allons approfondir la maniere dont l'IA, et plus specifiquement les Large Language Models (LLMs) fine-tunes, peuvent revolutionner la detection de ces attaques.

Le modele CyberSec-Assistant-3B, que nous avons developpe et entraine sur des jeux de donnees specialises en cybersecurite, represente une avancee concretement dans cette direction. Il fait partie de notre portfolio complet de modeles, datasets et Spaces IA pour la cybersecurite.


2. Les principales attaques AD et comment l'IA peut aider a les detecter

2.1 Kerberoasting : detection par analyse des requetes TGS anormales

Le Kerberoasting est l'une des attaques les plus repandues contre Active Directory. Elle consiste a demander des tickets de service Kerberos (TGS) pour des comptes de service possedant un Service Principal Name (SPN), puis a tenter de casser le hash du mot de passe hors ligne.

Comme detaille dans notre analyse approfondie du Kerberoasting : attaque et defense, cette attaque est particulierement dangereuse car elle ne genere aucune alerte dans les configurations par defaut d'Active Directory. Un utilisateur authentifie standard peut demander un TGS pour n'importe quel service enregistre dans le domaine --- c'est un comportement parfaitement legitime du protocole Kerberos.

Comment l'IA detecte le Kerberoasting :

Les approches traditionnelles basees sur des regles (par exemple, alerter sur l'Event ID 4769 avec un type de chiffrement RC4) generent un nombre considerable de faux positifs. Un LLM fine-tune apporte une detection bien plus fine :

  • Analyse comportementale des requetes TGS : Le modele apprend le profil normal de chaque utilisateur --- quels services il interroge habituellement, a quelle frequence, et avec quel type de chiffrement. Une deviation significative declenche une alerte contextualisee.
  • Detection des rafales de requetes : Le Kerberoasting automatise (via des outils comme Rubeus ou Invoke-Kerberoast) genere typiquement un grand nombre de requetes TGS en peu de temps. Le modele identifie ces patterns temporels anormaux.
  • Correlation du type de chiffrement : Les requetes utilisant RC4-HMAC (etype 23) au lieu d'AES sont un indicateur fort. Le modele apprend a ponderer ce signal en fonction du contexte.
  • Analyse croisee avec le comportement reseau : Le modele correle les requetes TGS avec l'activite reseau globale de l'utilisateur pour distinguer un administrateur legitime d'un attaquant.

Notre article sur l'exploitation du protocole Kerberos dans les environnements AD fournit des details techniques complementaires sur les mecanismes sous-jacents de cette attaque.

# Exemple de requete au modele CyberSec-Assistant-3B
prompt = "Analyse ces logs Kerberos et identifie les indicateurs de Kerberoasting"
# Le modele identifie : rafale de TGS, RC4 demande, comptes de service multiples

2.2 DCSync : detection de la replication DRS depuis des sources non-DC

L'attaque DCSync permet a un attaquant disposant de privileges suffisants (Replicating Directory Changes / Replicating Directory Changes All) de simuler le comportement d'un controleur de domaine et de demander la replication des donnees d'annuaire, y compris les hashes NTLM de tous les utilisateurs du domaine.

Notre guide complet sur l'attaque DCSync et les strategies de defense explique en detail les mecanismes de cette attaque devastatrice. Le DCSync exploite le protocole MS-DRSR (Directory Replication Service Remote Protocol), qui est utilise legitimement entre les controleurs de domaine pour synchroniser les donnees de l'annuaire.

Comment l'IA detecte le DCSync :

La detection traditionnelle repose sur la surveillance de l'Event ID 4662 avec des GUID specifiques correspondant aux droits de replication. Cependant, cette approche est fragile et sujette aux contournements. Un LLM fine-tune ameliore considerablement cette detection :

  • Identification des sources non-DC : Le modele maintient un inventaire dynamique des controleurs de domaine legitimes et alerte immediatement lorsqu'une demande de replication DRS provient d'une machine qui n'est pas un DC.
  • Analyse du profil de replication : Le modele apprend les patterns normaux de replication (frequence, volume, comptes cibles) et detecte les deviations.
  • Detection du ciblage selectif : Un DCSync malveillant cible souvent des comptes specifiques (krbtgt, administrateurs de domaine). Le modele identifie ces patterns de ciblage suspects.
  • Correlation temporelle : Le modele detecte les demandes de replication en dehors des fenetres habituelles ou immediatement apres une elevation de privileges suspecte.

2.3 Golden Ticket : detection des tickets impossibles et anomalies temporelles

L'attaque Golden Ticket represente le "Graal" de la compromission AD. En possedant le hash NTLM du compte krbtgt, un attaquant peut forger des tickets Kerberos TGT (Ticket Granting Ticket) avec des proprietes arbitraires --- n'importe quel utilisateur, n'importe quel groupe, n'importe quelle duree de validite.

Comme nous le decrivons dans notre analyse detaillee du Golden Ticket : attaque et defense, cette attaque est extremement difficile a detecter car le ticket forge est techniquement valide du point de vue cryptographique.

Comment l'IA detecte le Golden Ticket :

  • Detection des tickets "impossibles" : Le modele identifie des tickets dont les proprietes sont incoherentes --- par exemple, un TGT avec une duree de vie de 10 ans, ou un ticket emis par un DC qui n'existait pas au moment de l'emission.
  • Anomalies temporelles : Les Golden Tickets ont souvent des horodatages incoherents. Le modele detecte les ecarts entre l'heure d'emission du ticket et l'horloge du DC qui aurait du l'emettre.
  • Anomalies d'appartenance aux groupes : Le modele verifie que les groupes encodes dans le PAC (Privilege Attribute Certificate) du ticket correspondent aux appartenances reelles de l'utilisateur dans l'annuaire.
  • Detection de l'absence d'AS-REQ : Un Golden Ticket n'a pas ete obtenu via le processus normal d'authentification Kerberos. Le modele detecte l'utilisation de TGT pour lesquels aucune requete AS-REQ correspondante n'a ete enregistree.

2.4 Pass-the-Hash : detection des mouvements lateraux

Le Pass-the-Hash (PtH) permet a un attaquant d'utiliser directement le hash NTLM d'un mot de passe pour s'authentifier aupres de services distants, sans jamais connaitre le mot de passe en clair. Combine avec les techniques de relais NTLM modernes, le PtH constitue un vecteur majeur de mouvement lateral.

Comment l'IA detecte le Pass-the-Hash :

  • Analyse des patterns de mouvement lateral : Le modele construit un graphe des connexions habituelles entre machines et utilisateurs. Un utilisateur qui se connecte soudainement a des machines inhabituelles genere une alerte.
  • Detection des authentifications NTLM anormales : Le modele identifie les authentifications NTLM dans des contextes ou Kerberos devrait normalement etre utilise.
  • Correlation avec les processus : Le modele analyse les processus a l'origine des connexions pour detecter l'utilisation d'outils offensifs (mimikatz, secretsdump, etc.).
  • Analyse des velocites de connexion : Un attaquant utilisant PtH se connecte souvent a de nombreuses machines en peu de temps --- un pattern que le modele identifie aisement.

2.5 DCShadow : detection des controleurs de domaine non autorises

Le DCShadow est une attaque avancee qui consiste a enregistrer temporairement une machine comme controleur de domaine dans l'annuaire AD, puis a injecter des modifications directement dans la replication. Cette attaque est particulierement furtive car les modifications apparaissent comme provenant d'une replication legitime.

Comment l'IA detecte le DCShadow :

  • Surveillance des enregistrements SPN : Le modele detecte l'ajout de SPNs caracteristiques d'un DC (GC/, E3514235-4B06-11D1-AB04-00C04FC2DCD2/) sur des machines non-DC.
  • Analyse des objets nTDSDSA : Le modele surveille la creation d'objets nTDSDSA ephemeres dans la partition de configuration.
  • Detection des replication anormales : Le modele identifie les evenements de replication impliquant des sources non reconnues comme DC legitimes.
  • Correlation avec les modifications d'objets : Le modele detecte les modifications d'objets AD qui coincident avec l'enregistrement temporaire d'un nouveau DC.

3. Construction du modele CyberSec-Assistant-3B

3.1 Architecture et choix techniques

Le modele CyberSec-Assistant-3B est base sur une architecture de 3 milliards de parametres, optimisee pour le raisonnement en cybersecurite. Nous avons fait le choix d'un modele de taille moderee pour permettre un deploiement on-premise, compatible avec les exigences de confidentialite des environnements SOC.

3.2 Donnees d'entrainement

Le fine-tuning a ete realise sur des jeux de donnees soigneusement construits :

  • Logs d'attaques AD synthetiques : Des milliers de sequences de logs simulant des attaques Kerberoasting, DCSync, Golden Ticket, PtH et DCShadow, generes dans des environnements de lab controlees.
  • Documentation technique : Corpus de documentation Microsoft, MITRE ATT&CK, et articles de recherche en securite AD.
  • Interactions expert-modele : Des milliers de paires question-reponse elaborees par des experts en securite AD, couvrant l'analyse d'incidents, la remediation et les bonnes pratiques.
  • Rapports d'incidents anonymises : Des rapports d'incidents reels anonymises fournissant au modele une comprehension des scenarios d'attaque realistes.

3.3 Processus de fine-tuning

Le fine-tuning a suivi une approche en plusieurs etapes :

  1. Pre-entrainement supplementaire sur le corpus technique de cybersecurite
  2. Supervised Fine-Tuning (SFT) sur les paires question-reponse d'experts
  3. Apprentissage par renforcement avec feedback humain (RLHF) pour affiner la qualite et la pertinence des reponses
  4. Evaluation rigoureuse sur des scenarios d'attaque inedits

L'ensemble des modeles, datasets et outils est disponible dans notre collection CyberSec AI Portfolio.


4. Exemples pratiques : interroger le modele sur les attaques AD

Exemple 1 : Analyse d'un potentiel Kerberoasting

Utilisateur : J'observe une serie de 47 requetes TGS (Event ID 4769) provenant
du meme utilisateur en moins de 2 minutes, toutes avec le type de chiffrement
RC4-HMAC. Est-ce du Kerberoasting ?

CyberSec-Assistant-3B : Oui, avec une haute probabilite. Les indicateurs sont :
1. Volume anormal : 47 TGS en 2 min depasse largement le seuil normal (~2-5/heure)
2. Chiffrement RC4 : Les outils de Kerberoasting forcent souvent RC4 pour
   faciliter le cracking offline
3. Source unique : Un seul utilisateur ciblant de multiples services

Recommandations immediates :
- Verifier les SPNs cibles pour identifier les comptes de service a risque
- Verifier si l'utilisateur source a ete compromis
- Changer immediatement les mots de passe des comptes de service cibles
- Migrer les SPNs vers des comptes gMSA avec rotation automatique

Exemple 2 : Detection d'un DCSync suspect

Utilisateur : Un evenement 4662 avec le GUID 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
a ete enregistre depuis la machine WORKSTATION-42. Est-ce normal ?

CyberSec-Assistant-3B : C'est un indicateur critique de DCSync. Ce GUID
correspond au droit "Replicating Directory Changes All". Une workstation
standard ne devrait JAMAIS effectuer de replication d'annuaire.

Actions immediates :
1. Isoler WORKSTATION-42 du reseau
2. Identifier l'utilisateur et le processus a l'origine de la requete
3. Verifier les ACL sur le domaine pour les droits de replication anormaux
4. Considerer que les hashes de tous les comptes cibles sont compromis
5. Declencher une rotation complete des mots de passe si krbtgt a ete cible

Exemple 3 : Investigation d'un Golden Ticket potentiel

Utilisateur : Un ticket Kerberos TGT pour l'utilisateur "admin_backup" a une
duree de vie de 87600 heures. La politique du domaine fixe la duree maximale
a 10 heures. Que dois-je faire ?

CyberSec-Assistant-3B : C'est un indicateur fort de Golden Ticket. La duree
de vie (87600h = 10 ans) est completement incoherente avec la politique de
votre domaine (10h).

Plan de remediation :
1. URGENT : Effectuer une double rotation du mot de passe krbtgt
   (deux rotations espacees de 12-24h pour invalider tous les tickets forges)
2. Identifier comment le hash krbtgt a ete obtenu (DCSync ? acces au NTDS.dit ?)
3. Verifier tous les comptes Tier 0 pour des compromissions
4. Auditer les ACL du domaine et les Group Policy Objects
5. Mettre en place une surveillance renforcee des tickets avec des anomalies
   temporelles

5. Integration avec les workflows SIEM/SOC

5.1 Architecture d'integration

L'integration du modele CyberSec-Assistant-3B dans un environnement SOC existant suit une architecture en trois couches :

Couche 1 - Collecte et pre-traitement :
Les logs AD (Event IDs 4662, 4769, 4768, 4724, etc.) sont collectes par le SIEM (Splunk, Microsoft Sentinel, Elastic Security) et pre-traites pour extraire les champs pertinents.

Couche 2 - Analyse par le LLM :
Les evenements pre-filtres sont envoyes au modele CyberSec-Assistant-3B qui effectue une analyse contextuelle multi-dimensionnelle : comportement utilisateur, correlation temporelle, analyse de la chaine d'attaque.

Couche 3 - Decision et reponse :
Le modele genere des alertes enrichies avec un score de confiance, une classification MITRE ATT&CK, et des recommandations de remediation actionnables.

5.2 Cas d'usage concrets

  • Triage automatise : Le modele analyse les alertes brutes et les classe par severite, reduisant la charge des analystes SOC de 60 a 70 %.
  • Enrichissement contextuel : Chaque alerte est enrichie avec le contexte AD (groupes de l'utilisateur, sensibilite du compte, historique recent).
  • Assistance a l'investigation : Les analystes peuvent interroger le modele en langage naturel pour obtenir des explications sur les evenements detectes.
  • Generation de rapports : Le modele peut generer des rapports d'incident structures a partir des donnees brutes.

5.3 Exemple d'integration avec Splunk

# Exemple simplifie d'integration avec Splunk via l'API
import requests
from transformers import AutoModelForCausalLM, AutoTokenizer

# Recuperer les alertes AD depuis Splunk
splunk_query = '''
search index=windows EventCode=4769 Ticket_Encryption_Type=0x17
| stats count by Account_Name, Service_Name
| where count > 10
'''

# Analyser avec CyberSec-Assistant-3B
model = AutoModelForCausalLM.from_pretrained("AYI-NEDJIMI/CyberSec-Assistant-3B")
tokenizer = AutoTokenizer.from_pretrained("AYI-NEDJIMI/CyberSec-Assistant-3B")

def analyze_ad_alert(alert_data):
    prompt = f"Analyse cette alerte AD et determine s'il s'agit d'une attaque : {alert_data}"
    inputs = tokenizer(prompt, return_tensors="pt")
    outputs = model.generate(**inputs, max_new_tokens=500)
    return tokenizer.decode(outputs[0], skip_special_tokens=True)

6. Avenir : surveillance de la securite AD par l'IA

6.1 Tendances emergentes

L'avenir de la securite Active Directory est indissociable de l'intelligence artificielle. Plusieurs tendances se dessinent :

  • Detection en temps reel par LLM : Les modeles deviendront suffisamment rapides pour analyser les evenements AD en temps reel, et non plus en mode batch.
  • Agents IA autonomes pour le SOC : Des agents IA capables de mener des investigations completes de maniere autonome, de la detection initiale a la remediation.
  • Modeles federes : Des modeles entraines de maniere federee sur les donnees de plusieurs organisations, sans jamais partager les donnees brutes, ameliorant la detection collective.
  • Integration avec Zero Trust : Les LLMs alimenteront les moteurs de decision Zero Trust pour evaluer en continu la confiance accordee a chaque identite AD.

6.2 Defis a relever

  • Performance et latence : L'inference doit etre suffisamment rapide pour les environnements de production.
  • Explicabilite : Les decisions du modele doivent etre explicables aux analystes SOC.
  • Adversarial robustness : Les modeles doivent resister aux tentatives d'evasion par les attaquants.
  • Confidentialite : Le deploiement on-premise est essentiel pour les environnements sensibles.

7. Conclusion

La securite Active Directory entre dans une nouvelle ere grace a l'intelligence artificielle. Les attaques comme le Kerberoasting, le DCSync et le Golden Ticket restent des menaces majeures, mais les LLMs fine-tunes offrent desormais des capacites de detection sans precedent.

Le modele CyberSec-Assistant-3B demontre que des modeles de taille raisonnable, deployes on-premise, peuvent fournir une assistance precieuse aux equipes SOC. Combine avec les approches traditionnelles de securisation decrites dans notre guide de securisation Active Directory, l'IA constitue un multiplicateur de force considerable.

Pour approfondir vos connaissances sur les techniques d'attaque et de defense AD, nous vous invitons a consulter :

La convergence de l'expertise humaine en securite AD et de la puissance analytique des LLMs ouvre la voie a une defense proactive et intelligente de nos infrastructures d'identite les plus critiques.


Cet article a ete publie par AYI-NEDJIMI. Pour plus de ressources, visitez notre portfolio CyberSec AI.

Sign up or log in to comment