.png)
Initially, it appeared to be straightforward and manageable. It proved to be effortless when executed from a domain joined machine. However, the same cannot be said for a non-domain joined machine. In this case, Impacket failed to function altogether.
What am I referring to in this chapter of ‘Things I have Utterly Failed to Understand’?
Passing the Ticket or PTT.
I won’t delve into the basics of how to perform this, it is essentially very simple. Tarlogic Security has a good guide for both Windows and Linux here.
Unfortunately, it just was not working from my non-domain joined testing laptop. Normally it is a question of grabbing the Kerberos hash (NTLM\AES) and firing it into Mimikatz
That did not work (testing against a vanilla Server 2016 install):
I couldn’t pinpoint any fault in the process, it’s well documented from many sources on the Internet, neither could I find a switch in mimikatz such as –fix-idiocy that may have helped. @gentilkiwi – maybe something to look into?
Trying to troubleshoot proved to be a challenging task. Overall, there were a couple of days spent researching and trying different things to find a solution, which is why I’m writing this, to make it hopefully easier for someone else attempting to solve the issue.
I initially thought it would be a case of the standard troubleshooting that I go through. This is generally trying to find whatever I had installed to fix the last problem and find out why it is now interfering with whatever it is that I would like to do now. Like the time when all of my VMs refused to bridge over ethernet and would only bridge on WiFi. However, for a pleasant change, it didn't appear to be directly my fault this time. So, in the immortal words of OSCP, it was time to dig deeper. Or something like that anyway.
After looking at my network traffic to the DC (Domain Controller), it showed me that we were not attempting to authenticate by Kerberos and falling back to NTLM.
This is usually because an IP is being used instead of a FQDN (Fully Qualified Domain Name), but that was not the case here.
After considerable trial and error, I managed to narrow it down to not having a default Kerberos realm on my machine. Although I have encountered and executed PTT/Golden Ticket attacks successfully from non-domain joined machines without encountering this problem, it happened to be the case in this instance.
Adding a default realm and Key Distribution Centre (KDC) through the command line was simple through ksetup /setrealm and /addkdc (please remember to use capital letters for the realm).
Whilst the output indicates that a reboot is required for this to take effect, that didn’t appear to be necessary for performing a simple directory listing of the C$ on the DC.
It appeared to work fine for psexec.
And that solved the issue – well partially. Both under Windows and Kali, the impacket suite(which I can’t recommend highly enough, you’d be surprised how many tools are just wrappers for impacket functions) the same process failed:
Windows(please note that Windows must have a file called krb5ccache):
All set up but:
And the same result in Kali:
I'm not sure exactly why that is happening, perhaps this is something for us to research next, but rest assured I have a PythonLinuxGURU all over it.
If anyone reading this knows why or how I managed to make such a hash of this, please let me know! Hopefully, this was useful if you have had the same issue.
