Decoding the Chain A Practitioner’s Guide to Triaging cmd.exe → powershell.exe -EncodedCommand

Bottom Line Up Front

(HIGH CONFIDENCE) The process chain cmd.exe → powershell.exe -EncodedCommand is a high-suspicion signature in modern Windows environments and warrants triage on every observation, but it is not self-proving. It coincides with three ATT&CK behaviors at once — command-shell mediation (T1059.003), PowerShell execution (T1059.001), and command obfuscation (T1027.010) — and is a long-running tradecraft pattern across commodity malware, ransomware affiliates, and state-aligned operators. Microsoft documents -EncodedCommand as a supported parameter intended for commands with complex quoting, which means legitimate administrative, deployment, and packaged-installer workflows do produce it. The decisive question is what the decoded content does, not that encoding was used.

(HIGH CONFIDENCE) The single most important practitioner discipline is decode-first. PowerShell encodes the argument as Base64 of UTF-16LE text. Until that string is decoded, the analyst is reasoning about a transport wrapper, not the incident. CyberChef recipe From Base64 → Decode Text → UTF-16LE is the canonical step, and is equivalent to the PowerShell expression [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($s)).

(HIGH CONFIDENCE) PowerShell Script Block Logging (Event ID 4104) is the highest-value telemetry for this chain because it records the script blocks PowerShell actually compiles and executes — and in the case of -EncodedCommand, that is normally the decoded content. Two important nuances apply: dynamically generated script blocks (for example, IEX of a string built at runtime) usually produce additional 4104 events when each new block is compiled; and on PowerShell 5 and later, suspicious blocks can be auto-logged at Warning level even when full Script Block Logging is not enabled enterprise-wide. Warning-level 4104 is a useful minimum dataset, not a substitute for full logging.

(MODERATE CONFIDENCE) Companion flags raise confidence in malicious intent when they stack. The high-signal combination is an encoded command plus -NoProfile plus -WindowStyle Hidden plus -ExecutionPolicy Bypass, launched from a user-writable parent process such as Office, mshta.exe, wscript.exe, or cmd.exe itself when that cmd.exe was spawned by an Office macro or browser-download zone. A single one of these flags is interesting; three or four in combination is rarely consistent with sanctioned administration.

(MODERATE CONFIDENCE) Base64 by itself is not an AMSI bypass. The Antimalware Scan Interface is designed to inspect the decoded script content at runtime. Where attackers defeat AMSI, they do so by layering additional obfuscation on top of Base64 — string concatenation, character-code reconstruction, .NET reflection patching, or research-grade techniques such as ScriptBlock Smuggling — or by tampering with the AMSI surface directly. Analysts should treat Base64 as a transport-layer concern and AMSI evasion as a separate layer of evidence.

(MODERATE CONFIDENCE) The strongest detections are correlated, not signature-only. Vendor-published content from Splunk, Elastic, Microsoft, Red Canary, and Mandiant converges on the same model: parent provenance plus switch bundle plus decoded behavior plus follow-on file, network, or persistence activity. Regex on -EncodedCommand alone is fragile because the switch has many functionally equivalent forms (-enc, -ec, caret-injected and mixed-case variants), and because legitimate administrative use produces routine false positives.

(LOW CONFIDENCE) Emerging evasions such as ScriptBlock Smuggling (2024) are technically meaningful and should be tracked, but the original research noted no evidence of real-world deployment at time of publication. Analysts should keep these in the mental model for advanced bypass hunts while continuing to prioritize the much more common realities seen in current vendor content: encoded commands, compressed payloads, download cradles, AMSI tampering references, and suspicious parent-child chains.

1 · Anatomy of the Chain

1.1 What -EncodedCommand actually is

-EncodedCommand (aliases -enc, -ec, and various truncations Microsoft accepts because the parameter name is unambiguous from its prefix) is a documented PowerShell parameter that accepts a Base64-encoded string. Microsoft’s about_PowerShell_exe reference specifies the input must be Base64 of UTF-16 little-endian text. The intended use case is passing a command that contains complex quoting, escape characters, or newline structure that would otherwise be mangled by the calling shell. It is a transport feature, not an execution feature.

