LSASS Access from a Phishing Attachment
At 10:05, EDR alerts on LSASS access by an unsigned binary named update.exe running from C:\Users\mchen\AppData\Local\Temp. The parent process is outlook.exe, and the user mchen says she opened an invoice attachment 20 minutes earlier. EDR quarantined update.exe but did not isolate the endpoint because the policy is set to monitor for this alert type. The host is a Windows 11 laptop with 16 GB RAM, used by a finance manager who has Domain Admin credentials in a separate privileged account. The laptop is currently on the corporate VLAN, and the EDR console shows a successful outbound connection to 91.203.5.14:8443 two minutes after the alert. The SOC has a memory capture tool deployed and a forensic image can be taken remotely, but the user is in a meeting and the laptop is still powered on.
1. What are your immediate actions, in order, and why?
Read the worked answer
Treat this as a likely credential-theft incident. First, isolate the laptop through EDR network containment. Do not shut it down, reboot it, or let the user continue working. Isolation stops the outbound channel to 91.203.5.14:8443 while preserving memory and running processes. Second, notify the user and the identity team that the account and the separate privileged account may be compromised. Third, capture a memory image and export the quarantined update.exe with its hash. Fourth, collect volatile data: process tree with command lines, network connections, loaded modules, scheduled tasks, services, WMI persistence, autoruns, and the Outlook attachment. Fifth, review EDR telemetry for the LSASS access rights and whether a dump file was written. The order matters because containment reduces further theft, but memory capture must happen before any reboot or remediation that would erase evidence.
2. How do you scope credential exposure and lateral movement?
Read the worked answer
Assume LSASS access succeeded until proven otherwise. Check whether mchen's privileged Domain Admin account was logged on to the laptop at the time, including cached credentials, RDP sessions, and credential manager entries. Review domain controller logs for mchen's accounts: 4624 logons, 4672 special privileges, 4768/4769 Kerberos activity, and 4720/4728/4732 account or group changes. Search for the C2 IP, update.exe hash, and Outlook parent process across all endpoints. Check for new service creation, scheduled tasks, and remote logons from the laptop to servers. Reset the user's password and the privileged account password twice, revoke sessions, and rotate any secrets accessible from the host. If Domain Admin credentials were present, involve the AD security team and consider tiered administration review. Document which credentials were confirmed exposed versus suspected, because that distinction drives the scope of resets.
3. What evidence do you preserve for forensics and possible HR or legal action?
Read the worked answer
Preserve the memory image first, with hash and chain-of-custody form. Export the quarantined binary, its hash, and the EDR detection record. Collect the Outlook message and attachment in original form, including headers and transport logs. Capture the full process tree, parent-child relationships, command lines, network connections, and DNS queries. Export Windows event logs, Sysmon logs if present, PowerShell operational logs, browser history, downloads, and recent files. Acquire a forensic disk image if the incident is likely to lead to legal or HR action, but do not delay containment for a full image. Record the user's statement and the exact time of attachment opening. Keep evidence in a restricted case folder with access logging. Do not rely on screenshots alone. Note the limitation that the host remained powered on and connected for at least two minutes after the alert, so some activity may have occurred before containment.