Identifier les requêtes NTLM avec Graylog

Pourquoi traquer NTLM ?

NTLM est un protocole d’authentification ancien, toujours présent dans les environnements Active Directory pour des raisons de compatibilité. Il est vulnérable au relay (NTLM Relay), au pass-the-hash et au cracking offline. L’objectif est d’identifier les machines et applications qui utilisent encore NTLM pour pouvoir les migrer vers Kerberos, et à terme restreindre ou désactiver NTLM.

Activer l’audit NTLM

Par défaut, Windows ne journalise pas le détail des authentifications NTLM. Il faut activer l’audit via GPO :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité

Sur les contrôleurs de domaine

• Sécurité réseau : Restreindre NTLM : Auditer l’authentification NTLM dans ce domaine → Activer tout

Cela génère des événements EventID 8004 dans le journal Microsoft-Windows-NTLM/Operational sur les DC.

Sur tous les serveurs

• Sécurité réseau : Restreindre NTLM : Auditer le trafic NTLM entrant → Activer l'audit pour tous les comptes

Cela génère des événements EventID 8001 et 8002 dans le même journal sur chaque serveur.

Collecter le journal NTLM avec NXLog

Le journal Microsoft-Windows-NTLM/Operational n’est pas collecté par défaut. Ajouter un bloc Input dans le nxlog.conf :

<Input in_ntlm>
    Module im_msvistalog
    Query <QueryList>\
      <Query Id="0">\
        <Select Path="Microsoft-Windows-NTLM/Operational">*</Select>\
      </Query>\
    </QueryList>
    ReadFromLast TRUE
    SavePos TRUE
</Input>

Et l’ajouter dans la route :

<Route r_dc>
    Path in_system, in_application, in_setup, in_security, in_directory_service, in_dns, in_ntlm => out_gelf
</Route>

Redémarrer le service NXLog après modification.

Requêtes Graylog

Toutes les authentifications NTLM auditées (DC)

L’EventID 8004 est le plus direct. Il est généré sur le DC à chaque authentification NTLM validée dans le domaine :

EventID:8004

Ce message contient le nom d’utilisateur, le nom de la machine source et le serveur cible.

Authentifications NTLM via le journal Security

L’EventID 4776 correspond à la validation d’identifiants NTLM par le DC (via le package d’authentification MICROSOFT_AUTHENTICATION_PACKAGE_V1_0) :

EventID:4776

Distinguer NTLM v1 de NTLM v2

Dans les événements 4624 (ouverture de session réussie), le champ LmPackageName indique la version NTLM utilisée.

NTLM v1 (le plus vulnérable) :

EventID:4624 AND message:"NTLM V1"

NTLM v2 :

EventID:4624 AND message:"NTLM V2"

Toutes les sessions NTLM (v1 et v2) :

EventID:4624 AND message:"NtLmSsp"

Échecs NTLM

EventID:4776 AND message:"Échec" OR (EventID:4776 AND message:"0xC000")

Les codes d’erreur courants dans le 4776 :

Identifier les machines source

Pour lister les machines qui s’authentifient encore en NTLM :

EventID:8004

Ajouter le champ source dans les résultats et regrouper par la valeur du champ Workstation dans le message. Un widget Quick Values sur le corps du message permet d’identifier rapidement les machines les plus fréquentes.

NTLM sur un serveur précis

EventID:8004 AND source:SRV001

EventID:4624 AND message:"NtLmSsp" AND source:SRV001

Extracteur recommandé

Pour exploiter les données plus facilement, créer un extracteur sur l’input GELF :

• Type : Regex
• Source field : message
• Regex : LmPackageName\s*:\s*(NTLM V\d)
• Store as field : ntlm_version

Ensuite la requête devient :

ntlm_version:*

Et on peut créer un widget Quick Values sur ntlm_version pour voir la répartition v1/v2.

Stratégie de réduction NTLM

Une fois les requêtes en place, la démarche est la suivante :

1. Auditer : laisser tourner quelques semaines pour avoir une cartographie complète
2. Identifier : repérer les machines et applications qui génèrent du NTLM
3. Corriger : configurer ces applications pour utiliser Kerberos (SPN, DNS, etc.)
4. Restreindre : passer progressivement la GPO de “Audit” à “Refuser” en ajoutant des exceptions si nécessaire
5. Surveiller : garder les alertes actives pour détecter toute régression

Note : ne jamais passer directement en mode “Refuser” sans avoir audité. Certaines applications anciennes ou certains NAS ne supportent que NTLM et tomberaient en panne silencieusement.