Windows Command Shell

Analysis

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
parentheses
commas
semicolons
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 > and >> 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.

Associated threats

Ippedo
Gamarue
SocGholish
CrackMapExec
Retadup worm
Impacket

TAKE ACTION

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.

Visibility

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:

Command monitoring

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

Process monitoring

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 monitoring

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 monitoring

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, mshta.exe, spawns 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, w3wp.exe.

Collection

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.

Detection opportunities

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

Obfuscated commands

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 wmiprvse.exe.

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 services.exe spawns cmd.exe along with a corresponding echo or /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 `start` and `exit` commands

This detection analytic looks for instances of explorer.exe spawning cmd.exe along with corresponding start and 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.

Testing

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.

Getting started

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

This obfuscates cmd.exe, writes “Hello, from CMD!” to hello.txt, and then displays it.

Useful telemetry will include:

Visibility	Telemetry	Collection
Visibility: Process monitoring	Telemetry: A `cmd.exe` process will start.	Collection: EDR tools, Sysmon Event ID 1, and Windows Security Event ID 4688 should collect relevant telemetry.
Visibility: Command monitoring	Telemetry: Command-line logging will capture the context of what is executed.	Collection: EDR tool, Sysmon Event ID 1, and Windows Security Event ID 4688 should collect relevant telemetry.
Visibility: File monitoring	Telemetry: `hello.txt` is created, written to, and read from.	Collection: 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.

T1059.003

#2

overall rank

18.9%

Customers affected

837

Threats detected

Threat sounds