Two practical consequences flow from that design. First, anything that can be expressed as a PowerShell command can be expressed as an encoded command, which means the encoding does not narrow the threat surface in any way. Second, because the decoded content goes through the same parser, AMSI, and Script Block Logging pipeline as a typed command, the encoding does not bypass PowerShell’s own runtime telemetry. It bypasses pattern-matching on the command line — nothing more.

1.2 Why cmd.exe is the suspicious parent

cmd.exe is the legacy Windows Command Shell interpreter and is mapped to MITRE T1059.003. As a parent for powershell.exe, it is meaningful in two ways. First, it is a frequent wrapper used by adversaries to launch PowerShell while hiding the true originator — for example, an Office macro shelling out to cmd /c powershell -enc … obscures the Office lineage from naïve parent-process alerting. Second, cmd.exe introduces its own command-line surface (/c, /k, &, |, ^) that can be used for further obfuscation before PowerShell is invoked.

The chain is high-suspicion specifically because the combination breaks the most common benign profile. Legitimate enterprise deployment tooling typically launches PowerShell directly from a service host (svchost.exe), the management console (mmc.exe), or a known agent. A cmd.exe → powershell.exe -EncodedCommand chain originating from an interactive user session, an Office process tree, or a script-host process tree should be triaged. The same chain originating from a known RMM, SCCM, or CI/CD parent and decoding to a recognizable benign script can usually be closed out after verification.

1.3 The Base64(UTF-16LE) detail that matters

The encoding is Base64 of UTF-16 little-endian text. This is not a stylistic choice — it is what PowerShell expects, and decoding with the wrong text encoding yields garbled output that can lead an inexperienced analyst to dismiss a payload as non-textual. The practical consequence is one CyberChef step and one PowerShell one-liner:

2 · Why Attackers Use This — Operational Use Cases

The use cases below are listed in roughly descending order of how often they appear in field telemetry. They are not mutually exclusive — a single intrusion will usually exercise several at once.

2.1 Defeating signature-based command-line inspection

(HIGH CONFIDENCE) This is the foundational reason encoding exists in the attacker toolkit. SIEM correlation rules, EDR command-line analytics, and antivirus signatures that look for keywords such as Invoke-Expression, DownloadString, Net.WebClient, Invoke-WebRequest, or FromBase64String see none of those tokens on the parent process’s command line when the payload is wrapped in Base64. The defeat is trivial in execution and requires no privileges. This is also the reason MITRE’s description of T1027.010 explicitly calls out Base64 as a command-obfuscation method.

2.2 Fileless and in-memory payload execution

(HIGH CONFIDENCE) Once decoded, the most common malicious form of the chain is some variant of the PowerShell download cradle:

Each of these retrieves a remote script and passes it directly to Invoke-Expression so the script is parsed and executed in memory without ever landing as a .ps1 file. MITRE maps this download-and-execute behavior to T1105 (Ingress Tool Transfer) and specifically names DownloadString and Invoke-WebRequest as canonical examples. Microsoft’s AMSI guidance describes the same family of behaviors under the umbrella of fileless malware, including persistence via Run-key blobs that re-invoke a Base64-encoded PowerShell one-liner at logon.

2.3 Execution-policy bypass — useful, but commonly misunderstood

(MODERATE CONFIDENCE) Two facts have to be held together. First, Microsoft’s own about_Execution_Policies documentation states explicitly that execution policy is not a security boundary — it is a user-convenience feature, and users (or attackers) can trivially bypass it by passing script content directly on the command line or by setting the policy at the process scope. Second, code executed via -EncodedCommand does not go through file-script execution-policy evaluation in the same way as a script on disk would, because there is no script file. The -ExecutionPolicy Bypass flag is therefore not strictly required for -EncodedCommand to execute. It appears anyway in a meaningful fraction of malicious samples because it is cheap insurance for the operator across mixed environments.

