Falcon Credential-Dump Alert on a Domain Controller During Backup
At 01:10, Falcon raises a high-severity credential-dumping detection on DC-02. The process is rundll32.exe comsvcs.dll MiniDump, parent taskeng.exe, user svc_backup, and the command line includes the LSASS PID with output to C:/Windows/Temp/bkp.dmp. The backup team change window runs 00:30-03:00. Falcon also shows connections from DC-02 to 10.20.4.15:445 and 10.20.4.16:445, and 19 successful 4624 type 3 logons from 10.20.4.0/24 in the same hour. The backup service account is used by a scheduled task on DC-02 and has domain admin. The SOC has no ticket linking the task to the change window. EDR shows bkp.dmp was created and deleted five minutes later. The Falcon detection is not mapped to a MITRE technique in the console. The SOC asks if this is a true positive and whether to disable the service account during month-end close.
1. Assess whether this is a true positive. What correlations do you need before calling it malicious?
Read the worked answer
Treat it as a true positive for credential access until proven otherwise. rundll32 comsvcs.dll MiniDump targeting LSASS is a known credential-dumping technique. Legitimate backup software usually uses VSS or backup APIs, not a comsvcs MiniDump of LSASS. The parent taskeng.exe, the domain-admin service account, and the dump file created then deleted within five minutes are all high-risk indicators.
Correlate the scheduled task. Pull the task XML, task creation time, author, action, and trigger. Check whether it existed before the change window and whether it matches an approved backup runbook. A task created recently or pointing to a temp path is malicious. If the task is the normal backup job but its action was modified, treat that as tampering.
Correlate identity and network. Review 4624 type 3 logons from 10.20.4.0/24: which accounts, which source hosts, and whether they align with backup servers. Check whether 10.20.4.15 and 10.20.4.16 are known backup nodes or newly active. Look for 4624 type 3 followed by 4672 special privileges. The absence of a change ticket is significant but not conclusive; backup teams often work from standing windows.
Check Falcon detection context. Confirm the process hash, signer, command line, and whether bkp.dmp was read or copied. The missing MITRE mapping is a console gap, not evidence of benign activity.
2. What immediate response do you take, and should you disable svc_backup during month-end close?
Read the worked answer
Do not start by disabling the account blindly. First contain the host and preserve evidence: isolate DC-02 from unnecessary network access, kill the process if still running, capture memory, preserve the dump file if recoverable, and collect the scheduled task, Security log, and Falcon triage package. If DC-02 is a domain controller, coordinate isolation carefully because it may affect authentication.
Handle the account with a graded response. Reset svc_backup credentials and revoke its sessions, but disabling it may break backups during close. A better immediate step is to remove domain-admin rights temporarily, restrict logon to approved backup hosts, and rotate the password with the backup owner present. If the task is confirmed malicious, disable the account and rebuild the task from a known-good definition.
Assume credential exposure. A MiniDump of LSASS can expose domain credentials. Reset privileged accounts that logged on to DC-02, including the service account and any admin accounts in the logon session. Consider a double krbtgt reset if you find Golden Ticket indicators or broad credential misuse. Escalate to incident response; month-end close is a business constraint but not a reason to leave a domain-admin credential-dumping path active.
3. How would you hunt for credential reuse from this dump across the enterprise?
Read the worked answer
Hunt authentication anomalies, not just the dump file. Use Falcon and DC logs to find accounts that logged on to DC-02 before the dump and then authenticated from unusual sources afterward. Look for 4624 type 3 and type 10 logons from workstations or servers that normally do not access those accounts, especially at unusual hours. Correlate with 4672 special privileges and new service creation.
Look for lateral movement paths. Check SMB connections from 10.20.4.0/24 to other servers, remote service creation, scheduled tasks, and WMI or PowerShell remoting. Review Falcon ProcessRollup2 for psexec, wmic, and schtasks on hosts that received new logons. Search for the dumped credentials in memory or files on other systems only through approved forensic collection.
Prioritize privileged accounts. Service accounts with domain admin, backup accounts, and any admin who logged on to DC-02 are the highest risk. Reset them in a controlled sequence and monitor for re-use. If you see successful authentication with a reset account from an old session, that is strong evidence of credential reuse. Document the hunt scope, time range, and data sources so the incident team can extend it.