EDR flags a process reading LSASS memory. Why does it matter and what do you do?
Short answer
LSASS stores cached credentials and secrets, so an unexpected process reading its memory is a hallmark of credential theft (e.g., mimikatz-style dumping). Triage the offending process and parent, isolate the host to stop lateral movement, and rotate the credentials that could have been captured — including privileged and service accounts. It has nothing to do with graphics rendering or disk space, and ignoring it as normal can lead to domain-wide compromise. The benign-sounding distractors are exactly how analysts miss an active intrusion.
LSASS (Local Security Authority Subsystem Service) is the Windows process that handles authentication and, in doing so, holds credential material in memory — password hashes, Kerberos tickets, and sometimes cached secrets. That makes its memory the single richest target on a Windows host. An unexpected process opening a handle to LSASS and reading its memory is the classic signature of credential dumping, the technique behind tools like Mimikatz.
Why it matters so much
Stolen LSASS credentials enable lateral movement and privilege escalation. With a captured hash an attacker can pass-the-hash to other systems; with a Kerberos ticket they can move as a real user; with a domain admin's credentials they can take the entire domain. A single LSASS dump can convert one compromised laptop into a full Active Directory breach. This is not a low-severity event.
What to do
- Investigate the process and its parent — what is it, where did it run from, who launched it, is it signed?
- Isolate the host via EDR to cut lateral movement while preserving volatile evidence.
- Rotate exposed credentials — every account that had a session on that host, prioritizing privileged and service accounts; if domain controllers or domain admins were in scope, treat the domain as compromised.
Why the distractors fail
- "Normal Windows behavior — ignore it" is how a real breach gets waved through. Some signed processes do touch LSASS, but you confirm that; you don't assume it.
- "Only affects graphics rendering" and "the disk is full" are nonsense — LSASS has nothing to do with the GPU or storage. They're there to catch a candidate who doesn't actually know what LSASS is.
What the interviewer is probing
Whether you can connect "process reading LSASS" to credential theft and a potential domain-wide incident, and whether your instinct is isolate-and-rotate, not dismiss.
Likely follow-ups
- What legitimate processes do access LSASS, and how do you tell them apart from a dumper?
- How would Credential Guard or LSASS protected-process-light change the attacker's options?
- Which credentials must be rotated first, and how do you handle Kerberos krbtgt if it was exposed?