Wednesday, September 23, 2015

Ways To Load Kerberos Tickets

Everyone is aware of the awesomeness that Mimikatz is and most likely golden tickets. Mimikatz ships with lots of kerberos functionality.

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:

  • Mimikatz via Pass The Ticket (ptt) functionality
  • You can load it via the kiwi module in meterpreter -- stealing Chris' image here:

    • 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
    What's important to note here is that WCE will NOT load a Mimikatz generated ticket (didn't try ccache format). What you CAN do is  load the ticket via mimikatz on your offline host then export with with WCE, then upload WCE and the WCE ticket (wce_krbtkts) to the host and load it into the cache there.

    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

    1. 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
    2. 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.
    3. 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:




    Anonymous said...

    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:

    CG said...

    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

    Anonymous said...

    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 - ).
    # 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 (or any of the Impacket python scripts that take the -k option) as such:

    # python -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!

    6. Now much more interesting :-), run the same kerberos auth method but now with 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 -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.