Operationally this means: -ExecutionPolicy Bypass is a strong corroborating signal, not a requirement. Its absence does not exonerate a chain. Group Policy MachinePolicy and UserPolicy execution policy still override session-scope command-line settings, so enterprise GPO that pins execution policy meaningfully raises the friction on script-file payloads even when -EncodedCommand remains usable.

2.4 AMSI evasion — framed correctly

(MODERATE CONFIDENCE) AMSI integrates with PowerShell, the Windows Script Host engines, JScript and VBScript, and Office VBA macros, and is explicitly intended to inspect obfuscated and evasive script content at runtime. Microsoft Defender uses AMSI to deepen detection on exactly the kind of decoded payload that -EncodedCommand produces. The corollary matters: Base64 by itself is not an AMSI bypass.

Where attackers defeat AMSI, they do so on top of Base64, by one of several routes:

• String fragmentation and concatenation that breaks AMSI signature patterns after decoding (”Am”+”si”+”Sc”+”an”).

• Character-code reconstruction ([char]65+[char]109+…) to assemble sensitive identifiers at runtime.

• .NET reflection patching of amsi.dll exports such as AmsiScanBuffer so AMSI scans return clean.

• AMSI surface tampering via writable structures in the .NET runtime — including the 2024-disclosed AMSI Write Raid class of bypass — which can avoid calls to VirtualProtect that EDR commonly monitors.

• Research-grade techniques such as ScriptBlock Smuggling, which exploit the PowerShell/.NET AST boundary to produce a benign AST for AMSI and logging while compiling a different, malicious AST for execution. As of the original 2024 publication, the authors reported no evidence of real-world use.

For triage, this means: a decoded payload that references amsi tokens, performs System.Reflection lookups against amsi.dll, patches AmsiContext, or assembles AMSI-relevant strings from char arrays is a near-decisive escalation.

2.5 C2 staging — Cobalt Strike, Metasploit, commodity RATs

(HIGH CONFIDENCE) Encoded PowerShell is the delivery and staging mechanism of choice for the major post-exploitation frameworks. Cobalt Strike Beacon, Metasploit Meterpreter, Sliver, and a long list of commodity RATs (Remcos, NetSupport, AsyncRAT, ValleyRAT, and others) can be staged from a one-line encoded PowerShell command that fetches the next-stage shellcode or .NET loader and reflectively loads it in memory. Cobalt Strike Malleable C2 profiles allow extensive customization of the network surface — user agents, headers, URI patterns, jitter — so the resulting beacon traffic can be tuned to mimic legitimate web activity. This is one reason a network pivot from any encoded PowerShell event is non-negotiable.

2.6 LOLBin chaining

(HIGH CONFIDENCE) Adversaries chain Living-off-the-Land Binaries to obscure the chain origin and to defeat alerting that depends on a single parent–child edge. Recurrent patterns in field reporting include:

• Office (winword.exe, excel.exe, outlook.exe) → cmd.exe → powershell.exe -enc — the classic macro-lure chain.

• Microsoft’s Attack Surface Reduction rules now directly target several of these surrounding behaviors — for example, blocking Office applications from creating child processes and blocking execution of potentially obfuscated scripts — which is a useful hardening lever even when -EncodedCommand itself cannot be blocked outright.

3 · Companion Flags — The Stacking Pattern

Individual PowerShell switches are benign in isolation. What raises confidence is their combination, especially when stacked with an encoded argument and a user-writable parent process. The table below summarizes the flags most often observed alongside -EncodedCommand in malicious tradecraft and the analytic value of each.

4 · The Decode-First Methodology

Triage of this chain is deterministic. Five steps, in order, get an analyst from the alert to a defensible conclusion. Skipping any step in the early sequence increases the chance of either missing the incident or escalating noise.

Step 1 — Decode the argument safely

Extract the Base64 string from the command line and decode it offline. Use CyberChef (browser-side, no execution risk) or Python in an isolated host. Do not run the decoded command on the analyst workstation. The decoded text is the first artifact of investigative value — everything upstream of decode is process metadata, not behavior.

