Detect Security Support Provider in Microsoft Sentinel
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/
KQL Detection Query
let KnownSSPs = dynamic(["kerberos", "msv1_0", "schannel", "wdigest", "tspkg", "pku2u", "cloudAP", "negoexts", "wsauth", "livessp"]);
DeviceRegistryEvents
| where Timestamp > ago(24h)
| where ActionType == "RegistryValueSet"
| where RegistryKey has "\\Control\\Lsa" and RegistryValueName in~ ("Security Packages", "OSConfig\\Security Packages")
| mv-expand parse_json(RegistryValueData) to typeof(string)
| where not(RegistryValueData in~ (KnownSSPs))
| project Timestamp, DeviceName, RegistryKey, RegistryValueName, RegistryValueData, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountName
| sort by Timestamp descDetects modifications to the LSA Security Packages registry values that add non-standard SSP DLLs. Maintains a list of known legitimate SSPs and alerts on any additions outside that list. An SSP loaded into lsass.exe has access to all credentials in memory, making this a critical persistence and credential access vector used by tools like Mimikatz.
Data Sources
Required Tables
False Positives & Tuning
- Installation of third-party SSP/credential providers (smart card middleware, biometric authentication packages)
- Windows OS upgrades that modify the Security Packages list
- Microsoft cloud authentication updates adding or modifying cloudAP
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.