M1025 Privileged Process Integrity: Protecting LSASS and Privileged Processes

An attacker who reaches administrator on a Windows host can usually read every credential cached in the Local Security Authority (LSA), or load code into it, unless the process itself is protected. MITRE ATT&CK M1025 Privileged Process Integrity is the mitigation for that problem: defending highly privileged processes such as authentication services, security agents and system services from tampering, injection and memory reads. This guide treats M1025 as a control a team implements. It shows which techniques ATT&CK v20 says the mitigation addresses, how to roll out LSA protection (RunAsPPL) safely with audit mode, what it does not stop, and how to prove it is working. It is for Windows platform, endpoint and detection engineering teams, and it links the deeper control guides rather than repeating them.

Key takeaways

• Small mapping, high value. ATT&CK v20 maps M1025 to seven techniques, all around LSA: credential dumping, LSASS memory, authentication packages, security support providers, LSASS drivers and authentication process modification.
• Two techniques have no other mitigation. In ATT&CK v20, T1547.002 Authentication Package and T1547.005 Security Support Provider are mitigated only by M1025, so a host without LSA protection has no ATT&CK mitigation left for them.
• RunAsPPL is the core setting. Value 1 enables LSA protection with a UEFI lock, value 2 without; Microsoft enables it by default only on new, enterprise-joined Windows 11 22H2 or later installs with HVCI support.
• Audit before you enforce. Unsigned smart card drivers, password filters and other LSA plug-ins stop loading under enforcement; Code Integrity events 3065 and 3066 show them in audit mode first.
• Kernel access defeats it. Protected Process Light (PPL) is enforced by the kernel, so a vulnerable signed driver undoes it; pair M1025 with driver blocklisting, Credential Guard and privileged account controls.

What the control is

ATT&CK describes M1025 as defending highly privileged processes (system services, antivirus, authentication processes) from tampering, injection or compromise. The mitigation text lists five measure groups: protected process mechanisms (RunAsPPL for LSASS), anti-injection and memory protection (Control Flow Guard, DEP, ASLR and endpoint tools that block injection), code signing validation (App Control for Business, formerly WDAC, or AppLocker), access controls (DACLs, mandatory integrity control, disabling unnecessary debugging) and kernel-level protections (PatchGuard on Windows, SELinux or AppArmor on Linux).

In practice, every technique ATT&CK actually links to M1025 is about the Windows LSA process, lsass.exe. When LSA runs as a Protected Process Light, the kernel refuses handle requests that would let a normal process, even one running as administrator, read its memory or inject code, and LSA only loads plug-ins and drivers signed by Microsoft. That single property cuts off memory reads of cached credentials and blocks the persistence techniques that load attacker code into LSA. The Linux items in the ATT&CK text are general hardening rather than mapped technique mitigations; Linux process protection is covered under related mitigations below.

Techniques ATT&CK says M1025 mitigates

The table lists all seven technique relationships for M1025 in ATT&CK Enterprise v20, grouped by tactic, with how the control helps according to ATT&CK's own usage text. The last column shows how many other mitigations ATT&CK lists for the same technique, computed from the v20 data.

Priorities: T1003.001 is the reason most teams deploy M1025, because LSASS memory dumping is the standard route from one compromised host to domain-wide lateral movement. T1547.002 and T1547.005 are the reason to deploy it everywhere, including servers: with no other ATT&CK mitigation available, detection is the only fallback. T1556.001 matters most on domain controllers, where a malicious plug-in in LSA can accept a skeleton password for every account. For technique depth, see the T1003 OS Credential Dumping, T1547 Boot or Logon Autostart Execution Defensive Guide, MITRE ATT&CK T1556 Modify Authentication Process Guide and MITRE ATT&CK T1556.001 Domain Controller Authentication.

Implementing LSA protection well

Microsoft documents LSA protection for Windows 8.1 and later clients and Windows Server 2016, 2019, 2022 and 2025. The setting lives at HKLM\SYSTEM\CurrentControlSet\Control\Lsa, DWORD RunAsPPL, and needs a restart.

Microsoft enables LSA protection by default on Windows 11 22H2 and later only when the device is a new installation (not an upgrade), is enterprise joined (Active Directory, Microsoft Entra or hybrid) and supports HVCI, and this automatic enablement does not set the UEFI variable. Every upgraded device, every older server and every workgroup machine therefore needs the setting applied explicitly.

Rollout sequence

1. Inventory LSA plug-ins. Smart card and other credential provider drivers, cryptographic plug-ins and password filters or password change notification agents (including in-house ones and identity sync agents on domain controllers) all load into LSA. Microsoft requires drivers to be WHQL signed and other plug-ins signed through the LSA file signing service.
2. Turn on audit mode on a pilot ring. Collect Microsoft-Windows-CodeIntegrity/Operational events 3065 (shared section requirements) and 3066 (Microsoft signing level requirements). Microsoft notes no audit events are produced while Smart App Control is on or a kernel debugger is attached.
3. Fix or replace failing plug-ins. A password filter that fails to load is a silent failure of your password policy, so treat each event as a change request, not noise.
4. Enforce with value 2 first, then 1. Value 2 can be rolled back with policy; value 1 cannot be removed without the Microsoft LSA Protected Process Opt-out tool (LsaPplConfig.efi) run at the console. Move tier 0 systems to the UEFI lock once stable.
5. Watch enforcement events. Events 3033 and 3063 show plug-ins blocked in enforced mode.
6. Roll back cleanly if needed. Set RunAsPPL to 0 or delete it and restart; with the UEFI lock, use the opt-out tool. Microsoft describes turning off Secure Boot as a last resort only.

