Premières étapes d'analyse d'un 100% CPU du processus Lsass.exe
Lsass est le module qui traite toute la sécurité de Windows. Entre autre les demandes d'authentification, la gestion de l'Active Directory, de la réplication, etc.
Lsass.exe est souvent la "victime" d'un autre processus générant un très grand nombre de requêtes LSA. Cela peut être des demandes d'authentification, des recherches de site, de serveur, l'évaluation des groupes d'un utilisateur, la traduction de nom d'utilisateur (vers un SID par exemple), ...
La première étape consiste à vérifier si l'activité Lsass est causée par des sollicitations réseau ou si elles sont causées par une activité interne. Pour cela, le test consiste à débrancher le câble réseau ou à désactiver la carte réseau (attention aux logiciels de prises de main à distance) pendant une dizaine de seconde. Si l'activité baisse à partir de ce moment-là, il faut se concentrer sur les requêtes réseau. Autrement, il faut se concentrer sur l'activité locale.
Origine réseau
Une trace réseau pendant une durée significative (une à cinq minutes) permettra d'obtenir une idée précise des requêtes adressées au contrôleur de domaine. Il faut ensuite analyser la trace pour identifier quel type de trafic est le plus important, s'il provient d'une machine identifiée ou de tout type d'ordinateur. Des exemples de 100% CPU causé par le réseau sont des demandes d'énumération des groupes par un applicatif, des accès massif à un partage, des requêtes LDAP très complexe ne pouvant tirer parti des index en place (en particulier avec des filtres contenant des chaînes partielles en utilisant des wildcards).
Il convient alors de vérifier en fonction du type de trafic et de son origine quel composant ou application en est à l'origine et déterminer s'il est normal ou pas.
Origine locale
Plusieurs actions complémentaires sont possibles : suivre les performances des modules exploitant lsass.exe (annuaire ldap, authentification, réplication, …) et capturer l'image de l'exécution du processus lsass.exe,
Performance
Pour cela, lancez le moniteur de performance avec les compteurs suivants :
- L’objet thread avec les compteurs % Temps processeur et ajouter toutes les instances LSASS et ID Thread.
- L’objet Process avec le compteur lsass avec toutes les instances LSASS
- L’objet Processeur avec le compteur % Temps processeur et %Temps Utilisateur avec l’option toutes les instances sélectionné
- L’objet NTDS avec les compteurs : DRA Inbound Bytes Total/sec, DRA Inbound Object Updates Remaining in Packet, DRA Outbound Bytes Total/sec, DRA Pending Replication Synchronizations, Kerberos Authentications/sec, NTLM Authentications, LDAP Bind Time, LDAP Successful Binds/sec, LDAP Client Sessions, LDAP Searches/sec
Pour votre information voici quelques détails sur les compteurs NTDS :
- DRA Inbound Bytes Total/sec : Nombre d'octets reçus par secondes résultants de réplications entrantes (somme des données compressées et non compressées).
- DRA Inbound Object Updates Remaining in Packet : Nombre d'octets reçus de réplications entrantes qui n'ont pas été enregistrés dans la base. Indique que le serveur reçoit des réplications entrantes mais est trop chargé pour les appliquer rapidement.
- DRA Outbound Bytes Total/sec : Nombre d'octets émis par secondes résultants de réplications sortantes (somme des données compressées et non compressées).
- DRA Pending Replication Synchronizations : Nombre de réplications mises en queue en attente d'être effectuées (réplication backuplog). Revient à ce qui est affiché par repadmin/queue.
- Kerberos Authentications/sec : Nombre d'authentifications par secondes par dessus Kerberos effectuées par secondes.
- NTLM Authentications : Nombre d'authentifications par secondes par dessus NTLM effectuées par secondes.
- LDAP Bind Time : Temps en millisecondes nécessaire pour effectuer un bind à l'AD.
- LDAP Successful Binds/sec : Nombre de binds LDAP par seconde gérés par le serveur.
- LDAP Client Sessions : Nombre de sessions LDAP courantes gérées par le serveur.
- LDAP Searches/sec : Nombre de recherches LDAP effectuées par secondes
Vous pouvez également utiliser le "Performance Monitor Wizard" disponible sur le site web Microsoft. Il permet de configurer l'analyseur de performance facilement. (https://www.microsoft.com/downloads/details.aspx?FamilyID=31FCCD98-C3A1-4644-9622-FAA046D69214&displaylang=en)
Image du processus
Pour cela, il faut installer les Debugging Tools for Windows disponibles sur le site web Microsoft à l'adresse
https://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
Ensuite, via le script AdPlus.vbs (installé par défaut dans \Program Files\Dubugging tools for Windows), générez plusieurs dump du processus lsass à l'aide de la commande
cscript adplus.vbs -hang -pn lsass.exe -r <nombre de snapshot> <intervalle en secondes>
L'idéal étant d'avoir au moins 3 dumps à 1mn d'écart.
Exemple
Cscript adplus.vbs -hang -pn lsass.exe -r 3 30
Un dossier sera alors créé :
Hang_Mode__Date_01-16-2009__Time_15-36-2525
avec, entre autre le fichier
PID-436__LSASS.EXE__full_0650_2009-01-16_15-47-12-110_01b4.dmp
L'analyse de ces dumps est assez complexe, mais une première vérification peut être faite.
Avec WinDBg, ouvrez le fichier PID-436__LSASS.EXE__full_0650_2009-01-16_15-47-12-110_01b4.dmp (File, Open Crash Dump...). Il faut ensuite configurer les symboles pour pouvoir interpréter son contenu. Cela se fait via la commande
.sympath srv*c:\symbols*https://msdl.microsoft.com/download/symbols
le dossier c:\symbols sera utilisé pour mettre en cache les fichiers téléchargés.
Exécutez ensuite la commande !runaway. Cela vous affiche, par ordre croissant de temps d 'activité chacun des thread de lsass.exe
Exemple :
0:000> !runaway
User Mode Time
Thread Time
40:40c 0 days 0:00:00.110
35:2fc 0 days 0:00:00.090
32:2d8 0 days 0:00:00.080
49:608 0 days 0:00:00.070
51:658 0 days 0:00:00.060
30:2cc 0 days 0:00:00.060
Identifiez le ou les threads les plus consommateurs et, pour chacun, exécuter la commande.
~<thread>k
Vous aurez ainsi la pile d'appel de fonction et donc le ou les modules en cours d'exécution. Ainsi que les éventuels modules tierces chargés.
Ces manipulations permettent une première analyse et l'identification de suspect. Pour une analyse plus avancée, il sera nécessaire d'ouvrir un incident auprès de votre support Windows.
Cyrille de Pardieu