Overpass-the-hash is a Kerberos abuse pattern where an attacker uses a recovered NT hash to request Kerberos tickets, commonly by relying on RC4-HMAC compatibility. The important point for defenders is that this can turn credential material that looks “NTLM-only” into Kerberos access when the environment still permits the relevant encryption type.
Commands:
Privilege::debug
Sekurlsa::logonpasswords
sekurlsa::pth /user:duff /domain:jessybrings.com /ntlm:{the-ntlm-hash-you-grabbed}
That will launch a new window running as the target user.
Bit more detail:
Remember before a Kerberos client starts to retrieve service tickets for resources it will obtain a ticket granting ticket (TGT)
After it has the TGT it fronts up to the domain controller asking for a service ticket the thing the user wants to access.
It is kind of like when you go to the fair and pay for admission, you get a stamp or bracelet or whatever at the entrance. Then you also need to get a ticket for the ride that you want. The person at the ride booth (should) make sure you are wearing the bracelet (TGT), and then they’ll give you a ticket for the ride (service ticket).
In the case of over-pass-hash, we are generating the things that would get us that original TGT in memory on the Windows client (making a fake bracelet), then contacting the domain controller for a service ticket to the thing we want access to, and automatically getting the TGT back as part of the exchange so that we can go on and request all access we want to other things.
Its worth noting that you can actually perform a similar thing with the users AES keys if you happened to be in an elevated position and able to use dcsync (that is, you have sync rights on the domain head of the domain you are working with).
Lsadump::dcsync /user:duff /domain:jessybrings.com<br />Sekurlsa::pth /user:duff /domain:jessybrings.com /aes256:{the-hash-we-grabbed}
If you have DCSync on the domain head you’ve enough access to request the tickets needed for most domain-level operations, but just for reference - you can go ahead and use these newly added powers to say, access a SMB share remotely: you’d expect to see (AES) Kerberos tickets in the target name.
That confirms the technique works as expected in the lab.
Quick example:
- Say I’ve landed on a machine that appears to be in use by a fellow called “todd”, sadly my shell is in the context of a user called ‘chad’.
- I’ve noted that “todd” is a local administrator on this windows 10 endpoint, but he is in no special groups in the domain context.
- In a stunning coincidence, I’ve also noted that there is a share on the ‘exchange’ server called “todds-secret-share”. Only the “todd” principal and the domain admin appear to have rights but I am trying to access that share.
- We load mimikatz on ‘win10’ (the machine that todd is logged on)
- We issue the commands:
Privilege::debug<br />Sekurlsa::logonpasswords
- Using our new hash, we issue the command:
sekurlsa::pth /user:todd /domain:chadduffey.com /ntlm:89551acff8895768e489bb3054af94fd
- We should be able to now move from our shell that was running as whomever (‘chad’ in this case), to a shell with “todds” credentials allowing us to get at that target share.
And, we can…