Where identity fits

LSASS holds the credentials of whoever and whatever logged on: interactive administrators, but also service accounts running Windows services and scheduled tasks on that host. A service account with a static password and broad rights is the most valuable item in LSASS memory on many servers, and its credential rarely changes after theft. LSA protection reduces the chance it is read; group managed service accounts reduce the value if it is. See the Windows Services and Service Account Security Guide.

What M1025 does not stop

• Kernel-level attackers: PPL is enforced by the kernel. An attacker who loads a vulnerable signed driver (T1068 Exploitation for Privilege Escalation) can remove the protection or read memory directly. Microsoft's vulnerable driver blocklist, on by default since the Windows 11 2022 update and enforced with memory integrity (HVCI), Smart App Control or S mode, is the counterpart control. See the Bring Your Own Vulnerable Driver and EDR Killers Guide.
• Credentials outside LSASS memory: the SAM database (T1003.002), NTDS.dit (T1003.003) and replication abuse (T1003.006 DCSync) are not process-memory attacks. Microsoft also states Credential Guard does not protect the Active Directory database or SAM.
• Disabling the setting: without the UEFI lock, an attacker with administrative rights can change the registry value and wait for a reboot. The lock, or monitoring changes to the Lsa key, closes that gap.
• Credentials entered after compromise: PPL protects memory, not the logon path. Keylogging, credential prompts and abuse of a logged-on user's session remain possible.
• Everything else on the host: PPL protects only processes Windows starts as protected. Endpoint security agents use their own anti-tamper features, and ATT&CK places tool tampering under T1685 Disable or Modify Tools with different mitigations.

Layering with other controls

Decision guidance: on every Windows client and member server, enable LSA protection; the compatibility risk is limited to LSA plug-ins and is measurable in audit mode. On domain controllers, enable LSA protection but not Credential Guard, which Microsoft does not recommend there. Small organisations without Intune or Group Policy expertise should prioritise domain controllers and administrator workstations first. Note that the ATT&CK M1043 usage text still says Credential Guard is not configured by default; Microsoft's current documentation describes default enablement on eligible devices, so check device state rather than relying on either statement.

Verifying it works

• Per host: System log, source WinInit, event ID 12 states that LSASS.exe was started as a protected process with level 4. Absence after a reboot means the setting did not apply.
• Configuration drift: alert on changes to HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL and on new values under the Lsa key that register authentication packages or security packages, which are the persistence points for T1547.002 and T1547.005.
• Blocked loads: Code Integrity events 3033 and 3063 on enforced hosts show either a compatibility problem or a tampering attempt; both need an owner.
• Testing: in a lab, a controlled purple team exercise that attempts an LSASS memory read as administrator should fail on protected hosts and succeed on an unprotected control host. Map the result to T1003.001 in your coverage tracker.

Metrics: percentage of Windows hosts reporting WinInit event 12 after last boot, by tier; percentage of tier 0 hosts with the UEFI lock; number of unsigned LSA plug-ins outstanding from audit mode; mean time to remediate a RunAsPPL drift alert; percentage of devices with the vulnerable driver blocklist enforced.

Related D3FEND countermeasures and framework mapping

The MITRE D3FEND ontology relates M1025 to four countermeasures: D3-BA Bootloader Authentication, D3-DLIC Driver Load Integrity Checking, D3-PSEP Process Segment Execution Prevention and D3-SCF System Call Filtering. Driver load integrity is the closest match to the signed plug-in requirement of LSA protection.

Common failure patterns

• Assuming default enablement covers the estate. Upgraded devices and older servers do not get LSA protection automatically; only new, enterprise-joined, HVCI-capable Windows 11 22H2+ installs do.
• Enforcing before auditing. A password filter or smart card driver silently stops loading, and the business learns about it through failed logons or a password policy that no longer applies.
• No UEFI lock on tier 0. Domain controllers protected only by a registry value can be unprotected by anyone who is already an administrator there.
• Treating PPL as the whole answer. Without driver blocklisting and HVCI, a signed vulnerable driver turns PPL off; without M1026, administrator credentials still land on every host.
• Not monitoring the Lsa key. Authentication package and security package registrations have no other ATT&CK mitigation, so missing the registry change means missing the persistence.

Practitioner checklist

• Inventory every LSA plug-in, password filter and smart card driver, with owner and signing status.
• Run AuditLevel 8 on a pilot ring and clear all 3065 and 3066 events before enforcement.
• Deploy RunAsPPL through Group Policy or Intune to every Windows client and server, including domain controllers.
• Use the UEFI lock (value 1) on tier 0 systems once stable.
• Confirm WinInit event 12 per host and report coverage by tier.
• Alert on changes to RunAsPPL and to authentication and security package registrations under the Lsa key.
• Enforce the vulnerable driver blocklist and memory integrity alongside LSA protection.
• Enable Credential Guard on eligible clients and member servers, not on domain controllers.
• Record the result per technique (T1003.001, T1547.002, T1547.005, T1547.008, T1556.001) in your ATT&CK coverage tracker.

Standards and references

• MITRE ATT&CK: M1025 Privileged Process Integrity
• Microsoft Learn: Configure added LSA protection
• Microsoft Learn: Credential Guard overview
• Microsoft Learn: Microsoft recommended driver block rules
• Microsoft Learn: Attack surface reduction rules reference
• MITRE D3FEND: Driver Load Integrity Checking
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Credential Guard and VBS · T1003 OS Credential Dumping · Bring Your Own Vulnerable Driver and EDR Killers Guide · M1043 Credential Access Protection · Privileged Access Workstations Guide