Detect Security Support Provider in Elastic Security
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 stored in Windows, including logged-on user Domain passwords and smart card PINs. The SSP configuration is stored in 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 at next boot or via the AddSecurityPackage API. Mimikatz, Empire, and PowerSploit all include SSP persistence capabilities.
MITRE ATT&CK
- Tactic
- Persistence Privilege Escalation
- Technique
- T1547 Boot or Logon Autostart Execution
- Sub-technique
- T1547.005 Security Support Provider
- Canonical reference
- https://attack.mitre.org/techniques/T1547/005/
Elastic Detection Query
registry where event.type == "change" and
registry.path : ("*\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Security Packages", "*\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\OSConfig\\Security Packages") and
not registry.data.strings : ("kerberos", "msv1_0", "schannel", "wdigest", "tspkg", "pku2u", "cloudAP", "negoexts", "wsauth", "livessp", "") and
registry.data.strings != nullDetects modification of LSA Security Packages registry keys to add new SSP DLLs. Adversaries abuse this mechanism (T1547.005) to load malicious DLLs into lsass.exe at boot, gaining access to plaintext credentials. This query filters known-good SSPs and alerts on any novel entries.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate third-party authentication software (e.g., smart card middleware, biometric providers, enterprise SSO solutions) registering their own SSP DLL during installation
- System administrators manually updating SSP configuration as part of hardening or authentication infrastructure changes
- Security software vendors (e.g., CyberArk, BeyondTrust) that legitimately add SSP components for privileged access management
Other platforms for T1547.005
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Add Malicious SSP via Registry
Expected signal: Sysmon Event ID 13: RegistryValueSet on Control\Lsa\Security Packages with the added 'df00tech-test'. PowerShell ScriptBlock Log Event ID 4104.
- Test 2Enumerate Current Security Packages
Expected signal: Sysmon Event ID 1: Process creation for reg.exe querying the Lsa key.
- Test 3Mimikatz-style SSP Installation Simulation
Expected signal: Sysmon Event ID 13: RegistryValueSet showing mimilib added to the Security Packages list. MDE DeviceRegistryEvents captures the full multi-string value.
References (5)
- https://attack.mitre.org/techniques/T1547/005/
- http://docplayer.net/20839173-Analysis-of-malicious-security-support-provider-dlls.html
- https://technet.microsoft.com/en-us/library/dn408187.aspx
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1547.005/T1547.005.md
- https://github.com/gentilkiwi/mimikatz
Unlock Pro Content
Get the full detection package for T1547.005 including response playbook, investigation guide, and atomic red team tests.