An ATT&CK technique page has a description of the behavior, the platforms it applies to, detection guidance and mitigations. Reading T1003.001, OS Credential Dumping: LSASS Memory, shows how to turn one page into a log requirement, a detection idea and a hardening list. This post walks through it.
Step 1: read the header
The page names the sub-technique, its identifier T1003.001, its parent technique T1003, its tactic (Credential Access, TA0006) and its platform (Windows). It lists version 1.5, created 11 February 2020 and last modified 12 May 2026, and reflects ATT&CK v20. Check the modified date. Content changes, and a page you read two years ago may differ.
Step 2: understand the behavior
The description says attackers target credentials held in the memory of the Local Security Authority Subsystem Service, known as LSASS. They can read that memory directly or dump it to a file and analyze it elsewhere. Harvested credentials can then support lateral movement.
The page also covers Security Support Provider DLLs, which load into LSASS at boot and can reach stored passwords. It names four: MSV, WDigest, Kerberos and CredSSP.
Step 3: turn the detection note into a log requirement
The page's detection strategy looks for a non privileged or unusual process that opens a full access handle to lsass.exe and then performs a memory dump, file creation or registry change.
What logs would show that? You need process access events, file creation events and registry events with enough detail to name the source process. Sysmon's process access event, for instance, is described by Microsoft as enabling detection of tools that read LSASS memory. If you do not collect those events, this detection cannot work. That is a logging gap, and finding it is the value of the exercise.
Step 4: pull the mitigations into a hardening list
The page lists seven mitigations. In plain terms:
- Enable attack surface reduction rules that protect LSASS.
- Use Credential Guard, noting it is not on by default and has hardware requirements.
- Restrict or disable NTLM and disable WDigest.
- Use complex, unique local administrator passwords.
- Limit domain accounts in local administrator groups and restrict privileged account use across tiers.
- Enable Protected Process Light for LSA.
- Train users not to reuse passwords across accounts.
Several of these are system configuration, not detection. Prevention reduces how often you need the alert.
Step 5: write down the result
For each technique you review, record four things: the log source needed, whether you collect it, the rule that covers it with its last test date, and the hardening steps with owners. A short table beats a long document.
What to be careful about
Do not copy detection text into a production rule without testing. Legitimate tools, such as security software and crash handlers, also touch LSASS memory, so you will need exclusions with reasons.
Quick check
Do I need to read every technique page?
No. Choose the techniques that match your systems and likely threats, then go deep on those.
Sources
Last reviewed: 19 October 2026.
