DC0029: Script Execution
The execution of a text file that contains code via the interpreter.
Analyst context for executives and security teams
Script Execution is an ATT&CK data component for evidence that a text file containing code was run through an interpreter. Its value is not that scripts are inherently malicious, but that many legitimate administrative and automation workflows use the same pattern defenders need to understand during investigations.
Executive priority
Treat this as a coverage and evidence question: can the organization prove when interpreted scripts run, by whom, from where, and under what context? This matters for incident response readiness, audit defensibility, and prioritizing monitoring around automation-heavy environments. ATT&CK does not specify platforms, tactics, or detection logic for this component, so leaders should ask whether local logging standards cover the interpreters and business systems that matter most.
Technical view
SOC and IR teams should validate whether telemetry can distinguish interpreter execution from ordinary application activity and whether records preserve enough context to support triage: script path or content reference when available, interpreter process details, initiating user or service account, parent process, command line or arguments where collected, timestamp, host, and related file activity. Because no ATT&CK relationships or official detection text were supplied, this component should be used as a logging requirement and investigation pivot rather than a standalone detection rule.
Likely telemetry
- Interpreter process execution records
- Command-line or argument logging where available
- Script file access or execution metadata
- User, service account, and session context
- Parent-child process relationships
Detection direction
- Confirm which script interpreters exist in the environment and whether their executions are centrally logged.
- Tune detections against local baselines because script execution is often legitimate for administration, automation, deployment, and maintenance.
- Validate whether telemetry includes enough context to separate expected automation from unusual users, locations, parent processes, or execution timing.
- Identify blind spots where interpreter execution occurs without command-line detail, file context, user context, or reliable retention.
- Use this component as supporting evidence in investigations rather than assuming script execution alone indicates malicious activity.
Mitigation priorities
- Define logging requirements for interpreter-based script execution across in-scope systems.
- Centralize and retain script execution evidence so SOC and IR teams can reconstruct activity.
- Review administrative and automation practices to establish expected script execution patterns.
- Apply least-privilege and change-control expectations to accounts and systems that routinely run scripts.
- Periodically test whether incident responders can answer who executed a script, where it ran, and what context was recorded.
Analyst notes and limits
This object is a data component, not a technique. It describes an evidence source useful for detection engineering and investigations. The supplied ATT&CK fields provide a definition only; no official detection guidance, tactics, platforms, or relationship context were provided.
Coverage and detection value depend on the organization’s interpreters, operating environments, logging configuration, retention, and baselines. The supplied ATT&CK data does not support claims about specific platforms, adversaries, active exploitation, impact, or guaranteed detection.
Script Execution
The execution of a text file that contains code via the interpreter.
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.0 | Current bundle | a06baf91fcfa… |
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 DC0029Open 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.