Attivo Networks Blogs

Credential Dumping by Exploiting Security Support Provider

Reading Time: 2 minutes  |  Published: June 25, 2021 in Active Directory, Blogs

Written by: Vikram Navali – Senior Technical Product Manager –Windows operating systems have authentication mechanisms to automatically execute libraries or programs when the computer system boots up or during the user account login. The organization can configure this function by placing these programs at designated locations or configuring them in a Windows Registry entry. Attackers can find a way to maintain persistence by modifying these system configurations or registering malicious Dynamic-Link Library (DLL) programs such as a Security Support Provider (SSPs) during system boot and escalate privileges.

A Security Support Provider is a DLL that performs security-related operations such as authentication and makes one or more security packages available to applications.

The Security Support Provider Interface (SSPI) is a component of a Windows API that functions as a standard interface to several SSPs. This component enables Windows authentication methods to extend easily to allow adding new SSPs without additional coding.

Attackers can modify registry keys to inject malicious SSPs that execute DLLs during computer system boot-up when Windows loads SSP DLLs into the Local Security Authority (LSA) process. Attackers can then extract encrypted and plaintext passwords stored in Windows, such as logged-on user’s Domain password or smart card PINs.

The Mimikatz application supports the following two methods of implementing SSPs.

  • Registering SSP DLLs

In this manual method, Mimikatz provides a DLL file “mimilib.dll” that attackers copy to the same location as LSASS (C:\Windows\System32). This DLL file is responsible for creating the kiwissp.log file, which stores credentials in plaintext.

Two Registry keys store the SSP configuration:

  • HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages 
  • HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages

The following PowerShell commands check the registry entries for the presence of SSP configuration entries. The figure below shows how attackers can add some of the standard Windows authentication SSPs (Kerberos, msv1_0, Schannel, wdigest, tspkg, and pku2u) when the query returns empty results.

Powershell Commands

Attackers can also verify the SSP entries from the registry editor by navigating throughHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

Whenever the user reboots their computer systems, Windows creates a kiwissp.log file under C:\Windows\System32. Attackers can get access to plaintext passwords stored for all domain users the system has authenticated.

  • In-memory updating of SSPs

Mimikatz supports another method of leveraging in-memory technique that injects new SSPs into the LSASS memory using the “privilege::debug” and “misc::memssp” commands.

By running the above Mimikatz commands, attackers will create a mimilsa.log file under C:\Windows\System32\ that contains cleartext passwords of all logged-on users.


The above two methods allow attackers to inject a new SSP into a Windows system and automatically log locally authenticated credentials.

Detect and Mitigate Malicious SSP

The Attivo Networks ADAssessor continuously monitors Active Directory (AD) for exposures and misconfigurations at the domain, user, and computer levels. The solution monitors every domain controller and alerts when a new Security Package gets loaded.


An attacker with administrator privileges can steal credentials from the memory of compromised systems. Attackers can tamper with the registry key and add new or malicious SSPs. Organizations should deploy solutions that audit and detect unauthorized modifications on a Domain Controller to avoid attackers exploiting the Security Support Provider. For more information, please visit





No Comments

Post a Comment

fifteen − thirteen =