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:

C:\Windows\System32\kiwissp.log 

First, you will have to copy mimilib.dll in System32

copy C:\Windows\Temp\mimilib.dll C:\Windows\System32\mimilib.dll

Then, edit LSA registry keys to include the new security support provider

reg add "hklm\system\currentcontrolset\control\lsa\" /v "Security Packages" /d "kerberos\0msv1_0\0schannel\0wdigest\0tspkg\0pku2u\0mimilib" /t REG_MULTI_SZ /f

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