LSASS Dump on a Shared Jump Host
At 03:12, EDR on JUMP-02 - a Windows jump host used around the clock by on-call administrators - alerts on rundll32.exe loading comsvcs.dll and calling MiniDump against lsass.exe (PID 712), writing C:\Windows\Temp\dbg_2024.dmp. The parent is a PSEXESVC service created four minutes earlier; the running account is svc_backup, a domain service account with local administrator rights on 40 servers. At 03:13 the dump is copied over SMB to \fs01\IT$\tools. At 03:19 svc_backup authenticates to DC-02, which it has not touched in 90 days. A documented exception exists: the nightly backup job runs procdump64.exe with -ma against lsass on three application servers between 01:00 and 02:00, from a hash-pinned signed binary. It never runs on JUMP-02 and never uses rundll32. Two earlier alerts on the same host were closed as benign last month: a PsExec software push by the same account, and a Defender folder exclusion added by an administrator.
1. Is this malicious? Lay out the discriminating evidence and what you would verify in the next fifteen minutes.
Read the worked answer
Treat this as credential theft until disproven. The decision does not hinge on whether rundll32 + comsvcs.dll is a known dumping technique - it is, and rundll32 being signed is irrelevant. It hinges on whether the observed activity fits the documented exception.
It does not, on four independent axes:
- Binary: the exception uses procdump64.exe, hash-pinned. Observed is rundll32 with comsvcs.dll MiniDump.
- Host: the exception covers three named application servers. Observed is a shared jump host.
- Time: the exception window is 01:00–02:00. Observed is 03:12.
- Invocation path: the parent is a PSEXESVC service, meaning remote service creation, not a scheduled job.
The 03:19 authentication to DC-02 by the same account, first in 90 days, seven minutes after a dump, is the pattern of pass-the-hash or credential reuse - the second half of the attack.
Verify inside fifteen minutes:
- 7045 service-install events on JUMP-02, and 4624 type 3 on JUMP-02 immediately before 03:08 to identify who created PSEXESVC.
- Whether dbg_2024.dmp still exists and its size - a full LSASS dump is typically tens of megabytes.
- 5145 on fs01 for the .dmp write, and who has read it since.
- 4624/4648 on DC-02 and 4662 for replication rights.
- Change tickets for the window, and whether the on-call administrator was actually working.
Reopen the two closed alerts. An administrator-added Defender exclusion followed by LSASS access from the same account is a classic defence-evasion precursor. 'Admin activity' is not a closure reason once that account is seen dumping credentials.
2. Given svc_backup's breadth and the 24/7 use of JUMP-02, what containment and scope decisions follow?
Read the worked answer
Immediate actions
- EDR network containment on JUMP-02, machine left powered for memory capture. Preserve dbg_2024.dmp as evidence - do not delete it - but assume its contents, including local administrator material and possibly domain credentials, are already in attacker hands.
- Disable svc_backup, reset the password twice, remove it from local Administrators on the 40 servers, and invalidate its Kerberos tickets. It is a service account: enumerate its scheduled tasks first or you will cause an outage. If jobs must run, stand up a replacement least-privilege account rather than re-enabling the old one.
Scope
- DC-02 is the pivot of concern. Hunt for DCSync (4662 with DS-Replication-Get-Changes-All), new or modified privileged accounts, and krbtgt password age. If DCSync is confirmed, plan a double krbtgt reset - disruptive and requiring the IT manager, but the only way to invalidate forged tickets.
- Retro-hunt all endpoints for rundll32 with comsvcs, for PSEXESVC service creation, and for .dmp files written to shares. Search EDR for LSASS handle opens outside the three exception hosts.
- Review JUMP-02's recent RDP sessions: a jump host concentrates privileged sessions, so a credential dump there can be worth more than one on a server.
Why not disable the on-call administrator and reboot JUMP-02: a reboot destroys memory evidence, and the administrator may be a victim of credential theft rather than the actor. Isolate systems, preserve identities, and let forensics attribute.
Notify the on-call admin group through a channel the suspect account cannot read.
3. What detection and control gaps does this incident expose, and which changes would you prioritise?
Read the worked answer
Detection gaps
- The backup exception is keyed on process name and hash but not on host, time window, or parent process. Exceptions must be as narrow as the documented behaviour and expire for review.
- No correlation rule for the sequence service-install → LSASS handle open → .dmp write to a share. Individually each event is noisy; as a chain it is almost unambiguous.
- Defender exclusion changes are not alerted on. They should be, at high severity, with the requesting user and ticket reference.
- No alert on archive or dump files appearing in administrative shares, which is also your exfil-staging gap.
Control gaps
- A single service account with local administrator on 40 servers, usable interactively on a 24/7 jump host, is a Tier-0 design failure. Move to tiered administration and LAPS for local administrator passwords.
- Enable Windows Defender ASR rules for credential stealing from lsass and for process creation originating from PSExec and WMI. Enable LSA protection (RunAsPPL) and Credential Guard where the platform supports it; they raise the cost of exactly this technique.
- Restrict who can create services on jump hosts and log it centrally.
Priority order: the chain detection first (cheap, high precision), then exclusion-change alerting, then ASR and LSA protection, then the tiered-admin programme, which is a quarter-long project but removes the underlying leverage.