Protected Process Light (PPL): Stopping Attackers From Killing Your Security Agents

There is a grimly consistent step in modern intrusion playbooks: before the ransomware detonates, before the credential dump, before the exfil, the operator tries to kill your security tooling. If your EDR agent, your antivirus service, or your Sysmon process can be terminated by a local administrator, then everything downstream of it — telemetry, blocking, alerting — goes silent at exactly the moment you need it most. MITRE ATT&CK tracks this as T1562.001: Impair Defenses — Disable or Modify Tools, and it is one of the highest-value moves an attacker can make.

Windows ships a defense against precisely this: Protected Process Light (PPL). Used well, it makes your security agents genuinely hard to tamper with, even from a SYSTEM-level shell. Used carelessly — or not at all — it leaves your most important processes as easy to taskkill as Notepad.

What PPL actually protects

PPL is a kernel-enforced protection level, distinct from the older full "Protected Process" model used for DRM. A process running as a PPL is shielded so that other processes cannot open a handle to it with dangerous access rights — even a full administrator or SYSTEM process is denied PROCESS_TERMINATE, PROCESS_VM_WRITE, PROCESS_VM_READ, and code-injection rights against it. Concretely, PPL blocks:

• Termination — an attacker cannot simply taskkill /f your EDR service.
• Memory reads — no dumping the process to steal secrets it holds.
• Code injection / DLL loading — no hollowing the process to make it lie about what it sees.
• Debugger attachment — no live tampering with agent logic.

Protection is tiered by signer level (WinTcb > Windows > Lsa > Antimalware). A process can only tamper with a PPL at an equal-or-higher signer level, and the required PsProtectedSigner value is baked into the binary's Authenticode signature. That is why you can't just flip a flag to make an arbitrary EXE a PPL — the vendor has to sign for it.

The LSASS lesson, applied everywhere

The most familiar PPL use case is LSASS. Enabling RunAsPPL forces lsass.exe to run as a Protected Process Light, which is what breaks the classic mimikatz sekurlsa::logonpasswords handle open. The registry lever is simple:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" ^
  /v RunAsPPL /t REG_DWORD /d 1 /f
# Modern builds also honor RunAsPPLBoot for UEFI-lock persistence

The same principle extends to your security stack. Microsoft Defender's core services run PPL by default; the two MsMpEng.exe and related processes are Antimalware-signed and cannot be casually killed. Third-party EDR vendors register an Early Launch Anti-Malware (ELAM) driver so their user-mode agents can also be launched as Antimalware-level PPLs. Sysmon, since recent versions, similarly supports running its service protected.

The uncomfortable truth: many organizations deploy expensive EDR and never verify it is actually running protected. An unprotected agent is a checkbox, not a control.

How attackers get around it — and what to watch

PPL is strong but not magic. Real-world bypasses have relied on:

1. Bring-Your-Own-Vulnerable-Driver (BYOVD) — a signed-but-buggy kernel driver is loaded to strip the protection flag from kernel memory. This is why the Microsoft vulnerable driver blocklist and HVCI matter alongside PPL.
2. Disabling before boot — flipping RunAsPPL to 0 and rebooting, if the attacker already has persistence and admin. UEFI-locked configuration resists this.
3. Attacking the ELAM/registration path — tampering with the driver or service registration so the agent never launches protected in the first place.

Defense-in-depth is the answer: PPL for the agent, HVCI + the vulnerable-driver blocklist to blunt BYOVD, and tamper-protection so the protection settings themselves can't be quietly rolled back.

What WinSentinel audits

WinSentinel treats "is your defense actually protected?" as a first-class check rather than an assumption. On a single machine — and remember, every WinSentinel module runs at full power on one machine for free, with no limits — the relevant audits verify:

• RunAsPPL is enabled for LSASS (and boot-locked where supported), flagging the exact registry state.
• Defender / third-party AV core processes are running at the expected protection level, not merely installed.
• Tamper Protection is on, so PPL and related settings can't be silently disabled.
• The Microsoft vulnerable-driver blocklist and memory integrity (HVCI) are active, closing the BYOVD path that most PPL bypasses depend on.

For teams running WinSentinel Pro across a fleet, these findings roll up centrally: the orchestration node shows which endpoints have unprotected agents, alerts on drift when a machine that was protected regresses (say, after a bad update or a rogue admin), and lets you dispatch a fix without touching each box by hand. That fleet-wide "who lost their PPL last night" view is exactly the kind of question you can't answer by logging into 80 machines individually.

The takeaway

Protected Process Light turns your security agents from a soft target into a hard one — but only if it's actually enabled and continuously verified. Enable RunAsPPL, confirm your EDR launches protected via its ELAM driver, keep Tamper Protection and the vulnerable-driver blocklist on, and audit all of it on a schedule. The attacker's first move is to blind you; PPL is how you make that move fail.