T1547.005 Security Support Provider

Technique: T1547.005
Tactics: Persistence, Privilege Escalation
Research, 90 days: 1
KEV CVEs mapped: 0
SigmaHQ rules: 1
Elastic, Splunk: 5
thrunt rules: 0
Upstream: https://attack.mitre.org/techniques/T1547/005

MITRE description

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: <code>HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages</code> and <code>HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages</code>. 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.(Citation: Graeber 2014)

Research citing this technique

Reports and advisories from the last 90 days that cite this technique.

2026-08-13 Recorded Future Insikt: Malware Crypting Services and the Threat Actors Who Sell Them

Detection coverage

SigmaHQ community rules

Security Support Provider (SSP) Added to LSA Configuration (core)

Elastic and Splunk rules

Suspicious Module Loaded by LSASS (elastic)
Mimikatz Memssp Log File Detected (elastic)
Potential PowerShell HackTool Script by Function Names (elastic)
Installation of Security Support Provider (elastic)
Windows Security Support Provider Reg Query (splunk)

Signal counts reflect the current corpus snapshot. Research citations are the technique IDs named in vendor reports and government advisories from the last 90 days; KEV mappings come from MITRE CTID. Coverage is the SigmaHQ rule inventory (core, emerging-threats, threat-hunting) at release r2026-07-01 plus Elastic and Splunk production rules. Rule bodies are not mirrored; links go upstream.