Agent Foskett Academy • SOC Analyst Academy • Module 4 • Lesson 32 • Endpoint Incidents: Following the Attack Chain

Lesson 32 — The PowerShell Command Was Encoded

Lesson 31 gave us the first clue: a browser spawned PowerShell.

Now the command line gives us another one. Instead of readable instructions, the process contains an encoded payload.

Encoding is not proof of malicious activity. Administrators and software can legitimately encode PowerShell commands. But in an already unusual process chain, it changes the priority of the investigation.

Agent Foskett's question is simple: what does the encoded command actually say?

Obfuscation can hide intent from the analyst. Decode first, interpret second, and then validate what actually executed.

Decode the Command Back to SOC Analyst Academy

Agent Foskett investigating an encoded PowerShell command in Microsoft Defender XDR

The command line was trying not to be read

Find the encoded execution, preserve the original evidence, decode it safely and follow every useful indicator revealed by the plaintext.

✓ Hunt encoded PowerShell

✓ Preserve the original command

✓ Decode Base64 safely

✓ Pivot on revealed URLs, files and commands

Case briefing

10:14:22 msedge.exe ↓ 10:14:27 powershell.exe ↓ -WindowStyle Hidden -EncodedCommand SQBFAFgA... THE FIRST QUESTION Why did the browser launch PowerShell? THE NEXT QUESTION What is the encoded command hiding?

Investigation objective

Identify encoded PowerShell execution, preserve the original command line, decode the payload without executing it, determine its intent and correlate the decoded instructions with endpoint telemetry.

Investigator's rule

Encoded does not automatically mean malicious. Treat encoding as a characteristic that requires explanation, then validate the decoded content against what actually happened on the device.

Stage 1 — hunt for encoded PowerShell

12345 678910111213141516

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any (
    "-EncodedCommand",
    "-enc",
    "-e"
)
| project Timestamp,
          DeviceName,
          AccountName,
          InitiatingProcessFileName,
          ProcessCommandLine,
          SHA1
| order by Timestamp desc

Short switches need context

PowerShell parameters can be abbreviated. Very short strings such as -e can also create false positives, so always inspect the full command line before drawing a conclusion.

Preserve the original evidence

Record the complete command line exactly as observed before decoding or transforming anything. Your investigation notes should retain both the original and decoded forms.

Stage 2 — isolate the suspicious event

123456 789101112131415

DeviceProcessEvents
| where DeviceName =~ "WS-FIN-044"
| where Timestamp between (
    datetime(2026-08-24 10:14:00) ..
    datetime(2026-08-24 10:15:00)
)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| project Timestamp,
          DeviceName,
          AccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          ProcessCommandLine,
          ProcessId,
          InitiatingProcessId

Parent process still matters

The encoded command does not replace the Lesson 31 evidence. Browser → PowerShell remains part of the same attack story and increases the significance of the encoded execution.

Capture time and process identifiers

Timestamp and process identifiers help correlate the PowerShell event with child processes and nearby file or network activity.

Stage 3 — decode without executing

ORIGINAL COMMAND powershell.exe -EncodedCommand SQBFAFgA... ↓ EXTRACT ENCODED STRING ↓ DECODE AS DATA — DO NOT RUN IT ↓ READ PLAINTEXT ↓ IDENTIFY URLS / PATHS / COMMANDS / INDICATORS ↓ VALIDATE AGAINST TELEMETRY

PowerShell's -EncodedCommand commonly represents Base64-encoded Unicode text. Decode the string in a safe analysis workflow and treat the result as evidence to inspect — not a command to execute.

Decoding is not execution

The goal is to convert encoded data back into readable text. Do not paste an unknown decoded command into a shell simply to see what it does.

Readable does not mean harmless

Once decoded, the command may reveal a download URL, script block, executable path or additional obfuscation. Continue analysing each layer until the intended behaviour is understandable.

Stage 4 — turn decoded content into pivots

Decoded clue	Next investigation step
URL or domain	Check related network telemetry and prevalence.
IP address	Correlate connections from the device and other endpoints.
File path	Search file creation, modification and execution events.
Executable or script	Follow process creation and ancestry.
Registry path	Check for configuration or persistence changes.
Another encoded block	Continue decoding as data until intent becomes clear.

Stage 5 — follow the decoded command into network telemetry

12345 67891011121314 1516

DeviceNetworkEvents
| where DeviceName =~ "WS-FIN-044"
| where Timestamp between (
    datetime(2026-08-24 10:14:00) ..
    datetime(2026-08-24 10:20:00)
)
| where InitiatingProcessFileName in~ (
    "powershell.exe",
    "pwsh.exe"
)
| project Timestamp,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          InitiatingProcessCommandLine
| order by Timestamp asc

