T1547.005: Security Support Provider
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]
Analyst context for executives and security teams
Security Support Provider abuse is a Windows persistence and privilege-escalation behavior that matters because it targets the Local Security Authority path used for authentication. If an unauthorized SSP DLL is configured, it can be loaded into LSA at boot or through the documented API path and may gain access to sensitive credential material such as domain passwords or smart card PINs. For leaders, this is less about a noisy malware symptom and more about whether the organization can prove its Windows authentication boundary is protected and monitored.
Executive priority
Prioritize this where Windows systems handle privileged, domain, or operationally critical access. The business question is whether changes to LSA security package configuration would be noticed quickly enough to prevent durable credential exposure and follow-on access. This technique supports persistence and privilege escalation, so it should inform identity risk reviews, incident response playbooks for suspected credential compromise, and audit evidence around protection of privileged authentication processes.
Technical view
SOC and IR teams should validate coverage around the two documented registry locations: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages and HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages. Monitoring should focus on unauthorized additions or changes to configured security packages, DLL loading into LSASS/LSA context, and evidence of changes that become active at reboot or through AddSecurityPackage. The relationship to DET0542 supports a detection approach centered on registry and LSASS monitoring. The relationships to Mimikatz, PowerSploit, and Empire should be treated as context for defensive validation and not as attribution.
Likely telemetry
- Windows registry auditing or endpoint telemetry for changes to the LSA Security Packages registry values
- LSASS/LSA module or DLL load telemetry, especially newly introduced or unexpected security support provider DLLs
- Process telemetry identifying the process or account responsible for modifying the LSA security package registry keys
- System boot or service initialization evidence that helps correlate when configured SSPs would load
- Configuration evidence for privileged process integrity controls such as Windows LSA protection / RunAsPPL where available
Detection direction
- Baseline expected values for both LSA Security Packages registry paths and alert on additions, removals, or unusual DLL references.
- Correlate registry changes with subsequent LSASS module loads and reboot timing; registry-only detection may miss activation context, while module-only detection may miss persistence setup.
- Tune carefully for legitimate administrative or security software changes to SSP configuration, and require change-management context for approved modifications.
- Use the DET0542 relationship as the primary ATT&CK-supported detection direction: registry and LSASS monitoring for SSP abuse.
- During investigations, treat mapped tool relationships as indicators that this behavior can appear in post-exploitation workflows, but do not infer a specific tool or actor without local evidence.
Mitigation priorities
- Implement privileged process integrity for authentication-related processes where supported, including enabling Windows LSA protection / RunAsPPL as referenced by mitigation M1025.
- Maintain an approved baseline for LSA security package configuration and investigate deviations from that baseline.
- Limit and review administrative change paths that can modify HKLM LSA configuration, using local access-control and change-management evidence to support auditability.
- Include SSP registry and LSASS integrity checks in incident response procedures for suspected Windows credential compromise or persistence.
- Validate mitigations in a test group before broad rollout because changes to LSA protection and authentication components can affect compatibility with legitimate security or authentication software.
Analyst notes and limits
This object is a Windows sub-technique of Boot or Logon Autostart Execution and is mapped to persistence and privilege escalation. The older T1101 entry is revoked by this object. ATT&CK provides no official detection text for this technique, but the supplied relationship to DET0542 gives a clear defensive theme: monitor LSA registry configuration and LSASS behavior. M1025 provides the supplied mitigation direction around privileged process integrity and RunAsPPL.
This take is based only on the supplied ATT&CK fields and relationships. It does not assert active exploitation, actor attribution, customer exposure, or guaranteed detection. Local baselines, authorized SSP usage, endpoint telemetry quality, and compatibility requirements are necessary to determine actual risk and coverage.
Security Support Provider
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]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1101 | Security Support Provider | Security Support Provider revoked by this object. |
| Enterprise | T1547 | Boot or Logon Autostart Execution | This object subtechnique of Boot or Logon Autostart Execution. |
Groups, software, and campaigns
S0002: Mimikatz
S0363: Empire
Empire is an open-source, cross-platform remote administration and post-exploitation framework that is publicly available on GitHub. While the tool itself is primarily written in Python, the post-exploitation agents are written in pure PowerShell for Windows and Python for Linux/macOS. Empire was one of five tools singled out by a joint report on public hacking tools being widely used by adversaries.[1][2][3]
S0194: PowerSploit
PowerSploit is an open source, offensive security framework comprised of PowerShell modules and scripts that perform a wide range of tasks related to penetration testing such as code execution, persistence, bypassing anti-virus, recon, and exfiltration. [1] [2] [3]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | c5181da7fb56… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Graeber 2014
Graeber, M. (2014, October). Analysis of Malicious Security Support Provider DLLs. Retrieved March 1, 2017.
Open source URL -
[2]
Microsoft Configure LSA
Microsoft. (2013, July 31). Configuring Additional LSA Protection. Retrieved June 24, 2015.
Open source URL -
[3]
mitre-attack T1547.005Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.