DC0064: Command Execution
Command Execution involves monitoring and capturing the execution of textual commands (including shell commands, cmdlets, and scripts) within an operating system or application. These commands may include arguments or parameters and are typically executed through interpreters such as `cmd.exe`, `bash`, `zsh`, `PowerShell`, or programmatic execution. Examples:
- Windows Command Prompt - dir – Lists directory contents. - net user – Queries or manipulates user accounts. - tasklist – Lists running processes. - PowerShell - Get-Process – Retrieves processes running on a system. - Set-ExecutionPolicy – Changes PowerShell script execution policies. - Invoke-WebRequest – Downloads remote resources. - Linux Shell - ls – Lists files in a directory. - cat /etc/passwd – Reads the user accounts file. - curl http://malicious-site.com – Retrieves content from a malicious URL. - Container Environments - docker exec – Executes a command inside a running container. - kubectl exec – Runs commands in Kubernetes pods. - macOS Terminal - open – Opens files or URLs. - dscl . -list /Users – Lists all users on the system. - osascript -e – Executes AppleScript commands.
Analyst context for executives and security teams
Command Execution is a telemetry category for seeing the actual textual commands, cmdlets, scripts, and parameters run inside an operating system or application. For leaders, its value is practical: many investigations hinge on whether the team can reconstruct what was typed or executed, not just that a process ran. Without this evidence, SOC and incident response teams may struggle to determine intent, scope, and containment priorities.
Executive priority
Prioritize this as an evidence-readiness issue. Command-level visibility can materially improve incident decision-making, compliance evidence, and resilience planning because it helps answer questions such as: what was executed, by whom or what process, with what parameters, and in what environment. Since ATT&CK does not provide tactics, platforms, relationships, or detection guidance for this data component, leaders should ask whether command telemetry is consistently available across the environments they actually operate, including operating systems, applications, shells, scripting interfaces, and container or orchestration tooling where present.
Technical view
SOC, detection engineering, and IR teams should validate that telemetry captures command text and associated arguments or parameters from relevant interpreters and execution paths referenced by MITRE, such as cmd.exe, PowerShell, bash, zsh, programmatic execution, docker exec, kubectl exec, macOS Terminal usage, and osascript-style execution where these exist in the environment. Because no official ATT&CK detection logic is supplied, this object should be treated as a foundational data source to support analytics rather than as a detection by itself.
Likely telemetry
- Command line text, including arguments and parameters
- Shell and interpreter execution records
- Script or cmdlet execution records
- Application-level command execution logs where supported
- Container or orchestration command execution records where such platforms are used
Detection direction
- Inventory where command execution telemetry is collected and where it is missing; the supplied object does not specify platforms, so local environment mapping is required.
- Validate that telemetry includes full command text and parameters, not only process names or high-level execution events.
- Tune analytics with awareness that many commands are administrative and benign; context such as user, host, parent process, workload, and timing is usually needed to reduce false positives.
- Confirm coverage for multiple execution surfaces described by MITRE, including shells, cmdlets, scripts, programmatic execution, and container or Kubernetes-style exec activity where applicable.
- Use this data component to support investigation timelines and behavior reconstruction, but do not treat its presence alone as proof of malicious activity.
Mitigation priorities
- Start with logging and retention requirements: define which systems and applications must preserve command execution evidence for SOC and IR use.
- Standardize collection for command text, parameters, user context, host or workload context, and timestamps across in-scope environments.
- Review access controls around powerful command execution interfaces so that monitoring is paired with least-privilege administration.
- Protect command telemetry from tampering and ensure it is available during incident response and audit reviews.
- Periodically test whether representative administrative and scripted commands are visible end-to-end in monitoring and investigation workflows.
Analyst notes and limits
This is a data component, not a technique. Its defensive value is in enabling detection, triage, and forensic reconstruction across many possible command execution surfaces. The ATT&CK entry provides examples of command types and interpreters but does not supply tactics, platforms, relationships, or detection analytics.
The supplied ATT&CK fields do not include official detection guidance, mapped tactics, explicit platforms, relationships, or threat usage context. Any coverage assessment must be based on the organization’s own logging architecture, systems in use, and retention policy.
Command Execution
Command Execution involves monitoring and capturing the execution of textual commands (including shell commands, cmdlets, and scripts) within an operating system or application. These commands may include arguments or parameters and are typically executed through interpreters such as `cmd.exe`, `bash`, `zsh`, `PowerShell`, or programmatic execution. Examples:
- Windows Command Prompt - dir – Lists directory contents. - net user – Queries or manipulates user accounts. - tasklist – Lists running processes. - PowerShell - Get-Process – Retrieves processes running on a system. - Set-ExecutionPolicy – Changes PowerShell script execution policies. - Invoke-WebRequest – Downloads remote resources. - Linux Shell - ls – Lists files in a directory. - cat /etc/passwd – Reads the user accounts file. - curl http://malicious-site.com – Retrieves content from a malicious URL. - Container Environments - docker exec – Executes a command inside a running container. - kubectl exec – Runs commands in Kubernetes pods. - macOS Terminal - open – Opens files or URLs. - dscl . -list /Users – Lists all users on the system. - osascript -e – Executes AppleScript commands.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 2.1 | Current bundle | de0330022f24… |
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 DC0064Open 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.