Cela fait plus de 10 ans que les experts cybersécurité alertent sur le Kerberoasting, cette attaque aussi simple qu’efficace pour récupérer les mots de passe de comptes à privilèges via Kerberos. Et pourtant, en 2025, cette technique continue de caraméliser les contrôleurs de domaine, avec un petit goût de brûlé pour les SOC qui n’y voient que du feu.
Pourquoi cette attaque vieillit bien ? Parce que vos détections… vieillissent mal.

🧯 Petit rappel pour les distraits : c’est quoi le Kerberoasting ?

Le Kerberoasting, c’est un peu comme scanner un menu de restaurant pour y trouver des plats chiffrés avec des mots de passe faibles… sauf qu’ici, le menu, c’est Kerberos.

En clair :

1. L’attaquant, déjà dans le SI avec un compte lambda (merci phishing ou mot de passe « Azerty123 »),
2. demande un ticket TGS pour un compte de service,
3. récupère le ticket chiffré avec le hash du mot de passe du compte,
4. repart avec sous le bras pour le craquer tranquillement en local avec Hashcat, JTR, ou son blender préféré.

Et voilà. Le compte de service, souvent admin local ou pire, est compromis. Et vous, vous ne voyez rien venir.

🕵️‍♂️ Des détections obsolètes face à un feu discret

Les outils de détection se basent encore trop souvent sur des règles rigides façon :

• « Si plus de X requêtes TGS par minute → alerte ! »
• « Si chiffrement RC4 utilisé → suspicion ! »

Sauf que :

• Les services légitimes font parfois plein de requêtes (bonjour les faux positifs),
• Et les attaquants ne sont pas pressés : une requête toutes les 15 minutes sur 24h ? Personne ne lève un sourcil.
• Les admins adorent encore RC4 (soupirs).

Résultat : des alertes partout… sauf là où il faut.

🧠 Nouvelle approche : Kerberos rencontre les stats

Une équipe de chercheurs (coucou BeyondTrust) a décidé de lâcher les regex pour adopter une modélisation statistique comportementale.

Leur méthode ?
👉 Regrouper les requêtes TGS dans des clusters de comportements (ex. : nombre, type de service, moment, user-agent…)
👉 Suivre l’évolution de ces clusters dans le temps sous forme d’histogrammes
👉 Détecter les anomalies statistiques, pas juste les pics.

Bonus :

• Chaque alerte est explicable (on comprend pourquoi elle est levée),
• Le modèle affiche son niveau d’incertitude (vous avez dit XDR ?),
• Ça tourne en temps réel, avec moins de 30s de calcul par heure d’événements.

Pas mal pour une détection que votre SIEM mettait 2 jours à rater.

🧪 Testé en conditions réelles : pas qu’un PowerPoint

La méthode a été testée sur 50 jours d’événements Kerberos en prod :

• Détection fiable de 2 attaques réelles de type Kerberoasting simulées,
• Identification de 3 changements d’infrastructure (migrations, mises à jour AD) sans faux positifs critiques,
• Une anomalie « exotique » détectée, analysée et justifiée.

Le modèle a non seulement évité la panique, mais aussi donné du contexte à chaque alerte.

Autrement dit : moins d’alertes à la noix, plus d’intelligence dans vos logs.

🧰 Et en pratique ? Tu fais quoi demain ?

Quelques pistes concrètes pour ne pas finir rôti :

• 🔒 Audit de tous les comptes de service avec SPN → longs mots de passe + sans RC4, please.
• 🚫 Supprimez les accounts avec Kerberos RC4 par défaut (vous savez qui vous êtes).
• 📉 Surveillez les TGS émis par utilisateur unique sur des services multiples, mais pas juste en volume brut.
• 📊 Intégrez une logique de détection adaptative, même à petite échelle (Elastic, Sentinel, Splunk → c’est faisable).
• 🧩 Coupler cette détection avec un ITDR comme BeyondTrust peut automatiser la réponse.

💣 En conclusion : Kerberos est votre ami… jusqu’à ce qu’il vous plante un couteau dans le dos

Le vrai problème, ce n’est pas Kerberos. C’est la paresse de vos détections et la rigidité de vos outils. Les attaquants se sont adaptés, et vous ?

