Guided lab: the credential dump that used nothing but Windows
An LSASS dump taken with a DLL that ships in System32, called by ordinal so the obvious rule misses it. Work out which process touched LSASS, which access mask matters, and whose credentials you now have to assume are gone.
- ATT&CK
- T1003.001
The call
2026-08-28, 11:42:00 UTC. The EDR at Marlowe and Fenn Surveyors, a firm of chartered surveyors, raises a medium-severity alert on MARL-APP-06: "suspicious rundll32 activity". It is the fourth rundll32 alert this week and the other three were a printer driver. You have the Sysmon log for the host.
Artifact 1: process creation
11:41:52 Event ID 1 Process Create
Image: C:\Windows\System32\rundll32.exe
OriginalFileName: RUNDLL32.EXE
CommandLine: rundll32.exe C:\Windows\System32\comsvcs.dll, #24 724 C:\Users\Public\Libraries\d.bin full
ParentImage: C:\Windows\System32\cmd.exe
User: MARLOWEFENN\adm.voss
IntegrityLevel: High
LogonId: 0x2B44756
Q1
The command line never says "lsass" and never says "dump". What is the number 724, and how would you prove it rather than assume it?
Stuck? Where to look
The export being called takes three arguments. Think about what a function that writes a dump needs to be told first.
Show me the method
Look for another event in the same second that names a process with that ID. Sysmon event 10 records both the source and the target process IDs.
Show the answer
724 is a process ID. The MiniDump export of comsvcs.dll takes a process ID, an
output path and the word full. Artifact 2 confirms it: the event 10 below has
TargetProcessId: 724 and TargetImage: lsass.exe.
Do not skip the proof. A PID in a command line is only a number until another record ties it to a process, and "724 is probably LSASS" is an assessment where "event 10 names PID 724 as lsass.exe" is an observation.
Q2
A detection rule that alerts on command lines containing MiniDump was deployed on
this host and did not fire. Why not?
Stuck? Where to look
Look at what sits where the function name should be.
Show the answer
The export was called by ordinal. #24 is the position of MiniDump in the
DLL's export table, and rundll32 accepts either form. Operators use the ordinal
precisely because rules match the word.
A rule that survives this matches the DLL name together with either spelling, and better still does not depend on the command line at all: the event 10 in Artifact 2 exists however the dump was requested.
Artifact 2: who opened LSASS that minute
11:41:52 Event ID 10 ProcessAccess
SourceImage: C:\Windows\System32\rundll32.exe
TargetImage: C:\Windows\System32\lsass.exe
TargetProcessId: 724
GrantedAccess: 0x1FFFFF
CallTrace: C:\Windows\SYSTEM32\ntdll.dll+9d4c4|C:\Windows\System32\KERNELBASE.dll+2c13e|C:\Windows\System32\comsvcs.dll+1a4b2|C:\Windows\SYSTEM32\dbgcore.DLL+6f1e
11:41:58 Event ID 10 ProcessAccess
SourceImage: C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24090.11-0\MsMpEng.exe
TargetImage: C:\Windows\System32\lsass.exe
TargetProcessId: 724
GrantedAccess: 0x1000
11:41:53 Event ID 11 FileCreate
Image: C:\Windows\System32\rundll32.exe
TargetFilename: C:\Users\Public\Libraries\d.bin
Q3
Two processes opened LSASS within six seconds. One is the finding and one is the antivirus doing its job. Which field separates them, and which bit of it?
Stuck? Where to look
Both events have the same target. Compare what each process was allowed to do with the handle it got.
Show me the method
GrantedAccess is a bitmask. Look up PROCESS_VM_READ and
PROCESS_QUERY_LIMITED_INFORMATION in Microsoft's process access rights table
and test each mask against them.
Show the answer
GrantedAccess, and specifically the 0x0010 bit, PROCESS_VM_READ.
0x1000 is PROCESS_QUERY_LIMITED_INFORMATION on its own. A handle with that
mask can ask what the process is called and whether it is still running. It
cannot read a byte of its memory, so it cannot dump credentials.
0x1FFFFF is PROCESS_ALL_ACCESS, which includes PROCESS_VM_READ. The call trace
passing through comsvcs.dll and dbgcore.DLL, the library that writes minidumps,
closes the question.
This is why filtering LSASS access alerts by source image is fragile and filtering by mask is not. Security products open LSASS constantly. Very few things need to read its memory.
Q4
The dump file is on disk. State precisely what this evidence does not tell you, and what you have to assume as a result.
Stuck? Where to look
Two separate unknowns: what was inside the file, and where the file went next.
Show the answer
It does not tell you whose credentials were in LSASS, and it does not tell you whether the file left the host.
For the first, do not guess. Every account with a logon session on MARL-APP-06 at 11:41:00 had material in that process. Pull event 4624 for the host, take every session that had not yet logged off, and treat each of those accounts as compromised: interactive and RemoteInteractive logons first, because those leave reusable credentials in memory, and service accounts running on the host.
For the second, nothing here settles it. A 40 MB file in a world-writable
directory is staged for collection. You need the network telemetry for the
minutes after 11:42:00, and file events showing a read, a copy or a deletion of
d.bin.
Observed: adm.voss's session ran rundll32 against comsvcs.dll with LSASS's PID,
obtained a full-access handle, and wrote d.bin. Assessed, with high confidence:
an LSASS credential dump. Unknown: contents and exfiltration.
What to do with it
Reset every account that had a session on the host, starting with the privileged ones, and find out how adm.voss's session came to be running this at all. That account is either compromised or misused, and the dump is the second thing that happened on this host, not the first.
For prevention, enabling LSA protection (RunAsPPL) stops this particular route, and Credential Guard removes much of what is worth stealing. The Sigma endpoint pack has a rule for the comsvcs route that matches the ordinal as well as the name.
Argue underneath
The alert was medium severity and it was the fourth rundll32 alert that week.
Should LSASS access with PROCESS_VM_READ from a non-security process page
somebody at any hour, given how rarely it is benign? What would that cost your
team in a month, and is the number you are imagining measured or assumed?
Sources
The scenario above is invented. These are what its real half rests on.
Discussion
GuidelinesSign in to comment. Corrections and additions are the point: this is a working document.