Jump to content
Nytro

Poking Around With 2 lsass Protection Options

Recommended Posts

Poking Around With 2 lsass Protection Options

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
 
 
1*JSulA0hlWI4NBfbtGBDUOg.png
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:

 
 
1*ENyCeNAkDWpYidk2AQEfDA.png
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:
 
1*vbhOIh4eag7EzmvEcLNZOQ.png
returned for each local account
  • sekurlsa::pth /user:<user> /domain:<domain> /ntlm:<ntlmhash>: Did not work:
 
1*cqxHoucPiqVRZ4qJIoeBNw.png

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
 
 
1*imRlHNxuG9bvwlnUPId5Pg.png
  • 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:

 
 
1*CD7DlvEEakQTYlkrQnzbkw.png

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:

 
 
1*cs7A4E5w73nawfAbqF6EwQ.png
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:
 
1*vbhOIh4eag7EzmvEcLNZOQ.png
returned for each local account
  • sekurlsa::pth /user:<user> /domain:<domain> /ntlm:<ntlmhash>: Did not work:
 
1*rTP3FscUFavurAkvUd1sRQ.png

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>
 
 
1*imRlHNxuG9bvwlnUPId5Pg.png
  • 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:

 
 
1*YVQpXyEbHbDGeJ1Zhxq0iw.png

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.


 

Sursa: https://medium.com/red-teaming-with-a-blue-team-mentaility/poking-around-with-2-lsass-protection-options-880590a72b1a

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...