Security Support Providers (SSPs) are dynamic libraries in Windows that provide authentication and security services. Typically, these libraries are loaded into the Local Security Authority (LSA) process, where they perform critical tasks such as password authentication and managing security protocols.
SSPs play a key role in handling sensitive system operations and are integral to the overall security and authentication framework of Windows. They are designed to ensure secure access to system resources by processing user credentials, managing authentication protocols, and supporting various security policies within the operating system.
To read about other sub-techniques of the T1547 Boot Logon or Auto Start Execution technique, you can visit the related hub blog.
Adversaries can exploit Windows Security Support Providers (SSPs) to achieve persistence and escalate privileges by instructing the Local Security Authority (LSA) process to load malicious DLLs during system startup. SSPs are essential components responsible for managing user authentication and security, providing attackers with access to sensitive information such as encrypted and plaintext passwords.
The following registry keys are crucial in managing SSPs:
|
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages |
By modifying the values within these keys, attackers can add malicious SSPs to the registry. For example, they might insert a malicious DLL path to execute their code when the system boots or when specific Windows API functions, such as AddSecurityPackage, are called.
Here's an example of how an attacker might add a malicious SSP to the registry:
|
# Get the current value of 'Security Packages' and store it in the $oldvalue variable $oldvalue = $(Get-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name 'Security Packages' | Select-Object -ExpandProperty 'Security Packages') # Create a backup of the current 'Security Packages' value under 'Security Packages old' Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" -Name 'Security Packages old' -Value "$oldvalue" $newvalue = "C:\Path\To\Malicious.dll" Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name 'Security Packages' -Value $newvalue |
Once the malicious DLL is added, it will be loaded during system startup, allowing the adversary to execute arbitrary code under the context of the LSA process. This gives the attacker the ability to maintain persistence on the system, access sensitive authentication data, and potentially escalate privileges.
One example comes from a PowerShell-based malware analysis conducted in December 2025 [1].
|
SHA-256*: 827c2bfb7f028924c5ec60dab9fda84c5d25ba6b1340e4d6ca0d515636b73974 |
The attacker copies the malicious SSP DLL to the System32 directory.
|
# malware string |
The malicious DLL is copied to System32, making it a trusted system file, which can later be loaded by LSASS at startup.
The attacker adds the malicious DLL name to the Security Packages registry key to ensure it is loaded by LSASS during system startup.
|
# malware string |
By adding the DLL name to the registry, the malicious DLL is loaded automatically during system startup, allowing it to monitor authentication processes.
Once loaded, the SSP can intercept authentication processes, capturing credentials.
|
# malware string |
This registers the malicious DLL with secur32.dll so it can start intercepting authentication requests and harvesting credentials.
The malicious SSP remains active even after reboots by being registered in LSASS to load on system startup.
|
# malware string |
After installation, the attacker confirms that the SSP is loaded successfully and will persist across reboots.
The script ensures it runs with administrative privileges to modify system directories and the registry.
|
# malware string |
Administrative privileges are required to modify the registry and install the malicious DLL in system directories. If the script isn't run with these rights, it fails.
This technique underscores the importance of securing Windows authentication infrastructure, as adversaries can exploit SSPs to maintain long-term persistence, silently capture sensitive credentials, and escalate privileges, all while evading traditional detection methods.
[1] “Free Automated Malware Analysis Service - powered by Falcon Sandbox.” Available: https://hybrid-analysis.com/sample/827c2bfb7f028924c5ec60dab9fda84c5d25ba6b1340e4d6ca0d515636b73974. [Accessed: Dec. 16, 2025]