LSASS Memory

LSASS (Local Security Authority Subsystem Service) is the Windows process that holds credential material in memory after a user logs on: password hashes, Kerberos tickets, and other secrets needed to support single sign-on so a user isn't re-prompted for a password every time they access a resource.

Anyone who can read LSASS's memory with sufficient privilege can extract those credentials. This is one of the most consequential techniques in an intrusion. A successful LSASS dump often hands an attacker the keys to move far beyond the single host they started on.

With local admin rights on a compromised host, an attacker dumps LSASS's memory to a file (using built-in tools like Task Manager, or purpose-built ones like Mimikatz, ProcDump, or comsvcs.dll's MiniDump export), then extracts credentials from that dump offline: cached passwords, hashes usable for pass-the-hash attacks, and Kerberos tickets.

The credentials harvested this way belong to whoever has logged into that machine, which can include a domain admin doing routine support. That is why a single successful LSASS dump can be the pivot point that turns a low-value workstation compromise into full domain compromise.

Data source: Sysmon process-access records (Event ID 10) for handles opened on LSASS, naming the requesting image and account -- a channel a Security log clear misses

{
  "host": {
    "name": "APP01"
  },
  "event": {
    "code": "10",
    "action": "ProcessAccess"
  },
  "winlog": {
    "event_data": {
      "SourceImage": "C:\\\\Users\\\\Public\\\\rundll32.exe",
      "TargetImage": "C:\\\\Windows\\\\System32\\\\lsass.exe",
      "GrantedAccess": "0x1fffff"
    }
  }
}

Prebuilt Elastic rule: Suspicious Lsass Process Access

Not every process that touches LSASS is malicious. Plenty of legitimate security and system tooling does. What matters is the requesting process and the specific access rights requested: access masks associated with full memory-read capability (values like 0x1fffff, 0x1010, 0x120089 turn up across most dumping tools) from a process that isn't a known, trusted security product is the strongest signal.

Hunting manually: filter Sysmon Event 10 where TargetImage is lsass.exe, exclude known-good source processes (your EDR, antivirus), and flag the remaining access attempts for review, paying particular attention to the specific GrantedAccess value requested.

A second, related situation worth knowing: not every credential-dumping attempt succeeds, and a blocked or failed attempt is also worth detecting. If LSASS is protected against unauthorized access (through mechanisms like LSA protection or Credential Guard), an attacker's dumping tool may fail to get the access it needs.

The important lesson here is a general one: the absence of the ProcessAccess event you'd expect from a successful dump is not, by itself, proof that nothing was attempted. It could mean an attempt was blocked, but it could just as easily mean this specific telemetry simply isn't being collected on that host, since ProcessAccess auditing has to be deliberately enabled. Don't treat a missing event as a clean bill of health without first confirming the sensor actually covers that signal.

When the expected access-event evidence isn't there, a more resilient pivot is the attempting process's own execution record, which doesn't depend on ProcessAccess auditing at all. A dumping attempt still has to run as a process, so if you can identify LSASS's process ID from ordinary process events in that window, searching for a command line that carries that PID as an argument can surface the attempt even when the access itself produced no direct evidence.

Legitimate EDR and antivirus products read LSASS memory routinely as part of their own monitoring. This is by far the most common source of noise when hunting this technique.

The distinguishing signal is knowing your own environment's trusted security tooling and excluding it explicitly, then treating any *other* process requesting LSASS access as worth investigating, especially unsigned binaries and signed tools not normally used for security purposes (legitimate sysadmin utilities being repurposed, for instance). Crash-handling processes (WerFault.exe) accessing a crashed LSASS is also a known benign pattern worth excluding specifically rather than broadly ignoring all LSASS access.

• MITRE ATT&CK T1003.001: LSASS Memory
• Elastic Security: Suspicious Lsass Process Access

2 scenarios in this catalog cover T1003.001. We don't name them — identifying the technique is part of what a scenario grades. Explore the dashboard →