A Security Support Provider (SSP) is a Windows dynamic-link library (DLL) that implements the Security Support Provider Interface (SSPI), enabling authentication protocols (like Kerberos, NTLM, or Schannel) for applications. SSPs manage security-related operations—authentication, message integrity, and confidentiality—across networks.
In penetration testing, a Security Support Provider (SSP) is a critical target because it serves as the bridge between applications and security protocols (like New Technology LAN Manager (NTLM), Kerberos, or Digest).
For an attacker, the SSP is essentially a “hook” into the Windows authentication engine. If you can manipulate or inject a malicious SSP, you can intercept credentials in cleartext or maintain persistent access to a machine.
1. Credential Harvesting (The “MSSP” Attack)
The most common use case for SSPs in pentesting is stealing passwords. When a user logs in or authenticates to a service, the Local Security Authority (LSA) loads the registered SSPs to handle the request.
-
The Technique: A pentester with local administrator or SYSTEM privileges can register a malicious SSP (often called a “Fake SSP” or “MSSP”).
-
The Result: Because the LSA runs as a high-privileged process, any time a user authenticates, the malicious SSP intercepts the cleartext password before it is hashed and logs it to a file on disk (usually
C:\Windows\System32\kiwi_ssp.logif using Mimikatz).
2. Maintaining Persistence
SSPs are excellent for long-term persistence because they are loaded every time the system starts.
-
Registry Injection: By adding a DLL path to the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Security Packagesregistry key, the pentester ensures their code runs within the LSA process memory. -
Stealth: Unlike a suspicious
.exerunning in the background, a malicious SSP hides insidelsass.exe, a legitimate and vital system process, making it harder for basic EDRs to flag without specific memory forensic rules.
3. Mimikatz Integration
In a practical pentesting engagement, you rarely write an SSP from scratch. You typically use Mimikatz. There are two primary ways to deploy this:
| Method | How it Works | Pros/Cons |
|---|---|---|
| In-Memory Injection | Uses misc::memssp to inject the SSP directly into the lsass.exe memory. | Pro: Leaves no trace on disk. Con: Lost upon reboot. |
| DLL Drop | Drops mimilib.dll into System32 and updates the registry. | Pro: Survives reboots (Persistent). Con: Easier for AV to find the file on disk. |
Red Team Considerations
While targeting SSPs is powerful, modern Windows environments have introduced defenses that you should be aware of during your testing:
-
LSA Protection: If
RunAsPPLis enabled, you cannot easily inject code intolsass.exeeven as an Administrator. You would first need to bypass PPL (often using a signed driver exploit). -
Credential Guard: This moves the “secrets” into a virtualized container (VBS), meaning even if you hook the SSP, you might only see an encrypted blob rather than the cleartext password. #credentials persistince mimikatz #services vulnerability