M1040 Behavior Prevention on Endpoint: Endpoint Behaviour Prevention Mapped to ATT&CK

Signature scanning stops known files, but most intrusions now run through scripts, Office child processes, injected code and signed drivers that no signature list will catch in time. MITRE ATT&CK mitigation M1040, Behavior Prevention on Endpoint, is the control that blocks those actions on the host by watching process, file, memory and API behaviour and stopping the sequence before it completes. This guide reads M1040 from the ATT&CK v20 data: which techniques MITRE says it mitigates, how each one maps to concrete prevention settings, where the control runs out and what covers the gap, and how to measure coverage. It is written for detection engineers, endpoint owners and SOC leads who already run an EDR and want to turn prevention on deliberately rather than leave it in detect-only mode.

Key takeaways

• M1040 is a prevention control, not a detection one. ATT&CK defines it as blocking suspicious process behaviour, unauthorised file access, abnormal API calls and exploit activity on the endpoint, not alerting on them after the fact.
• ATT&CK v20 maps it to 51 techniques and sub-techniques. The heaviest clusters are Process Injection (T1055, 14 entries), Office Application Startup (T1137, 7 entries), Obfuscated Files or Information (T1027, 6 entries) and Command and Scripting Interpreter (T1059).
• Most of ATT&CK's usage text names Windows attack surface reduction (ASR) rules. That makes the Windows estate the easiest place to start, with three ASR rules Microsoft calls standard protection that can usually go straight to Block.
• Audit first, then block in rings. Behaviour rules break line-of-business software; the safe path is audit mode, exclusions reviewed and justified, then Block or Warn by deployment ring.
• It does not stop valid credentials used through legitimate tools. An attacker with a working service account or API key often never trips a behaviour rule, so M1040 must sit beside identity controls and other mitigations.

What ATT&CK means by Behavior Prevention on Endpoint

The ATT&CK v20 description of M1040 covers the use of technologies that detect and block potentially malicious activity by analysing the behaviour of processes, files, API calls and other endpoint events, using heuristics, machine learning and real-time monitoring rather than signatures alone. It lists four implementation areas:

• Suspicious process behaviour: EDR tooling blocks processes that behave unusually, such as a user-level application spawning a privileged process through an abnormal parent-child relationship.
• Unauthorised file access: endpoint or DLP tooling blocks a process reading or modifying sensitive files, ATT&CK's examples being /etc/shadow on Linux and the SAM registry hive on Windows.
• Abnormal API calls: runtime analysis blocks API sequences associated with injection, ATT&CK naming OpenProcess and WriteProcessMemory.
• Exploit prevention: behavioural exploit protection halts a process when it sees anomalous memory writes such as a buffer overflow.

The distinction from neighbouring mitigations matters when you assign owners. App Control for Business (WDAC) decides which code may run at all (ATT&CK M1038 Execution Prevention). M1040 assumes the code is running and judges what it does. A mature endpoint uses both: allow-listing shrinks the population of code, behaviour prevention catches abuse of the code that remains, including signed system binaries. For the EDR platform itself, see the EDR Guide.

Techniques M1040 mitigates, by tactic

The table groups all 51 non-revoked technique and sub-technique relationships in the ATT&CK v20 Enterprise data by tactic, with the gist of ATT&CK's own usage text for each. Where ATT&CK lists a parent and its sub-techniques with the same text, they share a row.

Two rows sit outside the classic endpoint. T1564.014 is about scanning artefacts in packaging and deployment pipelines, and the T1486 text reaches into AWS policy. The Codefinger campaign shows why: attackers used stolen long-lived AWS keys to re-encrypt S3 objects with SSE-C keys only they held. See the Codefinger S3 ransomware breach. No endpoint agent saw that attack; the preventive control was a policy condition denying SSE-C and the removal of long-lived keys.

From ATT&CK rows to concrete prevention settings

Because ATT&CK cites Windows ASR rules for most rows, the fastest practical mapping is rule by rule. The rule names and GUIDs below are from Microsoft's ASR rules reference (checked November 2026). Equivalent behaviour policies exist in other EDR platforms under different names; use the techniques column to map your own product's policies.

