Windows Command Shell
While it doesn’t do much on its own, Windows Command Shell can call on virtually any executable on the system to execute batch files and arbitrary tasks. Command Shell overtook PowerShell in 2022 as the most prevalent technique we detected.Pairs with this song
Windows Command Shell overtook its cousin PowerShell as the number one adversary technique Red Canary observed in 2022. Hopefully things won’t be awkward at Thanksgiving.
Why do adversaries use Windows Command Shell?
Windows Command Shell is the native command-line interpreter (CLI) across every version of the Windows operating system. As utilitarian as it is ubiquitous, Windows Command Shell is one of the primary ways that adversaries interact with compromised systems. Unlike its more sophisticated and capable cousin, PowerShell, Windows Command Shell’s native feature set—i.e., commands that may be invoked without starting a new process on the system—is limited, having remained constant for years or even decades. Despite its limitations, an adversary can abuse Windows Command Shell to call on virtually any executable, making it an extremely versatile tool.
How do adversaries use Windows Command Shell?
From a high level, an adversary can use Windows Command Shell to:
- obfuscate malicious activity
- collect system information
- modify systems
- execute binaries
- bypass security controls
Adversaries commonly employ obfuscation to evade detection and delay or confound analysis. However, robust detection logic can effectively uncover obfuscation techniques. Indicators of obfuscation include gratuitous use of:
- environment variable substrings
- for loops
- double quotes
- caret symbols
- random variable names
If your detection logic is looking for specific strings (e.g.,
powershell.exe), you may be blind to adversaries calling something like
P^ow””ersh””ell. Daniel Bohannon has covered obfuscation methods in depth.
Beyond obfuscation, adversaries frequently use the shell’s built-in
type command for information gathering. The
type command can be used to display the contents of configuration files, including everything from the relatively mundane but interesting
%windir%\system32\drivers\etc\hosts to source code files for sensitive applications. Combine the use of the built-in
type command with shell redirection via the
>> operators, and adversaries have a means of copying files (even binary files) without using the copy command itself.
In addition to abusing the command shell for information gathering, adversaries can use it to modify system settings too. They can add entries to the
\hosts file mentioned above, and can also use the built-in
echo command to redirect the shell output.
Moving beyond the command shell’s built-in commands,
cmd.exe can be used to launch virtually any executable on the system, either native binaries that ship with Windows, binaries that adversaries drop on the systems, or interpreters such as PowerShell, CScript, and more. Combine this with the shell’s built-in capabilities and the ability to put these commands together in batch files, and adversaries have unlocked a powerful tool in the humble Windows Command Shell.
Lastly, adversaries can use the Command Shell to bypass security controls. In recent years we have seen malicious use of obscure file system features such as symlinks and directory junctions. The shell built-in command
mklink can be used to create these special file system features, allowing adversaries access to data they would normally not have rights to access—such as sensitive files stored in volume shadow copies.
- Retadup worm
Since the Windows Command Shell is so versatile and adversaries abuse it in so many different ways, it’s difficult to offer generic guidance that security teams to prevent this behavior outright. However, much of the malicious command shell activity we observe involves obfuscation, which can be mitigated by Defender Antivirus’s “Block execution of potentially obfuscated scripts” attack surface reduction rule.
Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.
The Windows Command Shell often plays a supporting role in the threats we detect. Given this, many different telemetry or data sources might offer valuable insight into suspicious command shell activity, depending on the context in your specific environment. As with many of our detection analytics, we rely extensively (but not exclusively) on process and command-line monitoring. The following data sources—largely available via commercial EDR products—offer valuable visibility into malicious use of the Windows Command Shell:
Given adversaries’ affinity for obfuscation, some of the most effective detection analytics in our arsenal are those that look for characters and strings commonly used in obfuscation. These obfuscation techniques can point defenders to malicious behavior without needing to know the contents of command. Because the Windows Command Shell is so often used to execute more useful or interesting system binaries, detection analytics that monitor for execution of those binaries with suspicious parameters are also useful.
While monitoring for suspicious command-line parameters can help you catch malicious or suspicious activity, this shouldn’t be your only source of visibility. Monitoring process relationships, especially in combination with process behaviors, is another important capability. For example, while monitoring for Microsoft Office products spawning a Windows Command Shell may be prone to false positives, the same detection logic combined with suspicious command-line parameters, network connections to external domains, or cross-process events to critical processes (e.g.,
lsass.exe) may offer much higher fidelity.
Process access monitoring
Detection logic that monitors for the Windows Command Shell or its child processes injecting threads into
lsass.exe or other critical processes is generally a high-fidelity analytic.
Network connections associated with Windows Command Shell are often benign, but there’s value in monitoring for connections to suspect top-level domains—or domains commonly associated with malicious activity. Combining such detection logic with other analytics adds to the fidelity of any triggered detections.
File modification and creation events in the context of the Windows Command Shell are a valuable source for detecting adversaries, especially when combined with interesting process relationships. For example, if Microsoft’s HTML Application Host,
cmd.exe and that child process writes a malicious or unknown executable to disk—or copies an existing binary to a different directory—it should be investigated. This same coverage should be extended to other Microsoft processes, such as the Internet Information Services worker process,
Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.
Windows Security Event ID 4688: Process Creation
Process Creation (4688) events with command-line argument logging enabled is the best native source of telemetry for detecting malicious use of the Windows Command Shell. A good understanding of baseline scripts and processes that call the Windows Command Shell will be essential to reduce noise and combat potential false positive alerts.
Sysmon Event ID 1: Process creation
Sysmon process creation events are another rich source of telemetry for detecting adversarial abuse of the command shell. Like Windows Security Event ID 4688, process creation events track process starts and corresponding command lines.
Sysmon Event ID 11: File create
File creation events are populated whenever a file is created or overwritten. Since processes constantly create temp files during normal activity, Event ID 11 can be incredibly noisy without thoughtful tuning. However, you can use Event ID 11 to track the Windows Command Shell’s file creation history and gain valuable insight into malicious and suspicious activity.
Endpoint detection and response (EDR) products
Most commercial EDR products provide detailed visibility into all of the data sources referenced above and offer great value to security teams seeking to detect adversaries abusing the Windows Command Shell.
Windows Command Shell is among the most prevalent adversary techniques we detect year after year—even though it mostly plays a supporting role. As such, we have a well-stocked library of 129 detection analytics for catching malicious use of Windows Command Shell. That’s nine fewer detection analytics than last year, due largely to tuning improvements and false positive reduction efforts across our detector library. The following pseudo-detection analytics are adapted from Red Canary behavioral analytics and should serve as a guide for security teams who’d like to improve their defense in depth.
Note: These detection analytics may require tuning.
Detecting obfuscation in the command shell is relatively straightforward, but there are a lot of variations to consider when you’re developing detection coverage. Of course, the process you’re looking for will always be
cmd.exe, but the corresponding command line can contain a variety of suspicious characters. The trick is finding the thresholds where the inclusion of obfuscation characters go from normal to anomalous (but benign) to suspicious enough to warrant alerting. The following pseudo-detection logic offers a good starting point for developing detection coverage for obfuscation in the command line:
process == cmd.exe && command_includes [high numbers of the following characters] ('^' || '=' || '%' || '!' || '[' || '(' || ';' || ' ')
The following test demonstrates a partially obfuscated command execution. In this case, string substitution is performed by referencing substrings in environment variables.
%LOCALAPPDATA:~-3,1%md /c echo "tweet, tweet" > tweet.txt & type tweet.txt
Unusual or suspicious process ancestry
We have a lot of detection analytics that seek out suspicious or unusual process lineage spawning or spawning from
cmd.exe. Many of them don’t often generate confirmed threat detections but can occasionally raise the flag on important threats, like Exchange compromises. One semi-common pattern in our library of analytics is suspicious process interactions between the Windows IIS worker process (
w3wp.exe) and the command shell. The following amalgamation of analytics might help you detect a diverse array of malicious activity related to web server compromises:
parent_process == w3wp.exe && process == cmd.exe && command_includes ('http://' || 'https://' || 'echo') || child_process == powershell.exe
The following example demonstrates
cmd.exe executing from a suspicious parent process. In this case,
cmd.exe will spawn as a child of
wmic process call create CommandLine="cmd /c powershell.exe -C Write-Host ([Net.WebClient]::new().DownloadString('https://gist.githubusercontent.com/mgraeber-rc/25ebfac64a2ba5ca22639da9c1aefcfd/raw/d0c4f7338ebc2f8d5349b66b2e31cf239297053f/tweet.txt'))"
Bypassing security controls
Adversaries bypass controls using the Windows Command Shell in a plethora of ways, but you can detect the one we see most often with a simple combination of process execution and a corresponding command line.
process == cmd.exe && command_includes ('bypass' || '-exec')
The following test demonstrates launching PowerShell and bypassing the execution policy:
echo Write-Host tweet, tweet > tweet.ps1 cmd /c powershell.exe -exec bypass -file tweet.ps1
Windows scheduled task create shell
Adversaries frequently establish persistence by using scheduled tasks to launch the Windows Command Shell. Detecting this behavior is relatively straightforward.
process == schtasks.exe && command_includes ('create') && ('cmd.exe /c' || 'cmd /c')
The following test demonstrates creating a scheduled task that spawns
cmd.exe as SYSTEM:
schtasks /Create /SC DAILY /TN spawncmd /TR "cmd.exe /c echo tweet, tweet" /RU SYSTEM
Service Control Manager spawning Command Shell with suspect strings
The following pseudo detector should generate an alert when
cmd.exe along with a corresponding
/c command, which are common attributes of post exploitation that we’ve seen in association with this technique.
parent_process == 'services.exe' && process == 'cmd.exe' && command_includes ('echo' || '/c')
Windows Explorer spawning Command Shell with
This detection analytic looks for instances of
cmd.exe along with corresponding
exit commands that we commonly observe in conjunction with a wide variety of malicious activity.
parent_process == 'explorer.exe' && process == 'cmd.exe' && command_includes ('start' && 'exit')
Weeding out false positives
Unfortunately, the best data source for detecting malicious usage of the Windows Command Shell—process creation events with command-line arguments captured—will also be the primary source of false positives. Understanding your environment and what normal use of the Windows Command Shell looks like is key to separating the wheat from the chaff. To build a successful detection pipeline that doesn’t overwhelm analysts with false positives, create filters to bucket normal usage, unusual usage, and suspicious or known malicious usage.
Start testing your defenses against Windows Command Shell using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
View atomic tests for T1059.003: Windows Command Shell. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using Command Prompt:
%LOCALAPPDATA:~-3,1%md /c echo Hello, from CMD! > hello.txt & type hello.txt
What to expect
cmd.exe, writes “Hello, from CMD!” to
hello.txt, and then displays it.
Useful telemetry will include:
EDR tools, Sysmon Event ID 1, and Windows Security Event ID 4688 should collect relevant telemetry.
Command-line logging will capture the context of what is executed.
EDR tool, Sysmon Event ID 1, and Windows Security Event ID 4688 should collect relevant telemetry.
EDR tools and Sysmon Event ID 11 should collect relevant telemetry.
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.