Il est temps de passer d’un modèle où on guette les éclairs, à un modèle où on comprend les nuages.

Et si votre SIEM vous crie « Kerberoasting detected » à chaque pause-café de l’admin, c’est peut-être pas un feu… juste votre détection qui fume.

🛡️ Mini-Playbook SOC – Détection comportementale de Kerberoasting

🎯 Objectif

Renforcer la détection des attaques de type Kerberoasting en utilisant une approche comportementale et statistique, plus robuste que les règles statiques traditionnelles.
Ce playbook est conçu pour être progressivement déployé dans un SOC, avec ou sans solution ITDR.

🧩 Étape 1 – Prérequis techniques

Collecte de logs indispensable :

• 🎫 Event ID 4769 (Windows Security Log) : émission d’un ticket TGS.
• 🧑‍💻 Nom d’utilisateur (UserName)
• 🖥️ ServiceName (SPN demandé)
• 🔒 EncryptionType
• 📆 Timestamp

Outils recommandés :

• SIEM (Splunk, ELK, Sentinel, QRadar, etc.)
• Un moteur d’analyse statistique :
  • Python (Pandas, SciPy, Scikit-learn)
  • Ou module UEBA du SIEM, ou ITDR type BeyondTrust

🧪 Étape 2 – Prétraitement & segmentation

But : construire des comportements « normaux » de demande TGS.

➤ À faire :

1. Nettoyer les logs :
   • Supprimer les événements système (compte machine, service SYSTEM).
   • Normaliser les formats de timestamp.
2. Grouper les événements :
   • Par utilisateur (UserName)
   • Par intervalle horaire (1h ou 4h selon volume)
3. Extraire les variables clés :
   • Nombre de requêtes TGS / heure / user
   • Types de chiffrement utilisés
   • Nombre de SPN différents ciblés
   • Diversité des services demandés
   • Volume moyen vs pic soudain

📊 Étape 3 – Analyse comportementale

Objectif : détecter des écarts significatifs au comportement historique.

➤ Options :

• Approche statistique simple :
  • Moyenne mobile + écart-type
  • Détection d’anomalies (Z-score, IQR)
• Approche avancée (optionnel) :
  • Clustering non supervisé : DBSCAN ou K-Means
  • Modèles de détection d’anomalies : Isolation Forest, One-Class SVM

💡 Conseil : commencez simple, puis complexifiez au besoin. Le Z-score suffit souvent à détecter les attaques « anormales ».

🚨 Étape 4 – Déclenchement d’alertes

➤ Critères recommandés :

• Requêtes TGS > moyenne + 2x écart-type
• Utilisateur demandant > X SPN différents en 1h
• Ticket RC4 demandé alors que l’AD est censé être AES-only
• Présence de tickets chiffrés sur des comptes désactivés

Bonus : Ajouter une marge d’incertitude dans l’alerte pour prioriser les analyses (ex. : score de confiance sur 100).

📦 Étape 5 – Réponse SOC

Workflow type :

1. Analyse rapide de l’utilisateur ciblé :
   • Légitimité du compte ?
   • Session interactive ? Service ?
2. Vérification des SPN demandés :
   • Services connus ?
   • Changement récent ?
3. Corrélation avec d’autres événements :
   • Création de compte ?
   • Mouvement latéral suspect ?

Actions possibles :

• Isolation du poste
• Réinitialisation des comptes de service concernés
• Investigation via EDR
• Création d’un cas dans ITDR / XDR

🛠 Étape 6 – Automatisation (optionnel mais recommandé)

• 🔁 Script Python pour scoring et analyse horaire
• 📤 Export CSV ou JSON vers SIEM ou outil XDR
• 📧 Alerte automatisée par email/Slack si score > seuil
• 🧠 Intégration dans un moteur de détection type Sentinel + Azure Logic Apps

📘 Étape 7 – Documentation & retour d’expérience

• 🔎 Documenter chaque cas détecté (vrai positif, faux positif, test Red Team…)
• 🛡️ Mettre à jour le modèle selon les changements d’infrastructure (migration, nouvelle app…)
• 🧑‍🏫 Former les analystes SOC à l’interprétation des comportements au lieu des simples règles

