Persistence via LSA Security Support Provider Registry Modification

Attackers can modify the Windows Security Support Provider (SSP) configuration to achieve persistence on a compromised system. SSPs are DLLs that provide authentication functions to the Local Security Authority (LSA). By adding a malicious SSP, an attacker can have their code loaded into the LSA process at system startup. This technique can be difficult to detect as the LSA process is a critical system component. This brief focuses on detecting registry modifications associated with adding or modifying SSP entries. The rule specifically looks for changes to registry keys related to Security Packages and OSConfig Security Packages, while excluding known legitimate processes like msiexec.exe.

Attack Chain

1. Attacker gains initial access to the system (e.g., through phishing or exploitation of a vulnerability).
2. The attacker escalates privileges to Administrator or SYSTEM.
3. Attacker uses a tool like reg.exe or PowerShell to modify the registry.
4. The registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages or HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages is modified to include a malicious DLL.
5. The system is restarted, or the LSA process is restarted.
6. The malicious SSP DLL is loaded into the LSA process.
7. The malicious SSP DLL executes its payload, providing the attacker with persistent access.

Impact

Successful exploitation allows the attacker to maintain persistent access to the compromised system, even after reboots. This can lead to data theft, further lateral movement within the network, or the deployment of ransomware. While the number of victims is unknown, this technique can be used in targeted attacks against high-value targets.

Recommendation

• Enable Windows Registry auditing to capture registry modification events (Data Source: Sysmon, Microsoft Defender XDR).
• Deploy the Sigma rule Installation of Security Support Provider to your SIEM to detect suspicious SSP registry modifications.
• Investigate any alerts generated by the Sigma rule, focusing on processes modifying the Security Packages or OSConfig\Security Packages registry keys (see Investigation Guide in rule).
• Regularly review the list of installed SSPs on critical systems to identify any unauthorized entries.
• Implement strict access controls to prevent unauthorized modification of the registry.