3 min read
The Local Security Authority (LSA) Subsystem Service is a process in Microsoft Windows that verifies logon attempts, password changes, creates access tokens, and other important tasks relating to Windows authentication and authorization protocols.
Microsoft Windows is and has always been, a prime target for cyber-criminals. The obvious reason for this is because it is the most popular operating system. Cyber-criminals will try numerous techniques to gain access to a Windows system, and then try to use the privileges they have in order to gain access to other systems and accounts. As such, one of the most important things you can do to keep your Windows systems and accounts secure is protect the Local Security Authority Subsystem.
Attackers rely on various tools, such as Mimikatz and LSAdump, to dump password hashes or clear-text passwords from memory. By enabling LSA Protection on Windows, you will have more control over how information stored in memory can be accessed and hopefully prevent non-protected processes from accessing the data.
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 the AD Account Keeps Getting Locked Out Frequently and How to Resolve It