Poking Around With 2 lsass Protection Options

Cedric Owens
May 3, 2018 · 6 min read

Welcome to my first post! I am a career blue teamer turned red teamer a few years back. My blue team background includes incident response, threat detection, malware analysis, and threat hunting in both Federal and Commercial sectors. Having spent a good amount of time analyzing malware and chasing attackers on networks, I now have an interest in helping to sharpen and challenge other fellow blue teamers. This was one of the reasons I decided to switch roles a bit and take on offensive security roles (red team) a while back (well that and I have always enjoyed looking ways to circumvent controls). And so I created this blog site to post observations along the way. I also plan to put content here that is very simple and has steps that blue teamers can follow if they want to become more familiar with certain tools/tactics. There are several red teamers and security experts leading the way with new research findings and releasing bleeding edge tools and techniques. The goal for this blog is to help other blue teamers become more familiar with the offensive security side of the house, and to do so with small achievable steps.

This brief post is centered around looking at LSA Protection and Credential Guard against some of the commonly used mimikatz modules, as well as looking at workaround for erach. So…here we go!

Testing Overview

I have a very basic testing scenario:

  • Testing host: Windows 10
  • Countermeasures tested: LSA Protection, Credential Guard
  • Used mimikatz for credential dumping (note: there are tons of ways to run mimikatz — in memory, on disk, remotely as a .xsl file invoked via wmic, etc.; whatever method used, I am assuming you already have mimikatz running)

Scenario 1: Windows 10 with LSA Protection

First, I ran mimikatz without LSA Protection and validated that I was able to get credentials. I used the commonly used “sekurlsa::logonpasswords” mimikatz command to retrieve hashes and clear text passwords from lsass.

Next, I enabled LSA Protection by following the steps posted at: https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection:

  • Using regedit, I navigated to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  • Then I set the value of the registry key to: “RunAsPPL”=dword:00000001
Image for post
Image for post
Added RunAsPPL with a dword of 1 to HKLM\SYSTEM\CurrentControlSet\Control\Lsa
  • rebooted

After reboot, I ran the same “sekurlsa::logonpasswords” mimikatz command and observed the output:

Image for post
Image for post
mimikatz sekurlsa::logonpasswords after enabling LSA Protection

The LSA Protection is preventing the mimikatz module above from working. I also tried the mimikatz modules below:

  • lsadump::secrets: Still worked and I was able to get syskey information to decrypt secrets from from the registry on disk
  • lsadump::sam: Still works, since it’s reading credentials from the SAM on disk
  • lsadump::lsa: Did not work:
Image for post
Image for post
returned for each local account
  • sekurlsa::pth /user:<user> /domain:<domain> /ntlm:<ntlmhash>: Did not work:
Image for post
Image for post

Lastly, I also tried the golden ticket and dcsync options with mimikatz and both successfully worked (note: I had already compromised the test environment domain and had domain admin level rights before this test):

  • kerberos::golden /user:<user> /domain:<domain> /sid:<sid> /krbtgt:<krbtgt hash> /endin:<value> /renewmax:<value>: Successful
Image for post
Image for post
  • lsadump::dcsync /domain:<domain> /user:<user>: Successful

LSA Protection Bypass:

Mimikatz has the mimidrv.sys driver that can bypass LSA Protection. I downloaded the mimikatz_trunk zip file from Ben Delpy’s mimikatz github repo, and copied the whole folder over, which included mimikatz.exe, mimidrv.sys, and mimilib.dll. I ran mimikatz.exe, and started the mimidrv.sys driver, and used that to remove LSA Protection from the lsass.exe process:

Image for post
Image for post

In the same mimikatz session, I then ran sekurlsa::logonpasswords and then got clear text passwords and hashes, proving that the mimidrv.sys driver does effectively bypass and remove LSA Protection. This would be trivial for an attacker to do once they already have admin access to a system.

In summary, LSA Protection seems to offer some protections against “out-of-the-box” mimikatz. However, as noted above the mimikatz driver bypasses LSA Protection settings allowing mimikatz to to steal clear text credentials and hashes. Also mimikatz and other credential dumpers can still dump hashes of local accounts since those hashes are on disk as opposed to in LSASS, where LSA Protection helps. Additionally, if an attacker has access to an LSA Protection-enabled system, the attacker can resort to keystroke logging or social engineering in order to get credentials. I would still recommend LSA Protection, as this would make an attacker take additional steps to dump credentials, but it is not a 100% bulletproof solution to credential dumping.

Scenario 2: Windows 10 with Credential Guard

I enabled Credential Guard by using the DG Readiness Powershell Script posted here: https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage

I downloaded the ps script, set the execution policy to bypass, imported it, and ran it:

.\DG_Readiness_Tool_v3.2.ps1 -Enable -AutoReboot

Note: To disable run the same command but use -Disable instead.

After rebooting I ran the “sekurlsa::logonpasswords” mimikatz command and received the following output:

Image for post
Image for post
mimikatz sekurlsa::logonpasswords on system protected with Credential Guard

Instead of the NTLM hash, Credential Guard returns an encrypted string. This is because Credential Guard isolates and protects secrets in an isolated lsass process using virtualization. The normal lsass process uses remote procedure calls to communicate with the isolated lsass process.

Next I also tried the mimikatz modules below:

  • lsadump::secrets: Still worked and I was able to get syskey information to decrypt secrets from from the registry on disk
  • lsadump::sam: Still works, since it’s reading credentials from the SAM on disk
  • lsadump::lsa: Did not work:
Image for post
Image for post
returned for each local account
  • sekurlsa::pth /user:<user> /domain:<domain> /ntlm:<ntlmhash>: Did not work:

Lastly, I also tried the golden ticket and dcsync options with mimikatz and both successfully worked:

  • kerberos::golden /user:<user> /domain:<domain> /sid:<sid> /krbtgt:<krbtgt hash> /endin:<value> /renewmax:<value>
Image for post
Image for post
  • lsadump::dcsync /domain:<domain> /user:<user>: Successful

Credential Guard Workaround:

I followed steps outlined by Ben Delpy at: “https://twitter.com/gentilkiwi/status/942912600991465472?lang=en

In a nutshell, I first ensured that the mimikatz mimilib.dll binary was in the same directory as mimikatz.exe, started mimikatz.exe, validated that Credential Guard was enabled (encrypted strings returned from sekurlsa::logonpasswords command), and ran the mimikatz “misc::memssp” command:

Image for post
Image for post

Now we have an SSP injected into memory. In essence, mimikatz is registering mimilib.dll as an SSP, allowing mimikatz to log the passwords of all users who login to c:\windows\system32\mimilsa.log.

Next I hit ctrl-alt-del and selected “Lock” and then logged in. After logging in, I opened a cmd prompt and typed “type c:\windows\system32\mimilsa.log” and verified that my clear text credentials there.

In summary, Credential Guard seems to offer some protections against “out-of-the-box” mimikatz, as does LSA Protection. However, mimikatz has the ability to register a dll as SSP and obtain clear text credentials of all users who login. Also mimikatz and other credential dumpers can still dump hashes of local accounts since those hashes are on disk as opposed to in lsass. Additionally, just as with LSA Protection-enabled systems, attackers can resort to keylogging or social engineering to get credentials. I would still recommend Credential Guard, but know that it is not a 100% bulletproof solution to credential dumping. I would recommend looking into additional detections such as looking for “mimilsa.log” on systems.

Red Teaming with a Blue Team Mentality

Posts from a blue teamer turned red teamer

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store