Step 2 — Rebuild the full process tree

Identify the grandparent and parent of cmd.exe. A Word, Excel, Outlook, or PDF reader grandparent is a high-confidence escalation. A browser grandparent following a recent download is also high-confidence. A trusted management agent or service-host grandparent paired with a benign decoded payload is the canonical false-positive shape. Pull Event ID 4688 records (where command-line auditing is enabled) and Sysmon Event ID 1 records and trace lineage by ProcessGuid rather than by PID, since PIDs are reused and ProcessGuid is more resilient to PPID spoofing.

Step 3 — Pivot to PowerShell telemetry

Pull Event ID 4104 (Script Block Logging) for the host and time window. For -EncodedCommand invocations, 4104 normally records the decoded script body that PowerShell compiled. For dynamically generated content — anything constructed at runtime from strings, char arrays, or IEX of a downloaded payload — expect additional 4104 events for each newly compiled block. Reconstruct multi-fragment script bodies by their ScriptBlock ID. Pull Event ID 4103 for module and pipeline records where relevant.

Step 4 — Correlate to network and follow-on activity

If the decoded script contains DownloadString, DownloadFile, WebClient, Invoke-RestMethod, Invoke-WebRequest, or sockets primitives, pivot to network telemetry for the destination. Pull Sysmon Event ID 3 (network connection) records bound to the offending ProcessGuid. Examine DNS records and TLS metadata. Cobalt Strike default and many off-the-shelf profiles still leave fingerprints in user-agent, URI structure, and TLS JA3/JA4 hashes.

Step 5 — Hunt persistence and residual artifacts

Even in a fileless case, check the standard persistence surfaces:

5 · Forensic Artifacts and Telemetry

5.1 Telemetry hierarchy

5.2 The Event ID 4104 nuance

Operational language about 4104 sometimes overstates its coverage. The precise statement is this: 4104 records the script blocks PowerShell actually processes. For -EncodedCommand, the processed block is normally the decoded command body, which is why 4104 is the highest-fidelity record of attacker behavior even when the command line itself is opaque. But when a script dynamically constructs and executes new code — for example IEX $downloaded of content retrieved at runtime — each new script block compiled produces its own 4104 event. Analysts hunting fileless chains should therefore look across the time window for additional 4104 events tied to the same process, not only the initial decode.

Two configuration realities apply. First, full Script Block Logging must be explicitly enabled by policy. Second, on PowerShell 5 and later, suspicious blocks can be auto-logged at Warning level even when full logging is not enabled — useful as a fallback dataset, but not a substitute for full coverage.

5.3 4688 caveats

Windows Event ID 4688 (process creation) does not record the full command line by default. Microsoft’s command-line auditing documentation is explicit on this — the field must be turned on via the ProcessCreationIncludeCmdLine_Enabled policy or its registry equivalent. Without it, 4688 records that powershell.exe launched, but not what it was told to do. Where 4688 command-line coverage is unavailable, Sysmon Event ID 1 carries the full command line and parent context, and is the more reliable source.

5.4 Filesystem and registry sweep

6 · False Positive Discipline

Treating every encoded PowerShell event as malicious is operationally untenable and degrades analyst calibration. Splunk and Elastic both note in their published content that legitimate administrative use is a known source of noise — installers, deployment wrappers, MDM agents, and SCCM-style packaging frequently emit encoded PowerShell as a routine implementation detail of command-quoting safety. The job of the analyst is not to suppress the chain blindly, but to apply a small set of consistent filters.

Likely benign profile

• Parent process is svchost.exe, services.exe, mmc.exe, or a known SCCM / Intune / RMM / EDR / backup agent.

• Command was launched in the context of a service account with a known scheduled deployment window.

• No -WindowStyle Hidden and no -NoProfile present.

• Decoded content is plain administrative — for example a Get-Service pipeline, a registry read, an inventory query, or a vendor-provided installer command.

