Hi everyone in this video instead of doing the usual walk-through I decided to do something a little bit different. what I’m going to do is a walk-through of a walk-through. What am I talking about?

I’ve recently watched a video by Cass and ippsec that explains a walk-through of one of the hack the box boxes that has some nice Active Directory elements to it. If you haven’t seen their walk-through, once you’re done with this video, do yourself a favor and go watch them.

As amazing as these breakthroughs were, I appreciate that the guys usually have limited time to run through the box and they don’t want to get into a lot of theory. So that leaves some of the people that are starting on this path a little bit confused onto why is this working or why is this happening. So I decided explain some of the elements of the walk through in the hope of complimenting them instead of just creating yet another walkthrough video.

In this video we’re going to be talking about what Kerberos is and particularly what the attack that you’ve seen in these walkthroughs is, as well and how does the attack work. The name of the attack is AS-REP roasting. 

What is Kerberos?

To understand this, we need a quick overview of what Kerberos is. In a nutshell Kerberos is an authentication protocol that is used in windows environments. And if you want take the 30,000 feet view of it at a very high level this is how it works. Imagine you’re logged in to your computer nd you want to access a server imagine you want to access an SQL Server for example. So what do you do is you need to ask for permission to access the server from something called the KDC.

KDC stands for key distribution center. And as the name suggests it hands out keys for clients, like you, to access servers like the SQL server.

1. You go ahead and ask the KDC for permission.  And you say I would like to go and access that server.
2. The KDC looks at your identity and verifies it and it says OK here is your ticket and this ticket will allow you to go and access that server.
3. You take that ticket, you present it to that server the server will validate this ticket and if the ticket looks valid you will have access.

This is a very high level overview of how Kerberos works.

 

Kerberos, a Deeper Look

So let’s take a deeper dive to understand this a little bit more. Take a deeper breath 🙂

When you log into your computer you provide your username and password. Your password is not saved on your computer. Normally what is saved is your password hash. When you are trying to communicate with the KDC, you are going to submit an authentication package to prove your identity. This authentication package will have your username the date the time etc. and this information will be encrypted using a secret key.

The KDC will have to decrypt it to validate your identify. Because you submitted your username with this authentication package the KDC knows who you are. The KDC also has access to your hash. It stored on a local database. The KDC will retrieve your password hash from its local database and using your secret key will decrypt the authentication package.

If it’s able to decrypt the authentication package it will then validate your identity. Once that’s done it will provide you with something called a TGT or a ticket granting ticket. You hold on this TGT dearly because it proves you have validated your identity to the KDC. Next time you want to ask the KDC for access to a server, you show it your TGT to the KDC and it will give you a key to the server you want to access.

So now you want to access the SQL server. You take this TGT and you present it to the KDC. The KDC will decrypt the TGT and if the decryption is successful, it will know it’s from you and will issue you an access with a key that will allow you to access the server that you want to access. Now this key is encrypted with the SQL server’s secrets. So you’re not going to be able to see this key. You take key that you just received from the KDC and you submit it so the SQL server.  The SQL server can decrypt this reply because it has access to its own secret key and if it is successful would give you access.

So the KDC has two services.

• The Authentication Service (AS) which has validated your identify in the first step. And has issued you with the TGT that proves you validated your identify.
• And the Ticket Granting Service which will hand you out a key every time you present the TGT.

You will be communicating with both throughout this process. And typically, they both run on the domain controller.

Now that you understand this let’s take a deeper-er dive. So take a deeper-er breath.

Kerberos, a Deeper-er Look

The first step that normally happens is that you are going to send an authentication request to the Authentication Service. At this point of time, you haven’t proven your identity and you haven’t validated your identity to the KDC. SThis will result in your authentication request being rejected. Typically speaking what happens is we start with sending the authentication package. This is were you send the authentication request to the Authentication Service to validate your identity.

If you remember, here what happens is that you are providing an authentication package which is partially encrypted using your secret key. And part of your secret key is your password hash. The AS will take this package and decrypt it and validate your identity. Once the identity is validated the AS will reply with some information including the TGT an addition to another piece of information. That piece of information is encrypted with your secrete key which, as you know by now, part of it would be your password hash.

Remember this is a very important piece of information that we need to understand why the attack will be talking about happens.

To recap, you send the authentication package to validate your identify. This package is encrypted with your secret key, part of which is your password hash. The AS replies with the TGT and another piece of informiation that is also encrypted with your secret key, part of which is your password hash.