✅ Résumé visuel

🧠 En bonus : 3 conseils pratiques et des exemples de script

• Crée une whitelist de services bavards légitimes (imprimantes, services backend, etc.)
• Renomme les SPN obsolètes ou désactive les comptes dormants
• Utilise AES comme standard, et dis adieu au RC4

✅ 1. Exemple de script Python : détection simple d’anomalie TGS par Z-score

Ce script analyse des logs d’événements TGS (Event ID 4769) depuis un CSV extrait de ton SIEM (ou via API), et identifie les utilisateurs qui font des requêtes TGS anormalement élevées.

💾 Format CSV attendu (tgs_logs.csv) :

🐍 Script Python (Z-score, seuil = 2σ)

python

import pandas as pd
import numpy as np
from datetime import timedelta

# Charger les logs TGS
df = pd.read_csv("tgs_logs.csv", parse_dates=["TimeGenerated"])

# Grouper par utilisateur et heure
df["TimeRounded"] = df["TimeGenerated"].dt.floor("H")
grouped = df.groupby(["UserName", "TimeRounded"]).size().reset_index(name="TGS_Count")

# Moyenne + écart-type par utilisateur
stats = grouped.groupby("UserName")["TGS_Count"].agg(["mean", "std"]).reset_index()
grouped = grouped.merge(stats, on="UserName")

# Calcul du Z-score
grouped["z_score"] = (grouped["TGS_Count"] - grouped["mean"]) / grouped["std"]
grouped["anomalie"] = grouped["z_score"] > 2  # seuil = 2σ

# Affichage des anomalies
anomalies = grouped[grouped["anomalie"]]
print("🚨 Anomalies détectées :")
print(anomalies[["UserName", "TimeRounded", "TGS_Count", "z_score"]])

🔍 Résultat attendu :

text
🚨 Anomalies détectées :
  UserName     TimeRounded         TGS_Count    z_score
  john.doe     2025-07-22 14:00     34           2.87
  svc.account  2025-07-22 09:00     61           3.15

✅ 2. Exemple de requête KQL (Azure Sentinel / Microsoft Defender)

Détection de pics de requêtes TGS suspects (EventID 4769), par utilisateur sur 1h, avec filtrage RC4 :

kql
SecurityEvent
| where EventID == 4769
| where AccountType == "User"
| extend HourBucket = bin(TimeGenerated, 1h)
| summarize TGS_Count = count(), 
            SPNs = dcount(ServiceName),
            RC4_Tickets = countif(EncryptionType == "0x17")
    by Account = TargetUserName, HourBucket
| join kind=inner (
    SecurityEvent
    | where EventID == 4769
    | summarize avg_count = avg(count()) by TargetUserName
) on $left.Account == $right.TargetUserName
| where TGS_Count > avg_count * 2  // seuil ajustable
| project HourBucket, Account, TGS_Count, SPNs, RC4_Tickets

✅ Exemple de requête ELK / Lucene / Kibana DSL

En supposant que tu logs les 4769 dans un index winlogbeat-* :

json
GET winlogbeat-*/_search
{
  "size": 0,
  "query": {
    "bool": {
      "must": [
        { "match": { "event.code": "4769" }},
        { "match": { "winlog.event_data.TicketEncryptionType": "0x17" }}
      ]
    }
  },
  "aggs": {
    "users": {
      "terms": { "field": "winlog.event_data.TargetUserName.keyword", "size": 10 },
      "aggs": {
        "by_hour": {
          "date_histogram": {
            "field": "@timestamp",
            "fixed_interval": "1h"
          },
          "aggs": {
            "tgs_count": { "value_count": { "field": "winlog.event_data.ServiceName.keyword" }}
          }
        }
      }
    }
  }
}

🔎 Tu peux ensuite visualiser ces buckets horaires dans un dashboard Kibana et appliquer des seuils manuellement, ou via Watcher / alertes.

🔧 Bonus : intégration SIEM ou alerting

• Splunk : convertis le script en recherche SPL et utilise anomalydetection ou movingavg.
• Sentinel : ajoute un Playbook Logic App pour créer un ticket automatiquement.
• ELK : ajoute un trigger dans Watcher ou ElastAlert.

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com