Boot or Logon Autostart Execution: Security Support Provider
- ID
- T1547.005
- Tactics
- TA0003 Persistence, TA0004 Privilege Escalation
- Sub-technique of
- T1547 Boot or Logon Autostart Execution
- Platforms
- Windows
- Data sources
- Windows Registry Key Modification, Module Load, Process Creation
- Source
- attack.mitre.org
- MITRE last modified
- 25 Oct 2025
Adversaries may abuse security support providers (SSPs) to execute DLLs when the system boots. Windows SSP DLLs are loaded into the Local Security Authority (LSA) process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs.
The SSP configuration is stored in two Registry keys: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages and HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages. An adversary may modify these Registry keys to add new SSPs, which will be loaded the next time the system boots, or when the AddSecurityPackage Windows API function is called.[1]
Detection
- DET0542 Registry and LSASS Monitoring for Security Support Provider Abuse
Data components: Windows Registry Key Modification, Module Load, Process Creation
Mitigations (1)
- M1025 Privileged Process Integrity
Windows 8.1, Windows Server 2012 R2, and later versions may make LSA run as a Protected Process Light (PPL) by setting the Registry key
HKLM\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\RunAsPPL, which requires all SSP DLLs to be signed by Microsoft. [1] [2]