Security Support Provider
Where this stands
2 published detections cover this technique. Every one is unverified — no rule on Siemphony has been executed against real telemetry.
What the technique is
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 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: 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 the next time the system boots, or when the AddSecurityPackage Windows API function is called.
Read it on attack.mitre.orgWhat MITRE says you would watch
- AN1495
Monitor registry modifications to HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages or...\OSConfig\Security Packages, especially insertions of new DLL entries. Correlate this with subsequent DLL module loads into lsass.exe. Track unsigned or anomalous DLLs loading into LSASS using image load auditing. LSASS loads unsigned DLL due to AuditLevel=8 registry configuration or System reboot followed by DLL load into lsass.exe
Technique names and descriptions © MITRE ATT&CK®, CC BY 4.0. Not endorsed by MITRE.