• No outbound network connection from the PowerShell process within a short window after launch, or any outbound connection is to a known internal endpoint.

• No new persistence artifact created in the same time window.

High-confidence malicious stack

• Parent process is Office, mshta.exe, wscript.exe, cscript.exe, a browser-spawned cmd.exe, or a process running from a user-writable directory.

• Encoded command plus at least two of -NoProfile, -WindowStyle Hidden, -ExecutionPolicy Bypass, -NonInteractive.

• Decoded script contains a download cradle, AMSI references, reflection lookups against amsi.dll, Base64-plus-compression patterns, or shellcode-loader primitives.

• Outbound HTTP/HTTPS or DNS to a low-reputation or newly registered destination within seconds of launch.

• New Run-key, scheduled task, service, or WMI subscription created on the host inside the same incident window.

7 · MITRE ATT&CK Mapping

The chain rarely maps to a single technique. The grid below covers the techniques most commonly observed in field reporting for this attack family. Confidence in mapping is high for the Execution and Defense Evasion entries, which are intrinsic to the chain itself; the Persistence and C2 entries depend on what the decoded payload actually does.

8 · Detection Engineering — Behavioral Correlation Beats Regex

Current published content from Splunk, Elastic, Microsoft, Red Canary, and Mandiant converges on a single design principle: detection for this chain has to combine signals. Regex on -EncodedCommand alone is fragile, both because the switch has many functionally equivalent forms and because legitimate enterprise usage produces routine false positives that bury the malicious cases.

8.1 Detection patterns that work

(HIGH CONFIDENCE) The strongest detection logic in production today combines the following signal classes:

• Parent provenance: escalate when the parent of cmd.exe → powershell.exe is Office, a script-host engine, mshta.exe, a browser-download zone, or a binary running from a user-writable directory.

• Switch bundle: flag combinations of -EncodedCommand with -NoProfile, -WindowStyle Hidden, or -ExecutionPolicy Bypass. Two or more in combination is rarely sanctioned admin use.

• Argument shape: alert on long Base64 strings on PowerShell command lines and on high Shannon entropy in PowerShell arguments. Elastic publishes a rule on long PowerShell interpreter arguments specifically because length and entropy are robust to switch-name obfuscation.

• Decoded behavior: hunt 4104 events for download-cradle tokens (DownloadString, WebClient, Invoke-RestMethod), AMSI references, compression-plus-Base64 patterns (DeflateStream, GzipStream, FromBase64String), and shellcode-loader primitives.

• Follow-on activity: escalate when an encoded PowerShell event is followed within seconds by an outbound network connection from powershell.exe, a file creation, a Run-key write, or a new scheduled task on the same host.

8.2 Detection patterns to avoid in isolation

These produce alert volume out of proportion to their analytic value when used as a sole signal:

• Exact-string match on powershell.exe -EncodedCommand with no other signal. The shorthand forms (-enc, -ec, caret-injected variants, mixed-case) will be missed and admin noise will dominate.

• Alerting on any cmd.exe → powershell.exe relationship regardless of arguments. The volume is unmanageable in any environment with active management tooling.

• Static blocklists of Base64 strings. The encoded body changes per-operator and per-campaign; blocklisting catches yesterday’s sample.

8.3 Detections worth implementing first

If only three detections can be built tomorrow, build these:

1. Parent + encoded + hidden: any powershell.exe with -enc / -ec / -EncodedCommand and -w hidden or -WindowStyle Hidden where the parent is cmd.exe, mshta.exe, wscript.exe, cscript.exe, an Office binary, or any process running from a user-writable path.

2. 4104 download cradle: Script Block Log entries containing DownloadString, Invoke-RestMethod, Invoke-WebRequest, Net.WebClient, or Net.Sockets — particularly when paired with IEX or Invoke-Expression.

3. Encoded plus network plus persistence: any encoded PowerShell launch followed within sixty seconds by both an outbound HTTP/HTTPS connection from the same PID and a Run-key, scheduled task, service, or WMI subscription write on the same host.

9 · Hardening and Mitigation

