Kerberos version pass the hash where we take the ntlm hash (mimikatz can get this from memory for you) and work towards a TGT with it. Possible because the NT hash is used to support Kerberos RC4 encryption (RC4-HMAC-MD5).

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’s 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 fronting up to 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 pretty much got all you need for anything, 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.

Neat.

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 desperate to peek in 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 sweet sweet secret share…

And, we can…