A user opened an Office document and enabled macros; EDR then shows a child process spawned by Word. What's your first action?

When a user enables macros in an Office document and Word (winword.exe) immediately spawns a child process — powershell.exe, cmd.exe, wscript.exe, or a dropped binary — that is the textbook signature of a malicious document delivering initial access. The macro is the payload's launcher; the child process is the payload (or its downloader) executing. This is one of the most common ways intrusions begin.

The right first action: contain, then investigate

• Isolate the host via EDR to cut any command-and-control and stop the payload from spreading laterally, while keeping it powered on so you don't lose memory-resident evidence.
• Capture volatile data — running processes, network connections, the full process tree, loaded modules — before it changes.
• Investigate the spawned process: what it is, what it contacted, what it wrote to disk, and whether it created persistence (a scheduled task, Run key, or service). That tells you whether one isolated host is enough or you have a wider problem.

Why the distractors fail

• "Tell the user to close the document" does nothing about a payload that has already executed. Closing Word doesn't kill a spawned powershell.exe or undo persistence.
• "Run an Office repair" treats this as an application glitch. It isn't a glitch — it's code execution.
• "Nothing — macros are safe if the file came by email" is exactly inverted. Email attachments are the primary delivery channel for malicious macros (MITRE ATT&CK T1566.001). The origin makes it more suspicious, not less.

What the interviewer is probing

Even at junior level, whether your reflex under a live alert is contain and preserve evidence rather than tidy-up or wishful thinking. They want to see that you recognize macro-to-child-process as initial access and that you don't tip the user off or destroy volatile state before you've understood what ran.