Rule modes, per Microsoft: 0 Off, 1 Block, 2 Audit, 5 Not configured, 6 Warn. They are set through Intune endpoint security (profile Attack Surface Reduction Rules), Group Policy (Microsoft Defender Exploit Guard > Attack Surface Reduction > Configure Attack Surface Reduction rules) or Add-MpPreference -AttackSurfaceReductionRules_Ids ... -AttackSurfaceReductionRules_Actions .... Note that Set-MpPreference overwrites the existing rule list while Add-MpPreference appends. For the wider product configuration, see the Microsoft Defender for Endpoint Guide.

On Linux, the ATT&CK injection rows include T1055.008 Ptrace System Calls and T1055.009 Proc Memory. Beyond the EDR's own behaviour policy, the kernel's Yama module limits ptrace through /proc/sys/kernel/yama/ptrace_scope: 1 restricts attach to descendants, 2 requires CAP_SYS_PTRACE, and 3 disables attach entirely and cannot be changed back until reboot. That is an NHI Mgmt Group recommendation that complements, rather than appears in, the ATT&CK text.

Where identity fits

Several M1040 rows are credential theft in disguise. LSASS protection (T1003.001) is what keeps cached service account and admin credentials from being lifted on a jump host. PsExec and WMI blocking (T1047, T1569.002) collides with deployment tools that run under service accounts, so exclusions tend to be requested for exactly the most privileged non-human identities in the estate. Treat each exclusion as an access decision: name the owning service account, scope the path, set an expiry and review it. On build agents and CI runners, where secrets and tokens live in process memory and environment variables, injection and credential-theft rules are worth enforcing even when developer laptops stay in audit. See the Credential Dumping Guide for the wider credential picture.

How to implement M1040, step by step

1. Baseline coverage: export your EDR's current prevention policy per device group and mark each ATT&CK row above as Block, Audit or Off. Many estates run the agent in detect-only mode without knowing it.
2. Turn on the standard protection rules: Microsoft states the three standard protection rules (LSASS, WMI persistence, vulnerable signed drivers) can typically go to Block or Warn without testing. Do these first; they cover T1003.001, T1546.003 and T1543.
3. Run everything else in audit: set the remaining rules to Audit across a representative pilot, then read event ID 1122 (audit hits) in the Windows Defender Operational log or the equivalent advanced hunting table for long enough to cover month-end and patch cycles.
4. Write justified exclusions: per-rule exclusions where the product supports them, path plus file rather than whole folders, each with an owner and review date. Global exclusions weaken every rule at once.
5. Enforce in rings: move rules to Block (or Warn where users need an override) ring by ring, IT first, then a pilot business unit, then broad. Track event ID 1121 (block) and 1129 (user overrode Warn).
6. Protect the configuration: alert on event ID 5007 (settings changed) and on any attempt to stop or modify the agent, which ATT&CK v20 tracks under T1685 Disable or Modify Tools.
7. Roll back cleanly: keep the previous policy version; a rule breaking a critical app is reverted to Audit for that ring, not switched off everywhere, and the exclusion is fixed before re-enforcing.

Choosing where to enforce first

• Small organisations: enable the standard protection rules plus the Office and script rules in Block; most small estates have few macros and little custom scripting, so audit periods can be short.
• Large estates: enforce first on servers that hold credentials (jump hosts, deployment servers, CI runners) and on high-exposure user groups (finance, executive assistants), where T1137 and T1204 lures land.
• Block or Warn: Warn suits user-facing rules where a legitimate rare action exists; Block suits rules with no business use, such as Office injecting code. Rules without Warn support must go straight from Audit to Block.
• Developer and admin workstations: the prevalence and obfuscation rules generate the most noise here; consider them later, with App Control doing more of the work.

What M1040 does not stop

