M1038: Execution Prevention
Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions. This mitigation can be implemented through the following measures:
Application Control:
- Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution. - Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.xml"`)
Script Blocking:
- Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources. - Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g., `Set-ExecutionPolicy AllSigned`)
Executable Blocking:
- Use Case: Prevent execution of binaries from suspicious locations, such as `%TEMP%` or `%APPDATA%` directories. - Implementation: Block execution of `.exe`, `.bat`, or `.ps1` files from user-writable directories.
Dynamic Analysis Prevention: - Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time. - Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.
Security context for executives and security teams
Execution Prevention is a control family for stopping unapproved applications, scripts, binaries, or suspicious runtime behavior before they can run. Its business value is reducing the chance that a malicious file, renamed utility, script, or abused interpreter becomes an incident. For leaders, the key question is not whether a tool exists, but whether allowlists, script controls, and execution blocking are enforced on the systems and user groups where unauthorized code would create the most operational risk.
Executive priority
Prioritize this mitigation where unauthorized execution would disrupt business continuity, increase privilege escalation risk, or weaken audit evidence around endpoint and server control. The relationship set shows relevance across execution, stealth, privilege escalation, and lateral movement behaviors, including command and scripting interpreters, PowerShell, Windows command shell, Unix shell, cloud APIs, container CLI/API, WMI, masquerading, trusted developer utilities, shared modules, and tainted shared content. Executives should ask which assets have enforceable application control, which exceptions are business-justified, and whether high-risk script and user-writable locations are governed rather than merely monitored.
Technical view
SOC, detection engineering, and IR teams should validate that execution prevention is configured to block or constrain unauthorized applications, scripts, and binaries, especially from user-writable paths such as TEMP or APPDATA where supported by local policy. For Windows-related relationships, validate controls around PowerShell, cmd, WMI, MSBuild, script types such as VB/JavaScript/AutoHotKey/AutoIT, and signed or trusted developer utilities that may proxy execution. For Linux, macOS, ESXi, containers, network devices, IaaS, SaaS, identity provider, and cloud API contexts represented in related techniques, confirm whether equivalent execution restrictions, mandatory access control, CLI/API governance, and script controls exist. Because MITRE provides no official detection text for this mitigation, local telemetry and prevention logs are required to prove coverage.
Likely telemetry
- Application control allow/block events and policy enforcement logs
- Script execution and script-blocking events, including PowerShell and other interpreter activity where available
- Process creation and command-line telemetry for shells, interpreters, developer utilities, and execution from user-writable directories
- EDR runtime prevention, behavior-blocking, and quarantine/block decisions
- File metadata, extension, path, signature, and hash evidence relevant to masquerading and file-type masquerading
Detection direction
- Confirm that prevention events are ingested and distinguish true blocks from audit-only or report-only policy modes.
- Tune for execution from suspicious or user-writable locations while accounting for legitimate software updaters, administrative tools, developer workflows, and automation scripts.
- Review allowlist exceptions for trusted utilities, interpreters, signed binaries, and developer tools because related techniques include proxy execution and masquerading behaviors.
- Correlate blocked or allowed execution with file name, path, signature, file type, interpreter, parent process, user, and host role to reduce false positives and identify risky exceptions.
- Validate coverage beyond Windows where applicable; related techniques include Linux, macOS, ESXi, containers, network devices, IaaS, SaaS, office suite, and identity provider contexts, but implementation mechanisms will differ.
Mitigation priorities
- Start with business-critical servers, administrative workstations, and high-risk endpoints where unauthorized execution would have the highest operational impact.
- Implement application control using digitally signed or pre-approved application policies, with careful exception governance and change management.
- Block or constrain unauthorized scripts, including PowerShell and JavaScript where applicable, and apply constrained language or signed-script requirements when appropriate to the environment.
- Prevent execution of executables and scripts from user-writable directories such as TEMP and APPDATA where supported by platform and business process.
- Apply platform-appropriate mandatory access control or execution policies for non-Windows systems where relevant.
Additional notes and limits
This is a mitigation object, not a technique, so the defensive value is in control validation rather than adversary procedure detail. The supplied relationships show broad relevance to execution and stealth behaviors, especially command and scripting interpreters and masquerading. Strong assessment requires comparing the intended prevention policy with actual enforcement mode, exception inventory, and telemetry ingestion.
The ATT&CK object does not specify platforms or tactics directly and provides no official detection guidance. Platform relevance is inferred only from the supplied related techniques. Local architecture, endpoint tooling, cloud/container usage, administrative workflows, and business-approved exceptions are required to determine practical coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Execution Prevention
Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions. This mitigation can be implemented through the following measures:
Application Control:
- Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution. - Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.xml"`)
Script Blocking:
- Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources. - Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g., `Set-ExecutionPolicy AllSigned`)
Executable Blocking:
- Use Case: Prevent execution of binaries from suspicious locations, such as `%TEMP%` or `%APPDATA%` directories. - Implementation: Block execution of `.exe`, `.bat`, or `.ps1` files from user-writable directories.
Dynamic Analysis Prevention: - Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time. - Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.
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.
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.
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.