LSASS Access from a Masqueraded Scheduled Task
A Windows Server 2019 file server, FS-03, hosts 12 TB of engineering drawings. EDR is in audit-only mode because a line-of-business application crashed under blocking. At 03:12 the EDR sensor records rundll32.exe launched from C:\ProgramData\Microsoft\Windows\Caches\a1b2c3\updating.tmp, accessing lsass.exe with read-memory rights. The parent is svchost.exe hosting Task Scheduler; the task is named \Microsoft\Windows\UpdateOrchestrator\Backup and triggers at 03:00 daily. Windows Security logs show 4624 type 3 logons from 10.10.5.88, a marketing workstation, at 03:10 and 03:11, and 4672 special privileges assigned to the same account. That account is a domain service account used by the backup application on seven servers. No EDR block occurred. The server owner reports no performance issues and asks you not to reboot.
1. Do you contain now? Justify the decision and give the order of actions, including what must happen before remediation.
Read the worked answer
Contain now, but preserve memory before remediation. The combination is not ambiguous: a scheduled task masquerading under a Microsoft path launches rundll32.exe from C:\ProgramData\...\Caches, and that process requests read access to LSASS. Legitimate UpdateOrchestrator tasks run from %SystemRoot%\System32, not ProgramData. The 4624 type 3 logons from a marketing workstation at 03:10–03:11 and 4672 special privileges on the backup service account suggest credential use and lateral movement.
Order: 1) Use EDR live response to capture memory, the process command line, parent chain, and network connections. 2) Network-isolate FS-03. 3) Disable the scheduled task and quarantine the binary. 4) Disable and rotate the service account; it is used on seven servers, so assume compromise. 5) Do not reboot until memory is captured.
Why not just delete the task: the binary and task XML are evidence, and the attacker may have other persistence. Deleting one artifact without scoping the seven servers invites re-entry.
2. How would you scope the compromise using host and identity artifacts? What would make you revisit the severity?
Read the worked answer
Scope using host and identity artifacts, not just the alert. On FS-03, check Task Scheduler operational logs for 4698 (task created) and 4702 (task updated), and find the creation time and source. Review Security 4624, 4625, and 4672 around 03:00–03:15, and EDR telemetry for rundll32.exe writing to LSASS across all hosts. The service account's authentication history will show which of the seven servers and which workstation were used. On 10.10.5.88, look for the same binary hash, scheduled tasks, and outbound connections.
Pivot on the account: a domain service account with special privileges on seven servers is a high-value pivot. Check for new services, run keys, WMI subscriptions, and scheduled tasks on each. If the account password is unchanged, assume the attacker can reproduce access.
Decision point: if the task was created by the backup application's installer and the binary is signed by the backup vendor, revisit severity. Check the signature and hash against vendor documentation before declaring a breach.
3. The server owner asks you to turn on EDR blocking globally. Recommend a policy change and the compensating controls, with a test plan.
Read the worked answer
Change EDR policy, but not by simply turning blocking on everywhere. Audit-only mode exists because the line-of-business app crashed. Enabling block globally risks an outage on a 12 TB production file server. Instead, create a narrow block rule for LSASS access by non-allowlisted processes, and keep the rest in audit. Test the rule on a non-production clone of FS-03 with the backup app running.
Also fix the underlying exposure: the server should not accept SMB or RDP from a marketing workstation. Add host firewall rules restricting management traffic to jump hosts. Rotate the service account to a group managed service account with least privilege, and remove interactive logon rights. Add detection for scheduled tasks created under \Microsoft\Windows\UpdateOrchestrator\ whose action path is not in System32.
Metrics: number of LSASS-access events blocked, false-positive rate from the backup app, and time to detect a new task in a nonstandard path. Re-enable broader blocking only after the vendor app is fixed or excluded by hash.