An attacker who cannot run code cannot do much, which is why M1038 Execution Prevention is mapped to more ATT&CK techniques than almost any other mitigation. ATT&CK v20 links it to more than 80 techniques and sub-techniques across eight tactics, from PowerShell and WMI to signed-binary proxy execution, vulnerable drivers and, new in recent versions, prompt injection against AI agents. This guide reads that mapping technique by technique: what application control and script restriction actually stop, which rows depend on blocking specific built-in tools, where execution prevention fails, and how to measure coverage. It is for endpoint, detection engineering and platform teams. Building an allowlisting policy from scratch is covered in the linked control guides and is not repeated here.
Key takeaways
- Four measures, one goal. ATT&CK groups M1038 into application control, script blocking, executable blocking from user-writable paths and behaviour-based prevention.
- Living-off-the-land rows need named blocks. About a quarter of the mapping is signed Windows tools (mshta.exe, msbuild.exe, InstallUtil.exe, wmic.exe and others) that an allowlist trusts unless you deny them explicitly.
- PowerShell needs enforcement, not settings. Microsoft documents that Constrained Language mode is only a security control when an application control policy enforces it; setting the mode by hand is for experimentation.
- Drivers and kernels are in scope. T1068 and T1547.006 are mitigated by driver blocklists and kernel module controls, not by user-mode allowlisting alone.
- AI agents extend the idea. For T1698 and T1699, ATT&CK applies execution prevention to agent actions: authorise tool calls outside the model, never on the model's say-so.
What M1038 covers
ATT&CK defines M1038 as preventing the execution of unauthorised or malicious code through application control, script blocking and other execution prevention mechanisms (attack.mitre.org, mitigation version 1.3, last modified 12 May 2026).
| Measure in ATT&CK text | ATT&CK example | Typical tooling (alphabetical) |
|---|---|---|
| Application control | Allow only signed or pre-approved applications on servers and endpoints | AppArmor, App Control for Business (WDAC), AppLocker, fapolicyd, SELinux |
| Script blocking | Constrained Language mode for non-administrators; block untrusted JavaScript in browsers | PowerShell language modes under application control, browser policy |
| Executable blocking | Block .exe, .bat and .ps1 from user-writable directories such as %TEMP% and %APPDATA% | Path rules in application control policy |
| Dynamic analysis prevention | EDR that analyses runtime behaviour and blocks suspicious execution | Endpoint detection and response platforms |
See the Application Allowlisting Guide, App Control for Business (WDAC) and fapolicyd and Linux Application Allowlisting Guide for policy design.
Techniques M1038 mitigates, by tactic
The table lists the entries with the most defensive value, grouped by tactic, with what ATT&CK's usage text says execution prevention does. Tactic names follow v20, where defence evasion is split into Stealth and Defense Impairment.
| Tactic | Technique | How execution prevention helps (per ATT&CK usage text) |
|---|---|---|
| Execution | T1059.001 PowerShell | Application control; Constrained Language mode restricts dangerous elements such as Add-Type |
| Execution | T1059.003 Windows Command Shell, T1059.006 Python, T1059.007 JavaScript, T1059.011 Lua | Application control, or denylist the interpreter where it is not required |
| Execution | T1059.004 Unix Shell | Application control; on ESXi, execInstalledOnly runs only binaries packaged and signed in a vSphere installation bundle (VIB) |
| Execution | T1059.005 Visual Basic | VBA macros from the internet, based on Mark of the Web, may be blocked in Office applications by default from version 2203 |
| Execution | T1047 Windows Management Instrumentation | Block wmic.exe where not required, for example with App Control (WDAC) rules |
| Execution | T1204.002 Malicious File, T1204.004 Malicious Copy and Paste | Stop executables masquerading as other files; Constrained Language mode for pasted commands |
| Execution | T1609 Container Administration Command | Read-only containers and file systems, minimal images, SELinux-style restrictions |
| Execution | T1698 Indirect Prompt Injection, T1699 Direct Prompt Injection | Do not let model output or retrieved content authorise consequential agent actions; enforce tool and resource authorisation outside the model |
| Stealth | T1218 System Binary Proxy Execution (.001 to .005, .008, .009, .012 to .015) | Block hh.exe, CMSTP.exe, InstallUtil.exe, mshta.exe, Odbcconf.exe, Regsvcs/Regasm, verclsid.exe, mavinject.exe, MMC where not required |
| Stealth | T1216 System Script Proxy Execution, T1220 XSL Script Processing | Block signed scripts and msxsl.exe that are not needed |
| Stealth, Execution | T1127 Trusted Developer Utilities Proxy Execution (.001 MSBuild) | Block or restrict developer utilities such as msbuild.exe if not required |
| Stealth | T1036 Masquerading (.005, .008) | Allow common utilities by attributes other than file name (signer, hash) |
| Stealth, Execution | T1574 Hijack Execution Flow (.001, .006 to .009, .012) | Block unknown DLLs and binaries placed for hijacking, using App Control, AppLocker or Software Restriction Policies |
| Persistence, Privilege Escalation | T1546.008 Accessibility Features, T1546.009 AppCert DLLs, T1546.010 AppInit DLLs | Block replacement binaries and unapproved DLLs |
| Persistence, Privilege Escalation | T1547.006 Kernel Modules and Extensions | SELinux, KSPP, grsecurity and kernel tuning to restrict module loading |
| Privilege Escalation | T1068 Exploitation for Privilege Escalation | Block known vulnerable drivers; validate driver block rules in audit mode first |
| Privilege Escalation | T1611 Escape to Host | Read-only containers and minimal images |
| Persistence | T1176.001 Browser Extensions, T1176.002 IDE Extensions | Extension allow or deny lists |
| Defense Impairment | T1553 Subvert Trust Controls (.001, .003, .005) | Gatekeeper settings on macOS; block malicious SIP DLLs; block container file types at gateways |
| Defense Impairment | T1685 Disable or Modify Tools | Allow only approved security tools; block tools abused to impair defences |
| Command and Control | T1219 Remote Access Tools (.001 IDE Tunneling, .002) | Block unapproved remote access software; control Dev Tunnels by policy |
| Impact | T1490 Inhibit System Recovery | Block utilities such as diskshadow.exe where not required |
Technique detail: T1059 Command and Scripting Interpreter Defensive Guide, T1218 System Binary Proxy Execution Defensive Guide, T1574 Hijack Execution Flow Defensive Guide, T1047 Windows Management Instrumentation Defensive Guide and T1204 User Execution.
Prioritising the mapping
NHI Mgmt Group recommends this order, based on how much of the table each step covers and how safely it can be enforced:
- Block execution from user-writable paths. One path rule set for %TEMP%, %APPDATA%, Downloads and similar locations covers most of T1204.002 and the "new binary" variants of T1574 and T1546.
- Deny the proxy-execution binaries. Microsoft publishes recommended block rules for App Control listing signed tools that can bypass allowlists, including cscript.exe, wscript.exe, mshta.exe, wmic.exe, msbuild.exe, cdb.exe, windbg.exe and InstallUtil.exe. The sample policy ships in audit mode. This one policy addresses large parts of T1218, T1127, T1047 and T1216.
- Enforce PowerShell Constrained Language mode. Microsoft's language modes documentation states that PowerShell runs in ConstrainedLanguage automatically when a system application control policy is detected, and that it must be paired with App Control in system lockdown so it cannot be bypassed. Scripts the policy allows still run in FullLanguage, so sign your administrative scripts.
- Block vulnerable drivers. Microsoft's vulnerable driver blocklist is on by default on Windows 11 2022 update and later, and is enforced when memory integrity (HVCI), Smart App Control or S mode is active. Elsewhere Microsoft recommends adding it to an App Control policy, in audit mode first. This covers T1068's driver route.
- Full allowlisting on servers. Servers have stable software sets, so a signer and managed-installer based allowlist is practical there before it is on user devices.
- Interpreters and extensions. Denylist Python, Lua, AutoIt and similar interpreters on systems that do not need them, and set browser and IDE extension allowlists.
Choosing the mechanism
| Mechanism | Platform | Strongest against | Trade-off |
|---|---|---|---|
| App Control for Business | Windows | T1218, T1127, T1574, T1068 (driver rules), PowerShell lockdown | Machine-wide; Microsoft states it meets MSRC security servicing criteria |
| AppLocker | Windows | Per-user or per-group restrictions on shared machines | Receives security fixes but no new features; Microsoft says it does not meet the servicing criteria |
| fapolicyd, SELinux, AppArmor | Linux | T1059.004, T1059.006, T1547.006, container rows | Policy authoring effort; package-manager trust model |
| execInstalledOnly | VMware ESXi | Unsigned binaries on hypervisors (T1059.004) | Only VIB-packaged software runs |
| Gatekeeper and system settings | macOS | T1553.001, T1548.004 | Coarser than a full allowlist |
| Read-only containers, minimal images | Containers | T1609, T1611 | Requires immutable build and deploy practice |
| Out-of-model authorisation | AI agents | T1698, T1699 | Needs a policy layer between agent and tools |
Microsoft's guidance is to enforce App Control at the most restrictive level the organisation can support and use AppLocker only to fine-tune per user or group. Small organisations can start with audit-mode block rules and path restrictions; large ones should use managed installer and signer rules so that policy follows the software deployment pipeline. See the Application Control and Endpoint Prevention Buyer's Guide.
Machine identities and pipelines
Execution prevention touches non-human identities in three places. First, build agents and CI runners execute whatever the pipeline definition says; treat runner images as servers with fixed software sets, apply allowlisting, and keep interpreters there only because builds need them. Second, Kubernetes service account tokens are what T1059.013 and T1609 abuse once code runs in a container; read-only root file systems and minimal images limit what that code can do with them. Third, AI agents act through tool credentials: ATT&CK's T1698 and T1699 guidance means that the agent's identity, not the prompt, should decide which tools and resources a request can reach. See the MITRE ATT&CK T1609 Container Administration Command page.
Implementation approach
- Baseline. Deploy the policy in audit mode to a representative pilot ring and collect block events for at least two weeks.
- Classify events. Each would-be block is a legitimate tool needing a signer or managed-installer rule, an unneeded tool to deny, or a finding to investigate.
- Enforce by ring. Move servers and privileged access workstations to enforced mode first, then standard users, then developers with a separate policy.
- Handle exceptions with supplemental policies. Time-limited, owned and reviewed; never by switching a ring back to audit permanently.
- Roll back cleanly. Keep the previous signed policy version ready to redeploy; note that Microsoft says a reboot is needed for already-running blocked drivers to stop.
- Keep the lists current. Microsoft updates the vulnerable driver blocklist quarterly and advises adding deny rules for older versions of applications that had bypasses fixed.
What M1038 does not stop
- Allowed tools used maliciously: An allowlist that trusts PowerShell in FullLanguage for signed scripts, or an RMM tool the business uses, will run attacker commands through them. Behaviour detection (M1040) covers this.
- In-memory and exploit-based execution: Code injected into an allowed process is not a new executable; exploit protection (M1050) and EDR carry the load.
- Administrators who can change policy: Unsigned App Control policies can be replaced by a local administrator; signed policies and privileged account controls (M1026) are the counter.
- Cloud and SaaS execution: T1059.009 Cloud API activity from an attacker's own machine never touches your endpoints; identity controls apply instead.
- Drivers not yet on the list: Microsoft states the blocklist is not guaranteed to cover every vulnerable driver.
Common failure patterns
- Audit mode forever. Policies are deployed in audit, produce events nobody reviews, and never move to enforcement.
- Path rules on writable paths. Allowing everything under a directory users or services can write to turns the allowlist into a staging area.
- Execution policy mistaken for a control.
Set-ExecutionPolicy AllSignedwithout App Control leaves PowerShell in FullLanguage; enforcement comes from the application control policy. - No block rules for signed tools. A signer-based allowlist trusts every Microsoft-signed binary, including the proxy-execution tools in T1218, unless the recommended block rules are added.
- Developer exemptions that cover everyone. A broad exception for build tools is applied to all users rather than to a developer ring.
Detection and measurement
- Log: App Control and AppLocker block and audit events (Microsoft-Windows-CodeIntegrity and AppLocker event logs), fapolicyd denials, PowerShell sessions not in ConstrainedLanguage on enforced machines, policy changes, execution from user-writable paths.
- Test: for each mapped technique, run a safe emulation (for example a benign script launched through mshta.exe in a test ring) and record block, audit-only or allowed.
| Metric | What good looks like |
|---|---|
| Endpoints and servers with an enforced (not audit) policy | All servers; rising coverage of user devices |
| Microsoft recommended block rules deployed in enforce mode | All Windows devices except a documented developer ring |
| Mapped M1038 techniques with a validated block | Tracked per quarter, especially T1218 and T1059 rows |
| Open policy exceptions past their expiry date | Zero |
| Days from vulnerable driver list release to deployment | Within one patch cycle |
D3FEND and related mitigations
The MITRE D3FEND knowledge graph relates M1038 to four defensive techniques: D3-EAL Executable Allowlisting, D3-EDL Executable Denylisting, D3-DLIC Driver Load Integrity Checking (ensuring the integrity of drivers loaded during operating system initialisation) and D3-PSEP Process Segment Execution Prevention (preventing execution of memory outside the code segment).
| Related mitigation | Relationship to M1038 |
|---|---|
| M1033 Limit Software Installation | Stops software arriving; M1038 stops it running |
| M1040 Behavior Prevention on Endpoint | Blocks malicious behaviour by allowed programs |
| M1042 Disable or Remove Feature or Program | Removes the binary instead of blocking it |
| M1045 Code Signing | Provides the signer trust that allowlists depend on |
| M1048 Application Isolation and Sandboxing | Contains code that is allowed to run |
See M1033 Limit Software Installation, M1040 Behavior Prevention on Endpoint and M1045 Code Signing.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CM-7(5) Authorized Software: Allow-by-exception; CM-7(2) Prevent Program Execution | Allowlisting and blocking program execution |
| NIST SP 800-53 Rev. 5 | SI-7 Software, Firmware, and Information Integrity | Integrity checks on code before execution |
| NIST CSF 2.0 | PR.PS-05 | Installation and execution of unauthorised software are prevented |
| CIS Controls v8.1 | 2.5 Allowlist Authorized Software; 2.6 Allowlist Authorized Libraries; 2.7 Allowlist Authorized Scripts | Application, library and script allowlisting |
| ISO/IEC 27001:2022 Annex A | 8.19 Installation of software on operational systems; 8.7 Protection against malware | Controlled software and malware prevention |
Practitioner checklist
- Map your application control policies to the M1038 technique list and mark each row enforced, audit-only or uncovered.
- Block execution from user-writable directories on every managed endpoint.
- Deploy Microsoft's recommended block rules in audit, review, then enforce.
- Enforce PowerShell Constrained Language mode through App Control, and sign administrative scripts.
- Confirm the vulnerable driver blocklist is active (or added to App Control) on all Windows devices.
- Apply full allowlisting to servers, CI runners and privileged access workstations first.
- Enable
execInstalledOnlyon ESXi hosts and use read-only, minimal container images. - For AI agents, enforce tool and resource authorisation outside the model.
- Expire every policy exception and alert on policy changes.
Standards and references
- MITRE ATT&CK: M1038 Execution Prevention
- MITRE D3FEND: Executable Allowlisting (D3-EAL)
- Microsoft Learn: App Control and AppLocker overview
- Microsoft Learn: Applications that can bypass App Control and how to block them
- Microsoft Learn: Microsoft recommended driver block rules
- Microsoft Learn: about_Language_Modes
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
Related NHI Mgmt Group resources: Application Allowlisting Guide · App Control for Business (WDAC) · Application Control and Endpoint Prevention Buyer's Guide · M1037 Filter Network Traffic