Depuis les mises à jour de sécurité de mars 2024, une fuite de mémoire dans lsass.exe peut saturer les contrôleurs de domaine Windows Server 2012 R2, 2016, 2019 et 2022 jusqu’à provoquer un redémarrage non planifié. Découvrez comment identifier, corriger et prévenir le problème.
Vue d’ensemble de la vulnérabilité LSASS
Le Local Security Authority Subsystem Service (LSASS) est responsable de l’authentification Kerberos/NTLM, de la création des jetons d’accès et de l’application des stratégies de sécurité. Sur un contrôleur de domaine (DC), chaque requête d’ouverture de session génère des structures en mémoire — si ces allocations ne sont pas libérées correctement, la consommation mémoire augmente linéairement. Une fois dépassée la limite de mémoire virtuelle (généralement 2 Go pour un processus 64 bits sous Windows Server), LSASS se bloque ; le système redémarre, interrompant toutes les authentifications AD DS.
La fuite a été introduite par les correctifs Patch Tuesday du 12 mars 2024 (KB 5035855, 5035857, 5035858, 5035860…). Les environnements à forte activité (plusieurs milliers de tickets Kerberos à la minute) pouvaient atteindre la saturation en à peine 24 h.
Chronologie des correctifs et meilleures actions
| Moment | Correctifs disponibles | Contenu relatif à LSASS | Actions recommandées |
|---|---|---|---|
| 22‑25 mars 2024 | Correctifs hors bande (OOB) : KB 5037422/7425/7423/7426 | Éliminent la fuite de mémoire Kerberos | Installer l’OOB avant toute autre CU 2024 pour stabiliser les DC. Test préalable en pré‑production vivement conseillé. |
| 9 avril 2024 | CU Patch Tuesday : KB 5036894 (Server 2022) / KB 5036909 (Server 2019…) | Ne corrige pas la fuite ; LSASS peut toujours crasher | • Pas encore déployée ? Appliquer l’OOB puis la CU. • Déjà déployée ? L’OOB est « Not applicable ». Attendre la CU de mai (ou ultérieure). |
| 14 mai 2024 | CU Patch Tuesday : KB 5037782 (Server 2022), KB 5037765 (Server 2019)… | Intègre le correctif LSASS + autres failles critiques | Mettre à jour tous les DC ; remplace l’OOB et la CU d’avril. |
| 11 juin 2024 | CU Patch Tuesday : KB 5039227 (Server 2022), KB 5039217 (Server 2019)… | Confirme la correction LSASS et élimine une fuite LSARPC supplémentaire | Déployer pour rester protégé et profiter des corrections cumulatives suivantes. |
Plan de déploiement optimisé
- Inventorier les versions : repérer chaque DC et noter version/édition/KB actuels (
wmic qfe get HotFixIDouGet-HotFix). - Seuil critique : si la CU d’avril (ou aucune CU post‑mars) est installée, planifier le correctif OOB ou directement la CU de mai 2024 (ou plus récente).
- Fenêtre de maintenance : prévoir un redémarrage après mise à jour ; l’arrêt brutal de LSASS forcera un reboot de toute façon.
- Approche par anneaux : Lab ▶ Pilote ▶ Production. Surveillez le compteur
Process • Private Bytesde LSASS pendant 48 h. - Sauvegarde d’état AD : créer un snapshot avant patch (via Veeam, Windows Server Backup…).
Surveiller et diagnostiquer la fuite mémoire
Une fuite LSASS se manifeste ainsi :
- Augmentation régulière de la mémoire privée LSASS (plusieurs Mo par minute).
- Événements ID
1015(LSA) ou1202(Kerberos) dans le System Log. - Erreur critique
Event ID 1000(Application Error) pointant verslsass.exe. - Alerte SCOM/Nagios portant sur l’utilisation mémoire > 80 % ou
Working Set> 1,5 Go.
Commandes rapides
Get-Process -Name lsass | Select-Object WorkingSet64,PrivateMemorySize64
# Collecte toutes les 5 min pendant 24 h
while (\$true) {
(Get-Date).ToString('s') + ' ' +
(Get-Process lsass).PrivateMemorySize64 / 1MB | Out-File C:\Temp\lsass\_mem.txt -Append
Start-Sleep -Seconds 300
}Mesures provisoires pour la continuité de service
- Redémarrages planifiés : toutes les 12 h dans les forêts très sollicitées (script
shutdown /rou tâche planifiée). - Équilibrage de charge Kerberos : ajoutez un DC supplémentaire ou réactivez un DC secondaire jusque‑là en veille.
- Réduction du trafic : implémenter la stratégie Cached Credentials côté postes distants pour limiter l’interrogation des DC.
- Surveillance proactive : alerte SCOM/Prometheus dès que LSASS approche 500 Mo de mémoire privée.
Scripts PowerShell prêts à l’emploi
# Vérifier si un DC exécute une CU vulnérable
$badKB = @('KB5035855','KB5035857','KB5035858','KB5035860','KB5036894','KB5036909')
$installed = (Get-HotFix).HotFixID
$installed | Where-Object { $badKB -contains $_ } |
# Redémarrage automatisé si mémoire > 1400 Mo
\$lsass = Get-Process lsass
if (\$lsass.PrivateMemorySize64 -gt 1400MB) {
Restart-Computer -Force
}FAQ — Fuite mémoire LSASS
Le correctif OOB de mars suffit‑il toujours ?
Non : il n’inclut pas les correctifs de mai/juin contre d’autres vulnérabilités critiques. Déployez la plus récente CU disponible.
Pourquoi l’OOB refuse‑t‑il de s’installer après la CU d’avril ?
La logique d’installation détecte un numéro de build plus élevé et déclare le package « Not applicable ». Il faut attendre la CU suivante.
La CU de mai échoue (0x800f0982) sur Server 2019 non anglophone ; que faire ?
Microsoft a publié un package révisé via WSUS/Catalog. Videz le cache %windir%\SoftwareDistribution, puis réessayez.
Un contrôleur de domaine virtuel peut‑il être restauré depuis un snapshot pris avant le correctif ?
Non : cela rompt la cohérence USN et génère une erreur USN rollback. Utilisez uniquement les sauvegardes d’état du système compatibles AD.
Bonnes pratiques de durabilité opérationnelle
En complément du correctif :
- Sizing mémoire : attribuez au minimum 4 Go de RAM par vCPU sur un DC virtuel, avec un soft limit d’alerte à 75 %.
- Politique de jetons Kerberos : ajustez
MaxTokenSize(gpo : Kerberos Policy) pour éviter des tickets excessivement grands. - SSU minimal : assurez‑vous que le Servicing Stack Update exigé par chaque CU est présent. Sinon, l’installation renvoie
CBS_E_NEW_SERVICING_STACK_REQUIRED. - Journalisation : activez LSASS leak diagnostics via
HKLM\System\CurrentControlSet\Control\Lsa\Tracing\Enabled=1pour obtenir des Etw détaillés.
Analyse technique détaillée
Le défaut, introduit dans la pile Kerberos (Kerberos.dll), touche la gestion des Service Ticket Cache Entries. À chaque authentification, LSASS stocke des structures KERB_TICKET_CACHE_ENTRY. Lorsqu’une application utilise l’API SSPI pour SSO, une reference count doit être décrémentée ; le correctif de mars rompt cette décrémentation pour certains états (renewable+forwardable). Résultat : reference jamais à 0, objet jamais libéré. Le correctif OOB rétablit la désallocation en ajustant le chemin de code du « KerbCleanupTicketsRoutine ».
Les versions impactées de Kerberos.dll affichaient des numéros 10.0.20348.2248 à 10.0.20348.2325. Le patch de mai passe à 10.0.20348.2461.
Procédure pas‑à‑pas de mise à jour (SCCM & WSUS)
- Créer un groupe de mise à jour dans SCCM ciblant « Windows Server — Security Updates » et filtrer par KB.
- Planification : déployer première vague sur 5 % des DC (test/pilote). Retours sur 24 h.
- Automatiser le reboot avec un délai de 15 min après install (
/norestartn’est pas recommandé sur un DC). - Validation post‑patch : exécuter
dcdiag /v /c /e /f:dcdiag.txt. - Relevé de performance via
logman(Data Collector Set), conserver 72 h pour confirmer l’absence de ré‑ascension mémoire.
Conséquences d’une absence de correctif
Outre les redémarrages, la saturation de LSASS :
- dégrade la délivrance des tickets Kerberos (erreurs KDC_ERR_NO_SRV),
- sature les canaux NTLM entraînant des lenteurs d’ouverture de session,
- engendre des déconnexions OWA, SharePoint, SQL Server — la chaîne d’authentification échoue,
- peut déclencher un basculement spontanée des rôles FSMO si le DC maître tombe.
Perspective long terme
Microsoft a annoncé la migration progressive du code Kerberos vers un nouveau module NegoCore plus sécurisé. À l’avenir, les fuites mémoire devraient être isolées dans un conteneur protégé. En attendant, il est crucial de maintenir une hygiène de patch stricte, particulièrement sur les rôles cœur comme AD DS.
Conclusion
• Le correctif LSASS n’était pas dans la CU du 9 avril 2024.
• Les OOB de mars ou, mieux, les CU de mai / juin 2024 (et suivantes) éliminent la fuite et améliorent la stabilité.
• Surveillez LSASS, planifiez les redémarrages et maintenez vos DC constamment à jour : vous éviterez les interruptions d’authentification et protégerez vos utilisateurs.