How Attackers Exploit Security Support Provider (SSP) for Credential Dumping

Obtaining account login names and passwords in the form of hashes or clear text is a primary objective of adversaries. Credential dumping or credential exfiltration helps attackers to perform lateral movement, spreading further through an organization’s network, accessing restricted data and executing commands and programs with high privileges.

There are a number of well-known and relatively simple credential stealing attacks such as dumping the SAM database, stealing credentials with LSASS or extracting passwords from NTLMv2 that have been widely covered. However, obtaining Windows login credentials by exploiting Security Support Provider DLLs is another viable technique that security teams need to understand and defend against. In this post, we explain how attackers can exploit SSP DLLs to access encrypted and plain text passwords stored in Windows.

How Do Attackers Exploit SSP?

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.

What is a Security Support Provider (SSP)?

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 and add 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.

Using Mimikatz to Inject Windows Security Support Providers (SSPs)

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

1. Registering SSP DLLs

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

Two Registry keys store the SSP configuration:

• HKLMSYSTEMCurrentControlSetControlLsaSecurity Packages

• HKLMSYSTEMCurrentControlSetControlLsaOSConfigSecurity 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 standard Windows authentication SSPs (Kerberos, msv1_0, Schannel, wdigest, tspkg, and pku2u) when the query returns empty results.

Attackers can also verify the SSP entries from the registry editor by navigating through HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa.

Whenever the users reboot their computer systems, Windows creates a kiwissp.log file under C:WindowsSystem32. Attackers can access plaintext passwords stored for all domain users the system has authenticated.

2. 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:WindowsSystem32 that contains cleartext passwords of all logged-on users.

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

How to Detect and Mitigate Malicious SSPs

The SentinelOne Ranger AD solution 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.

Conclusion

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 Singularity Ranger AD.