EDR LSASS Alert on Engineering Workstations
An engineering firm with 240 endpoints runs EDR managed by a small SOC. At 02:14 on Tuesday, EDR raises a high-severity alert on ENG-WS-042: powershell.exe accessed LSASS memory, parent taskeng.exe, command line contains an encoded blob. The user is jdoe, a design engineer. The same alert fires on three other hosts in the same OU within 11 minutes. All four have a scheduled task named 'VendorBackupHealth' created 9 days ago, and the helpdesk change log shows a backup agent update scheduled for 02:00 that week. EDR network telemetry shows each host made HTTPS connections to 198.51.100.77, a newly observed IP with no reputation data, sending 2-4 MB per host. The backup vendor's known update servers are in 203.0.113.0/24. No files were encrypted. The SOC has no packet capture and one analyst on shift.
1. What triage steps and evidence would you collect before deciding whether this is malicious?
Read the worked answer
Start with the scheduled task and process tree, not the alert title. Export the task definition, action, trigger, author, and creation source; compare it with the change record. Pull the PowerShell command line and decode it in an isolated environment or with a safe decoder, not by executing it. Check the PowerShell file hash, signature, and path, and the parent process chain. Compare the four hosts for identical task XML, hash, and network destination. Resolve 198.51.100.77 and check passive DNS, TLS certificate or SNI if available, and proxy logs. Ask the backup vendor whether 198.51.100.77 is an authorized update or telemetry endpoint and whether the update accesses LSASS. Preserve EDR telemetry, task XML, process memory if policy allows, and relevant Windows event logs before remediation.
2. Would you isolate the four hosts? Justify the decision given business impact and uncertainty.
Read the worked answer
Yes, isolate them at the network level using EDR containment rather than shutting them down, because the combination of LSASS access, an encoded command, a newly observed external IP, and four hosts in 11 minutes is suspicious enough to warrant containment. Isolation limits command and control and lateral movement while preserving memory and remote forensic access. The business impact is real: design engineers may lose access to file shares and licensing, so notify the engineering manager and agree on a short containment window. Do not delete the scheduled task or uninstall the agent before collecting evidence. If the vendor quickly confirms the binary hash, signature, and destination as legitimate, release containment and document the exception; if not, escalate to incident response and reset credentials for the affected users.
3. If this is a false positive, what tuning is needed? If it is malicious, what is the likely objective and next containment step?
Read the worked answer
If false positive, do not broadly allowlist PowerShell or LSASS access. Allowlist the specific signed vendor binary by hash and path, scoped to the backup service account and the scheduled task, and require the vendor to document why its health check reads LSASS. Add a lower-severity rule for that exact behavior so other LSASS access still alerts. If malicious, the likely objective is credential access followed by command and control. Next steps are to reset passwords for jdoe and any accounts that logged on to the four hosts, rotate local administrator and service account secrets, block 198.51.100.77, hunt for the same task XML and IP across all endpoints, and review domain controller logs for authentication from those hosts. Check whether the encoded command created persistence or scheduled tasks beyond the four known hosts.