LSASS - Local Security Authority Subsystem Service

Wat is LSASS?

LSASS (voluit Local Security Authority Subsystem Service) is het Windows-proces dat de authenticatie regelt. Het draait op de achtergrond als lsass.exe en controleert bij elke aanmelding of een wachtwoord klopt, lokaal of tegen Active Directory.

Het belangrijkste voor dit verhaal is wat er na die controle gebeurt. LSASS gooit de inloggegevens niet weg, maar houdt ze in het geheugen vast zolang de sessie loopt. Zo kan Windows ze hergebruiken wanneer u een share opent of uw mail ophaalt, zonder dat u steeds opnieuw uw wachtwoord hoeft te typen. Het proces draait met de hoogste rechten op de machine (SYSTEM), dus alleen een beheerder of Windows zelf komt erbij.

Op een gezonde machine draait er precies één lsass.exe, gestart vanuit C:\Windows\System32. Ziet u er twee, of eentje die ergens anders vandaan komt, dan is dat vrijwel altijd malware die zich voordoet als het echte proces.

Waarom is LSASS interessant voor aanvallers?

Die inloggegevens in het geheugen zijn precies wat een aanvaller wil hebben. Wie ze bemachtigt, kan zich voordoen als de ingelogde gebruiker en zo verder het netwerk in bewegen.

Wat er te halen valt verschilt per systeem. Meestal is dat de NTLM-hash, de versleutelde vorm van het wachtwoord waarmee een aanvaller op andere systemen inlogt zonder het wachtwoord zelf te kennen. Daarnaast liggen er Kerberos-tickets klaar, de toegangsbewijzen die Windows na het inloggen uitdeelt, en DPAPI-sleutels waarmee bijvoorbeeld opgeslagen browserwachtwoorden te ontcijferen zijn. Op slecht onderhouden systemen staat het wachtwoord er soms zelfs leesbaar bij.

Dat leesbare wachtwoord was jarenlang het grootste probleem. Het kwam door een oud protocol, WDigest, dat het wachtwoord nodig had om te werken. Sinds Windows 8.1 staat WDigest standaard uit, dus op een bijgewerkt systeem levert een aanval geen leesbaar wachtwoord meer op, maar nog wel de hashes en tickets. Het buitmaken van dit materiaal heet credential dumping (MITRE ATT&CK T1003.001).

Hoe dumpt een aanvaller LSASS?

Voor elke variant heeft een aanvaller eerst beheerrechten op de machine nodig. De simpelste manier vraagt verder geen enkele tool. Open Taakbeheer als administrator, klik lsass.exe met de rechtermuisknop aan en kies “Dumpbestand maken”. Windows schrijft dan een dump van het geheugen naar schijf, die een aanvaller daarna rustig op zijn eigen machine uitleest.

In onze pentests werkt het meestal geautomatiseerd. Wij gebruiken NetExec, dat LSASS op afstand over het netwerk dumpt en de inloggegevens er meteen uithaalt:

# NetExec: dump LSASS op afstand en parse de inloggegevens (vereist lokaal beheer)
nxc smb 10.0.0.5 -u administrator -p Wachtwoord -M lsassy

# Mimikatz: rechtstreeks uit het geheugen lezen op de machine zelf
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

# comsvcs.dll: een dump maken via een ingebouwd Windows-onderdeel, zonder externe tool
rundll32 C:\windows\system32\comsvcs.dll,MiniDump <LSASS_PID> C:\out.dmp full

LSASS in een pentest

Zodra wij in een Active Directory pentest lokaal beheer op een werkstation hebben, kijken we vrijwel altijd als eerste naar LSASS. Op een machine waar net een beheerder heeft ingelogd, liggen diens inloggegevens nog in het geheugen, en daarmee hebben wij de sleutel om verder het netwerk in te bewegen.

Meestal krijgen we geen leesbaar wachtwoord, maar wel de NTLM-hash, en die is genoeg voor de volgende stap. Met Pass-the-Hash loggen we in op een ander systeem waar dezelfde beheerder rechten heeft, lezen daar opnieuw LSASS uit, en herhalen dat tot we bij een domain admin uitkomen. In ons rapport leggen we vast hoe die keten kon ontstaan. Meestal komt het neer op beheeraccounts die op gewone werkstations inloggen, of lokale wachtwoorden die overal gelijk zijn.

Hoe voorkomt u LSASS-dumping?

LSASS helemaal afschermen kan niet, want Windows heeft die inloggegevens zelf nodig om te werken. Maar de keten die een aanvaller doorloopt, is op meerdere plekken te breken:

• LSA Protection zet LSASS in een beschermde modus, waardoor gewone programma’s niet meer bij het geheugen kunnen, ook niet als ze als beheerder draaien. U regelt het met de registerwaarde RunAsPPL. Op schone installaties van Windows 11 (22H2 en nieuwer) in een bedrijfsomgeving staat het vaak al aan, maar na een upgrade of op losse machines meestal niet.
• Credential Guard gaat een stap verder en bewaart de gevoeligste gegevens in een door de hardware afgeschermd deel van Windows, los van LSASS. Vanaf Windows 11 22H2 staat het standaard aan op de meeste zakelijke machines, maar niet op domain controllers.
• Controleer dat WDigest uit staat, zodat er geen leesbare wachtwoorden in het geheugen belanden. Sinds Windows 8.1 is dat de standaard. Staat de registerwaarde UseLogonCredential op 1, dan heeft iemand het bewust weer aangezet.
• Zet de Defender-regel tegen LSASS-diefstal aan, de ASR-regel “Block credential stealing from lsass.exe”. Die is vooral handig op systemen waar LSA Protection en Credential Guard niet mogelijk zijn.
• Houd in de gaten wie LSASS benadert. Een poging om het geheugen uit te lezen laat duidelijke sporen na in het event log (Sysmon Event ID 10), waar een goede EDR of SIEM op alarmeert.

Hoeveel een geslaagde dump oplevert, hangt af van wat erin ligt. Met LAPS en een strikte scheiding tussen beheer- en werkaccounts belandt het wachtwoord van een domain admin nooit op een gewoon werkstation, en dan valt er een stuk minder te halen. Geen enkele maatregel is op zichzelf genoeg. Samen breken ze de keten op meerdere plekken tegelijk.