I'm PKDC, your Personal Kerberos Domain Concierge for the Whatever_domain

So in my last post I demonstrated how you can use Samba to replicate a domain and then create a giant keytab full of keys to use.  You can then use the Heimdal Kerberos implementation to log in as any user you want.

That's neat and all, but what if I want to query the information I pulled offline? We know that Samba can function as a domain controller, but is there a way to coax Samba to be able to present the into to us in a usable format?  IE can we query group membership?

Well, as it turns out, the answer is yes and more...  I'm going to show you how to make your own personal Kerberos Domain Concierge for the domain you just dumped.

Wait what do you mean 'concierge'?

 A popular definition of the word 'concierge' (at least here in the states) is a hotel employee who assists guests with local information, such as maps, restaurant suggestions, event tickets, etc... They are usually at the front of the establishment (at some more touristy locations they have their own office / desk area).

Within the context of pentesting, what I want to do is gather enough information from a site to replicate my own personal domain controller, query it for information and ultimately be able to authenticate against it instead of the target domain.  In other words, literally stealing a domain controller and putting it under my control.

Sound evil?  Yes.  Yes it is.

Moving from Replication Dump to Kerberos Domain Concierge

One of the nifty things that the replication did for us was create a samba config file for us.  Here's what that looks like.

Fairly straightforward.  The config claims to be DC1, and starts up a bunch of services.  For what we need, I'm going to turn off stuff that will likely be noisy.  For example, I don't want our Concierge to replicate anything.  So I'll remove both 'wrepl' and 'drepl' from the list.  I'll also nuke 'dnsupdate' and 'nbt' (netbios over tcp/ip) since DNS might try to update and netbios is noisy as hell...

I also want to bind the instance to localhost.  This actually requires a couple of lines because just saying 'use this interface' isn't enough, you have to put in 'no really I mean it' as well :/  The two lines that get added to the 'global' section are 'interfaces = lo' and 'bind interfaces only = yes'. So here is my finished config.

So I now start up samba with 'samba -s /root/tmp/dc_copy/etc/smb.conf' and see what complains....  I try using the user1 hash to authenticate to get information about user1 using the 'net' command.

And it fails.  Ok something isn't happy.  Let's look at the logs...

So winbindd is complaining about not having a local password to add.  So I do a little digging and discover that I need to add something to 'private/secrets.tdb' for the machine password.  I create a dummy password and insert the key using 'tdbtool', kill / restart samba and try again...

Holy !@$!@# it worked!  Now, let's see if we can coax it to give us a ticket for kerberos...  In order to do this, I make a slight change to the krb5.conf file.  I changed the KDC from dc1 to 127.0.0.1.

From here, I do the 'kinit' using the previously generated keytab.  And voila! I get a ticket from our own personal Concierge....

And here's the wireshark capture showing that the traffic went across localhost

So what happens if we try to use this ticket to authenticate to DC1?  On the localhost side, we get a request for a service ticket, which is to be expected.

On the 10 side we see that there is a pause between the DNS query for the address and the SMB connection.  This is where the Concierge was asked about giving us access to the CIFS share on the domain controller.

Here's the list of the tickets we ended up with.

So like a true professional, our Concierge got us tickets to whatever we wanted without complaining ;-)

Ramifications

Ok.  So this is cute, so what?  Why should somebody care about this?

Well... aside from the fact that I now have a Domain Controller that I can authenticate against that the other side has no visibility into, this is sort of the penultimate demonstration of domain compromise.  Standing up your own domain controller for their environment.  Unless they are looking for / logging replication traffic, they would have no idea WTF is going on.  I *believe* that some of the next generation detection capabilities depend on being able to watch authentication traffic on the DC, so not authenticating against that would cause some serious problems detection wise.

Other Thoughts / Ideas

Right now this is a localhost only copy of the database.  It would be entertaining to see if this could be extended so that other people / VMs could authenticate against this on an assessment.  Getting this working on the *NIX side should be straight forward.  I REALLY want to see if I can get my Windows attack platform to authenticate to it.  That aught to be fun...  We'll see how this goes...