Attack #4: Pass-the-Hash with Mimikatz
In my previous post, we learned how to extract password hashes for all domain accounts from the Ntds.dit file. In this post, we’re going to see what you can do with those hashes once you have them. Mimikatz has become the standard tool for extracting passwords and hashes from memory, performing pass-the-hash attacks and creating domain persistence through Golden Tickets. Mimikatz can be executed in a variety of ways to evade detection, including entirely in memory as part of the Invoke-Mimikatz command within PowerSploit. Let’s take a look at how easy Mimikatz makes it to pass-the-hash and perform other authentication-based attacks.
Pass-the-Hash
With the hash from the Ntds.dit file in hand, let’s look at how easily Mimikatz can enable us to perform actions on behalf of the Administrator account within the domain.
First, I will log into my computer as the user Adam, who has no special privileges within the domain:
As Adam, if I try to execute PSExec, a tool for remote PowerShell execution, against my domain controller I receive an access denied message.
By issuing a command with Mimikatz, I can elevate my account to that of the Domain Administrator account. This will launch whatever process you specify with this elevated token. In this case, I will launch a new command prompt.
With the newly launched command prompt I can perform activities as Jeff, the Domain Administrator, while Windows still thinks I am Adam. Here you can see I am now able to launch the PSExec session and enumerate the contents of my domain controller’s NTDS directory using the Pass-the-Hash technique.
With the Ntds.dit file decrypted, every user’s password hash is in my control so I can perform actions on behalf of any user just as easily. This is a scary way to not only gain unlimited access but to cover my tracks and blend in as though I am the users who I am impersonating.
Protecting Against Pass-the-Hash
Pass-the-Hash is difficult to prevent, but Windows has introduced several new features to make it harder to execute. The most effective approach is to implement logon restrictions so your privileged account hashes are never stored where they can be extracted. Microsoft provides best practices to follow a tiered administrative model for Active Directory that ensures privileged accounts will be significantly harder to compromise using such methods. Enabling LSA Protection, leveraging the Protected Users security group, and using Restricted Admin mode for Remote Desktop are some other ways in which you can protect against these attacks.
In addition to proper upfront security, monitoring authentication and logon activity for abnormalities can expose any attempts to leverage these attack paths. Many times, these attacks follow patterns and result in accounts being used in ways that are not normal. Being alerted to this as it occurs can detect an attack before it is too late.
This is the final installment in our blog series, 4 Active Directory Attacks and How to Protect Against Them. To view the previous blogs, please click on the links below.
- AD Attack #1 – Performing Domain Reconnaissance (PowerShell)
- AD Attack #2 – Local Admin Mapping (Bloodhound)
- AD Attack #3 – Extracting Password Hashes from the Ntds.dit File
To watch the AD Attacks webinar, please click here.
Learn how StealthDEFEND helps protect against AD attacks here.
Don’t miss a post! Subscribe to The Insider Threat Security Blog here:
Jeff Warren is Stealthbits’ General Manager of Products. Jeff has held multiple roles within the Technical Product Management group since joining the organization in 2010, initially building Stealthbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining Stealthbits, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development.
With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering Stealthbits’ high quality, innovative solutions.
Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware.
Related Posts
- SERVER (UN)TRUST ACCOUNT
- Making Internal Reconnaissance Harder Using NetCease and SAMRi10
- Setup, Configuration, and Task Execution with Covenant: The Complete Guide
- Protecting Against DCShadow
- What is a DCShadow Attack and How to Defend Against it
- Next-Gen Open Source C2 Frameworks in a Post PSEmpire World: Covenant
- Detecting Persistence through Active Directory Extended Rights
- Lateral Movement Through Pass-the-Cache
- Resource-Based Constrained Delegation Abuse
- Honey Token Threat Detection with StealthDEFEND
Wow. Brilliant Blogs !!! Mind blown by precision and clarity of content
Pardon my newbie question:
With regards to the statement:
‘By issuing a command with Mimikatz, I can elevate my account to that of the Domain Administrator account.’
The /ntlm:xxx hash you are providing in the command – whereis this obtained? Is this the local hash of the client admin user account? Or is Jeff the Domain Controller Admin. In case of latter, Jeff already has access to the Domain Controller machine, so this is moot.
Good question, I didn’t cover that much in this post, but the NTLM hash can be obtained using another Mimikatz command sekurlsa::logonpasswords. The user logged in (Adam) must be a local Administrator to obtain other password data stored on that machine, which In this example would obtain a Domain Administrator (Jeff). So with no domain privileges at all and only local privileges, Adam is able to extract Jeff’s password hash and pass it to a domain controller to obtain Domain Admin rights.
Which actions are achieved by performing a Pass-the-Hash attack on a domain-joined computer?
The simplest way to look at it is anything that can be done from a command prompt. That could be interacting with a system through PowerShell or directly connecting to a SQL Database. There are very few limits to what can be done using pass-the-hash.
Pardon the noob question.
After you dump the hash on a windows host. What would you use to PtH?
Such as:
1. Administrator:500:d9cdsfhtysrdfgsdfgdsfgfds:gsdgdsfgsdgdsfgsdfcab
2. Administrator:500:aad3bdfghjfghgdfghdfghdfghdfghdfgh:31ddfgdsfgdfgsdfgsdfgsdfg:asdfasdfasdfasdf
3. Administrator:$NTLM$112233445566778899asdfasdfsadfasdfasdf:::::::
4. Administrator:$NTLMv2$NTLMV2WORKGROUP$dsfgsdfgsfdgdsfgdsfgdsfgdsfgsdfg$sdf1100000000000fdsgfdgsdfgsdfgdfg00000000000000200120
These are several samples I’ve gathers but after you dump the hash, which of the listed hashes you’d use to PtH? I am looking at the difference between NTLMV2 and NTLM.. I’m guessing the v2 is much stronger and harder to crash the hash?
Great video, I’m understanding your article well, just not sure how you used to PtH.. I saw that you used the NTLM: value to PtH?
Again, pardon the noob question.
In my example, I am getting the NTHash using Mimikatz and the sekurlsa::logonpasswords command. It looks like you may be grabbing your hashes through network authentication with a tool such as Responder. I would recommend using Mimikatz to grab the hashes directly off of the Windows system and using those for pth. Alternatively, you can use tools like John the Ripper to crack the hashes from Responder.