Investigating LSASS and its Capabilities

 

What is LSASS?

The Local Security Authority Subsystem Service (LSASS) running as lsass.exe on Windows is the guard at the gate of your system’s security. After you log in, LSASS holds your credential data in memory: things like Kerberos tickets, NTLM hashes, and sometimes even plaintext passwords. This makes it attractive for attackers looking to hijack sessions, move laterally, or escalate privileges.

This covers the TTP of TA0008 (Lateral Movement), TA0006 (Credential Access), TA0010 (Exfiltration). Sometimes its difficult to map to MITRE ATT&CK framework accurately as it gives a brief description of what the general outlook and goal of the adversary is trying to do. The real attack nature depends on what is being and accessed and the eventual goal and nature of the attack.

Why Attackers Target LSASS

Reading LSASS memory is like opening a treasure chest full of credentials. Tools such as Mimikatz, Procdump, Taskmgr, or even native system libraries like dbghelp.dll and dbgcore.dll, are commonly used to grab this data. Adversaries both malware and red teams leverage on LSASS memory access to clone identities and escalate privileges.

How to Detect LSASS Memory Access

1. Watch for Unusual Process Access

Look for processes requesting access to lsass.exe. In Windows logs, Sysmon event ID 10 (ProcessAccess) and Security event IDs 4656/4663 are key. If a non-system or non-privileged process is accessing LSASS, raise a weak signal or alert. Logs can be captured by a logging device such as Splunk or Winlogbeat (which can be parsed by logstash and retrieved from elasticsearch). 

2. Spot Debugger DLL Loads

Many tools inject or load dbgcore.dll, dbghelp.dll, or use ntdll to trigger dumps. Monitoring Sysmon’s “Image Loaded” events (event 10 or 11) for such libraries combined with lsass.exe in the stack can quickly uncover suspicious activity.

3. Monitor for Dump Files

After LSASS is accessed, tools often write memory dumps (e.g., file1.dmp). Sysmon event ID 11 (FileCreate) with filenames like lsass*.dmp is a strong indicator.

False Positives

1. Legitimate Security Tools

  • Antivirus and endpoint detection tools (e.g. Microsoft Defender, CrowdStrike) sometimes scan or interact with LSASS as part of their normal behavior.

  • These will show up in logs as accessing lsass.exe, but are signed, known processes from trusted vendors.

2. System Utilities and Admin Tools

  • Tools like Task Manager, Process Explorer, and Sysinternals' tools might access LSASS during legitimate diagnostics.

  • These tools are often used by IT admins or security teams but if used at odd hours or from user sessions that don’t normally run them, they could still be suspicious.

3. Backup and Monitoring Agents

  • Some backup software or performance monitoring agents may access protected memory spaces (including LSASS) to gather system metrics.

  • Check process names and parent-child process relationships.

Process Spoofing

Attackers can:

  • Rename their tool to look like a trusted binary (e.g., Taskmgr.exe, svchost.exe, procdump.exe)

  • Copy the file appearance and file metadata (version, description, etc.) to appear more legitimate

  • Use signed binaries (from trusted vendors)

  • Inject code into legitimate processes (process hollowing or DLL injection)

This lets them bypass naive detections that rely only on process names instead of deeper context like:

  • Digital signatures

  • Parent-child process chains

  • Command-line arguments

  • Behavioral patterns


Security systems or analysts that rely solely on process names (e.g., “only alert if mimikatz.exe touches LSASS”) can completely miss the threat.

A malicious binary spoofed to be named Taskmgr.exe can:

  • Look legitimate to the naked eye

  • Pass basic signature checks if unsigned binaries are allowed


Ways to circumvent:

1. Verify Digital Signatures

Check if the process is digitally signed by Microsoft or another verified vendor. You can check this by right clicking and under properties you should be able to see a digital signature tab.

2. Use File Path Heuristics

Legitimate Windows binaries live in C:\Windows\System32 or C:\Windows\SysWOW64. If Taskmgr.exe is running from C:\Users\Public\Downloads\, that’s a huge red flag.

 3. Monitor Process Behavior

Look beyond names:

  • Is it accessing LSASS?

  • Is it spawning suspicious child processes (e.g., PowerShell, cmd, or rundll32)?

  • Is it loading debug libraries like dbgcore.dll?


In a high level detection criteria this can be something like:
  ProcessName = "Taskmgr.exe" AND
  ImagePath NOT LIKE "C:\\Windows\\System32\\%" AND
  (AccessedProcess = "lsass.exe" OR LoadedDLLs CONTAINS "dbghelp.dll")