redteam Featured

Roasting your way to DA - Build-Break-Defend-Fix

Dive into both Kerberoasting and ASREP Roasting, looking at how they work, how to introduce them into an environment and how to fix them or where possible monitor and defend against them.

Andy Gill

May 8, 2020 • 13 min read

Now that you have finished enjoying the beauty of Scotland in winter.

Welcome to part 2 of my paving the way to DA series, in this post I'll be covering both Kerberoasting and ASREP Roasting, taking a deeper dive into how they work, how to introduce them into an environment and how to fix them or where possible monitor and defend against them.

If you missed the first part of the series it can be found here, both are independent of each other but they are different ways of escalating your privileges on a network and each can be defended or fixed.

Also if you'd prefer to follow along with a video I streamed this earlier in the month:

Before we dive into all the fun stuff it is important to get a bit of background on the components that underpin the attacks discussed in this post. There are three main components that form kerberos authentication, the domain controller, target service and a client.

Essentially when a user from an endpoint(the client in this example) wants to access a specific service. The client requests an authentication ticket also known as a ticket-granting ticket (TGT) from the Key Distribution Centre (KDC).

The KDC will verify the credentials and sends back an encrypted TGT and session key for the client to access a specific service.
The TGT is encrypted using the Ticket Granting Service (TGS) secret key
The TGT is stored by the client and, when it expires the local session manager will request another TGT (this happens in the background and is invisible to the user/client).

When the client needs to communicate with a service on another node (a "principal", in Kerberos parlance), the client sends the TGT to the TGS, which usually shares the same host as the KDC. Service must be registered at TGS with a Service Principal Name (SPN).

A SPN is a feature whereby a user can request a ticket from the domain controller to access a service on the domain, the domain controller replies with a ticket that is encrypted with the user for that service's hash.

The client sends the current TGT to the TGS with the Service Principal Name (SPN) of the resource the client wants to access
The KDC verifies the TGT of the user and that the user has access to the service
TGS sends a valid session key for the service to the client
Client forwards the session key to the service to prove the user has access, and the service grants access.

Kerberoasting(T1558.003)

Kerberoasting works provided the target user has a non-null SPN property. We can take their kerberos hash and crack their password offline using something like john the ripper or hashcat.

Build

