"This module is blocked from loading into the Local Security Authority" message

When "Added LSA protection" is enabled on the computer (which can happen automatically with new, non-upgraded computers), you may see the following warning popup:

The "Added LSA Protection" simply marks lsass.exe as a "protected process", which prevents 0patch Loader DLL (0patchLoader.dll or 0patchLoaderX64.dll) from being injected into it.

We occasionally have patches that have to be applied to lsass.exe (although not necessarily directly to lsass.exe but to some DLL that lsass.exe is using), and not being able to get 0patch Loader DLL loaded into lsass.exe means we cannot apply these patches. A typical example of a patch that needs to be applied to lsass.exe is our patch for PetitPotam (https://blog.0patch.com/2021/08/free-micropatches-for-petitpotam.html). This vulnerability was never properly addressed by Microsoft and one can still use it to attack computers in the network as long as NTLM is not completely disabled. Preventing 0patch Loader from loading into lsass.exe effectively disables this patch.

Currently the only way to resolve this problem is to disable the added LSA protection as described in Microsoft's article. We believe allowing 0patch to work adds more value than this additional protection which an attacker with admin privileges* on the computer can disable anyway unless UEFI lock is used (added LSA protection is not needed against a non-admin attacker because they can't inject into lsass.exe or open this process anyway).

Note that the message displayed above may stop showing if "Don't show this message again" was ticked, in which case our patches for lsass.exe may not be getting applied - without you noticing anything. If in doubt, please review your "Added LSA Protection" settings.

How Do I know I disabled protection for lsass.exe?

1. Login to the affected computer
2. Launch Microsoft's Process Explorer as admin (https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer)
3. Enable the "Protection" column
4. Locate lsass.exe and verify that the "Protection" value is empty or "PsProtectedSignerNone"

Important: Feedback from our users indicates that sometimes in addition to setting the RunAsPPL registry value to 0 (as specified in Microsoft's article), the RunAsPPLBoot value also had to be set to 0 in order for the problem to stay resolved after a reboot.

* Some background about the effectiveness of the additional LSA protection: this protection is aimed against a local attacker who has already obtained administrative access, but wants to extract stored credentials - password, password hashes and Kerberos tickets - from lsass.exe process to obtain additional access. e.g., credentials of a domain administrator who has previously logged into the computer. While a high-privileged attacker always has sufficient control over the computer to disable LSA protection and then extract credentials from an unprotected process, this would involve a computer restart and a change of a registry setting. Both of these could potentially be detected by local security products, dependent on their capabilities and configuration.

Alternatively, a local administrative attacker could also exploit some vulnerability on the computer to extract credentials from a protected lsass.exe process, without restarting the computer and making any registry changes. For instance, this article describes 4 different ways of doing so, one of which was still working at the time of article's publication. In addition, the KslDump tool does the extraction using a Microsoft-signed vulnerable kernel driver. The point is, PPL protection of lsass.exe is well-intentioned but was shown to be unreliable.

In this context we believe the value of allowing 0patch to apply patches to lsass.exe outweighs the value of LSA protection.