T1547.005 Security Support Provider
sub-techniqueEnterpriseAdversaries 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.
platforms
Platforms this applies to.
tactics
ATT&CK tactics this technique serves.
sub-technique of
The broader entity this sits under.
mitigations
ATT&CK mitigations that reduce this.
detected by (3)
Data components that detect this.
countered by (D3FEND)
D3FEND countermeasures that counter this.
NIST CSF 2.0 — areas of relevance (Protect / Detect)
NIST CSF 2.0 areas this most relates to (evidence-ranked).
- PR.DSData Securitystrong · backed by 4 of 5 mapped controls
- DE.CMContinuous Monitoringstrong · backed by 3 of 5 mapped controls
- ID.RARisk Assessmentmoderate · backed by 2 of 5 mapped controls
Derived from MITRE CTID (Apache-2.0) and the NIST 800-53 ↔ CSF crosswalk (public domain). Indicative relevance along the Protect/Detect axis — not a compliance assessment or coverage claim.
mitigating controls (5)
Security controls that mitigate this.
software (3)
Malware and tools associated with this.
Detected by (Sigma) (1)
Sigma detection rules related to this.
source
Where this definition is published.