M1025: Privileged Process Integrity
Privileged Process Integrity focuses on defending highly privileged processes (e.g., system services, antivirus, or authentication processes) from tampering, injection, or compromise by adversaries. These processes often interact with critical components, making them prime targets for techniques like code injection, privilege escalation, and process manipulation. This mitigation can be implemented through the following measures:
Protected Process Mechanisms:
- Enable RunAsPPL on Windows systems to protect LSASS and other critical processes. - Use registry modifications to enforce protected process settings: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL`
Anti-Injection and Memory Protection:
- Enable Control Flow Guard (CFG), DEP, and ASLR to protect against process memory tampering. - Deploy endpoint protection tools that actively block process injection attempts.
Code Signing Validation:
- Implement policies for Windows Defender Application Control (WDAC) or AppLocker to enforce execution of signed binaries. - Ensure critical processes are signed with valid certificates.
Access Controls:
- Use DACLs and MIC to limit which users and processes can interact with privileged processes. - Disable unnecessary debugging capabilities for high-privileged processes.
Kernel-Level Protections:
- Ensure Kernel Patch Protection (PatchGuard) is enabled on Windows systems. - Leverage SELinux or AppArmor on Linux to enforce kernel-level security policies.
*Tools for Implementation*
Protected Process Light (PPL):
- RunAsPPL (Windows) - Windows Defender Credential Guard
Code Integrity and Signing:
- Windows Defender Application Control (WDAC) - AppLocker - SELinux/AppArmor (Linux)
Memory Protection:
- Control Flow Guard (CFG), Data Execution Prevention (DEP), ASLR
Process Isolation/Sandboxing:
- Firejail (Linux Sandbox) - Windows Sandbox - QEMU/KVM-based isolation
Kernel Protection:
- PatchGuard (Windows Kernel Patch Protection) - SELinux (Mandatory Access Control for Linux) - AppArmor
Analyst context for executives and security teams
Privileged Process Integrity is a hardening control for the processes attackers most want to tamper with: authentication, credential-handling, antivirus, system services, and similar high-trust components. Its business value is reducing the chance that a compromised endpoint or server becomes a credential theft and persistence platform, especially around LSASS and authentication-process abuse.
Executive priority
Prioritize this mitigation where credential theft or authentication backdoors would create high business impact: domain controllers, administrator workstations, critical Windows servers, and systems running sensitive authentication or security services. Leaders should ask whether protected-process settings, code integrity, memory protections, and access controls are consistently enforced and whether exceptions are documented as audit evidence. This is especially relevant to resilience against credential-access, persistence, privilege-escalation, and defense-impairment techniques related to OS Credential Dumping, LSASS Memory, authentication packages, security support providers, LSASS drivers, and modified authentication processes.
Technical view
Validate that high-privilege processes are protected from tampering, injection, unsigned code loading, unnecessary debugging, and unauthorized interaction. For Windows, the ATT&CK description specifically calls out RunAsPPL for LSASS, the RunAsPPL registry setting under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL, Windows Defender Credential Guard, WDAC or AppLocker, CFG, DEP, ASLR, DACLs, MIC, and PatchGuard. For Linux-related hardening, ATT&CK references SELinux, AppArmor, sandboxing, and kernel-level policy enforcement. Detection text is not provided by MITRE for this mitigation, so SOC teams should treat this as a control validation and drift-monitoring requirement rather than a single alert rule.
Likely telemetry
- Configuration state for protected process settings such as LSASS RunAsPPL where applicable
- Registry configuration evidence for LSA protection and authentication-related settings on Windows systems
- Endpoint security telemetry showing process injection attempts, memory tampering attempts, or blocked interactions with protected processes
- Code integrity and application control policy status, including WDAC or AppLocker enforcement and exceptions
- Process access events involving LSASS, security services, antivirus processes, or other privileged processes
Detection direction
- Build coverage around unauthorized access to or modification of privileged processes, especially LSASS and authentication components referenced by the related ATT&CK techniques.
- Monitor for configuration drift in protected-process, code-signing, memory-protection, and kernel-protection controls rather than relying only on malware detections.
- Tune carefully for legitimate administrative, endpoint protection, and system maintenance activity that may access sensitive processes, while requiring change records for exceptions.
- Correlate suspicious privileged-process interaction with credential-access and persistence context, including OS Credential Dumping, LSASS Memory access, authentication packages, SSPs, LSASS drivers, and modified authentication processes.
- Because MITRE provides no official detection guidance for M1025, validate local telemetry availability and alert logic through defensive testing and configuration assessment.
Mitigation priorities
- Start with the systems where compromise of authentication or credentials would have the highest blast radius, such as domain controllers, administrator workstations, and critical servers.
- Enable protected process mechanisms for sensitive Windows processes where applicable, including RunAsPPL for LSASS as described by ATT&CK.
- Enforce code integrity and signed-binary controls for critical processes using mechanisms such as WDAC or AppLocker where appropriate.
- Enable and verify memory-protection controls such as CFG, DEP, and ASLR, and use endpoint protection capabilities that block process injection attempts.
- Restrict access to privileged processes using DACLs, MIC, and removal of unnecessary debugging capabilities.
Analyst notes and limits
This object is a mitigation, not an adversary behavior, and ATT&CK does not assign platforms or tactics directly to the mitigation. However, its description and relationships strongly center on protecting credential and authentication processes, especially LSASS and related Windows authentication components, with some Linux controls also named. The relationship set is useful for prioritization: the mitigation maps to credential dumping, LSASS memory access, authentication package and SSP abuse, LSASS driver persistence, and authentication-process modification.
No official MITRE detection field is provided for this mitigation, and the mitigation itself lists no platforms or tactics. Platform references above come from the official description and related techniques. Local operating system versions, application compatibility, security tooling, and exception requirements must be assessed before enforcement.
Privileged Process Integrity
Privileged Process Integrity focuses on defending highly privileged processes (e.g., system services, antivirus, or authentication processes) from tampering, injection, or compromise by adversaries. These processes often interact with critical components, making them prime targets for techniques like code injection, privilege escalation, and process manipulation. This mitigation can be implemented through the following measures:
Protected Process Mechanisms:
- Enable RunAsPPL on Windows systems to protect LSASS and other critical processes. - Use registry modifications to enforce protected process settings: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL`
Anti-Injection and Memory Protection:
- Enable Control Flow Guard (CFG), DEP, and ASLR to protect against process memory tampering. - Deploy endpoint protection tools that actively block process injection attempts.
Code Signing Validation:
- Implement policies for Windows Defender Application Control (WDAC) or AppLocker to enforce execution of signed binaries. - Ensure critical processes are signed with valid certificates.
Access Controls:
- Use DACLs and MIC to limit which users and processes can interact with privileged processes. - Disable unnecessary debugging capabilities for high-privileged processes.
Kernel-Level Protections:
- Ensure Kernel Patch Protection (PatchGuard) is enabled on Windows systems. - Leverage SELinux or AppArmor on Linux to enforce kernel-level security policies.
*Tools for Implementation*
Protected Process Light (PPL):
- RunAsPPL (Windows) - Windows Defender Credential Guard
Code Integrity and Signing:
- Windows Defender Application Control (WDAC) - AppLocker - SELinux/AppArmor (Linux)
Memory Protection:
- Control Flow Guard (CFG), Data Execution Prevention (DEP), ASLR
Process Isolation/Sandboxing:
- Firejail (Linux Sandbox) - Windows Sandbox - QEMU/KVM-based isolation
Kernel Protection:
- PatchGuard (Windows Kernel Patch Protection) - SELinux (Mandatory Access Control for Linux) - AppArmor
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1547.008 | LSASS Driver Sub-technique | On Windows 8.1 and Server 2012 R2, enable LSA Protection by setting the Registry key |
| Enterprise | T1547.005 | Security Support Provider Sub-technique | Windows 8.1, Windows Server 2012 R2, and later versions may make LSA run as a Protected Process Light (PPL) by setting the Registry key |
| Enterprise | T1547.002 | Authentication Package Sub-technique | Windows 8.1, Windows Server 2012 R2, and later versions, may make LSA run as a Protected Process Light (PPL) by setting the Registry key |
| Enterprise | T1556.001 | Domain Controller Authentication Sub-technique | Enabled features, such as Protected Process Light (PPL), for LSA.CitationMicrosoft LSA |
| Enterprise | T1003.001 | LSASS Memory Sub-technique | On Windows 8.1 and Windows Server 2012 R2, enable Protected Process Light for LSA.CitationMicrosoft LSA |
| Enterprise | T1003 | OS Credential Dumping | On Windows 8.1 and Windows Server 2012 R2, enable Protected Process Light for LSA.CitationMicrosoft LSA |
| Enterprise | T1556 | Modify Authentication Process | Enabled features, such as Protected Process Light (PPL), for LSA.CitationMicrosoft LSA |
All related ATT&CK context
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 | 1.2 | Current bundle | 66c9c49fef19… |
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 M1025Open 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.