PowerShell is the most abused scripting engine in Windows environments. It provides attackers with a built-in, trusted execution environment capable of downloading payloads, injecting shellcode, querying Active Directory, moving laterally via WinRM, and bypassing traditional antivirus — all without writing a binary to disk. It is present on every modern Windows system and cannot be safely removed.
The primary evasion technique is command-line obfuscation: base64 encoding (-EncodedCommand), execution policy bypass flags, hidden window style, and AMSI patching. This SOP guides analysts through decoding these commands, correlating Script Block Logging output (which captures the decoded payload), and identifying the network and process chain that follows a malicious PowerShell execution.
◈ Table of Contents
Background
CONTEXT| MITRE | Technique | PowerShell Pattern | What Attacker Achieves |
|---|---|---|---|
| T1059.001 | Command and Scripting Interpreter — PowerShell | powershell.exe -EncodedCommand, IEX, Invoke-Expression, DownloadString | Arbitrary code execution in a trusted, signed process — common for all stages of attack chain |
| T1027 | Obfuscated Files or Information | -EncodedCommand (base64), -Enc, string concatenation, char code replacement, SecureString encoding | Hides payload content from command-line logging and signature-based detection |
| T1562.001 | Impair Defenses — Disable or Modify Tools | Set-MpPreference -DisableRealtimeMonitoring $true; AMSI patch via memory write to amsi.dll | Disables Windows Defender real-time monitoring or patches AMSI in-memory to bypass script scanning |
| T1105 | Ingress Tool Transfer | (New-Object Net.WebClient).DownloadString('http://...'); Invoke-WebRequest | Downloads second-stage payload directly into memory without writing to disk |
| T1086 / T1059 | PowerShell Remoting | Enter-PSSession, Invoke-Command -ComputerName, New-PSSession | Lateral movement via WinRM — executes commands on remote hosts using current credentials |
| Source | Sentinel Table | Key Fields | Required Setting |
|---|---|---|---|
| MDE Process Events | DeviceProcessEvents | FileName, ProcessCommandLine, InitiatingProcessFileName — captures the outer encoded command line | Defender for Endpoint onboarded |
| PowerShell Script Block Logging | Event (EventID=4104) | RenderedDescription — contains the DECODED PowerShell content before execution. Most important log source for obfuscated PS. | GPO: Computer Config → Windows Settings → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging = Enabled |
| PowerShell Module Logging | Event (EventID=4103) | Pipeline execution details — shows module imports and command outputs | GPO: Turn on Module Logging = Enabled; specify * for all modules |
| Windows Security Events | SecurityEvent (EventID=4688) | CommandLine field — process creation. Less detail than MDE but available without Defender. | Audit Process Creation + command-line logging GPO |
Script Block Logging (Event 4104) is the single most important control for PowerShell threat detection. Without it, encoded commands are invisible to analysts — you only see the base64 blob, not the decoded payload. Confirm GPO is deployed on all endpoints before declaring an investigation complete.
Identification
DETECT & INVESTIGATEAttackers encode PowerShell commands in base64 to prevent command-line logging systems from reading the actual instructions. The -EncodedCommand flag tells PowerShell to decode and execute the base64 blob — analysts must decode it manually or via Script Block Logging (Event 4104) to understand what the command actually did. Without decoding, you cannot determine intent, scope, or payload type.
- 1Locate the PowerShell process creation event in the device timeline. Note the full command line including all flags. If you see
-EncodedCommand,-Enc, or-efollowed by a long string of characters — that string is base64-encoded PowerShell. - 2To decode: extract the base64 string (everything after the flag). In PowerShell:
[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String('BASE64STRING')). In CyberChef: use "From Base64" → "Decode text" (UTF-16LE encoding). The decoded content reveals the actual commands. - 3Note the parent process. If the parent is
WINWORD.EXE,EXCEL.EXE,Outlook.exe, orchrome.exe— this is a phishing/macro execution chain. Immediately check the parent document or email for the delivery vector.
- 4Filter for Event ID 4104 in the time window around the alert. The Message field contains the fully decoded PowerShell script content — even if the outer command was base64 encoded. This is the ground truth of what PowerShell executed.
- 5Search the 4104 message body for any of the key indicator patterns in the table below. Presence of
amsiInitFailed,[Ref].Assembly.GetType, orSet-MpPreference -DisableRealtimeMonitoringindicates defense evasion — escalate to SEV1 immediately.
| Flag / Pattern | Meaning | Analyst Action |
|---|---|---|
| -EncodedCommand / -Enc / -e | Base64-encoded payload passed to PowerShell — hides actual instructions from command-line logging | Decode immediately. Check Event 4104 for the decoded content. |
| -ExecutionPolicy Bypass | Overrides the machine execution policy — tells PowerShell to run unsigned scripts regardless of policy | Not malicious alone, but in combination with other flags = deliberate evasion. Context-dependent. |
| -WindowStyle Hidden / -w h | Hides the PowerShell window from the user — attacker does not want the user to see the script running | Strong indicator of malicious intent. No legitimate admin tool hides its window by default. |
| IEX / Invoke-Expression | Executes a string as PowerShell code — classic fileless execution: download string, then IEX it without writing to disk | Check Event 4104 for what was passed to IEX. DownloadString + IEX = fileless payload execution. |
| DownloadString / DownloadFile / WebClient | Downloads content from a URL — used to fetch second-stage payloads or shellcode directly into memory | Extract the URL. Block it. Check network events for the connection. Check if download succeeded. |
| amsiInitFailed / [Ref].Assembly.GetType | AMSI bypass — patches the Windows Antimalware Scan Interface in memory so subsequent scripts are not scanned | AUTOMATIC SEV1. AMSI bypass = attacker is actively evading detection. Isolate device immediately. |
| Set-MpPreference -Disable* | Disables Windows Defender features (real-time monitoring, cloud protection, behaviour monitoring) | AUTOMATIC SEV1. Defense tampering = T1562.001. Re-enable Defender as first containment action. |
Malicious PowerShell rarely acts alone — it either downloads a second-stage payload (proving active C2 communication) or spawns a child process to execute that payload (proving successful delivery). Identifying both the download URL and the child process reveals the complete attack chain: initial access vector → PowerShell → C2 download → implant execution. Without this correlation you cannot scope the incident correctly.
- 1In the device timeline, set event type filter to Network connection. Filter Process name = powershell.exe. Check ±10 minutes around the alert time. Any external IP connection from PowerShell is suspicious — legitimate admin PS should not be reaching out to unknown IPs.
- 2Note the Remote URL or Remote IP. If the URL matches the DownloadString argument decoded from Event 4104 — the download was successful. If only an IP is shown (no URL) — the script used direct IP communication (common for C2 beacons). Run the IP through threat intel (VirusTotal, MDTI).
- 3Check for Process created events by powershell.exe — these are child processes spawned after the download. Common patterns: powershell.exe spawning
cmd.exe,net.exe,whoami.exe,rundll32.exe, or an unknown executable from %TEMP%.
If the PowerShell script used IEX (New-Object Net.WebClient).DownloadString(...), the payload was executed entirely in memory and may not appear as a dropped file. Check for an injected process instead: look for unusual memory regions (shellcode signatures) in the same powershell.exe PID, or check if the PS process opened a handle to another process (e.g. explorer.exe) within seconds of the download — that would indicate reflective injection.
Containment
STOP IT- 1Isolate the device via MDE: security.microsoft.com → Endpoints → Device inventory → [Device] → Isolate device → Full isolation. This stops any ongoing C2 communication while preserving the device for forensics.
- 2If Defender was disabled by the script: Via MDE Live Response, run
Set-MpPreference -DisableRealtimeMonitoring $falseandStart-Service WinDefendto restore real-time protection before the PowerShell process is killed — so Defender can scan the memory of the running process. - 3Kill the PowerShell process: Via Live Response, run
Stop-Process -Name powershell -Force. If a child process was spawned, kill it by name or PID as well. - 4Block the C2 URL/IP: If a download URL or C2 IP was identified — add it as a Custom Block Indicator in MDE. Also submit to your Sentinel watchlist and firewall block list.
Eradication
CLEAN UP- 1Check for persistence created by the PowerShell script: The most common follow-on actions are scheduled tasks (
schtasks), registry run keys, and WMI subscriptions. Run the SOP-26 identification steps on this device. - 2Search for the download URL org-wide: Run the I2 network KQL across all devices. If other devices connected to the same C2 IP — you have a broader campaign. Escalate to IR.
- 3Confirm Defender protections are restored: Check Device page → Security recommendations — all protections should show green. If AMSI was patched in-process, a device restart after isolation will restore it.
- 4Reset the affected user's credentials: The PowerShell script may have used the session token or harvested credentials in memory. Issue a password reset and re-enrol MFA before the user's account is re-enabled.
- 5Confirm Script Block Logging is deployed org-wide: Use the B2 GPO reference to verify coverage. If this attack was initially detected only by a command-line flag and not by 4104 content — you have a logging gap that must be closed before considering eradication complete.
- Device isolated; PowerShell process and any spawned child processes terminated
- Windows Defender real-time monitoring confirmed enabled; AMSI functioning normally (device restarted)
- C2 URL/IP blocked as Custom Indicator org-wide in MDE and Sentinel watchlist
- No persistence mechanisms (scheduled tasks, run keys) identified from the PS execution
- Org-wide hunt for same C2 IP returns clean across all devices
- Script Block Logging (Event 4104) confirmed deployed and ingesting into Sentinel
Escalation
TIERS| Tier | Trigger Condition | Who to Notify | Action |
|---|---|---|---|
| L1 → L2 | Single device, encoded PS with confirmed malicious payload (DownloadString/IEX), no AMSI bypass, no Defender tamper, device isolated, C2 blocked, no lateral movement | L2 SOC Analyst | Hand off: device name, user, decoded payload content, C2 URL/IP, containment actions taken |
| L2 → IR (SEV1) | Any of: AMSI bypass pattern confirmed in Event 4104, Defender disabled by the script, multiple devices connecting to same C2 IP, PowerShell used for lateral movement (PSSession to other hosts), credential harvesting commands found in decoded payload (Invoke-Mimikatz, sekurlsa) | IR Team + CISO | Declare SEV1. Full forensic collection. Map lateral movement. Credential reset across all potentially touched accounts. Regulatory assessment if any data exfiltration occurred. |
| L2 → Security Engineering | Script Block Logging (Event 4104) was not enabled on affected devices; Constrained Language Mode not enforced; PowerShell v2 downgrade was used to bypass logging | Security Architecture | Immediate: deploy Script Block Logging GPO. Disable PowerShell v2 (Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root). Consider Constrained Language Mode for non-admin users. |
Authorized security research & penetration testing only. Unauthorized use is illegal. Built by Rudra Verma | Senior Cyber Security Architect & Researcher | CyberHawk Threat Intel
◈ Stay Connected
Follow CyberHawk Threat Intel for threat intelligence, SOC playbooks, and detection engineering content.
"They can't exploit you if you are the Exploit."