Suspicious PowerShell.
Not Every Encoded Command Is An Attack.
An alert triage reference, not an incident lifecycle. This is what a SOC analyst actually does in the minutes after AMSI, an EDR sensor, or a script block logging rule flags PowerShell content: what to pull first, what separates a real intrusion from a noisy admin tool, and when to stop triaging and escalate. For the 4104/4103 script-block-logging events this alert is usually built on, see the Windows Event ID Cheatsheet.
Alert Overview
This alert rarely fires from a single sensor. Most PowerShell detections are one of four trigger sources, and knowing which one raised the alert changes what data is available to triage it with.
Common Trigger Sources
AMSI Or EDR Flag ├── Antimalware Scan Interface or an EDR sensor flags the PowerShell content itself, not just the process launch └── The flag usually fires on what the script does, not on the fact that PowerShell ran // the most common single trigger, and also the noisiest one Event ID 4104, Script Block Logging ├── A detection rule matches decoded script block content against a known-bad string or pattern └── This is the richest data source available for this alert. it shows the actual code, not just the command line // pull this first, everything else in triage builds on it Encoded Or Obfuscated Command Line ├── -EncodedCommand, a base64 blob, or string concatenation built to defeat keyword matching └── Obfuscation alone isn't malicious by itself. it just raises the bar for how closely triage has to look // presence of obfuscation is a reason to look closer, not a verdict on its own Unusual Parent Process ├── PowerShell spawning from winword.exe, excel.exe, outlook.exe, or a browser process └── A normal admin session spawns PowerShell from explorer.exe, a terminal, or an RMM agent, not an Office app // parent process is often the fastest signal for separating real from noise
Initial Triage Steps
Work through these in order. Each step narrows the picture before the next one, and skipping ahead usually means redoing work later.
Working The Alert, In Order
1. Pull the full command line and the decoded script block ├── Event ID 4104 (script block logging) gives the decoded content, not just what was typed at a prompt └── Event ID 4103 (module logging) shows which cmdlets and modules actually ran // the command line alone is often close to useless if the payload is encoded 2. Identify the parent process ├── A legitimate admin or RMM tool, an Office application, or something unrecognized entirely └── This one fact narrows the rest of the triage more than almost anything checked afterward // know what should have launched PowerShell before judging what did 3. Decode any base64 or -EncodedCommand content ├── Read what the payload actually does before forming an opinion on it └── An encoded string that decodes to a harmless one-liner ends the triage fast // don't triage off the encoded blob, decode it and read the result 4. Check for execution-policy-bypass flags together ├── -ExecutionPolicy Bypass, -NoProfile, -WindowStyle Hidden, -NonInteractive └── Any one alone shows up in legitimate scripting constantly. all four together is a rarer, more deliberate combination // look for the combination, not any single flag in isolation 5. Check for download-cradle patterns ├── IEX (New-Object Net.WebClient).DownloadString(...), or Invoke-WebRequest piped into Invoke-Expression └── This pattern fetches remote content and runs it without ever writing a file to disk // a confirmed cradle turns the rest of this triage into an active-compromise response
True Positive Indicators
Signals that point toward malicious use. None of these alone is automatic proof, but they carry real weight, especially in combination.
TRUE POSITIVE
Encoded Command Plus Obfuscation
Layered together, not used alone
-EncodedCommand or -enc combined with excessive string concatenation, character-code building, or repeated encoding layers. A single encoding pass is common. stacked obfuscation on top of it is a deliberate attempt to defeat detection.TRUE POSITIVE
In-Memory Download Cradle
Fetches and executes without touching disk
Content that pulls remote code and runs it directly in memory, never writing a file that antivirus could scan. This is one of the clearest fileless-execution patterns and is rare in legitimate day-to-day admin work.
TRUE POSITIVE
AMSI Bypass Pattern
High confidence malicious on its own
Reflection-based AMSI patching, or the classic
[Ref].Assembly-based tricks that flip the AMSI scan result in memory. There's no legitimate business reason to disable the interface that's supposed to be scanning the script itself.TRUE POSITIVE
Office Or Script-Host Parent Process
winword.exe, excel.exe, outlook.exe, or wscript.exe
PowerShell launched by an Office application or a script host almost always means macro-spawned or script-spawned execution, which is the classic delivery chain for a phishing payload rather than routine administration.
TRUE POSITIVE
Hidden Window, No Profile, Bypass Together
A combination rare in legitimate admin scripts
Hidden window, no profile load, and execution-policy bypass appearing on the same command line is a pattern built to run unattended and unseen. Legitimate admin work rarely needs all three at once.
False Positive Indicators
Reasons the same flags show up on legitimate activity. Worth ruling out before treating every encoded command as an attack.
FALSE POSITIVE
Known RMM Or Admin Tooling
SCCM, Intune, and backup agents encode commands by design
Software deployment and configuration tools routinely wrap their commands in base64 or
-EncodedCommand to avoid quoting issues, not to evade detection. Confirm the source before treating the encoding itself as suspicious.FALSE POSITIVE
Internal Automation Or DevOps Tooling
Same flags, a scheduled and non-interactive purpose
Internal scripts and pipelines use
-NonInteractive, -NoProfile, and hidden windows for the same reason a real intrusion does: they need to run unattended, without a user session in the way.FALSE POSITIVE
Security Tooling Triggering Its Own Rule
The EDR agent or a vulnerability scanner scanning itself
Some security products use PowerShell internally for routine scans or self-checks, and can trip the very detection rule they're feeding data into. Check the process lineage against known agent behavior before escalating.
Escalation Criteria
The conditions under which triage stops and this becomes a live incident, not a decision to sit on while gathering more context.
ESCALATE
Confirmed Download Cradle
Escalate immediately, treat the host as compromised
Once the cradle is confirmed to have executed an unknown remote payload, stop treating this as an alert to be ruled out and start treating the host as actively compromised. The investigation shifts from triage to response.
ESCALATE
Confirmed AMSI Bypass
High-confidence malicious on its own, regardless of what else is present
An AMSI bypass technique doesn't need corroborating evidence to justify escalation. Confirm the pattern and escalate, even if nothing else in the alert looks unusual.
ESCALATE
Correlates With A Phishing Email To The Same User
Link the investigations, don't run them separately
If the PowerShell activity lands close in time to a phishing email delivered to the same user, the two are very likely the same intrusion. Escalate as one linked investigation instead of two open, unconnected tickets.
Containment Actions
What to do once the alert is confirmed malicious, in an order that protects evidence before it protects convenience.
CONTAIN
Isolate And Preserve Before Remediating
Logs get destroyed by cleanup faster than by the attacker
Isolate the host and preserve the PowerShell transcript and script-block logs before any remediation action touches the system. A reimage or a quick fix run first destroys the evidence needed to scope the incident.
CONTAIN
Block The Destination
Cut off where the payload was reaching
Block the destination URL or IP that the download cradle reached out to. This stops the same infrastructure from being used again against this host or a different one while the rest of the response continues.
CONTAIN
Hunt For The Same Pattern Environment-Wide
One alert rarely means one host
Hunt for the same script hash or content pattern across the environment using a module-logging content match. A script that ran once was often staged or delivered to more than one endpoint.
CONTAIN
Verify Logging Coverage Fleet-Wide
A hardening follow-up, not an afterthought
Confirm Script Block Logging and Constrained Language Mode are actually enabled fleet-wide, not just on the host that happened to alert. Gaps here are usually how the next PowerShell-based incident goes unnoticed until it's much further along.