Quick introduction to Protected Processes and Protected Process Light for red team professionals
Learn about Protected Processes, Protected Process Light (PPL) and how they work.
Imagine that you receive a box of chocolates. However, your parents, concerned about your health, take it from you, put a lock and a seal around it and give it back to you. Now, you can see the box being there, you can touch and feel it but no matter what you do you cannot open it and take a chocolate from inside. Only your parents can access the contents inside.
Protected Processes (PP) are kind of like that locked and sealed box of chocolates that red team operators are interested in accessing but can’t. The operating system has put in controls to secure these processes and block certain operations by other processes. Only authorized personnel, such as your parents (trusted Windows components and security software), can access the contents of the box.
Protected Processes (PP) is a security mechanism developed by Microsoft to prevent unauthorized access to sensitive system processes such as LSASS. It was initially designed to provide Digital Rights Management (DRM) functionality and prevent media players from copying the DRM-protected content. It was later made available to other sensitive processes, such as anti-malware solutions, via Protected Process Light (PPL).
Protected process model imposes strict limitations, allowing only a specific subset of system-installed DLLs to be loaded. Additionally, for an executable to qualify as a protected process, it must be signed with a designated Microsoft certificate embedded within the binary. One of the key protections enforced by the kernel ensured that a non-protected process could not obtain a handle to a protected process with sufficient privileges to inject arbitrary code or access its memory.
A typical process cannot perform operations such as the following on a protected process:
Inject a thread into a protected process
Access the virtual memory of a protected process
Debug an active protected process
Duplicate a handle from a protected process
Change the quota or working set of a protected process
A typical process cannot perform the following operations such as the following on the threads of a protected process:
Set or retrieve context information
Impersonate the thread
Other processes can obtain only the following access rights on a protected process or its threads:
SYNCHRONIZE - Required to use the process handle in any of the wait functions.
PROCESS_QUERY_LIMITED_INFORMATION - Required to read certain information from the process object. This is a subset of the information provided by PROCESS_QUERY_INFORMATION.
PROCESS_TERMINATE - Required to terminate a process.
THREAD_QUERY_LIMITED_INFORMATION - Required to read certain information from the thread object. This is a subset of the information provided by THREAD_QUERY_INFORMATION.
THREAD_SET_LIMITED_INFORMATION - Required to set certain information in the thread object. This is a subset of the information provided by THREAD_SET_INFORMATION.
THREAD_SUSPEND_RESUME - Required to suspend or resume a thread.
Historically, a processes with SeDebugPrivilege, such as those running with administrator or local system privileges, have been able to obtain all access to a process or a thread. However, with protected processes even a process with SeDebugPrivilege cannot obtain more access rights other than the ones listed above.
PPL expanded the scope of protected processes. It relaxed some restrictions on which DLLs could be loaded into a protected process and implemented different signing requirements for the main executable. A major change was the introduction of signing levels (listed below), which categorized protected processes into different tiers. A PPL at a given level could fully access any process at the same level or lower, while access to higher levels was more restricted. These signing levels were also applied to the original Protected Process (PP) model, where a PP at a certain level could open any PP or PPL at the same level or below. However, the reverse was not true—a PPL could never gain full access to a PP at any signing level.
The signing levels implemented by PP and PPL are listed below (from most secure to least secure):
Windows TCB
Windows
Anti-Malware
CodeGen
Authenticode
Signing levels enable Microsoft to grant third parties the ability to create protected processes. However, as of now, the only type of protected process that third parties can generate is an Anti-Malware PPL.
PPL permits protected services to spawn child processes that also run as protected. These child processes inherit the same protection level as their parent service, and their binaries must be signed with the same certificate.
To alter a PPL service, it is important to remember that since non-protected processes cannot modify the configuration of a protected service, either the service must first mark itself as unprotected or it can be altered with the help of a driver. Once reconfigured to run as unprotected, the service can be altered or its memory can be dumped.
Red Team Notes
- Protected Processes (PP) - Introduced in Windows Vista, Protected Processes prevent unauthorized access and modification of critical system services, primarily used for DRM and Windows components.
- Protected Processes Light (PPL) - An extension of PP introduced in Windows 8.1, PPL allows non-Microsoft security software to protect their processes at different privilege levels, securing sensitive processes like LSASS from unauthorized access and tampering.Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.
References