While there is legitimate functionality to have SPNs implemented, where possible (and I'll dive more into this later on in the post) it is recommended to setup any service accounts with a long password and to use AES256 by default rather than RC4. However for the purposes of this lab example we're not going to select AES256, instead we are going to use RC4.

First we need to create the account within AD that is going to be our service account. This can be done with domain admin on any machine within the domain but is easiest from the domain controller. To do this, there are many ways however the easiest command would be:

net user zephr_adm password /add /domain

Once this is done we can add a SPN for the user with the following:

setspn -s smb/purplehaze.offense:445 zephr_adm

This will set a service principle name for the SMB service on port 445 for the zephr_adm user. As shown below:

Break Things

In order to kerberoast there are two options, on domain and off/outside a domain. Starting off with the attack path from on domain(which is the most likely situation during an internal or phishing engagement).

There are three tools that can be used for performing on-domain kerberoasting, rubeus, sharproast and invoke-kerberoast. Yes there are other tools out there for sure but I'll be covering how to perform the attack with these three and how to crack the hash produced in hashcat in this post :-).

Rubeus

Rubeus is a C# toolset for interaction with kerberos and abuse of features, it is part of GhostPack and can be pulled from GitHub here. It can be compiled using visual studio community edition which can be downloaded here. Simply open the .sln file in VS then select Build->Build Solution.

This will build and drop the exe into the bin folder ready to use with command line or execute-assembly. For the purposes of this blog I'm going to demo use from an on-domain machine using the command line interface rather than via a command and control server (C2). However the execution method is identical anyway(there are multiple ways to compile it as a library and other things).

Once we've built Rubeus it is time to poll the domain controller for potential kerberos accounts that are kerberoastable on the domain, we can do this by launching Rubeus from a domain connected machine or within the context of a domain user.

At this stage it is worth noting that everytime this command is run the machine will retrieve ALL of the kerberos tickets for the domain, as a result this needs to be considered as they will also be cached.

Rubeus.exe kerberoast /format:hashcat

Additionally if the defensive team are smart they may implement honeyroasting with a domain account honey pot(more on this later on how to implement and track from a defensive perspective).

For the purposes of the demo we're going to go after the account we created zephr_adm, therefore we'll grab the RC4 hash for this user using. This command requests only the RC4 version of the hash of the zephr_adm user and outputs it to hashcat format for easy cracking.

Rubeus.exe kerberoast /user:zephr_adm /format:hashcat /tgtdeleg

We'll take the hash and crack it with hashcat:

From the hash we can see it is $23 which indicates that the hash we retrieved is RC4. Which hashcat should be able to make light work of.

.\hashcat64.exe -m 13100 ep.txt wordlist.txt

For those that have never used hashcat, essentially the command above is:

hashcat64.exe: Running hashcat64 binary on windows
-m 13100: This is telling hashcat what the hashtype is, this is called a mask. In this case we're instructing it to use Kerberos 5, etype 23, TGS-REP.
ep.txt: This is where the hash file is, this could be called anything but I've named the file ep.txt as shown in the screen capture above.
wordlist.txt: This is a wordlist we're going to try the hash against to try and extract the cleartext password.

The password for the user was successfully retrieved which was found to be 14Carmex!. As the hash was RC4_HMAC it was easier to crack however if we were unable to retrieve a RC4 hash the other indicator would be $18 which is an AES hash. Hashcat can still attempt to crack this however it will take longer due to the encryption algorithm in use.

Alongside rubeus there are a few other ways to extract hashes when on a domain connected machine, sharproast and invoke-kerberoast, they both work in a similar way as shown.

SharpRoast

Rubeus younger brother and what the tool is based off of, SharpRoast (it's in the name) is a C# based toolset. It is now discontinued in favour of Rubeus however there may still be environments where it isn't detected vs Rubeus.

In order to use it, it also needs to be compiled in the same way as Rubeus. Once this is done the tool can be run as follows:

SharpRoast.exe all

This command will request all of the SPNs for the domain and give back the hashes which can be sent to hashcat or john the ripper again. However for the purposes of this demo we're going to specify the account for ease of access:

.\SharpRoast.exe zephradm

Again this hash can be taken and cracked with hashcat, another way technique to do the same action.

Invoke-Kerberoast

Finally probably the most used for a while is the powershell implementation of this attack, while attackers are moving more and more away from powershell, there are still environments where it works effectively.

Invoke-Kerberoast is an old module that was written into powersploit and empire but adopted by many frameworks and toolchains since then. It is essentially a powershell script that does the same actions as Rubeus and sharproast.

It can be run simply from powershell:

Invoke-Kerberoast

This will drop out all of the hashes on the domain in the same format that we've had from Rubeus and SharpRoast.

Once again take the hash value and drop it into hashcat, there's a quick way of outputting this:

Invoke-Kerberoast -OutputFormat HashCat|Select-Object -ExpandProperty hash | out-file -Encoding ASCII kerberosHashes.txt

This will drop the hashes into an output file ready for cracking!

Operational Security Considerations

While attacks are useful to know about it is just as important to understand the operational security impacts (also known as opsec) when using tooling and techniques. Specifically if the target has implemented honeyroasting then there are one-liners that can allow you to operate under the radar such as:

Rubeus.exe kerberoast /pwdsetbefore:01-01-2017 /resultlimit:10

This will task Rubeus with requesting all SPNs with a password set before 1st Jan 2017 which is before the concept of honeyroasting was introduced therefore less likely to trigger alerts on that front!

Defend

Now we've looked at how to build and break the issue it is important to understand how to effectively monitor for usage on your network and identify similar attacks. There's a few ways of detecting usage, specifically kerberoasting can be detected using either detection based on kerberos requests or by implementing honeyroasting. Instead of re-inventing the wheel, check out this post on honeyroasting by my colleague Tim.

Create a custom event view to identify when a Kerberos service ticket is requested for our honeypot user account. This can be accomplished by using the following XPath query that contains our newly created account. If we do not do this step, in a large active directory environment there will be thousands of 4769 event logs and it will be difficult to identify malicious activity.

<QueryList> <Query Id="0" Path="Security"> <Select Path="Security">*[System[(Level=4 or Level=0) and (EventID=4769)]] and * [EventData[Data[@Name='ServiceName']='tkerb']]</Select> </Query> </QueryList>

A quick and easy one liner to create a honeyroast account can be done as shown, this will require RSAT Tools from Microsoft.

$UserPassword = ConvertTo-SecureString 'set a really long password in here for a user you want to have as a honeyroast account' -AsPlainText -Force

New-ADUser -Name "tgttest" -AccountPassword $UserPassword -ChangePasswordAtLogon $false -City "London" -Company "CompanyName" -Country "UK" -Enabled $true -Description "Account used for testing access to senstive content" -Department "Privileged Accounts" -DisplayName "tgttest" -SamAccountName "tgttest" -Path "OU=PrivilegedAccounts,dc=STREAM-DC,dc=purplehaze,dc=offense" -PasswordNeverExpires $true -AllowReversiblePasswordEncryption $true

Essentially this creates an account that looks very juicy to an attacker, however when kerberoasting is initiated and this account triggers it is a surefire way of identify nefarious activity on the network.

Additional recommendations from MITRE include are:

Enable Audit Kerberos Service Ticket Operations to log Kerberos TGS service ticket requests. Particularly investigate irregular patterns of activity (ex: accounts making numerous requests, Event ID 4769, within a small time frame, especially if they also request RC4 encryption [Type 0x17]).

Fix

In terms of actually fixing the issue there are a few key pieces of advice, where possible don't use RC4 if it can be helped. Use long passwords, or use password vaults for service accounts. Change your password policy to require 100+ character passwords that are randomly generated therefore less likely to be cracked.

Implement detections for anomalous service ticket requests, requires tracking state of all tgt ticket requests in a domain which is not a trivial task. Implement the use of honeypot accounts to alert for malicious activity.
Enable AES support(depends on base domain support 2008+ )

ASREP-Roasting

ASEPRoasting is similar to Kerberoasting in the same manner that the attack queries accounts for TGTs, grab the hash, then crack them using our favourite password cracking tool hashcat.

For the purposes of this example I'll be carrying out the attacks from an on-domain machine, there are lots of posts out there that dive into it from all angles but few that show the full process tart to finish.

Build

The biggest difference and caveat with ASEPRoasting is that Kerberos pre-authentication needs to be disabled. This is a rare setting and unlike kerberoasting it is not a default setting.

When you request a TGT, via a Kerberos AS-REQ message, you also supply a timestamp that is encrypted with your username and password.

The Key Distribution center (KDC) then decrypts the timestamp, verifies the request is coming from that user, then continues with the authentication process. This is the pre-authentication process for Kerberos, which is obviously a problem for an attacker because we aren’t the KDC and cannot decrypt that message. Of course, this is by design, to prevent attacks, however if pre-authentication is turned off, we can send an AS-REQ to any user which will return their hashed password in return.

Since pre-auth is enabled by default, it has to be manually turned off, so this is rare, however still worth mentioning as there is a viable attack here to retrieve hashes for users.

Break

Rubeus ASREP

Again like kerberoasting ASREP can be attacked using Rubeus. To do so, the following command can be used:

Rubeus.exe asreproast

This will query for find all accounts that do not require pre-authentication:

We can take this hash and crack it within hashcat using a different mask this time:

.\hashcat64.exe -m 18200 epqa.txt wordlist.txt

Lucky for us there's only one hashtype for asrep which makes cracking easier, to use the account there are many methods to replay the credentials such as winrm, smb, rdp and LDAP. I'll touch on these techniques in a later blog post to allow you to leverage the skills you have learned.

Invoke-ASREPRoast

Again like kerberoasting there is a powershell counterpart to Rubeus which will enable you to extract hashes for asrep vulnerable users:

Invoke-ASREPRoast -Domain purplehaze.offense

Again this hash value can be taken and cracked with hashcat easily. The downside to the powershell implementation is that it is more likely to be caught by things like AMSI and other EDR monitoring, while Rubeus is supplied as a compile-it-yourself to evade simple signature based detection and able better customisation.

Defend & Fix

The primary fix for this issue is to uncheck the box that is checked, it is worth noting that this might not always be possible due to dependencies of third party plugins, therefore instead the same fixes can be applied such as long passwords and monitoring for potential alerts of ASREP accounts.

With AS-REP you see event IDs 4768 and 4625. This is because the user does not need to be pre authenticated, therefore an attacker doesn't need to know the password.

The primary difference between kerberoasting and asrep from a defensive perspective is

Windows Security Logs, Kerberoast will contain Event ID’s 4768 and 4769, where in AS-REP contains Event ID’s 4768 and 4625. The biggest indicator to me that one was AS-REP vs Kerberoast was the Failed login attempt along with there was no service ticket requested.
Kerberoast has AS-REQ/AS-REP AND TGS-REQ/TGS-REP. However AS-REP Roasting only uses AS-REQ/AS-REP. The key here is because Kerberoast is requesting a Service Account Authorisation Ticket, where AS-REP is only requesting a Kerberos Authentication Ticket.

In Summary

Essentially both attacks can be carried out from an on-domain machine and can enable you to escalate privileges, as we've seen it is pretty easy to implement into an environment and there are many tools out there to carry out the attacks. The difficulty always falls onto the defensive and fix measures as there isn't really one fix for all, certainly in the case of Kerberoasting, therefore having a proactive blue team is the best solution and laying additional traps(in the form of honeyroasting) is a good approach.

The Detection for Kerberoasting is hard, as requesting for service tickets does happen a lot with legitimate purposes, however if you look for service request formatted in RC4, then this should flag more malicious or anomalous activity.

The next post will take a deep dive into some more lateral movement techniques using kerberos and other funky methods.

As this is part of a 5 part series, if you missed the first part it can be found here: