3 min read
Protecting credentials is one of the most important aspects of Windows security. Attackers know that if they can compromise user logins or service accounts, they can escalate privileges and move laterally across your environment. One of the most common targets in these attacks is the Local Security Authority Subsystem Service (LSASS), since it stores and manages sensitive authentication material in memory. To combat this, Microsoft introduced LSA Protection, a feature designed to shield LSASS from credential theft.
What is Local Security Authority (LSA) Protection?
Local Security Authority (LSA) Protection is a Windows security feature that hardens the Local Security Authority Subsystem Service (lsass.exe). LSASS is responsible for handling logins, verifying credentials, and storing sensitive authentication data like NTLM hashes and Kerberos tickets. Because it holds such valuable information in memory, attackers often target LSASS with tools like Mimikatz to dump credentials and move laterally across the network.
When LSA Protection is enabled, LSASS runs as a protected process (RunAsPPL mode). This means only trusted, digitally signed Windows components can interact with it. Unauthorized programs, even those with local administrator rights, cannot inject code into LSASS or read its memory. This makes common credential dumping techniques far more difficult, adding an extra layer of defense against credential theft and privilege escalation attacks.
In short, LSA Protection locks down one of the most attractive targets for attackers on Windows systems. It’s not a silver bullet, but it significantly raises the barrier for anyone attempting to steal credentials from your environment.
What is a Protected Process
A protected process is a new security model that has been put in place in the kernel to prevent code injection attacks. A process will be considered protected if it adheres to the Microsoft Security Development Lifecycle (SDL). Any non-Windows DLLs that get loaded into the protected process must be signed with an appropriate certificate.
How to Enable LSA Protection
Firstly, since LSA Protection is controlled via the registry, you can use Group Policy to enable it across all devices on your network. To do this, you will need to set the value of RunAsPPL to 1, by executing the following code in PowerShell:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"RunAsPPL"=dword:00000001
The setting for LSA can be found at SYSTEM\CurrentControlSet\Control\Lsa
Image credit: https://itm4n.github.io/lsass-runasppl/
Best practices for Testing LSA Protection
According to Microsoft’s documentation about Configuring Additional LSA Protection, before you deploy LSA protection across your entire network it is a good idea to identify all LSA plug-ins and drivers that are in use within your organization. You should also check that all LSA plug-ins are digitally signed with a Microsoft certificate, that correctly signed plug-ins can successfully load into LSA and that they perform as expected. You can also use the audit logs to identify LSA plug-ins and drivers that fail to run as a protected process. If you want to streamline the process, you can use a PowerShell script to check if LSA is correctly enabled on a specific machine and to perform the necessary checks and balances to ensure that it is functioning as it should be.
Group Policy Examples and Settings for Effective Administration
15 Most Common Types of Cyber Attack and How to Prevent Them
Why AD Account Keeps Getting Locked Out Frequently and How to Resolve It
