Kerberoasting & Tickets RC4 : Détection Defender for Identity — Akuity SOC

Dans le paysage des compromissions Active Directory internes, la technique Kerberoasting (MITRE ATT&CK T1558.003) demeure un vecteur de prédilection pour l'escalade de privilèges. N'exigeant aucun privilège administratif préalable, cette attaque permet à n'importe quel compte utilisateur du domaine d'interroger le contrôleur de domaine (KDC) pour réclamer des tickets de service (TGS-REQ) associés à des comptes de service disposant d'un Service Principal Name (SPN). L'enjeu critique pour l'attaquant : obtenir un condensat de ticket chiffré afin d'en extraire le mot de passe en force brute hors-ligne (offline cracking).

Anatomie de l'attaque : La régression vers le chiffrement RC4

Le protocole Kerberos privilégie par défaut les algorithmes modernes comme l'AES-256 (chiffrement type 0x12). Cependant, lors d'un Kerberoasting optimisé via des outils comme Rubeus ou Impacket, l'attaquant force explicitement la négociation vers le type de chiffrement obsolète RC4-HMAC-MD5 (type 0x17). La raison opérationnelle est directe : casser un hash NTLM dérivé d'un ticket RC4 sous hashcat s'avère plusieurs centaines de fois plus rapide que d'attaquer une clé dérivée d'AES-256 via PBKDF2-HMAC-SHA1.

Lorsqu'une machine compromise émet des rafales de requêtes TGS avec downgrade RC4 sur des comptes de service sensibles (SQL Server, IIS, middleware), l'attaquant capture la portion chiffrée de la réponse TGS-REP et exporte les tickets hors du périmètre pour les casser sans générer d'événements de connexion anormaux sur les serveurs cibles.

Angle mort natif et télémétrie Defender for Identity

Si Defender for Identity inspecte en profondeur le trafic réseau transitant par les contrôleurs de domaine, les alertes natives de détection du Kerberoasting reposent souvent sur des seuils statistiques globaux ou des heuristiques comportementales. Les attaquants avancés contournent ces mécanismes en utilisant des techniques de low-and-slow, espaçant les requêtes TGS de plusieurs minutes ou ciblant des comptes spécifiques hors heures ouvrées. De plus, les environnements hybrides conservent fréquemment des comptes de service legacy configurés historiquement pour supporter uniquement RC4, noyant les requêtes malveillantes dans le bruit réseau.

Pour identifier avec certitude ces compromissions sans subir les faux positifs des comptes machines légitimes, les analystes doivent exploiter la télémétrie brute de la table IdentityLogonEvents dans Advanced Hunting (KQL).

Requête KQL : Détection des rafales TGS RC4

Cette requête corrèle les requêtes Kerberos de type RC4, exclut les comptes d'ordinateurs (qui effectuent régulièrement des requêtes hôtes légitimes) et isole les utilisateurs sollicitant un nombre anormal de SPN distincts :

IdentityLogonEvents
| where Timestamp > ago(24h) and Protocol =~ "Kerberos"
| extend EncryptionType = tostring(parse_json(AdditionalFields).TicketEncryptionType),
         TargetSpn = tostring(parse_json(AdditionalFields).Spn)
| where EncryptionType in ("0x17", "RC4-HMAC-MD5", "RC4")
| where not(AccountName endswith "$") and not(TargetSpn startswith "HOST/")
| where TargetAccountDisplayName !endswith "$" and TargetAccountDisplayName != "krbtgt"
| summarize 
    RequestedSpnCount = dcount(TargetSpn),
    SpnList = make_set(TargetSpn, 10),
    TargetAccounts = make_set(TargetAccountDisplayName, 10),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by AccountName, AccountDomain, IPAddress
| where RequestedSpnCount >= 3
| extend DurationSeconds = datetime_diff('second', LastSeen, FirstSeen)
| project FirstSeen, LastSeen, DurationSeconds, AccountName, AccountDomain, IPAddress, RequestedSpnCount, SpnList, TargetAccounts
| sort by RequestedSpnCount desc

Orchestration et Remédiation SOAR avec Akuity SOC

Face à une détection confirmée de Kerberoasting, chaque minute compte avant que le hash du compte de service ne soit cassé offline. Akuity SOC transforme cette alerte en remédiation immédiate :

• Décodage in-app étanche : L'assistant IA in-app d'Akuity SOC corrèle la rafale TGS-REQ RC4 et isole les comptes de service ciblés en temps réel, sans jamais exporter le moindre hash ou structure ASN.1 vers des outils web tiers.
• Riposte SOAR 1-clic coordonnée : Déclenchement instantané de confirmUserCompromised() et revokeSessions() sur le compte demandeur dans Microsoft Entra ID depuis l'inventaire des éléments de preuve, combiné à isolateDevice() dans Defender for Endpoint pour confiner le poste source.
• Gouvernance Zero-Trust certifiée : Élévation de privilèges sécurisée sous validation forte MFA AAL2 obligatoire et consignation dans un journal d'audit immuable certifié NIS 2 et SOC 2 Type II.

Mini-FAQ Technique

Pourquoi les attaquants ciblent-ils les comptes de service plutôt que les comptes administrateurs classiques ?

Les comptes de service disposent souvent de privilèges élevés (accès direct aux bases de données, droits d'administration de cluster) tout en ayant des mots de passe rarement changés pour éviter l'interruption des processus métiers. De plus, ils n'exigent pas de permissions administratives pour que leur SPN soit interrogé dans l'Active Directory.

Comment éradiquer définitivement les attaques de type Kerberoasting sur l'AD ?

La remédiation pérenne consiste à migrer les comptes de service vers des Group Managed Service Accounts (gMSA) qui gèrent des mots de passe complexes de 128 caractères changés automatiquement, et à désactiver le chiffrement RC4 sur le domaine au profit strict d'AES-128 et AES-256 via les stratégies de groupe (GPO Kerberos encryption types).