Security Support Provider (SSP) abuse is a persistence and privilege escalation technique on Windows. MITRE files it as T1547.005 under Boot or Logon Autostart Execution, with the tactics Persistence and Privilege Escalation.
The reason it matters is where the code ends up. Windows loads SSP DLLs into the Local Security Authority (LSA) process at system start. Once a DLL is inside LSA, MITRE notes it can reach encrypted and plaintext passwords stored in Windows, such as a logged-on user's domain password or smart card PINs.
How attackers use it
The SSP list lives in two Registry values: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages and HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages.
An adversary who can write to those values can add a new SSP. It is loaded the next time the system boots. MITRE also documents a second path: calling the AddSecurityPackage Windows API function, which loads a package without waiting for a reboot.
The result is code that runs inside a trusted security process on every boot, with a view of credential material.
How to detect it
MITRE's detection guidance for this technique is built around two signals.
- Registry changes to either
Security Packagesvalue, especially a new DLL name appearing in the list. - DLL loads into
lsass.exethat you cannot account for. Image load auditing helps you track unsigned or unusual modules entering LSASS.
Correlate the two. A registry edit followed by a reboot and then a new module in LSASS is the pattern to look for. MITRE also points to an LSASS load of an unsigned DLL because of an AuditLevel=8 configuration as a related signal.
How to reduce the risk
MITRE lists one mitigation, Privileged Process Integrity. On Windows 8.1, Windows Server 2012 R2 and later, you can run LSA as a Protected Process Light by setting HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL. That requires all SSP DLLs to be signed by Microsoft, which blocks an unsigned package from loading.
Pair that with tight control over who can write to the LSA registry keys, and keep a known-good list of your legitimate packages so a change stands out.
Quick check
Which two Registry values hold the SSP configuration?
Security Packages under HKLM\SYSTEM\CurrentControlSet\Control\Lsa and the same value name under Lsa\OSConfig.
What does running LSA as a Protected Process Light change?
It requires all SSP DLLs loaded into LSA to be signed by Microsoft, so an unsigned package is refused.
Sources
- MITRE ATT&CK, Boot or Logon Autostart Execution: Security Support Provider: https://attack.mitre.org/techniques/T1547/005
