This webcast was originally published on May 26, 2020
In this video, Tim Medin from Red Siege Information Security discusses the fundamentals and intricacies of Kerberos authentication within Windows environments. He explains how Kerberos functions as the main authentication mechanism in Windows Active Directory, detailing its components and the process of ticket granting. Tim also delves into various attack techniques such as Kerberoasting and Golden/Silver ticket attacks, providing insights on how these vulnerabilities can be exploited and suggesting measures for detection and defense.
- Tim Medin is identified as the creator of Kerberoasting, a notable cybersecurity technique.
- Kerberos is crucial for Windows authentication, involving a client, service, and an intermediary trusted by both, which ensures secure transactions without mutual trust between the client and server.
- The webinar detailed the process of Kerberos authentication and ticket granting, including how attackers can exploit Kerberos tickets to gain unauthorized access to systems.
Highlights
Full Video
Transcript
Jason Blanchard
Thank you for being here for this Black Hills information security webcast. We do these pretty much every week, sometimes two a week. Right now we’re doing a training class at the same time and helping support Durpcon. It’s a crazy day, but we have Tim Medin here from red siege information security.
Tim is a great family. He’s a part of the family, part of the Black Hills family. I’ve, known Tim for years. Tim’s fantastic. I asked him, hey, Tim, can I say that you were the creator of curb roasting?
Tim Medin
Yeah.
Jason Blanchard
I tell my kids, they have to say that too. Yeah. but Tim is the creator of curb roasting in some way, like with other people, maybe, I don’t know. He’s going to share the story, but thanks for being here.
This one is Black Hills Information security podcast.
Tim Medin
Webcast podcast.
Jason Blanchard
All right, I’m up. Take it away, Tim.
Tim Medin
Cool. Thanks, Jason. Thank you all million people who have showed up here again ask questions along the way. They’re going to get the lovely black hills people here who are going to field some of those questions and try to interject if something is a little bit, unclear, if, they can’t answer it directly or whatever it may be.
So anyways, who I begin. Quick background, timidine. I have a company called Red Siege. I do consult the pen testing and red teaming and such.
Also an author at sans. So I’m the lead author for the pen testing course, 560. I also teach 660 ions faculty. The, sans master’s program, program director and pen tester for a long time.
Quick want to quick shout out to Eric, van bogenhout. So I used some graphics from a couple of Eric’s slides. He’s actually my co author from 560. So we ripped out some of that content.
So quick shout out to him. Here is his contact info. He’s over in, Europe, so he’s probably not here. So real quick, what is Kerberos?
Tim Medin
Right.
Tim Medin
The simple answer is, of course, if you is going to be m, it’s going to be used for our windows authentication. And there’s three pieces. I actually got a nice Kerbero shirt from a friend of mine in Japan.
It’s a, Japan sized shirt. So I think it’s like a six x or a seven x. So it’s a m massive shirt for that thinner society over there than what I am.
But, Kerberos is what’s used for our windows authentication. The origin is, of course, Cerberos. It is the three headed dog that guards the entrance to Hades, to the underworld.
A lot of parallels there. The windows domain is hell. I’m sure a lot of you are probably saying stuff like that with that. Let’s get into, let me pull this up over here real quick.
Holy smokes, that discord’s flying. It’s amazing. The main authentication mechanism we’re going to use inside a windows active directory inside of windows domain is going to be of course, Kerberos.
As we have the three headed dog. There’s actually three different pieces as part of Kerberos. Now the key to Kerberos is, for example, I don’t trust the server and the server definitely doesn’t trust me.
But we both trust an intermediary. That’s the sort of three pieces. So we’ve got that KDC, the key distribution center, that should not say Kerberos.
That is actually a typo. The key distribution center, key distribution server. There’s a number of other subservices there. That is the domain controller.
That’s our KDC. I’m going to use the term KDC and DC, I’m going to use those interchangeably because that KDC, that particular service is part of the domain controller.
Of course we’ve got the client, this is the user who wants to authenticate to some sort of a service. And of course we have the service, the web server, the SQL server, whatever, it may be.
So some of the keys here, the important pieces with Kerberos is to demonstrate trust. We’re going to need to use some secrets.
We’re going to have these secret values. We’ll come back and discuss that in a little bit more depth. But the key here is that secret. There is only really one secret in the domain and that’s going to be the NTLM hash.
The password hash for the account is used either directly as an encryption key or used to generate then an encryption key. The key here, it all comes back to that password hash.
And frankly, in turn you could say it comes back to that particular password. Let’s walk through some of the basics on how this works.
Oh, my screen’s, there we go. I like to walk through this and explain, here’s how you can explain it.
like I’m five, let’s break this down and make this super simple. How could I explain this to my kids? For example, Justin’s going to be pasting a link here probably for great.
it’s a little bit more in depth, but it’s a nice simple breakdown on how Kerberos work. So first off, I need to tell the domain controller that KDC that I am, me, I am Tim, and I’m going to prove it by typing in my password, my password here as relic, he says is spring 2020.
Nailed it. We have to change that, right? So what happens here? And we’ll go into a little bit more depth on exactly what’s going on, but I’m going to prove that I am who I am by essentially using my password hash, right?
So once that happens, I now get a ticket granting ticket. So I only need to prove myself sort of one time.
This now allows me to request other tickets. You can sort of think of like this as sort of the entry to the theme park, right? I know, Disney is closed, but this gets me into the park.
I’m not going on any rides yet. This gets me into the park. That’s my ticket granting ticket here. So again, I’m going to prove who I am. It’s all going to be based on my password hash.
I then get that ticket granting ticket. Now when I want to authenticate to an additional service, what I can do here. Whoops, my stop.
My PowerPoint is freaking out on me. There we go. When, I want to authenticate to a service, let’s say I want to go on that ride. I need to present my ticket granting ticket now to the domain controller and say, hey, this is where I want to go.
This is the ride that I want to go on now. This is the service I want to talk to. So I present that ticking granting ticket. And then I get in response a service ticket.
That service ticket comes in two pieces. And we’ll talk about those two pieces here in just, a little bit. So I present my ticket granting ticket. The domain controller here says, okay, cool, let’s use this.
And now I’m going to give you this ticket. Now the important thing to remember here is the domain controller. The KDC does not decide if I have permissions.
If it did, imagine, how big that domain controller would have to be, how big that KDC would have to be to store all of the different users and groups and all the different permissions for everything.
This just says, hey, this is who Tim is. I’m going to let the service decide, does Tim have access or not? So what happens? As we mentioned, there’s those two pieces of our ticket, right?
Half of it’s going to be for me, half of it’s going to be for the server. We can see that right here. There’s two pieces, I keep half, that, keep this coupon part, the other half.
Now I’m going to send to that target service. The target service is then going to say, then make a decision as to whether I should have access or not and what level of access I should have.
Again, that’s not the domain controller making that choice. That domain controller would have to be massive to pull that off. So instead the server is going to make that decision itself by looking at what’s called my pack.
Now, the PaC, the privilege attribute certificate, which I’ll show you in just a minute here. This is like my driver’s license. It tells all sorts of things about me.
This is Tim. Here’s his group memberships, here’s his user id, et cetera. Then just look at your driver’s license, which has holograms and such.
There’s actually two signatures that server can then verify and say, hey, you can verify one of those two signatures, one of those two holograms, if you will, and say, okay, this pack is valid.
Cool, let’s carry on. Sometimes, again, we’ll come back to this a little while later. Sometimes it’s going to say, what, I need a secondary check. This pack looks good from my perspective, but I need a secondary check on another system.
I need to say, hey, domain controller, can you double check? And there’s very specific times when that’s going to happen. So here’s what your pack looks like.
There’s a Microsoft, link here you’ll see in a minute. And it shows you how you could maybe look at m your own package. But if we start here, off to the right, they’re kind of backwards because of the sizing.
But off to the right we can see for example, my account name. My account name is tm here the full account name, login information, etcetera, as well as my rid, that’s the last part of the sid that’s called my relative id.
And we’ve got my group membership array. I clipped that off for the sake of space, but we would see a list of the groups of which I am a member. Further, at the very end of the pack, as we mentioned, are those two signatures.
The first signature is signed using the key of, the member services password hash. That means of course that target service knows its own password and therefore its own password hash.
It can verify this first signature itself and say, hey, this is what I think it is. This signature checks out, I’m good.
The second signature is going to be signed with a key that only the domain controller has. And we’ll come back to that in a, little bit, but, a teaser there that’s going to be signed with the password hash for kRbTgT.
All right, so let’s take a look. We talked about the two pieces of the, service ticket, so we got the two pieces of service ticket. I feel like I’ve got a question here. What’s up, CJ?
Tim Medin
Real quick, what was pac stand for?
Tim Medin
Pac is the privilege attribute certificate right there at the top. And by the way, that is not a Bruins stripe around the room, tiny Tim, that’s a packer stripe.
You can see my, my finger right there. There’s my cheese head. So important.
Tim Medin
NTLM hash is the only secret. What about sign ins with smart cards or hello or business credentials?
Tim Medin
Well, we’ll come back to some of that. The guts of Kerberos still rely on this one particular sort of secret value. Now if you have to do additional authentication, you could have a bounce off your package.
There’s a number of additional complexities here and we don’t have necessarily time to go through all of it and then.
Tim Medin
never mind, I guess I’ll let you roll here.
Tim Medin
Yeah, so there’s other question with the, pack here. The pack is built on my user attributes. So if you add me to a group when my pack is generated, of course that’s going to adjust that pack.
This is essentially just a whole bunch of the user information about me, my ad account information jammed into one place inside the ticket. I think Erica asked this question.
Okay, cool. All right. so there’s my service ticket. Remember, there are two pieces. There’s the piece that I keep and there’s the piece that I send to the, remote system.
The piece that I keep contains information about the validity time. When does this thing expire? So I don’t use it after its expiration date.
This is going to be encrypted with the TGT session key. Remember when I first get access to the network, I say, hey, domain controller, can I get that ticket granting ticket?
Then from there there’s a session key inside. That’s how I’m going to essentially communicate with the domain controller. Now the other half we’ve got the path.
That’s my user information. We just talked about that path. This is the half that I’m going to send to the server. It also contains a session key. That session key here allows me to have an established cryptographic, keys between me and that member server so we can talk securely and frankly we don’t have to generate the key.
now this server portion, the key here, an important piece and we’re going to come back to this in a little while is it is encrypted using the service account password hash, right.
So that’s going to be important when we get to kerberosing and some of the silver ticket attacks here in just a little bit. Now you’ll notice when this ticket is generated, as we mentioned, it’s encrypted using the service accounts password hash.
So what we need in a domain is we need a mapping between the service and the underlying service account. With that we have an SPN.
This is our service principal name. This is the mapping between, let’s say I want to go to a file share on my specific file server.
I need a mapping between the service on the host and the underlying account. If I go to a mail server and I hit it with HTTP, that HTTP on that host goes together to build that name.
It’s mapped to an underlying account. And I’ll show you a quick picture of that in just a second. How do we establish that mapping? We can use set SPN if we do it manually.
Some services will do that themselves, if you set them and give them the correct permissions. Here’s an example of some spNs. Now when I connect to a service, I don’t know the underlying service account but the domain controller has to have that.
It has to have that. So we can encrypt the ticket and use that, equip the ticket with the correct key. So here’s a little table off to the bottom right here is I’ve got the mail service, the mail server, mail service rather on Cliff.
Get it? Great jokes. let’s see discord light up on that one. Nice. Thanks BB for loving my dad joke there. Old school dad joke too, right?
So the mail on Cliff is going to have a mapping to that mail service account on the background, right? And of course that name, that account name is whatever it is defined by that organization.
I could have Charlotte the web server, right? Charlotte the web server. And there’s going to be a mapping between the service HTTP, the host to that underlying account.
And then I’ll have a sequel server on a SQL, service on db zero one mapped back to the SQL engine. I see you guys are loving that joke, huh?
mega. Sorry. Who was that? Paco. Really brutal. That’s the mapping between these pieces. Now let’s talk through, now some of those different long term keys.
So as we mentioned, we have those three pieces. We’ve got the server, the target service. We’ve got, the client. And then of course we’ve got the KDC.
Each piece has its own long term key. So the KDC’s long term key is the password hash of, KrB Tgt, right?
So you’ve probably heard about that. If you’ve done anything with golden tickets, something like that, you probably are familiar with this account. The client long term key.
Well, that’s pretty straightforward. That’s my password hash. And then the target’s long term key is going to be the password hash of that underlying service, of that target service.
So here’s what all of this sort of looks like. This is going to be a little bit more complicated representation of how we do, our authentication.
What happens is I’m going to get a timestamp from the domain controller. Whoops, let me jump ahead here. I got these out of order. I’m going to get a timestamp from the KDC.
I’m going to encrypt it using my password hash and then I’m going to send it back. The KDC because it knows my password hash is then going to decrypt and confirm, hey, is this actually valid?
At that point I get my ticket granting ticket. Now I’ve got my ticket granting ticket which allows me access to some of those other systems.
To get access to those systems, as we mentioned before, I’m going to present my ticket granting ticket and I’ll get the service ticket.
This is a different representation of that same sort of information. Remember the piece that I’m going to send to that member server. In this case the file server includes the pack.
That pack has information about me. There’s actually a typo there too. There should be a privilege attribute certificate, not account. My bad.
So the pack validation. Now this is important, right? When the server gets that ticket, it can verify it itself, right? There’s those two signatures we saw earlier.
The first one it can check. It can look at that first signature and validate it itself. Now there’s that second signature, that second signature.
What has to happen is to validate that, it has to be sent back to the KDC, sent back to the domain controller. If the service, that target service is set to run as part of the operating system, what happens then is that we won’t get this second check for the sake of speed because it’s obviously going to be slower to say, hey, what?
Can I get a second opinion over here. Hey, domain controller, can you check this out for me? That’s of course going to be significantly slower. So things like, the database, your SQL server will not by default perform that additional validation.
So that’ll be important for some of the, silver tickets. things like web servers will always do the secondary check. And the reason it has to do with the app pools and such.
Now that is the explanation of Kerberos. so far I don’t see any questions queuing up yet, so I think we’re good.
All right, let’s, let’s talk now.
Tim Medin
Oh, no, I got your questions here.
Tim Medin
All right, Huckleberry, let’s roll.
Tim Medin
Where does Kerberos pre auth come in?
Tim Medin
That was, where was that? Right there.
Tim Medin
huh.
Tim Medin
So I, I’m going to get that ticket. Essentially the pre auth gives me my ticket granting ticket. That’s the short version of what that whole thing is. Without that, we would be sending around a lot more material that would be based on my password hash.
If I’m sending around the ticket granting ticket, realistically, you’re not going to crack that because that’s encrypted with a, randomly generated key instead of a crappy password that I may have.
Tim Medin
Where can they find the pack certificates? Where are those stored?
Tim Medin
The, pack is going to be, the pack is going to be in the ticket. So there’s a wireshark. Actually, when I did this, I actually let me pull up the pack here real quick.
There’s a wireshark tutorial or link or whatever. I forget what it was. But it talked you through importing the key and using that to decrypt the ticket.
And then you can look inside this. This is actually a screenshot from Wireshark. So that Microsoft link we posted before that will also give you, the same thing.
Tim Medin
The NTLM hash is stored in memory when we authenticate. So if Kerberos depended on the NTLM.
Tim Medin
How is it better? So, I don’t, sorry, I don’t quite get that.
Tim Medin
All righty. Skip it.
Tim Medin
Yeah. The nice thing with Kerberos is we can trust each other. So I trust the KDC, the other system could trust the KDC and we can use that trust.
If I went direct, what I would have to do is the target system would somehow have to have access to a password hash or some way, or some third way to check back with the, domain controller.
I think I’m answering that question.
Tim Medin
Okay. Is there any way for Linux clients to play in with the NTLM stuff.
Tim Medin
Absolutely. So one, of the big faults, and this was actually something I said or showed sort of at the beginning, the Microsoft Kerberos is actually a bastardization of the MiT Kerberos.
So with M Mit Kerberos, you’re going to use a key tab file and you’re going to authenticate with a random value. Now the big difference between Mit Kerberos and Microsoft Kerberos is mit Kerberos.
You generate a random key and that’s what you use to identify yourself. Now of course it’s nothing that you’re going to remember, which makes it a little bit less portable, but that’s going to be sort of the big key here, no pun intended, is that key tab file.
Similarly with your target services, I can have a key tab file, I can import that key into active directory and we could actually play from the Linux side as well. My guess, that is Erica asking that question, right?
Tim Medin
That was Erica. Yeah, you nailed it.
Tim Medin
Awesome. Cool. Other questions before we, jump into some of the attacks here. Now that we all understand the, basics here, I think we’re good.
Okay, good deal. All right, so let’s talk through some of these attacks. So one of the first ones, this is, sorry, one of the biggest ones is the golden ticket, right in the, shoot, what is this stupid movie?
Charlie and chocolate Factory, right? It always bothered me and Charlie and the chocolate factory that the grandpa had been in bed for like 40 years and they jumped up and starts singing and dancing because that’s what you would do if you never got out of bed.
But whatever. So the golden ticket here, remember that is the long term key, that KRB TGT, that password hash, that is the long term key used by the KDC.
So what happens now is if we as, the attacker can get access to that long term key, the password hash for that KRB TGT, the whole thing starts to break down because now we can start to rewrite some of those tickets.
I can now rewrite my pack and I can fix that second signature also. Now my ticket granting ticket, we can now rewrite some of that, as well.
Here’s the flow. If we use the golden ticket. So with the golden ticket, what I’m not going to do is ask for a ticket granting ticket. I’m going to skip that step and I’m just going to generate it myself.
So I start now with a ticket granting ticket and we’re going to have some changes. What I’m going to do here is I’ll just make myself a domain admin.
So now my path. So inside the ticket granting ticket actually is a copy of the path. Then, what happens is when I use that ticket granting ticket, the main controller just says copy paste.
Let’s just use that. And then it will then use that pack, the one that I have now created. I have now forged my own driver’s license. And now we can use that to access a wide range of systems.
We can see here, for example, my ticket says here that I am a domain admin. That’s going to give me a lot of different access to, a lot of systems, very privileged access.
So now what’s of course, special about the golden ticket? Well, of course, the obvious answer is, well, it’s sort of homemade. Right. We have skipped that first step.
We’ll talk in a little while, a little bit later about some of the detections and protections for some of this, as well. But now I’ve got a ticket that gives me access to everything.
I’ve skipped that first step. I don’t need the password for users. I can just now create ticket granting ticket at, will or in the account with all sorts of fake data.
if I so choose, by default, the tools are going to create these again by default for ten years. So this detection is, look for a ticket grading ticket.
That is ten years of validation period. All right, how can we create this? Pretty straightforward. A number of different tools that can do this. I love me some, Kerberos, I mean, sorry, mimikatz.
So with mimic cats, I generate my ticket granting ticket with this. So I’ll say Kerberos golden. I’m gonna give it to KRB TGT, the password hash for that particular account, and then all of the additional information.
There’s a question here I see up the side that says, does Kerberos not store the valid TGT? No, because that would be redundant. What it does do is the domain controller can check the signature, but because the signature is legitimate, because I created it, using the correct key, everything then checks out, right?
So once I create my ticket granting ticket, I’m going to load it with the PTT, put that into memory, start using that ticket, and now I can access all sorts of, systems.
So that’s the golden ticket. Let’s talk now a little bit about the skeleton key. If I as an attacker can get access to a domain controller, what I can do is I can shim out LSAss.
So what this means is I now inject shellcode, inject code into the LSAs process and say, when you check a password, why don’t you check it the normal way?
But why don’t you also check my code as well? If I log in with my password of summer 2020, that’s what I always use, it’s going to say, cool.
Now if this is running, I could also log in with Tim with the password of Mimikatz, and I could log in with any user with the password of Mimikatz.
I could log in as BB, a domain admin, the SQL admin, whatever I want. Because the domain controller that LSAss is now shimmed and there’s additional code. It says, cool, check the original, but also check the option here.
Right. The default is Mimikat. Change that. Default. Be very careful with that. I had, I didn’t get permission to ask beforehand. Well, yeah, I won’t say it now.
I will. Sure. Movix. Rob Fuller, awesome guy. Told me a story about he was doing a pen test, went to log into the, domain controller. what, let’s just try Mimikat.
Tried the password of Mimikat and it worked. So what had happened is the previous pen testers had skeleton keyed the domain controller, but they never cleaned up, which meant for that entire maybe year, anybody could have logged in to any account if they just used the password of mimicats.
Yeah, facepalm is absolutely right. I see pickles. Yeah, definitely not good. So if you happen to use this on a pen test or a red team, make sure you clean up afterwards.
All it requires is a simple reboot of the domain controller. So just bounce that thing up. So it does matter. So his question there is, does it matter which DC?
Yes, I need to, if I put it on, let’s say, let’s say that there’s ten DC’s and I put it on one, of course, my authentication request would have to hit DC one for it to, work.
If I hit DC two, the shim is not running, obviously would not work. All you have to do is just reboot that system. Yeah, I don’t know how long that uptime was for that or what the timing was, but all I know is it worked for Rob.
Okay, so skeleton key, pretty straightforward. Load up again. My favorite tool, mimicats and say misc skeleton.
There is no option just to set this. You have to recompile, it. All right, let’s talk through my favorite awesome gift, my favorite real estate.
This is a technique I came up with in 2014. So remember, if we go back to that whole process, right, when I authenticate and when I get to a service, first I need a ticket granting ticket, right?
So authenticate to domain controller and I’ll do that probably when I boot up first thing in the morning when I come in or whatever it m may be. Right. Then I’m going to ask the domain controller for a ticket for the service.
So now I have the service ticket. So I’ve got that service ticket. Remember, that service ticket is encrypted using the password hash of the target service.
So what I could do here is now I have this ticket, it’s encrypted using the password hash of the target service. And now, oops, sorry if that made a lot of noise.
I now have a way to start cracking. I have password material. I’m going to guess the password for the remote system.
After I have the ticket hash, it attempted to decrypt and then repete. Get a typo in there again. Dang it. lots of slides. I’m going to do this over and over again.
The beautiful thing with this is this is now an offline attack. I request the ticket, I bring it back to my system, and now I can do an offline attack.
Remember that the domain controller does not make the decision whether I have access to the service or not, right? That means I can request a ticket for anything.
I can request a ticket for any service in the organization. It can be things that I request, access to that I clearly don’t have access to, don’t have permissions to.
Those systems could be firewalled off, they could be offline broken. In fact, frankly, they could be taken out of the network. They could be take that system, take it, send it to recycling and not be in the network.
As long as that SPN mapping still exists, I can request a ticket. Okay, so this, what this allows, it allows the attacker to reach really deep inside the organization, get these tickets for oftentimes very sensitive accounts, and perform an offline password attack.
I remember when I first sort of came up with this, it took a while for people to figure it out and frankly me to explain it because it was so weirdly different. So let’s talk now about the extraction and some of the cracking.
I need to extract that ticket so I can do the cracking. Now there’s a number of different ways that we can extract, mimic cats.
It supports this extraction. The problem is with mimic cats, as much as I like it, some of the evasion can be a little bit difficult. There’s invoke, mimicat a number of the other different c two frameworks have ability to do the same sort of thing where I can extract the tickets myself.
Then we can do some of the cracking. I’ll show you a demo of that in just a little bit with our silver ticket here.
Remember, the ticket that the service sees is encrypted using the password hash of that account. So if I can get that password in some way, shape or form or get that password hash, maybe by compromising the domain controller, maybe by compromising the target system or maybe by Kerberos tick.
Now I have that password hash. What I can do now is I can start forging the silver ticket. Let’s take a look at the silver ticket once again.
So my silver ticket, remember when I receive a legitimate one, there’s two pieces, right? There’s a piece for me and there’s the piece I send to that remote system. The piece that I send to the remote system has those two signatures and the pack, the pack of course is signed with those two signatures.
It’s encrypted, sorry, it’s signed using the password hash of the target service. So we’re double using that password hash for the remote system. It’s once to encrypt the whole ticket and then again use for the signature.
Right. Now, of course, if I wanted to sign using Krb TGT, I would have to extract that. Or I can rely on the service not performing that secondary check.
I was going to do a demo, but I was curious on how this is going to work over the Internet and all that jazz. Instead, what I did is I did a demo and I just took a bunch of screenshots just to make sure that it worked.
Okay, here’s an example. This is my home domain here. So I’ve got my account here, just Tim, Medean.
Tim, I m create my account. I’m sorry, look at my account. And this user is just a lowly domain user. This does not require local admin on the end user system.
And it definitely doesn’t require administrative access on the service side either. bonus points if you do get access.
Sorry, bonus points if the member server has admin rights because now you can use that, right? So we can see here, my user is just a regular domain user.
My user is not one of the local administrators either. So just a regular old user on this box, right? Attacker is just a regular user.
Number of different ways we can extract this here. I just sort of truncated it a little bit for the sake of space. But in this case I use the invoke Kerberos to extract the ticket.
So here essentially is the ticket that I would get for that target service. Right? So what’s going on sort of in the background here, if I don’t have a ticket granting ticket, I’ll request one of those.
I’ll then send the ticket granting ticket to the domain controller, the KDC, and say, hey, I need a ticket for the SQL server. And then I end up with what you see on the screen here. Right on the screen here, you see that ticket?
I can then crack that, right? Because this ticket is encrypted using the password hash of that remote system. So there’s a number of different crackers.
Hashcat is by far my preferred option. Here’s an example. Hashcat command, very simplified. This isn’t meant to be a hashcat train exercise, but simple way to do this.
John the Ripper will do. Also do this as well. I prefer hash cat. Now I wrote a cracker. I wrote a cracker 2014 when I came up with this because there wasn’t anything else.
And I wrote it in Python and I knew it wasn’t going to be as fast as C, but I wasn’t good enough to write all the c on my tight deadline. So I wrote it with Python.
I thought it would be a great idea to use the multicore, multi processor support within Python with load additional module to make it go faster. And it did not.
There was an option in Mycracker to specify the number of threads. And then Ethan Robish at black, hills tried it out. He’s like, yeah, the optimal number of threads is one.
Technically, my code that meant to make it go faster actually probably slowed it down. Now I still get issue an issue request on GitHub for people to ask me to like update my cracker to python three.
Don’t use it, use hashcat. It’s so much faster. All right, so let’s say we do our cracking, right? So I’ve got my cracked account, right, I’ve got this ticket here.
I have cracked the password here for the SQL engine. In my case, I picked a simple password of password one. Just to save time, let’s take a look at that target service account once we have successfully cracked it.
My target service here, this is the SQL engine. This is just a regular domain user. This is a properly configured SQL server, ideally from an attacker’s perspective.
And frankly, what we see way too often is we’ll see an account like this that has significant privileges or might be a, domain admin.
Even in this case, I properly configured this server so it can register with a domain controller to register the SPN, but it has as minimal permissions as possible.
Remember, we don’t have to have local admin access on either the end user or that target service account.
What happened is I’ve got this now, quick demo here is I’m going to log in just using my regular account, my regular tm to the database server.
I haven’t done anything else yet. I don’t have access. What I was trying to prove here is that this Tim account, my regular account does not have access to the database server.
Okay, so now let’s generate a silver ticket, right? So I’ve cracked the password hash for a password rather for the remote service account, right?
I’ve kerberoasted it, got the ticket, cracked it, got the password and now I’ve got the password hash for that remote system. Now within mimikats I can generate a silver ticket.
I know it says Kerberos golden. That’s just the feature that we use within Mimikatz is still called golden, but we just provided a different hatch.
So what I’m going to do this is just creating a legitimate ticket. If I was going to recreate my ticket here, we’ll come back through a couple of these different pieces here.
The key pieces to this ticket are going to be the groups, the iD and of course the user. Let’s change this a little bit. So let’s change this.
I am me, but I’m also not me. What I’m going to do is I’m going to leave my user still as Tim, but I’m going to change my id, my rid to be that of Bob.
Now I’m going to authenticate to the SQL server. Here’s what happens when I authenticate to the SQL server. It lets me in. Now I can access Bob’s secrets.
So I can see that Bob’s secrets database things to do in the future. I need to buy some Brando. I need a time machine. Get a latte. Cool.
Type on the idea. Did I just spell something wrong? whatever. Now there’s another set of tables that I don’t have access to. I don’t have access to the plans for world domination.
So I, meaning Bob, does not have access to that. Let’s see real quick. Let’s back up a little bit. What does it look like in the SQL server?
So I’m going to run a couple of SQL queries. First I’m going to get my name. Who does the server think I am when I authenticate. What was the name that we gave to this?
Well, we see, of course tm. Now what is the name of the Sid? This s user Sid gets the Sid s user s name gets the name of that Sid.
And now we can see that the Sid that the server thinks I am is actually Bob’s. Weird, right? So I gave it my username but Bob’s rid.
So it’s authenticating me based on Bob’s access. Cool, right? And we can take another step further. Let’s add some additional groups.
So I’ve got my groups here, I’m going to add a couple of groups. I’m going to add, I don’t know, everything that has the word admins in it. Domain admins, enterprise admins, schema admins, whatever.
Now I generate this ticket and now I can access the plans for world domination. I can now see these because I now have access as domain admin.
Realistically, the domain admin is going to have access to, frankly everything. If we look at the Sid thing. Remember here, I didn’t change the Sid in this case.
I kept it as my own. It still thinks that I’m Tim, but I have access. Weird. Tim now has access because the additional fake groups, if you will, let’s turn control mode on here.
What happens now if we change this just a little bit? We say, what, let’s change our id to something else and let’s make the user your mom.
Now I’ve got 9999 as my rid and the user is your mom. I can still get access to the database. I will still get access to the database because of those group memberships.
But now my id and user are different and we can actually see this here. So if we look at the event log, we see the log on for your mom.
Now imagine, I always laugh, imagine doing that as incident response. Some executive walks in. So whose account was compromised?
your mom. I’m sorry, speak up. m your mom is the account and then the sid and everything is all sorts of broken.
So it’s like generating your own driver’s license here for my mclovin. And it’s got all of the barcodes and stuff. Everything looks sort of cool.
So that’s kerberosium and a silver ticket. I wanted to go through that because I had a couple of questions afterwards from different people, like hey, can you give me a demo of that? Also there was a misconception that the target service had to run as admin and it does not, that’s a key point here.
Does not have to run as, admin. Other, things we can do with Kerberos attacks is we can do pass the ticket. It sort of feels like not really an attack, but it is.
I mean, you’re just essentially taking someone’s ticket and then reusing it, right? It’s like grabbing the credit card out of mom’s wallet and using it. It’s the legitimate thing. I’m just not supposed to have it, right?
So I can grab the ticket, export it, for example with mimikats, to export the ticket, import it into another system and then use that to access other systems.
So we’re going to take that ticket granting ticket, dump it, put it someplace else, and then use that. We can also overpass the hash. Even if we disable NTLM inside of our organization, we can still remember that first authentication.
Let me jump ahead here. That first authentication, the thing that allows me into that network is based on the NTLM hatch. So I can still, even if NTLM is disabled everywhere else, that first request, for all intents and purposes, relies on it, and I can still use that.
Right. All right, so let’s go through some of the, wrap up here. So we’ll talk through when can we use these attacks and what are some of the, defenses?
Well, the golden ticket, this is used for persistence and pivoting. This is not an access mechanism. This does not get me into the network at first.
This does not give me my initial access. I have to have control of a domain controller or that level of permissions to get that password hash so that I could potentially reuse it.
Now, kerberoasting, this is a pivoting and escalation technique. You have to have access to the domain controller as some sort of authenticated user to request those tickets.
Once you have those tickets, we can now crack those passwords and then we could use that, those passwords and either use those credentials directly or we could use a, silver ticket.
A silver ticket is going to be used for a persistence and our escalation. We saw that with the database server where I rewrote that ticket, and now is able to access extra pieces on that target service, pass the ticket and overpass the hash.
We’re going to have access as a user, and this is going to be allowed, used for pivoting, not an escalation technique. Here’s a number of great posts that I recommend reading.
We don’t necessarily post them all in chat because there’s a ton of them. But shoot. Will Schroeder Harmjoy did a presentation a week and a half or two weeks ago.
Phenomenal, fantastic. On Kerberos revisited. And he talked about rebus rubus, can’t pronounce it right. Rubius, whatever. His tool here.
That thing is amazing. Holy crap. Thank you to him and the rest of the people that worked on it. It’s mostly just will. Phenomenal, phenomenal tool.
Check that out. If you’re an offensive person, you’ve got to get your hands on this tool. In fact, we’re working on it right now to add this into 560. And frankly, literally any reading, anything from Sean Metcalf.
It’s funny, I saw Sean in New York a couple of years ago and we were talking and somehow Kerberos came up because it always does whatever. And I was like, what, Sean?
People ask me all the time like can you explain Kerberos to me? And I told Sean, I’m like, I just bought him to your blog post because it’s way better than anything I could have written because you such a great and thorough job.
And he told me back, he’s like, well, honestly I write those blog posts to help me understand because I don’t necessarily understand it upfront and that helps me solidify it. Just like that’s really freaking cool, by the way, call out to all of you watching at home, write blog posts on stuff.
Even if you, if it’s already out there, even if it’s not like the latest and greatest tool. It helps you learn it and it helps you hopefully let somebody else learn it gets you get your spin on it too, as well, frankly.
It’s also good for job hunt stuff type, thing too. Hey look, I blogged, I’m good, I’m smart, right? All right, so some of the defenses, the key here for most of this is going to be monitoring the golden ticket.
I mean, the obvious answer is, well, don’t get owned. Great. Realistically that might happen. The key here, this is a little bit tougher.
So look for things where like, hey, why is my ticket granting ticket all of a sudden 10 hours? Right? sorry. Ten years. That’s funky. Something weird there, right?
not the best idea. Right? It’s not going to be a default that shows you that a tool is generating this. And as I mentioned, by default it’s going to be significantly less.
So look for a shorter ticket granting ticket if you see the long one. There’s other tools that will look for use of ticket granting tickets where the ticket granting ticket was never generated and never requested in the first place.
That’s going to take some extra tooling to, do that. There are some tools out there that will do this. I haven’t necessarily run up against any of those, but they are sort of out there.
Kerberoasting the big thing here is going to be looking for too many ticket requests. If all of a sudden you’ve got one user on your network that is requesting tickets over and over and over and over and over and over and over again, that’s a problem related to that.
If Steve in marketing or Sally in accounting is all of a sudden requesting a, single ticket, right. That single ticket’s being much lower, much, much slower.
It’s still out of, that’s not normal. Understand your baseline. Why all of a sudden are they requesting tickets for this thing if they’ve never done that before? Another great one, use honey tickets.
In fact, Will talks about this, in his talk sort of ways around this. In fact, what he’ll do, because Sean was one of the first people to come up with the idea of the honey tickets, is he won’t roast any accounts that are newer than Sean’s blog post.
Right. Because if that password hasn’t been changed since then or created since then, we know probably that it’s good and it’s not used. And by honey tickets, what I mean is you’ll create an account that’s used for nothing.
You’ll set the SPN and you’ll alert anytime someone requests a ticket for that, because there’s no valid reason why anyone inside your network should be requesting, that ticket.
So a single request for that ticket means something has gone, wrong. Right. A silver ticket again, monitoring. You’d have to keep an eye out for a, missing request, for ticket again, can be a little bit more difficult to, pull that up.
All right, so that is going to, wrap it up. So we have, let’s see. Hopefully there’s some more questions here. I see CJ coming back online.
Tim Medin
Good luck. We got a lot of tickets, so feel free to say pass on these because I’m just going to work from the bottom. Coming back up. Oh, boy.
How many requests are too many requests, Tim?
Tim Medin
How many requests are too many requests that can be completely dependent on the tuning of the defensive systems? I’ve heard that, I mean, one’s obviously going to be too low.
I’ve heard two because sometimes I’ll request two in a row. I’ve heard three is where we can start getting into better detection. So if someone, within a certain timeframe requests three Kerberos tickets, something funky is probably going on.
And again, as the attacker could just slow down and say, hey, I just want one. Right. So it’s gonna be much, much harder. Is there a specific way to identify.
Tim Medin
There’s a lot of defensive questions out there. You could probably do a whole, I’ll, show on that. Is there a way to identify golden ticket using the Microsoft event ids?
Tim Medin
I don’t know the answer to that.
Tim Medin
True. This one’s pretty theoretical. How does Kerberos work in a zero trust environment? You’ve got to be at, an environment where you’re trusting the domain controller and the key.
Tim Medin
Yeah, I mean, the whole thing that zero trust means zero trust, it means you just trust certain things less than other things. You still have to the authentication, right. You still trust your domain controller, you’re just not going to allow random connections in.
That’s a. Maybe that’d be a good topic for a whole sort of a podcast down the rabbit hole. Tim.
Tim Medin
why doesn’t Microsoft just use the MIT implementation of Gerberas?
Tim Medin
The reason why we don’t use the MIT implementation is ease of implementation in the domain. Everyone has a password. It’s already there to use it.
Otherwise you’d have to generate a secret, random value for everybody and then somehow distribute that and separate it from the account. Now that just becomes a pain.
It’s non trivial. Whereas the Kerberos, you just, we didn’t have it, and then the next day we did, and we didn’t even know that we had it.
Tim Medin
Is it reasonable to change the password for KRP TGT on a periodic basis?
Tim Medin
That’s a great question. So one of the, if an attacker has your KRB TGT and they can generate those golden tickets, right, the defense is what you ultimately are going to have to do is rotate that password, and if you do it too fast, you will break the entirety of the domain in an epic, epic fashion.
So you have to rotate, you have to rotate it twice because the current password and the last password are actually both still valid keys. So you have to rotate it twice. And again, you do it too fast, you break everything.
I don’t know if there’s benefit to like rotate it every day just because, I mean, if there’s an attacker in and they sort of detect those changes, they’ll probably just grab it anyway.
And if you’re not detecting the attacker in the first place, they’re just going to keep grabbing it over and over again. So I don’t know if there’s a tremendous value in that. And if you have a problem where a system is offline for let’s say two days, you rotate every day, that system’s going to come up and it’s dead.
So nice. Maybe like once a week, once a month. But again, I don’t know the value proposition kind of have to experiment and.
Tim Medin
See and it probably depends on the environment to some extent. Apologies if you answered these because I could only half listen because I was answering questions.
Sure, mimicats are detected by endpoints in Av. Is there another way around to generate a golden ticket?
Tim Medin
Yeah, I mean a lot of your C two frameworks will do the same sorts of things. I just picked mimicats because that was the tool I had there. So I mean the short answer is there’s a ton of them out there.
Pretty much every single c two framework has something like that built in. There’s another question that I wanted to get to, and I forgot to mention this too. A defense for kerberosing is obviously a good long password that’s not crackable related to that.
Ideally use like managed service accounts. So they are truly random passwords and they are automatically generated. And that makes this pretty much infeasible.
Yes.
Tim Medin
There were all sorts of questions about picking of RC four, AE’s. does it make a difference for which one’s more defensible? How do you select that?
Tim Medin
Yeah, so this is one of the things that Harmjoy was talking about is there’s still ways, even if you’ve got, you’ve turned off rc four in your environment, say AE’s only where you can force it to downgrade from an attacker’s perspective.
It doesn’t necessarily matter cause I can still do it crack the same way. It just means it’s orders of magnitude slower to do the cracking with AE’s versus rc four.
Also look for, and again, it’s not a perfect detection. You’re going to have to tune this, but look for those requests for rc four. But again you’re going to by default still have rc four, even if you disable rc four because of the way that Microsoft and Windows makes choices.
Again, watch Will’s presentation. He goes to the details.
Tim Medin
Nice. I’ll get very close to the end here. Any other protocols of authentication? Are there alternatives to Kerberos?
Tim Medin
I mean the windows domain? Not really. I mean that’s the whole point of the windows domain is you get the single sign on, you’ve got the single central nervous system and brain that allows you to do all that simply.
Right. So a single sign out is fantastic for usability, but it also means one piece is compromised and the whole thing crumbles. So there’s always pluses and minuses.
Tim Medin
We only got 1 minute left. I need Jason to come on and wrap this up. I’m afraid at 1.2 thousand something people and still 1800 generated a, ton of questions.
Tim Medin
Ton of good ones.
Tim Medin
Sorry we couldn’t get them to all of them. Sorry.
Jason Blanchard
Absolutely. Thank you so much for joining us here for this Black Hills information security webcast. We do these weekly. If this is your first time here, we have a discord channel. Follow that. It’s easier to have a conversation and discuss that way.
And we keep that going all the time. So here comes my daughter to show me some artwork that she did, working from home. Tim, thanks so much for being here. From red siege information security.
We are pen testers. So if you ever need a pen test. Susie. Hey, sweetheart. All right. Yeah, I’ll tell you all about it in a second.
Tim Medin
Guys can identify.
Tim Medin
This is the world of the coronavirus, right? Everyone’s experiencing this. It’s not unusual.
Tim Medin
Jason. my kid came in zoom m call. My kid came in to give me the tabs for notes on paper. Yeah, I have no paper on my desk. I haven’t used one of these in a decade, but somehow I needed the middle of my zoom call this morning.
Jason Blanchard
Yeah.
Tim Medin
I have a highlighter for you, Tim, if you need it.
Tim Medin
Sorry, Jason. Sorry, Jason. We’ve jumped the shark.