Detect Security Support Provider in Sumo Logic CSE
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/
Sumo Detection Query
_sourceCategory="windows/sysmon" EventCode=13
| where TargetObject matches "*\\Control\\Lsa\\Security Packages" or TargetObject matches "*\\Control\\Lsa\\OSConfig\\Security Packages"
| where !(Details matches "(?i)(kerberos|msv1_0|schannel|wdigest|tspkg|pku2u|cloudAP|negoexts|wsauth|livessp)")
| where Details != ""
| fields _messagetime, host, TargetObject, Details, Image, User
| sort by _messagetime desc Detects Security Support Provider persistence (T1547.005) by monitoring Sysmon registry value set events on LSA Security Packages keys. Filters out all known Windows default SSPs, alerting on any novel DLL added to the SSP list which would be loaded into LSASS at next boot or via AddSecurityPackage API.
Data Sources
Required Tables
False Positives & Tuning
- Third-party smart card or hardware token authentication middleware (e.g., ActivIdentity, Gemalto) that installs a custom SSP for certificate-based authentication
- Microsoft Entra ID (formerly Azure AD) Seamless SSO agent adding its own SSP component during domain join or hybrid identity configuration
- Internal corporate authentication systems or legacy PKI solutions that register proprietary SSP DLLs
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.