DET0202: Behavioral Detection of Windows Command Shell Execution
This detection strategy matters because Windows Command Shell execution is a common administrative capability that can also support adversary execution on...
Analyst context for executives and security teams
This detection strategy matters because Windows Command Shell execution is a common administrative capability that can also support adversary execution on Windows systems. For leaders, the value is not simply “detect cmd.exe,” but knowing whether the SOC can distinguish expected administrative use from suspicious command-shell behavior during an incident.
Executive priority
Prioritize this as a baseline Windows execution visibility question: do security teams have reliable evidence of command-shell activity, enough context to judge legitimacy, and a documented response path when suspicious use is found? This supports incident readiness, audit evidence for monitoring coverage, and operational resilience where Windows systems are business-critical.
Technical view
MITRE lists this detection strategy as detecting T1059.003, Windows Command Shell, under the Execution tactic on Windows. Because the detection strategy object itself provides no official detection logic, platforms, or description, teams should validate coverage against the related technique: command-shell process execution, parent/child process context, user and host context, command-line content where available, and remote-service context when command shell is invoked through remote access paths.
Likely telemetry
- Windows process creation telemetry
- Process command-line arguments where collected
- Parent and child process relationships
- User, host, and privilege context
- Remote service or remote logon context associated with command-shell execution
Detection direction
- Confirm whether command-shell execution is collected consistently across Windows endpoints in scope.
- Tune detections around behavioral context rather than command-shell presence alone, because cmd usage can be legitimate administration.
- Review parent process, child process, user, host role, and remote access context to reduce false positives.
- Identify blind spots where command-line arguments, process lineage, or endpoint telemetry are missing.
- Map alert logic and triage playbooks explicitly to T1059.003 so coverage can be tested and evidenced.
Mitigation priorities
- Establish visibility first: ensure Windows execution telemetry needed for command-shell investigations is available to SOC and IR teams.
- Limit unnecessary command-shell use through administrative policy and role-based access where appropriate.
- Harden and monitor remote service pathways that can invoke command execution on Windows systems.
- Document approved administrative patterns so anomalous command-shell use can be triaged faster.
- Use incident response exercises to verify that analysts can reconstruct command-shell activity from available logs.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description or detection text. The practical guidance here is derived from its relationship to T1059.003 Windows Command Shell and the related technique context: execution on Windows, including possible invocation through remote services.
No official detection analytics, data sources, platforms, tactics, or implementation details were provided for DET0202 itself. Local logging configuration, endpoint tooling, administrative practices, and asset criticality are required to determine actual coverage and alert quality.
Behavioral Detection of Windows Command Shell Execution
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1059.003 | Windows Command Shell Sub-technique | This object detects Windows Command Shell. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 18b4cae8df20… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0202Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.