Security Support Provider DLLs
MITRE ATT&CK™ Boot or Logon Autostart Execution: Security Support Provider - Technique T1547.005
Theory
We 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.
Practice
We won't be able to make it work If LSA protection (RunAsPPL) is enabled. Loaded SSP DLLs will have to be signed by Microsoft as LSASS.exe will run as a Protected Process Light (PPL).
We may modify LSA 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. The SSP configuration is stored in this two Registry keys:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages
.
The Mimikatz project provides a DLL file (mimilib.dll) that can be used as a malicious SSP DLL that will log credentials in this file:
First, you will have to copy mimilib.dll in System32
Then, edit LSA registry keys to include the new security support provider
In-memory DLL injection - Credential Access
We may directly inject SSP DLLs into memory. It prevent us from editing registries but using this approach, it will not persist accross reboots.
Resources
Last updated