Stealing Credentials with a Security Support Provider (SSP)

Stealing Credentials with a Security Support Provider (SSP)

Introduction: SSP Attacks

Mimikatz provides attackers several different ways to store credentials from memory and extract them from Active Directory. One of the more interesting tools provided is the MemSSP command, which will register a Security Support Provider (SSP) on a Windows host. Once registered, this SSP will log all passwords in clear text for any users who log on locally to that system. In this post, we will explore this attack and how it can be used by attackers to elevate their privileges.

SSP Attack Scenario

This attack can be performed against a Windows member server or domain controller. Let’s look at some of the reasons an attacker may want to register a malicious SSP on a computer:

  • An attacker has compromised a member server as a local Administrator, but has limited rights to move laterally throughout the domain.
  • An attacker has compromised a domain controller as a Domain Admin or Administrator, but wishes to elevate privileges to an Enterprise Admin to move laterally across domains.
  • An attacker has compromised a domain controller as a Domain Admin using a pass-the-hash attack, but wishes to leverage the clear text password of the admin to log into other applications such as Outlook Web Access or a remote desktop connection.

In any of these scenarios this attack can be very effective.

Performing the SSP Attack

Performing this attack is very simple. For this post, let’s focus on the attacks that target a domain controller.  Let’s assume we have compromised a Domain Admin account and wish to inject a malicious SSP into memory. All we need to do is issue the misc::memssp command within Mimikatz. Using Mimikatz to issue the command memssp, misc::memssp to inject a Malicious Security Support Provider (SSP)

Now the SSP is injected into memory. If the DC is rebooted, it will be lost and have to be injected again.  This can be solved by registering a DLL as an SSP that is provided with Mimikatz.

Once the SSP is registered, all users who log on to the DC, and all local services will log their passwords to the c:\Windows\System32\mimilsa.log file. Mimilsa.log file which contains the clear text passwords of users who have logged onto the system with the injected SSP

That file will contain the clear text passwords for all users who have logged on and service accounts running on the system. mimilsa.log with command memssp, misc::memssp for clear text password data logged by the Malicious Security Support Provider

SSP Attack Detection

This can be a difficult attack to detect. Looking for the existence of the mimilsa.log file would be a good check to run on DCs to see if any compromise has already taken place.

The following PowerShell will connect to every domain controller in the current domain and check for the existence of the mimilsa.log file. Hopefully, this comes back empty. PowerShell script to check for the existence of the mimilsa.log file that would indicate infection my injected SSP

The best prevention is to limit and monitor all Domain Admin members to prevent those accounts from compromise by an attacker.

How Attackers Are Stealing Your Credentials with Mimikatz:

To sign up for the Mimikatz blog series, please click here

To register for the Mimikatz webinar, please click here.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

One thought on “Stealing Credentials with a Security Support Provider (SSP)

  1. Thanks for sharing this informative post. I haven’t heard about this attacks before. But, it is very harmful and stealing all the windows users credentials. Thanks for awarning from this attacks.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free StealthAUDIT® Trial!

No risk. No obligation.

Privacy Preference Center

      Necessary

      Advertising

      Analytics

      Other