Detect Security Support Provider in Google Chronicle
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/
YARA-L Detection Query
rule ssp_registry_modification_t1547_005 {
meta:
author = "Argus Detection Engineering"
description = "Detects modification of LSA Security Packages registry keys to add non-standard SSP DLLs (MITRE ATT&CK T1547.005). Adversaries use this to load malicious DLLs into LSASS for credential access."
severity = "HIGH"
mitre_attack = "T1547.005"
created = "2026-04-20"
events:
$e.metadata.event_type = "REGISTRY_MODIFICATION"
(
re.regex($e.target.registry.registry_key, `(?i)\\Control\\Lsa\\Security Packages$`) or
re.regex($e.target.registry.registry_key, `(?i)\\Control\\Lsa\\OSConfig\\Security Packages$`)
)
not re.regex($e.target.registry.registry_value_data, `(?i)^(kerberos|msv1_0|schannel|wdigest|tspkg|pku2u|cloudAP|negoexts|wsauth|livessp|\s)*$`)
$e.target.registry.registry_value_data != ""
condition:
$e
}Chronicle YARA-L 2.0 rule detecting T1547.005 SSP persistence by monitoring REGISTRY_MODIFICATION events on LSA Security Packages keys. Alerts when registry value data contains SSP entries not present in the known-good Windows baseline list, indicating a potentially malicious SSP DLL (e.g., mimilib.dll) has been added.
Data Sources
Required Tables
False Positives & Tuning
- Enterprise identity platforms (e.g., Okta Device Trust, Duo Security) that install SSP components for endpoint-based MFA or device posture evaluation
- Windows Server role installations (e.g., Active Directory Federation Services) that add authentication SSP components as part of role setup
- Legitimate security monitoring tools that hook into LSA via SSP interface for credential exposure detection (DLP or insider threat tooling)
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.