• Valid accounts used normally: an attacker logging in with stolen credentials through RDP or a cloud console runs nothing anomalous. That is T1078 Valid Accounts territory, handled by MFA, credential hygiene and identity threat detection.
• Agentless and unmanaged assets: hypervisors, appliances, OT and SaaS have no endpoint agent; the Codefinger case above happened entirely in cloud APIs.
• Agent tampering: attackers increasingly use vulnerable drivers to disable security tools; the driver rules help but tamper protection and alerting on agent health are separate controls.
• Living-off-the-land with blessed tools: behaviour rules tuned to avoid breaking administrators also miss attackers acting like administrators. See the Living off the Land Guide.
• Exclusion abuse: a broad folder exclusion becomes a safe drop zone for payloads.

D3FEND's own mapping is a reminder of this boundary. In the D3FEND ontology, M1040 is related to user-behaviour analytics techniques such as D3-RAPA Resource Access Pattern Analysis, D3-SDA Session Duration Analysis, D3-UDTA User Data Transfer Analysis, D3-UGLPA User Geolocation Logon Pattern Analysis, D3-WSAA Web Session Activity Analysis, D3-ANET Authentication Event Thresholding, D3-AZET Authorization Event Thresholding and D3-JFAPA Job Function Access Pattern Analysis. Those are identity and session analytics, which is where the valid-account gap gets covered.

Common failure patterns

• Audit forever: rules enabled in audit during a pilot and never enforced, so dashboards show coverage that does not exist.
• Global exclusions for deployment tooling: excluding a whole tools folder or a deployment service account from every rule to fix one PsExec conflict.
• Mixed management planes: Group Policy and Intune both setting ASR, with Set-MpPreference scripts silently overwriting the rule list.
• Office installed outside Program Files: Microsoft notes that the Office child-process, Office injection and Outlook child-process rules are enforced only when Office is in %ProgramFiles% or %ProgramFiles(x86)%.
• Cloud protection off: the prevalence, obfuscation and ransomware rules depend on cloud-delivered protection, and quietly do less without it.
• Treating M1040 as the ransomware answer: as Codefinger showed, cloud-side encryption attacks never touch an endpoint.

Detection and measurement

Validate with authorised adversary emulation: run benign test cases for the mapped techniques in a lab ring and confirm each produces a block, not just an alert. The MITRE ATT&CK Coverage Mapping Guide covers how to record the results.

Framework mapping

Related ATT&CK mitigations: M1038 Execution Prevention (allow-listing), M1050 Exploit Protection, M1042 Disable or Remove Feature or Program (see M1042 Disable or Remove Feature or Program) and M1043 Credential Access Protection.

Practitioner checklist

• Export current EDR prevention settings and score each of the 51 M1040 relationships as Block, Audit or Off.
• Enforce the three standard protection rules (LSASS, WMI persistence, vulnerable signed drivers) on all Windows devices.
• Confirm the Vulnerable Driver Blocklist is on, and that cloud-delivered protection is enabled where rules depend on it.
• Run remaining rules in audit, review event 1122, and write per-rule exclusions with an owner and expiry.
• Enforce in rings, credential-holding servers and CI runners first.
• Use one management plane for ASR policy and alert on event 5007.
• Set Yama ptrace_scope to at least 1 on Linux servers that hold secrets.
• Deny SSE-C in S3 bucket or IAM policy where it is not used, per ATT&CK's T1486 guidance.
• Test with authorised emulation each quarter and record coverage against the ATT&CK rows.

Standards and references

• MITRE ATT&CK: M1040 Behavior Prevention on Endpoint
• Microsoft Learn: Attack surface reduction rules reference
• Microsoft Learn: Enable attack surface reduction rules
• Microsoft Learn: Attack surface reduction rules deployment overview
• Microsoft Learn: Attack surface reduction events in Windows Event Viewer
• Microsoft Learn: Microsoft recommended driver block rules
• Linux kernel documentation: Yama
• MITRE D3FEND knowledge graph

Related NHI Mgmt Group resources: EDR Guide · Endpoint Hardening Checklist · T1055 Process Injection Defensive Guide · Credential Dumping Guide · M1041 Encrypt Sensitive Information