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

Signers

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

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

It doesn’t end with the Registry entry. To ensure the LSASS’ PPL 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 LSASS’ PPL 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

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

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

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:

• NtSetSystemEnvironmentValueEx in kuhl_m_kernel.c
• ZwSetSystemEnvironmentValueEx in mimidrv.c

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.

Detection

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:

• Logging of Mimikatz actions, or rather kernel calls
• Logging of modified variables (protection) of LSASS in its EPROCESS structure
• Logging of modified UEFI variables

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.

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).

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.

Conclusion

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 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)

Links

• http://www.alex-ionescu.com/?p=116
• http://www.alex-ionescu.com/?p=34
• http://www.alex-ionescu.com/?p=97
• https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
• https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/eprocess
• https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
• https://docs.microsoft.com/en-us/windows/win32/services/protecting-anti-malware-services-
• https://github.com/Mattiwatti/PPLKiller
• https://github.com/gentilkiwi/mimikatz
• https://github.com/gentilkiwi/mimikatz/blob/master/mimidrv/mimidrv.c
• https://github.com/gentilkiwi/mimikatz/blob/master/mimikatz/modules/kuhl_m_kernel.c
• https://github.com/gentilkiwi/mimikatz/releases/tag/2.2.0-20191125
• https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/tree/master/NtObjectManager
• https://oofhours.com/2019/09/02/geeking-out-with-uefi/
• https://oofhours.com/2019/10/05/working-with-uefi-variables-from-powershell/
• https://twitter.com/gentilkiwi
• https://twitter.com/gentilkiwi/status/704127304105136128/photo/1
• https://twitter.com/tiraniddo/status/950869648760803329
• https://www.geoffchappell.com/studies/windows/km/ntoskrnl/structs/eprocess/index.htm