Word Spawns PowerShell: Deciding Whether a Workstation Incident Is Contained
A Tier-1 analyst escalates a Windows 10 engineering workstation, 10.60.22.145, after EDR flags "suspicious process injection." The timeline: at 09:41 the user opened invoice_Q3.docm from an external email; WINWORD.EXE spawned powershell.exe with -nop -w hidden -enc followed by a long base64 blob; at 09:42 PowerShell wrote C:\Users\Public\svchost.exe and registered a scheduled task named MicrosoftEdgeUpdateTaskMachineUA2 firing every 15 minutes; at 09:43 that binary opened a handle to lsass.exe with access mask 0x1010. EDR blocked the LSASS read but allowed everything else. The user is a mechanical engineer with no local admin rights, but the account belongs to a group holding local admin on 30 lab machines. Endpoint antivirus signatures are four days stale. The analyst asks whether the host is contained, what to collect first, and whether the lab machines are already in scope.
1. Reconstruct the intrusion in ATT&CK terms and state precisely what succeeded and what was blocked.
Read the worked answer
Initial access is spearphishing attachment (T1566.001) delivered as the .docm. Execution is user execution of a malicious document (T1204.002) followed by PowerShell (T1059.001); the -nop -w hidden -enc flags are obfuscation (T1027). Writing svchost.exe into C:\Users\Public is masquerading (T1036.005), placed in a world-writable directory that standard users can execute from. Persistence is a scheduled task (T1053.005) named to impersonate an Edge updater. Credential access is OS credential dumping against LSASS (T1003.001). The handle mask 0x1010 is PROCESS_VM_READ plus PROCESS_QUERY_LIMITED_INFORMATION - the minimum rights needed to read another process's memory. So execution, persistence, and defense evasion succeeded; the LSASS read was blocked. That does not mean no credentials were stolen: the PowerShell stage may have performed other collection, and a blocked handle is one technique, not the whole campaign. The host is not contained.
2. List the artifacts to collect, in priority order, and what question each one answers.
Read the worked answer
Memory first: it holds the injected payload, any plaintext credentials, and live network connections - nothing else answers "what is it doing now." Second, the scheduled task definition (schtasks query with XML output plus the TaskScheduler operational log) for creation time, author, and exact command line. Third, PowerShell operational logs 4104 script-block and 4103 module logging to recover the decoded base64 without guessing. Fourth, file-system artifacts - $MFT and USN journal for C:\Users\Public - and the binary's hash for intel lookup. Fifth, execution evidence: Prefetch, Amcache, and SRUM to prove what ran and when and to surface companion binaries. Sixth, Windows 4688 with command line plus 4624/4634 for the account's sessions. Seventh, the email itself: headers, sending infrastructure, and other recipients, which is how you find additional victims. Collect volatile before persistent data, and hash everything at capture.
3. Are the 30 lab machines in scope? What low-cost evidence would settle it?
Read the worked answer
Assume they are in scope until disproven. The account holds local admin on all 30, and the scheduled task could have been pushed by group policy or re-created by the attacker reusing the same credentials - either path reaches every one of them. Settle it cheaply first: a single EDR or SIEM query across the estate for the binary hash and the task name costs minutes, while forensic imaging 30 machines costs weeks. Then look for task-creation events matching that name, presence of the binary, 4624 type 3 or type 10 logons from 10.60.22.145 or from the user account in the relevant window, and process trees showing svchost.exe launched from C:\Users\Public. Check for the same LSASS handle pattern. Do not wait on antivirus: signatures are four days stale and the dropper is likely new. Prioritize machines where that account logged on interactively most recently.