But what if, the authentication step is not required? Are you able to just ask for the TGT directly? Does that mean you can also ask for the TGT on behalf of any user? And if the AS replies with the TGT of course it will be encrypted with that other user’s key, part of which will be the other user’s hash? Does that mean you can retrieve this hash and try to crack it?

AS-REP Roasting

The attack that we’ve seen the initial foothold is called AS-Rep Roasting and it does exactly that. It asks for a reply from the AS on behalf of a user that doesn’t require to prove its identify.

In effect, we request the TGT for an account that does not require pre authentication. Remember, pre-authentication happens before this, otherwise our request gets rejected. But in this case, there is no pre-authentication configured. Or to be more accurate, the pre-authentication step was removed due to a misconfiguration.

So we’re going to be requesting a TGT for any random account that is existing on the domain and from the reply we will be able to extract the hash of that account to crack it offline.

The prerequisite for this to work is that the user should be misconfigured with “do not require pre authentication”. This is not set by default. We are going to send the AS request directly without having to prove who we are. And then we’re going to get an AS reply for that particular, misconfigured user. That reply will have the user’s hash.

Kerbrute

We’ve seen two tools being used in the walk through the first one is called kerbrute . And the way this works is that it enumerates for usernames by sending TGT requests without the pre-authentication. When you send a request without pre-authentication you are going to get different responses. One response that we’ve seen already is you will get rejected and you will be asked to prove your identity. This means the KDC acknowledged the user exists. Another response is that you might get something that says the principle or the username is unknown. This is an indication that the user does not exist. An easy way to think of this is how sometimes you can do username enumeration on web applications. Imagine you’re trying to log in. If you put the wrong password some websites might tell you the password is incorrect. This indirectly says the username is valid but the password is not which allows for enumerating usernames.

It’s the same principle but instead of getting an error that says password incorrect, you’re getting an error that says principle unknown. So that allows us to enumerate usernames on the KDC.

impacket-GetNPUSers

Once we’ve identified valid usernames, particularly usernames that do not require pre authentication we can use another tool called from impacket called getNPUsers. The way this works, is it will request a TGT for any user you specify.  If the user is misconfigured to not require pre-auth the request will succeed. As we mentioned with this TGT you’re going to have the user’s hash. We will take this hash and crack it offline. So let’s see how this looks like in practice.

AS-REP Roasting Demo

The first tool that we’re going to be using is kerbrute. I specify the name of the domain controller and the domain and the text file with the usernames. As you can see, we identified two valid users from the list of our usernames

.

Let’s look at the Wireshark capture and see how that played out. As you can see packets #2 is linked with packet #8 which is its reply. Here we can clearly see that we sent the authentication service request and we get the authentication service reply, so our request was successful. We weren’t asked to pre authenticate. And if you look at the reply, you will see for which user that worked. Notice packet #3 which is again an authentication service request, and this is connected to the reply in packet #6. As we can clearly see we got a principle unknown message that tells us that the user is not valid. And lastly if we look at packet #5 you can see the response saying that pre authentication is required. So that tells me two things. That tells me that the user is valid, and it tells me that pre authentication step is required.

The first user that was identified, the request was followed by an immediate reply with no error messages. This is packets #2 and #8. In packet #2we sent the request and packet #8 we got the reply telling us that the user is valid and that we are able to get information without having to do the pre authentication. So the misconfigured user that we will try to abuse is the user in packet #2.

Let’s go ahead and abuse this user. For that we are going to be using impacted getNPUusers. I will specify the name of the user. You don’t have to specify any password just hit enter and you get a reply with the user’s hash.

If Let’s switch to Wireshark and see what happens. As you can see here, we sent an authentication service request, and we immediately got a reply. We weren’t asked to pre authenticate. we will see why this happens in a moment. And if you look at the content of the packet, you’ll see here something with “cypher” preceding it. This is the hash that we’ll be cracking. Now let me save this for a little bit later.

However if we try that using the administrator account, we get an error message.

What does this “don’t require pre authentication” mean and how is it set? If we go to our domain controller and we look at the properties of the user, you can see in the account options that we have an option that says do not require Kerberos pre authentication. And this is set here. This allows us to do our attack which is called AS-Rep roasting.

Now of course from here on you know what happens. We take this hash, and we crack it using hashcat.