Detecting PPL Manipulation? – A Test using LSASS as an Example

Detecting PPL Manipulation?

A Test using LSASS as an Example

Dominik Altermatt
by Dominik Altermatt
on January 16, 2020
time to read: 11 minutes


How to spot PPL manipulations in Windows

  • Mimikatz uses mimidrv to remove PPL protection from LSASS
  • Fast detection not possible with Windows standard tools
  • However, poor man's detection is possible with PowerShell
  • Reliability of the poor man's method or whether or not better detection options exist remains to be seen

The article Local Security Authority – keeping secrets safe by Michael Schneider introduces various hardening options for LSA, including the option of using the registry key to configure the LSA process (LSASS.exe) as a Protected Process Light (PPL) technology. To name but one example, the well-known attack multi-tool Mimikatz offers the option of using its mimidrv driver to remove the LSA protection through PPL and thus practically patch the LSASS process out of the box and then execute known actions such as dumping LSASS. Windows 10 version 1909 and Mimikatz version 2.2.0 20191125 were used for testing for the purposes of this article. In this regard, we can question whether the manipulation of the LSASS process from a protected (PPL) process to an unprotected one can be detected quickly and easily.

No satisfactory detection options with Windows standard and out-of-the-box tools could be identified for this process on the first go. At least process information can be queried with PowerShell Get-Process to distinguish between “normal” and PPL processes. However, in this article, it remains to be seen how reliable this is and whether better options exist.

Nonetheless, research revealed some interesting information on various topics related to Windows processes and LSASS as well as PowerShell projects and UEFI variables.

Protected Process Light

The concept (also see The Evolution of Protected Processes Part 1 and The Evolution of Protected Processes Part 2) of protected processes was initially introduced with Windows Vista so that protected contents (DRM) could only be manipulated by specific processes with a specific signature. However, using Protected Process was not a viable option for protecting other processes such as the LSASS.

With Windows 8.1, Microsoft introduced the Protected Process Light, which can be used more flexibly. PPL enhances the existing Protection Flag for processes with additional types for Protection Type and Signer. The protection type describes, for example, whether the process in question is a Protected Process or a Protected Process Light. The signer determines what type of code signing is required. The whole thing takes place in a hierarchy: only processes with the same or a higher level and the correct signature can now load drivers for the protected process, for example.

In the kernel structure of process objects, the EPROCESS structure, the following variables, to name but a few examples, are available for the Protection field from Windows 8.1 onwards.

Protection types

  1. PsProtectedTypeNone
  2. PsProtectedTypeProtectedLight
  3. PsProtectedTypeProtected
  4. PsProtectedTypeMax


  1. PsProtectedSignerNone
  2. PsProtectedSignerAuthenticode
  3. PsProtectedSignerCodeGen
  4. PsProtectedSignerAntimalware
  5. PsProtectedSignerLsa
  6. PsProtectedSignerWindows
  7. PsProtectedSignerWinTcb
  8. PsProtectedSignerMax

The list of types shows the entry for the PPL type PsProtectedTypeProtectedLight, while the list of signers shows the entry PsProtectedSignerLsa.

The signers also include a type for Antimalware PsProtectedSignerAntimalware because attackers also like to manipulate the processes of anti-malware solutions.

LSA protection

An entry in the registry can also be used to define the LSASS as a PPL, also see at Microsoft Docs

Configuring LSA Protection Mode

  1. Registry key: RunAsPPL = dword: 1 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa set
  2. Reboot

Verifying LSA Protection Mode

Once the registry key has been set and rebooting has taken place, verification can be performed as follows: The event with the source Wininit and event ID 12 is: LSASS.exe was started as a protected process with level: 4

Windows shows ID 12 in the event log

You can run the Sysinternals Process Explorer in Administrator mode to track this in a graphical interface.

The protected LSASS in the Process Explorer

It doesn’t end with the Registry entry. To ensure the LSASSPPL protection cannot be removed by simply deleting the registry key, another entry is written into a UEFI variable if the system then boots from a UEFI environment.