Did telemetry match the decoded intent?

If the plaintext references a remote destination and Defender records PowerShell connecting to it seconds later, the decoded command and observed behaviour reinforce one another.

Look for failed as well as successful behaviour

A malicious command can fail. Lack of a successful connection does not make the execution benign; document what was attempted and what the telemetry confirms.

Stage 6 — follow files revealed by the command

12345 67891011 121314151617

DeviceFileEvents
| where DeviceName =~ "WS-FIN-044"
| where Timestamp between (
    datetime(2026-08-24 10:14:00) ..
    datetime(2026-08-24 10:20:00)
)
| where InitiatingProcessFileName in~ (
    "powershell.exe",
    "pwsh.exe"
)
| project Timestamp,
          ActionType,
          FileName,
          FolderPath,
          SHA1,
          InitiatingProcessCommandLine
| order by Timestamp asc

Build the sequence

Browser launched PowerShell. PowerShell contained encoded instructions. The decoded command referenced external content. A file then appeared. That is now a timeline, not a collection of unrelated alerts.

Hash becomes another pivot

If a file hash is available, use it to determine whether the same file appears elsewhere in the environment and whether other devices show related execution.

Stage 7 — assess intent and confidence

ENCODED POWERSHELL ↓ DECODE SAFELY ↓ WHAT DOES THE PLAINTEXT DO? ↓ DOES ENDPOINT TELEMETRY CONFIRM IT? ↓ LEGITIMATE ADMIN / SOFTWARE ACTIVITY? │ ├── YES → DOCUMENT + VALIDATE │ └── NO / UNEXPLAINED ↓ DOWNLOAD / EXECUTION / EXTERNAL CONNECTION? ↓ ESCALATE THE ENDPOINT INVESTIGATION

Encoding raises questions, not guilt

Some management tools and scripts legitimately encode commands. The analyst's job is to establish purpose, provenance and observed behaviour.

Multiple weak clues can become strong evidence

Browser parent, hidden window, encoded command, external connection and new file activity together can form a far stronger story than any single characteristic.

Write the investigation finding

ENDPOINT INVESTIGATION FINDING msedge.exe spawned powershell.exe on WS-FIN-044. The PowerShell command used encoded execution. The original command line was preserved and the encoded data was decoded for analysis without execution. The decoded content referenced remote content and a local file path. Defender XDR telemetry showed related network and file activity immediately afterwards. No validated business explanation was identified. DECISION Escalate as suspected malicious PowerShell execution and continue following the endpoint attack chain.

Lesson 32 key takeaways

Encoded PowerShell is an investigative clue, not automatic proof of compromise.
Preserve the complete original command line before transforming the evidence.
Decode suspicious content as data; do not execute an unknown decoded command.
PowerShell command-line switches may be abbreviated, so short-pattern hunting needs validation.
Extract URLs, IPs, paths, filenames and commands from decoded content as investigative pivots.
Correlate decoded intent with observed process, file and network telemetry.
A failed malicious action can still be important evidence.
Keep the parent-child relationship from Lesson 31 in the same timeline.
Combine multiple contextual clues before deciding whether the activity is malicious.
Document both what the command attempted and what Defender XDR confirms actually happened.

Module 4 — Endpoint Incidents: Following the Attack Chain

Lesson 32 takes the suspicious PowerShell execution from Lesson 31 and reveals what the command was trying to hide. The next investigation step is to examine whether the wider process tree matches normal user activity.

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

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 4: Endpoint Incidents: Following the Attack Chain

Follow endpoint evidence across execution, persistence, credential access, movement and containment.

← Previous lesson

Lesson 31 — The Browser Spawned PowerShell Follow an unusual browser-to-PowerShell process chain.

✅ Current lesson

Lesson 32 — The PowerShell Command Was Encoded Investigate obfuscated or encoded command execution.

Next lesson →

Lesson 33 — The Process Tree Didn't Match Normal User Activity Use process ancestry to distinguish normal from suspicious execution.

How to investigate encoded PowerShell in Microsoft Defender XDR

Lesson 32 of the Agent Foskett SOC Analyst Academy teaches analysts how to find encoded PowerShell command lines, preserve the original evidence, decode suspicious Base64 content safely and correlate the revealed intent with endpoint telemetry.

KQL hunting for encoded PowerShell commands

Use DeviceProcessEvents, DeviceNetworkEvents and DeviceFileEvents to follow encoded PowerShell execution through the endpoint attack chain and make an evidence-led SOC decision.