TL;DR: Treat it as likely malicious until shown otherwise, because Office applications launching encoded PowerShell is a classic initial-access pattern. Read the process tree (where the document came from, what the command does once decoded, what it spawned and connected to), check the user and host context, and search for the same indicators elsewhere. If the command downloaded or executed anything, or connected out, isolate the host through EDR and declare an incident; preserve evidence before cleaning. Close as benign only with a specific, verified explanation, and feed the outcome back into tuning.
How to approach it
Give an ordered list of questions, each answered from a specific data source, with a decision point for containment. Show you can move quickly (minutes, not hours) and that you scope beyond the single host.
A strong answer
Process tree
parent, children
Decode command
in a safe tool
Document origin
email, download
Network and files
what it touched
Contain if confirmed
isolate host, reset
Then scope
Same document or sender elsewhere?
1. Read the alert and the process tree (first minutes).
- Parent and child:
WINWORD.EXElaunchingpowershell.exeis rarely legitimate. Note command-line arguments, and decode the base64 command in a safe tool, never by running it. - What did PowerShell do next: child processes, network connections (to which domains and IPs), files written, registry changes, scheduled tasks created.
- The document: its name, where it came from (email attachment, download, file share), and when the user opened it.
2. Context.
- User: finance staff are frequent phishing targets; is the account privileged, has it logged in elsewhere recently?
- Host: is it managed and patched, are attack surface reduction rules on, did EDR block anything?
- Is this a known test (a scheduled phishing simulation or red team)? Confirm with the owner, not the user.
3. Decide on containment quickly. If the decoded command downloads or runs a payload, or if there are outbound connections to unknown infrastructure, isolate the host with EDR network containment now. Isolation keeps the EDR channel open for investigation while cutting the attacker off. Declare an incident and open a channel.
4. Scope.
- Search EDR and email logs for the same document hash, sender, subject, domains and IPs across the organisation.
- Check whether other users received and opened the same email; pull the email from mailboxes.
- Check the user's account for suspicious sign-ins, mailbox rules, OAuth app consents and session tokens, since many initial-access payloads aim to steal credentials.
5. Preserve and investigate. Collect EDR telemetry, the document, a memory image if the payload ran, and relevant logs before remediation. Identify persistence mechanisms and any credentials exposed.
6. Remediate and recover. Remove persistence, reimage if code execution was confirmed (cleaning in place leaves doubt), reset credentials and revoke sessions, block indicators, and restore the user.
7. Close the loop. Record the verdict and evidence. If benign (a signed internal macro used by finance), document why and tune the detection narrowly, for example by allowlisting that signed macro's specific behaviour, not all Office-spawned PowerShell. If malicious, add detections for the payload's later stages and report the phishing campaign.
What interviewers probe next
- "The decoded command just checks the time. Close it?" Not yet; reconnaissance or a staged loader can look innocuous. Check what happened next on the host and whether the same document went to others.
- "Why isolate instead of shutting the laptop down?" Isolation preserves volatile memory and keeps the EDR session for investigation; powering off destroys evidence.
- "How long should this take?" Initial triage and a containment decision in minutes; full scoping can take hours.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
EDR alerts that a Word document on a finance laptop launched PowerShell with an encoded command, and the user is in a meeting.
Start here
How suspicious is this pattern?
Why would a Word document start PowerShell?
Very. Office applications launching encoded PowerShell is a classic initial-access pattern from malicious documents. Treat it as likely malicious until shown otherwise; legitimate business documents rarely need to spawn a script interpreter with hidden commands.
Carry it forwardOffice spawning encoded scripts is presumed malicious.
Weak answerWaiting for the user to explain before acting.
Constraint changes
What do you look at first?
What did the command actually do?
The process tree: where the document came from (email, download), what the decoded command does, what it spawned, which files it wrote and which network connections it made. Then the user and host context: role, recent sign-ins and other alerts.
Carry it forwardRead the process tree and decode the command.
Weak answerTriaging from the alert title alone.
Constraint changes
What if the command downloaded a file and connected out?
Has the attacker gained a foothold?
That indicates execution beyond the document. Isolate the host through EDR, declare an incident, and preserve evidence (memory, process details, the document and downloaded file) before cleaning. Block the destination and search for it elsewhere.
Carry it forwardDownload or outbound connection means isolate and declare.
Weak answerDeleting the file and closing the alert.
Constraint changes
How do you check whether others are affected?
Who else received the same email?
Search for the same document hash, sender, subject, command pattern and network destinations across email and endpoint telemetry. Finance teams are often targeted together, so expect related messages to colleagues.
Carry it forwardHunt for the same indicators across the estate.
Weak answerTreating it as one user's problem.
Constraint changes
When can you close it as benign?
Could you show the explanation to a reviewer?
Only with a specific, verified explanation, such as a known internal tool whose command and source you confirmed. Record the reason, and feed the outcome back into tuning so the same legitimate case does not page again, without suppressing the malicious pattern.
Carry it forwardClose as benign only with verified explanation.
Weak answerClosing because the user says they opened an invoice.
Now defend it
How would you handle the alert end to end?
Presume malicious; read the process tree and decode the command; check user and host context; if anything downloaded, executed or connected out, isolate the host, declare an incident and preserve evidence; hunt for the same indicators and email across the estate; block destinations; close as benign only with a verified explanation; and feed the outcome into tuning.
How it's scored
Weak: "Run the PowerShell command in a sandbox to see what it does" or "ask the user what they clicked".
Hire: Reads the process tree, decodes safely, checks network activity, isolates on evidence of execution, and searches for the same indicators elsewhere.
Strong Hire: Orders questions with data sources, makes an early containment decision, scopes through email and identity (mailbox rules, OAuth consents, sessions), preserves evidence before remediation, prefers reimaging, and tunes detections narrowly from the verdict.
Common mistakes
- Executing the payload to see what it does.
- Investigating only the one host.
- Forgetting the user's identity and cloud sessions.
- Closing benign alerts without recording why.