Extracting credentials from memory with LSA protection (Proctected Process Light) enabled

6 min readAug 21, 2021

Introduction

In this article, I’m going to describe how LSA protection aka “Protected Process Light” works and how we can bypass it to dump the cached credentials.

Before we jump to dumping cached credentials or LSA protection topic, we need to be familiar with assigned rights and process integrity levels which are part of access tokens in windows operating system.

Process Integrity Level

In Windows Vista and later, processes run at four different levels of integrity: high, medium, and low. Low integrity is used with sandbox processes such as web browsers. Applications executing in the context of a regular user run at medium integrity, and administrators can execute applications at high integrity. System is typically only used for SYSTEM services. How can view the integrity level for a specific process? We can use process explorer (procexp.exe) which is part of Sysinternals tool. By default, we won’t be able to view the integrity level of the running processes but we can go to “View” tab and select “select columns” and then tick the “Integrity Level”

viewing integrity level — Selecting “Integrity Level” column under the “Process Image” tab

Assigned Rights

Assigned rights (privileges) are also included in the access token. They are a set of predefined operating system access rights that determine which actions a process can perform. We can view the privileges for current user by typing whoami /priv in powershell or cmd.

If we try to modify the assigned privileges for the user that have an active logon session, the changes won’t take place and the privileges won’t be added/removed until the user logs out and logs in again. We can add privileges within two ways:

Using LsaAddAccountRights function from Advapi32 api.
Using secpol.msc

In this article, I’ll use the secpol.msc gui window for sake of simplicity. After typing secpol.msc in cmd or powershell or Run window, we will be presented with a new window. we’ll navigate to Security Settings > User Rights Assignment.

Dumping Credentials from LSASS process

LSASS process runs as system, we need system or local administrator permissions (high/system integrity shell access) to gain access to the hashes stored on a target. In addtion, if our current user has SeDebugPrivilege right, we can read and modify a process under the ownership of a different user. Armed with this information, we will use mimikatz to try dump the cached credentials as the following:

privilege::debug
sekurlsa::logonpasswords

In normal circumstances, we would have gotten the ntlm hash or sometimes clear-text passwords of the users that logged on this system. However, we got stopped by LSA protection aka protected process light (ppl).

why did we fail?

Back in those days, dumping credentials became popular and mimikatz project became famous. Thus, microsoft decided to mitigate this issue by releasing LSA protection and Windows Defender Credential Gaurd. We will overcome this issue later on in this article but before that, we need to know what lsa protection is and how does it work. By default, LSA protection is not enabled and the above commands would work. However, I enabled LSA protection on purpose so that we would face that error and I could explain what LSA protection is and how we can bypass it.

Protected Process Light

Microsoft introduced a feature named Protected Process Light (PPL) within windows 8.1 and onwards which could be layered on top of the current integrity level which means a process running at system integrity level cannot access or modify the memory space of a process executing at system integrity level with PPL enabled. LSASS supports PPL as well.

How shall we enable LSA protection

We need to define a new DWORD key in registery (regedit.exe) program in “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa”. The name of the key will be “RunAsPPL” and the value will be set to “1”. For the last step, we need to restart the computer.

Bypassing LSA protection

There are 3 ways to bypass LSA protection and dump the cached credentials.

Removing the RunAsPPL registry key and restart the system again. However, this is not a practical method because as soon as we restart the system, we’ll lose any credentials that were cached on memory.
Disabling PPL flags on the LSASS process by patching the EPROCESS kernel structure. PPL protection is controlled by a bit residing in the EPROCESS kernel object associated with the target process. If we could obtain code execution in kernel space, we could disable the LSA protection and dump the credentials.
Reading the LSASS process memory contents directly instead of using the open process functions

We will proceed with the second approach. Fortunately, there are couple of custom written tools for patching the EPROCESS kernel structure and disabling ppl flags on the LSASS process.

First project: mimidrv.sys from mimikatz

Luckily, Benjamin Delpy who is the author of mimikatz released a kernel driver named mimidrv.sys which allow us to bypass LSA protection as it was mentioned earlier. We need to have SeLoadDriverPrivilege and the ability to load any signed drivers but since we have an administrator or system access to dump credentials, we already have this privilege. We need to load the mimidrv.sys file by typing !+ in mimikatz environment. After that we will remove the protection from lsass.exe process. Now that we removed the protection flag from lsass.exe, we will try to dump the credentials.

!+!processprotect /process:lsass.exe /removesekurlsa::logonpasswords

This time we succeeded and were able to dump the credentials. There is a downfall regarding utilizing mimidrv.sys that we need to touch the disk (copy mimidrv.sys to the target system) which will get flagged by Anti-Virus products immediately.

Second Porject: PPLKiller

We could use an official and vulnerable kernel driver to remote code execution which ultimately we could execute our arbitrary command in kernel. PPLKiller is such an example.

Conclusion

To sum up, PPL is working in userland mode and the reason why all of the techniques that we mentioned in this article will work is that we are trying to execute our code in kernel mode. Whenever, we can execute our arbitrary code in kernel mode, we can disable any processes which are running in with PPL completely.
Thank you for reading this article.