On Windows, an alert shows a new scheduled task launching PowerShell from %TEMP%. What is this likely to be and your move?
Short answer
Legitimate software rarely runs PowerShell out of %TEMP% via a freshly created scheduled task — it's a common persistence and execution technique. Examine the task definition, the invoked script, the creating process and the timeline, contain the host, and sweep the environment for the same pattern. Updates don't look like this, blanket-trusting scheduled tasks ignores a known TTP, and deleting System32 breaks the OS while doing nothing about the threat. The first three options all reflect dangerously weak judgment.
%TEMP% is a scratch directory that no legitimate, installed application uses as the permanent home for code it schedules to run. A newly created scheduled task that launches powershell.exe against a script in %TEMP% combines two attacker favourites: a durable autostart mechanism and a script interpreter that lives off the land. Treat it as suspicious by default.
The right move: triage, then contain
Work the evidence in order:
- Read the task definition — its trigger, the exact command line, run-as account, and creation time.
- Pull the script from
%TEMP%and analyze it; expect obfuscation, base64, or a download cradle that fetches a second stage. - Identify the creating process and parent to learn how the task got there (a macro? a dropped binary? remote creation?).
- Build a timeline around the creation time to see what else happened.
- Contain the host (network-isolate via EDR, keep it powered on to preserve memory).
- Hunt the same TTP across the fleet — the same task name, script hash, or command-line pattern often landed elsewhere.
Why the distractors are dangerous
- "A routine Windows update" — Windows Update does not stage PowerShell scripts in a user's
%TEMP%via a new task. Calling it routine is how real intrusions get closed as false positives. - "Scheduled tasks are always safe" — they're a documented MITRE ATT&CK persistence technique (T1053.005); blanket trust is exactly the blind spot attackers rely on.
- "Delete the System32 folder" — this is the old prank-as-advice; it cripples the OS and does nothing to the threat. Picking it shows no understanding of the system.
What the interviewer is probing
Whether you recognize a textbook persistence pattern, resist explaining it away, and follow a disciplined triage-then-contain-then-hunt sequence instead of reacting destructively.
Likely follow-ups
- Which Windows event IDs record scheduled-task creation, and how would you pivot from one to the creating process?
- How would you decode and analyze an obfuscated or base64-encoded PowerShell command line safely?
- After containment, how do you scope whether other hosts got the same task?