ChecklistCONSTRUCTEDUntested
First 15 minutes: an LSASS credential dump alert on a server
A process that is not a security product has read LSASS memory. What to do before the playbook opens, in the order that protects the evidence and stops you adding your own credentials to the pile.
critical severityCredential AccessT1003.001
The clock starts when
EDR or Sysmon event 10 reports LSASS opened with memory-read access by a process that is not a security product, or a rule fires on rundll32 with comsvcs.dll.
Decide it is real, and keep what expires
Contain the host without destroying it
Treat the credentials as gone
Do not
- Do not log on to the host with a privileged account to have a look. You would be putting a fresh credential into the process that was just dumped.
- Do not reboot it, and do not let anybody reboot it to clear the alert.
- Do not delete the dump file. It is evidence of what was taken, and its timestamps are part of the timeline.
- Do not wait for confirmation that a credential was used before resetting privileged accounts.
Escalate now if
- A domain administrator or a tier-zero service account had a session on the host.
- The host is a domain controller, a backup server or a hypervisor.
- The dump file is already gone, or egress logs show it leaving.
- The same command line appears on a second host.
Minute sixteen. The checklist ends here and the response does not.
Open the endpoint execution playbookWhy this order
The instinct with a credential dump is to go and look at the host. It is the one thing on the list that makes the incident worse: an interactive or Remote Desktop logon places your credentials in the memory of the process the operator has already shown they can read. Everything in the first ten minutes is arranged so that nobody needs to.
The second instinct is to find out whether the credentials were used before resetting them. Resets are disruptive and the question is reasonable, but the cracking and the replay happen somewhere you cannot see, and the first evidence of use is usually the next intrusion stage.
What this does not cover
How the operator came to be running code on that server as an account with the privileges to open LSASS. That is the actual intrusion, and it started before this alert. The playbook linked above takes it from there.
This checklist is marked untested: it follows the cited guidance and the reasoning in the LSASS lab, and nobody has yet followed it during a real alert. Walk it through in a tabletop before you need it, and change it to fit who in your organisation is allowed to isolate a server.