In this way, the configuration survives reboots and even reinstallations. The fact that UEFI environment variables cannot be changed in User mode already means that the configuration is somewhat better protected. With this setup, however, the LSASSPPL protection can only be removed by booting UEFI application/shells.

Geeking out with UEFI is an interesting article on UEFI and Windows. In Working with UEFI variables from PowerShell, the same blog also introduces a PowerShell tool for reading UEFI variables.

Mimikatz and mimidrv

With the mimidrv driver, Mimikatz now offers the option of removing PPL protection:

  1. Windows Defender was disabled
  2. Run Mimikatz as administrator
  3. Load mimidrv ⇒ !+
  4. Remove Protection ⇒ !processprotect /remove /process:LSASS.EXE

PPL is removed from LSASS with Mimikatz and mimidrv

This process can be traced using the Process Explorer. To do so, Process Explorer has to be restarted; refreshing with F5 is not enough.

Process Explorer no longer shows a PPL flag for LSASS

According to a tweet by Mimikatz author Gentilkiwi (Benjamin Delpy), the following command is used to manipulate the LSASS protection.

Mimikatz Kernel Call-Function !sysenvset

A quick glance at the Mimikatz code revealed some hints as to which Windows kernel calls Mimikatz uses to make the manipulation. The following calls seem to (potentially) play an important role here:

While researching manipulation of PPL processes, I also noticed the PPLKiller project, which provides a tool for debugging purposes.

The other question we should ask is “Why is Mimikatz able to use mimidrv to patch the LSASS process, since this requires a valid signature that is accepted by Microsoft?” Mimikatz and mimidrv effectively have a corresponding signature.


The initial idea was to use the information acquired above to identify detection options of Windows standard tools such as Windows event/audit logs, Sysmon, etc. To do so, the following possible indicators can be summarized as the basis:

Unfortunately, I was unable to find a satisfactory solution for detecting this process within the time constraints and with Windows standard tools. So far, only one method that can check whether LSASS is still running as PPL, as a side effect, basically a poor man’s solution, has been identified.

PPL protection has the effect that certain information is not returned when process attributes are queried. Protection fields from the EPROCESS structure could not be directly read in the time available, without writing (or reusing) my own code.

However, the following PowerShell project might help here: NTObjectManager from Google Project Zero’s collection of “Sandbox Attack Surface Analysis Tools.” Another Twitter screenshot had provided the corresponding hint. Get-NTProcess a function of NTObjectManager.

Read PPL status with Get-NTProcess

However, the Protection field could not be read here either, as it appears that permission problems have to be solved first. However, the project offers a wide range of functions that could be helpful for a number of questions.

Poor man’s detection

If you compare the result of the PowerShell command Get-Process -name LSASS | Select-Object * before and after the manipulation with Mimikatz, you see that some attributes of the PPL-protected LSASS process are not returned. This could be used as a quick detection option for detecting unprotected processes (such as LSASS after Mimikatz manipulation).

Comparing the Get-Process result of a protected and an unprotected LSASS process

E.g. rows 20, 21, 24, 25, etc., do not show certain information in the result on the left (protected LSASS process), while this information is visible in the result on right (“normal” LSASS process).

As mentioned at the start, it is not clear whether this method is reliable. Of course, directly querying the protection variables would produce a more meaningful result. If anyone has information on how this can be done, we would be grateful if you could let us know.


We were unable to conclusively answer the question as to whether the manipulation of a process’ protection type can be detected using Windows standard tools. Since this issue is already relatively deep in the Microsoft code and takes place partially in Kernel mode, accessing the corresponding information is no trivial matter. Direct access through a distinct code, as with Mimikatz or PPLKiller, is possible, but only if the code has a corresponding signature. Of course, other options for easy detection that have not been identified in this article are absolutely conceivable.

About the Author

Dominik Altermatt

Dominik Altermatt is working since 2003 in the IT business and was responsible for Data Leakage Prevention at a Swiss bank for many years. Besides traditional penetration testing he is also focusing on the introduction and improvement of IT security management processes. (ORCID 0000-0003-4575-4597)


You want to bring your logging and monitoring to the next level?

Our experts will get in contact with you!

TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here