Lesson 142 — The PowerShell Command Was Encoded
The process chain from Lesson 141 has produced another clue: PowerShell was launched with an encoded command.
Encoding is not the same as encryption, and it is not proof of malicious activity. Administrators and software can legitimately use encoded PowerShell. Our job is to preserve the original telemetry, identify the encoded argument, decode a copy safely for analysis and then test what the decoded behaviour tells us about the endpoint attack chain.

Your case file
PowerShell executes on WS-FIN-042 with an -EncodedCommand argument. The readable command has disappeared behind a Base64 string.
Case briefing
Investigation objective
Identify encoded PowerShell executions, preserve the source evidence, extract the encoded argument, decode a copy in a controlled analysis workflow and correlate the resulting behaviour with surrounding process and network telemetry.
Investigator's rule
Never replace the evidence with your interpretation. Keep the original ProcessCommandLine. The decoded text is an analytical artefact derived from that evidence, not a substitute for it.
Stage 1 — hunt for encoded PowerShell
Start in DeviceProcessEvents. We are looking for PowerShell command lines containing common forms of the encoded-command switch.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any
("-EncodedCommand", "-enc", "-e ")
| project Timestamp,
DeviceName,
AccountName,
FileName,
ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
ProcessId,
InitiatingProcessId
| order by Timestamp descWhy search several forms?
PowerShell parameters can be abbreviated. An investigator should not assume every event will contain the full -EncodedCommand string. At the same time, very short matches can introduce noise, so every result still needs context.
What encoding changes
Base64 makes a command less readable in the raw process event. It does not make the underlying instructions unknowable. Treat encoding as a reason to inspect the content, not as a verdict.
Stage 2 — isolate the encoded token
Once encoded PowerShell is identified, extract the Base64-looking argument into its own field. This makes triage easier while retaining the full original command line alongside it.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| extend EncodedToken =
extract(@"(?i)(?:-EncodedCommand|-enc)\s+([A-Za-z0-9+/=]+)", 1, ProcessCommandLine)
| where isnotempty(EncodedToken)
| project Timestamp,
DeviceName,
AccountName,
InitiatingProcessFileName,
ProcessCommandLine,
EncodedToken
| order by Timestamp descWhy keep both fields?
The extracted token helps analysis, but the complete command line may contain other switches such as hidden-window or profile options. Those surrounding arguments are part of the evidence.
Regex is a starting point
The extraction pattern is designed for a common command-line form. Real telemetry can contain quoting, alternate syntax or unusual spacing. If extraction fails, inspect the raw command rather than concluding there was no encoded content.
Stage 3 — decode a copy safely
PowerShell's -EncodedCommand commonly represents Base64-encoded UTF-16LE text. Decode the captured string in a safe analysis environment. Do not execute the decoded command.
Decode is not execute
The purpose of decoding is to make the command readable. A decoded script can contain harmful instructions. Analysis should occur without invoking the command or retrieving its referenced payload.
Extract entities
From the decoded text, record useful pivots: URLs, domains, IP addresses, filenames, paths, registry locations, scheduled-task names, additional commands and any referenced executables.
Stage 4 — reconstruct activity around execution
Now return to telemetry. The decoded command gives you a hypothesis; the device events tell you what was actually observed around the execution time.
let TargetDevice = "WS-FIN-042";
let TargetTime = datetime(2026-08-18 01:22:11);
DeviceProcessEvents
| where DeviceName =~ TargetDevice
| where Timestamp between (TargetTime - 10m .. TargetTime + 10m)
| project Timestamp,
FileName,
ProcessCommandLine,
InitiatingProcessFileName,
AccountName,
ProcessId,
InitiatingProcessId
| order by Timestamp ascIntent versus observation
A decoded command can show what PowerShell was instructed to attempt. It does not prove every instruction succeeded. Separate command intent from observed endpoint behaviour.
Look for consequences
Did PowerShell spawn another process? Did a script host appear? Did a file execute? Did a command shell start? The next event in the chain may be more important than the encoded string itself.
Stage 5 — test the network behaviour
If the decoded content references remote infrastructure, check whether network telemetry attributed to the PowerShell process supports that behaviour.
let TargetDevice = "WS-FIN-042";
let PowerShellPID = 7316;
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where InitiatingProcessId == PowerShellPID
| project Timestamp,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
RemoteUrl,
RemoteIP,
RemotePort,
ActionType
| order by Timestamp ascCorrelation strengthens the finding
If the decoded text references a domain and DeviceNetworkEvents records the same PowerShell process contacting that infrastructure seconds later, two independent telemetry views now support the same investigation story.
Absence is not always proof
No matching network event does not automatically mean the command did nothing. Telemetry coverage, blocking, timing and the exact behaviour of the command all matter. State what the evidence shows — and what it does not.
Agent Foskett's decoded timeline
Your evidence board
| Evidence | What it supports | Weight |
|---|---|---|
PowerShell uses -EncodedCommand | Command content has been encoded and requires interpretation. | Context |
| Original command line preserved | Maintains the source telemetry and surrounding execution switches. | Essential |
| Decoded content references remote script infrastructure | Shows what the command was instructed to attempt. | Strong |
| PowerShell process creates subsequent suspicious processes | Supports execution consequences on the endpoint. | Strong |
| PowerShell network telemetry matches decoded infrastructure | Correlates decoded intent with observed communication. | Strong |
| Encoding alone | Does not establish maliciousness without surrounding evidence. | Insufficient alone |
Write the finding like an investigator
Example: Microsoft Defender XDR recorded PowerShell executing on WS-FIN-042 under the j.smith account with an encoded-command argument. The original command line was preserved and a copy of the Base64 content was decoded for analysis without execution. The decoded content referenced remote script retrieval and execution behaviour. Surrounding process telemetry and network activity attributed to the PowerShell process were then reviewed to determine whether the intended behaviour was observed. The encoded argument alone is not evidence of compromise; the assessment is based on the correlation between the command's decoded intent and the endpoint telemetry.
Lesson 142 key takeaways
- Encoded PowerShell is an investigative clue, not automatic proof of malicious activity.
- Preserve the complete original
ProcessCommandLine. - Search for common encoded-command parameter forms, but expect syntax variation.
- Extracting the encoded token can make triage easier without discarding source evidence.
- Decode captured content safely; do not execute it.
- PowerShell encoded commands commonly require the correct character encoding when converted back to readable text.
- Use decoded content to identify entities and formulate hypotheses.
- Separate what a command was instructed to do from what telemetry proves actually happened.
- Correlate process and network evidence before reaching a conclusion.
- Document both supporting evidence and evidentiary limits.
Module 12 — the attack chain continues
Lesson 141 established the suspicious parent-child relationship. Lesson 142 looked inside an encoded PowerShell command and turned unreadable command-line content into investigative pivots. Next we move deeper into process relationships and ask whether the execution tree fits legitimate user behaviour.
Continue your KQL investigation training
Related Agent Foskett Investigations
🔎 KQL Academy — Module 12: Advanced Endpoint Investigation
Investigate encoded PowerShell with KQL
Lesson 142 of the Agent Foskett KQL Academy uses Microsoft Defender XDR DeviceProcessEvents to identify encoded PowerShell command lines, preserve the original evidence and extract encoded arguments for safe analysis.
Correlate decoded PowerShell behaviour with Defender XDR telemetry
Learn how to turn decoded command content into investigative pivots and test those hypotheses against process and network telemetry without treating encoding alone as proof of malicious activity.
