Quick Review of Overpass-the-hash
In case you don't remember, the way that you get a TGT (ticket granting ticket) in Active Directory is via a process called 'pre-authentication'. Essentially the way this works is you take a timestamp (hence the requirement that the time be synced with domain controllers) and encrypt it with the user's shared secret (the password hash) and send it off to the Domain Controller. The DC will verify the blob by decrypting it with the copy of the key the DC has and seeing if the resulting timestamp fits in the window of time configured. Assuming that all is well, the DC will send the client a TGT.
So, in essence, to get a TGT you need 1) correct time 2) username 3) key for username 4) name of DC / domain. Ben's 'overpass the hash' method uses Mimikatz to set the hash/user/domain in memory on a Windows box. Then when you request a service using that credential, Windows will automagically ask for the TGT and any subsequent service tickets. Sometimes it is a bit fiddly to get the right Kerberos information to make it work since some places prefer to use the netbios name everywhere, but it's not too hard to figure out if you have enumerated the domain controllers.
Kerberos and *NIX
Kerberos is a central authentication service that started on *NIX and is currently being used by several organizations in various flavors. Integrating *NIX Kerb with AD has always been challenging as some of the changes to MS Kerb are different than the traditional Kerb implementations on the *NIX side.There are 2 primary implementations of *NIX Kerb, MIT and Heimdal. Both are in use today. MIT is considered the more stable while Heimdal is considered the most progressive. Samba generally prefers Heimdal for its Kerb interactions.
Recently I've had several clients who had large integrations of *NIX machines within their AD environment using a product called Centrify (https://www.centrify.com/). This allows users to sign into *NIX hosts with their Windows credentials using Kerberos via SSH. Essentially the *NIX boxes become domain joined and there are some interesting things you can do, such as push out Group Policy Objects (GPOs) to the *NIX machines.
So the issue I ran into was, since I popped the domain, how can I leverage this to log into the *NIX environment? I have all this Windows Kerberos functionality thanks to Mimikatz. How can I make it work with *NIX?
Quick Into to *NIX Kerberos Commands
Getting Kerberos up and going quickly on Kali (Debian base) is fairly straight forward. I'm going to recommend using Heimdal rather than MIT based on experiences.
Simply "apt-get install heimdal-clients" and it should pull in a all the required dependencies. We aren't quite done yet, however.
First, you need to point your name resolution to the domain controller. There's a lot of magic that gets figured out with Kerberos and DNS, so pointing the resolv.conf to the DC just makes life easier. Trust me.
Secondly, you need a working '/etc/krb5.conf'. I managed to steal re-purpose one from a working Centrify config. It is worth noting that you need to get the case correct here. Kerberos realms are capitalized. It took me forever to re-learn this, so you've been warned. I recommend starting with a known good / working configuration and then modify to suit your needs. Here it is from my internal 'exploits.com' domain in the lab (Windows 2008R2 domain at 2008R2 functional level):
[libdefaults]
default_realm = EXPLOITS.COM
default_tgs_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
default_tkt_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
permitted_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
dns_lookup_realm = true
dns_lookup_kdc = true
passwd_check_s_address = false
noaddresses = true
udp_preference_limit = 1
ccache_type = 3
kdc_timesync = 0
kdc_timesync = 0
[domain_realm]
dc1.exploits.com = EXPLOITS.COM
.exploits.com = EXPLOITS.COM
exploits.com = EXPLOITS.COM
[realms]
EXPLOITS.COM = {
kdc = dc1.exploits.com:88
master_kdc = dc1.exploits.com:88
kpasswd = dc1.exploits.com:464
kpasswd_server = dc1.exploits.com:464
}
Logging into a Kerberos domain is fairly straight forward. Assuming that you have everything configured correctly, you issue the command 'kinit user1@EXPLOITS.COM'. It will prompt you for a password. Then if it is successful, it will simply return you to a command prompt. To see if you actually got a ticket, use the command 'klist'. If everything went smoothly, then your output aught to look something like this:
The Kerberos tickets are stores in a file in /tmp called 'krb5cc_0' in a *NIX Kerberos format called CCACHE. The number at the end is the UID of the currently logged in user. If you are on a multi-user system you may see several files in /tmp with different UIDs. Keep in mind that Kerberos tickets are portable..... (and if you are root, easy to grab files with multiple tickets potentially in them) ;-)
Once you have a TGT you can generally simply use the '-k' flag with any of the samba utilities to log into Windows assets using the Kerberos ticket rather than credentials. You don't even need to specify a username either, since that's all in the ticket.
Round Uno
Initially when faced with logging into the *NIX assets I hadn't figured out a good way of leveraging the keys I had recovered from the AD compromise to move into the *NIX assets. So I'm going to briefly describe what I did, however, there is a much simpler / cleaner way now, so I'm not going to give too much detail here.Essentially I started with the overpass-the-hash from above and then exported the tickets using Mimikatz. From here, I converted the TGT from the .kirbi format into the .ccache format by using another tool from Ben called kekeo. I copied the resulting file over to my Kali box as '/tmp/krb5cc_0' and voila, I now had a TGT I could then work with. However, this is a multi-step process and a serious pain in the genitals, so I wanted to try to find a cleaner way, and in the end discovered something much much cooler...
Round Two.... FIGHT!
After digging through the Heimdal code and asking Ben some questions on twitter, he pointed me to a utility I wasn't aware of called 'ktutil'. This utility is used to manage 'keytab' files, which can include actual keys. I have keys, lots of them in fact from a domain compromise, it can't be that easy, can it?
Yup.
This is using Heimdal. Use Heimdal. The 'ktutil' on MIT is interactive and is much more painful to use. Hence my recommendation to use Heimdal. Heimdal. Heimdal.
From my Twitter post:
So you can specify a file to use as the keytab (-k) the username (Principal in Kerb lingo) , the encryption type (arcfour-hmac-md5 is used for NTLM auth), the password (-w <hash>) , specify that the password is actually a key in hex (--hex) and the version a capital V (-V 5). Now I used 5 thinking that this is kerberos 5, but this version might be some other version, so I'm not entirely sure. YMMV.
Then when you use kinit, you specify the keytab file to use (-t) and then magic happens. You end up with a TGT. MUHAHAHAHAH. Overpass-the-hash with Kerberos using native tools. I feel really silly for not having figured this out sooner. Seriously. However, digging into it a little more, I found something much much cooler, if you can imagine that.
Round Three - Dude, You're Screwed!
So whilst I was digging around, I thought about trying to automate using the keytab to just store all the keys for the domain and simply pick which one I wanted based on what I needed at the time. So I approached the problem from the direction of maybe writing a script to automate dumping all the keys into a keytab. I was poking around when I found something magical.
You can actually coax Samba to do all the work for you! For every key in AD for every user / computer. With built-in tools. From a non-domain-joined computer.
So, as it turns out the newer versions of Samba have the ability to replicate from a domain controller and then you can convert that into a huge keytab.
To use this 'feature' you need a newer version of Samba. This means compiling from scratch. Beyond the scope of what I'm writing about here, but it wasn't hard. Couple annoying dependencies and some multi-core compiling later I have a new build in /opt/smb.
This magical command is called 'samba-tool'. You can use it to replicate a remote DC (with an admin user of course) and it will dump the contents to a directory of your choosing. Plus you can use Kerberos, so you can simply use an existing ticket you received from OPTH. ;-)
You need to invoke samba-tool thusly (Note, this is what worked in my lab, might be fiddly, YMMV):
samba-tool drs clone-dc-database --include-secrets --targetdir=<dir> <DOMAIN in CAPS> -k1
You need to specify 'targetdir' and the domain obviously. The '-k1' tells it to use kerberos. My test domain has a large number of objects (computers / users/ groups ) that I created using Joeware's admod to give it some size.
So, this scrolls on for a bit until it's pumped the DC dry. The next step takes the data from here and generates a keytab file with everything in it. Note this step takes a long time. On my machine it took a few hours. There might be a way to optimize things a tad if you don't want everything.
Anywhoo... without further ado:
samba-tool domain exportkeytab <filename> -s <path to configfile>
Note that the new keytab can be whatever you want it to be, however the config file was actually generated by the previous command. Like I said earlier, this command takes a while for my largish domain, but I ended up with a keytab file with all keys (AES, NTLM, DES) from the domain. And in a much more compact format. My combined file for the domain is ~6meg.
You can list the keys contained in a keytab file using ktutil and can even get the actual keys themselves if you tack on '--keys'. Muahahahahahahahahaha
Final Deep Thoughts with @Passingthehash
So digging into it a tad, it looks like samba-tool is just a bunch of python code, so I think it should be possible to make some changes to make it more useful for the average pentester. For example, rip out the code to just do the domain replication. Also, make it an option whether or not to have computer accounts in the keytab, or limit the keytypes recovered. That aught to make things go much faster. Anyways, enjoy and have fun kids!
No comments:
Post a Comment