Just wanted to jot down some quick notes on using these tickets.
1. See the links in the resources section to generate a golden ticket. Chris Truncer's post is more than clear on how to do it, so I wont reproduce the content. What's more interesting (to me) is that you can generate these tickets offline on a host that is not connected to the network you are working on. This is perhaps handy if you have a bunch of host instrumentation on the network you are attacking and don't want to risk uploading and running Mimikatz on the host.
2. With this .kirbi ticket created you now need to load it into your session. You have a few options:
- Via WCE kerberos functionality
- -K Dump Kerberos tickets to file (unix & 'windows wce' format)
- -k Read Kerberos tickets from file and insert into Windows cache
- You can export the kirbi ticket with kirbikator (this will make it ccache ticket) and use smbclient or impacket (preferred) to use the ticket on linux/osx reference: https://twitter.com/gentilkiwi/status/561901226682744832
3. Depending on the type of alerting when you make a ticket it uses the 500 account by default. Assuming you aren't spoofing that particular account you might get the added bonus of having your actions attributed to another account.
Additional Gotchas
- CT's post uses a fake user. If you do this, according to @gentilkiwi you have to use the ticket within 20 minutes of creation. Mimikatz does let you create a ticket in the future with the /startoffset option
- Impacket currently (5 SEP 15 --this post will be published later) will NOT work with a fake or inactive user where windows will let it slide. So if you make a golden ticket you need it to be with an active user. I suspect beto will fix this soon.
- There is a lot of guidance around detecting this attack by using looking for tickets with a 10 year lifespan (this is the Mimikatz default). You can avoid this using the /endin option with Mimikatz. More here from MS: https://www.microsoftvirtualacademy.com/en-us/training-courses/how-to-avoid-golden-ticket-attacks-12134?l=4NoyuNYUB_604300474
Resources:
https://www.christophertruncer.com/golden-tickets-and-external-sids-compromise-the-child-and-win/
https://www.christophertruncer.com/golden-ticket-generation/
https://github.com/gentilkiwi/mimikatz/wiki/module-~-kerberos
http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf
3 comments:
Just throwing this question out there to the community or anyone that may know. In the few blog posts I've seen on the topic of golden tickets, usually they stop at the point you've applied the golden ticket on a target host (ie. golden_ticket_use) but they don't really go into techniques you can use *after* that to move laterally to other target systems once you have golden ticket privileges applied to your shell. The blog posts I've seen show a "dir \\\c$" which also implies you can copy your payload executable to that remote target (this works in my testing), but not further techniques to actually get RCE of that payload and a shell back from that desired remote target.
I did find one post that @armitagehacker wrote on using "wmic process call create" with the "/authority:”kerberos:DOMAIN\TARGET" option, however in my testing of this in my lab I wasn't able to get wmic to execute my remote payload when the golden ticket applied properly to my shell (ie. giving me "dir \\remote-dc-fqdn\c$" access to the remote target host)
My testing also confirmed what CG commented on that the domain account used when creating the golden ticket (ie. from the -u or /user: parm when created) should be a valid domain-admin level account which is not locked and not disabled or you could have issues when you go to use the golden ticket. What I've seen in my testing is when the golden ticket is used (ie. golden_ticket_use), AD logs will show kerberos authentication related log events tied to the domain-admin account you used when creating the golden ticket.
If anyone has some good techniques for lateral movement once the golden ticket is applied to your shell (especially when applied to a Meterpreter shell), please post - thanks.
reference links:
http://blog.cobaltstrike.com/2015/01/07/pass-the-golden-ticket-with-wmic/
http://blog.cobaltstrike.com/2014/05/14/meterpreter-kiwi-extension-golden-ticket-howto/
https://www.christophertruncer.com/golden-ticket-generation/
https://github.com/gentilkiwi/mimikatz/wiki/module-~-kerberos
the impacket suite of tools supports the -k options it should allow you to psexec and whatnot with the golden ticket. I've experienced some issues with my limited testing but i've chatted with Beto about it and it *should* work
Ah, yes CG that works beautifully! Here's the steps I followed in my lab that worked (there are probably other variations that work too):
1. Create your golden ticket (using mimikatz or wce) as normal and as documented in CG's article and other articles using a valid, non-locked, non-disabled, Domain Admin level user account (in the -u or /user: parm). I used mimikatz for this step to initially create my golden ticket.
2. Convert the golden ticket to a "ccaches" file using kirbikator tool (from gentilkiwi github - kekeo branch - https://github.com/gentilkiwi/kekeo/releases ).
# wine kirbikator ccaches golden.ticket
3. kirbikator will create a file with a long filename with the new ccaches version. I renamed that file to krb5cc_0 and copied that file to /tmp (ie final file in /tmp/krb5cc_0)
4. Export an env variable as such since this is needed by Impacket python scripts for kerberos auth:
# export KRB5CCNAME=/tmp/krb5cc_0
5. Run psexec.py (or any of the Impacket python scripts that take the -k option) as such:
# python psexec.py -no-pass -k DOMAIN/USER@TARGET "cmd.exe"
Where DOMAIN and USER match parameters used in the golden.ticket creation. TARGET is the ip address or fqdn of your domain member target Windows host.
Using this method I got a cmd prompt on the TARGET with full admin rights. Now substitute "cmd.exe" with any sweet remote file download call and execute method to get your payload (msfvenom, Veil, or custom) on the target and to execute it. See these links for some cool ideas. The bitsadmin method from the greyhathacker article worked very nicely in my case!
https://www.greyhathacker.net/?p=500
https://blog.netspi.com/15-ways-to-download-a-file/
6. Now much more interesting :-), run the same kerberos auth method but now with secretsdump.py to dump all hashes and lsa secrets. This also works if the TARGET is a DC and gets all domain hashes and already in JtR format. :-)
# python secretsdump.py -no-pass -k -outputfile secdump.txt DOMAIN/USER@TARGET
Would be awesome if you could run mimikatz itself via this method of an Impacket python script on Linux in the same way using the -k kerberos auth ?!?!? Then you could do all Windows password pillaging in the target environment in the same way from one Linux system, once you acquire a golden ticket.
Post a Comment