Disabling LSA Protection via Registry Modification

Local Security Authority (LSA) protection is a security feature in Windows that prevents unauthorized processes from accessing sensitive information stored in LSASS memory. This protection is enabled through the RunAsPPL registry key. Adversaries may attempt to disable LSA protection by modifying this registry key, allowing them to more easily access credentials stored in LSASS. This technique can be used as part of a broader attack to escalate privileges and move laterally within a network. The rule detects modifications to the RunAsPPL registry key that weaken LSA protection. This involves monitoring changes to the registry path *\\SYSTEM\\*ControlSet*\\Control\\Lsa\\RunAsPPL and alerting when the registry data does not contain values that enable protected LSASS modes (“1”, “0x00000001”, “2”, “0x00000002”).

Attack Chain

1. An attacker gains initial access to a system, potentially through phishing or exploiting a vulnerability.
2. The attacker escalates privileges to an administrator account, if necessary, to gain the required permissions to modify the registry.
3. The attacker modifies the RunAsPPL registry key located at HKLM\System\CurrentControlSet\Control\Lsa (or similar path under ControlSet00x) to a value that disables LSA protection (e.g., setting it to 0). This is often achieved using tools like reg.exe or PowerShell.
4. The attacker may stage the system for a reboot to apply the registry change.
5. After the system reboots, LSASS starts without Protected Process Light (PPL) protection, allowing the attacker to access its memory.
6. The attacker uses credential dumping tools like Mimikatz to extract credentials from the unprotected LSASS process.
7. The attacker uses the stolen credentials to move laterally to other systems on the network.
8. The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or disruption of services.

Impact

Successful disabling of LSA protection allows attackers to easily extract credentials from LSASS memory. This can lead to widespread compromise of user and service accounts, enabling lateral movement and privilege escalation within the network. The impact could range from data breaches and financial loss to complete system compromise and disruption of critical services.

Recommendation

• Enable Sysmon registry event logging to detect changes to the RunAsPPL registry key (Data Source: Sysmon).
• Deploy the Sigma rule “Disabling Lsa Protection via Registry Modification” to your SIEM to detect malicious modifications to the RunAsPPL registry key.
• Investigate any alerts generated by the Sigma rule, focusing on the process making the change, the user account, and any associated processes (see the “investigation_fields” in the source).
• Monitor for unusual process activity after registry modifications, such as the execution of credential dumping tools (e.g., Mimikatz).
• Regularly review and enforce the principle of least privilege to minimize the number of accounts with permissions to modify sensitive registry keys.
• Use host isolation when unauthorized LSA-protection weakening is detected and confirmed.