Detection alone is not the goal — narrowing the attack surface around the chain materially reduces the operational burden. The hardening controls below are drawn from current Microsoft and vendor guidance and are ordered roughly by impact-to-effort ratio.

9.1 Logging baseline

• PowerShell Script Block Logging enabled enterprise-wide via Group Policy (Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging). Without this, 4104 will only catch warning-level suspicious blocks.

• PowerShell Module Logging enabled for at least Microsoft.PowerShell.* modules; ideally enabled for all modules.

• PowerShell Transcription enabled to a secured network path so transcripts are not deletable by the compromised user.

• Process command-line auditing enabled so Windows Event ID 4688 records full command lines.

• Sysmon deployed with a tuned configuration (SwiftOnSecurity or Olaf Hartong modular configs are reasonable starting points).

9.2 Attack-surface reduction

• ASR rule: Block all Office applications from creating child processes (GUID d4f940ab-401b-4efc-aadc-ad5f3c50688a).

• ASR rule: Block execution of potentially obfuscated scripts (GUID 5beb7efe-fd9a-4556-801d-275e5ffc04cc).

• ASR rule: Block Win32 API calls from Office macros.

• ASR rule: Block JavaScript or VBScript from launching downloaded executable content.

9.3 Application control

• WDAC / App Control for Business with script enforcement enabled places non-allowlisted PowerShell scripts into Constrained Language Mode and blocks all MSHTA-mediated script execution. This is the highest-impact single control against the LOLBin chains that most often deliver encoded PowerShell.

• Constrained Language Mode on endpoints where full scripting is not operationally required. Most user workstations qualify.

9.4 Legacy PowerShell removal

• Microsoft has begun removing PowerShell 2.0 from Windows 11 24H2 and Windows Server 2025. Audit for any remaining PowerShell 2 invocations and alert on -Version 2.0 on modern hosts as a downgrade-attack indicator (T1689).

9.5 Identity and privilege

• Local administrator removal on user workstations. Most stages of this chain still execute under user privilege, but persistence and lateral movement are sharply harder without local admin.

• LAPS deployment to remove shared local-admin password material that an in-memory chain can otherwise harvest.

10 · Triage Playbook — One Page for the Console

11 · Open Questions and Limitations

(MODERATE CONFIDENCE) The biggest practical limitation of this triage model is visibility. If 4688 command-line auditing is off, if Sysmon is not deployed or is misconfigured, or if PowerShell Script Block Logging is not enabled, most of the signal that makes the chain reliably triageable disappears. Microsoft’s own documentation is explicit that 4688 command-line logging is not enabled by default, and PowerShell’s logging documentation is explicit that full Script Block Logging must be configured by policy. Detection engineering on this chain is therefore inseparable from the logging baseline.

(MODERATE CONFIDENCE) A second limitation is the partial coverage of warning-level 4104 events. Where full Script Block Logging is not yet deployed, the warning-level subset is a valuable fallback dataset — but it is filtered to PowerShell’s built-in suspicious-keyword heuristics, which means content that does not match those heuristics will not be recorded. Treat warning-level 4104 as a minimum dataset, not a substitute for full coverage.

(LOW CONFIDENCE) A third area to track but not overweight is the family of AST-level evasions that exploit the PowerShell/.NET boundary. ScriptBlock Smuggling, disclosed in 2024, is technically meaningful — the published research describes producing a benign AST for AMSI and logging while compiling a different, malicious AST for execution — but the authors stated they had no evidence of real-world deployment at time of publication. Hunting for the technique is sensible at advanced shops; assuming it is in play in every case is not.

(MODERATE CONFIDENCE) Finally, statistics in this space should be read with care. Some widely repeated figures — for example, marketing-grade claims about the number of threat groups, the percentage of attacks involving any given LOLBin, or the share of incidents that are “fileless” — are useful for direction but should not be treated as precise denominators. The analytic conclusions in this Field Note rest on the technique’s observed behavior and on primary vendor and platform documentation, not on any single industry statistic.