Honeyroasting. How to detect Kerberoast breaches with honeypots

Introduction

As we know one of the main issues facing defenders, especially in large environments, is protecting against threat actors after they gain a foothold in the environment. If an attacker lands on a domain-joined PC, the attack surface is massive, and it is vital to detect them as quickly as possible. Antivirus and more common EDR solutions have come on a long way in detecting and preventing attackers, but a sophisticated threat actor will likely be able to circumvent these controls by using custom implants and advanced techniques.

One method, which is often overlooked by defenders, is the use of honeypot accounts. A honeypot account is an account strategically positioned in a network to look interesting for an attacker. If any contact is made with the honeypot account than an alert is sent to the defenders to investigate.

The primary aim of using the honeypot account in this context is to detect Kerberoasting (covered in @myexploit2600‘s post How to: Kerberoast like a boss) which based on our experience in the industry is one of the most common attack vectors used after a foothold is obtained within a network.

One of the advantages of using a honeypot account is that there are no additional software costs. A lot of blue team solutions cost big money and require a significant amount of resource to implement and administer. When using a honeypot account, there is also a zero chance of false positives being generated as the account should never be requested or used.

Domain Admin Honeypot account setup

To set up a honeypot domain admin account, we firstly need to create one in Active Directory. A similar naming convention to the existing “Domain Admins” accounts should be used to make it look legitimate. A password of 128 randomly generated characters should be used to prevent an attacker being able to crack the hash after they obtain it.

After assigning permissions we need to choose a suitable Service Principal Name (SPN). This is what the attacker will see when they conduct a Kerberoasting attack and so it’s important to make it look like something legitimate such as a MSSQL service account which a lazy sys admin has put in the “Domain Admins” group. It’s also essential to make it a unique name so check your existing SPN’s and double check the “adminCount” attribute is set to 1.

Enable “Audit Kerberos Service Ticket Operations” logging to capture event 4769 which occurs when a Kerberos service ticket is requested.

If you have a SIEM or use a SOC managed service, then these events should already be being captured and you could create a custom alert, but for this blog post, we will explain how to identify this activity with no additional services or products.

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>

After creating the custom event view, we carry out a Kerberoasting attack to test if it works.

The event is successfully picked up in our custom event view and we need to create a method to alert the administrators that an attacker is potentially in the network. The alert contains the IP address of the client machine that carried out the Kerberoasting attack. This could be a compromised user, or an attacker physically connected to the network using their own device.

We now can create a specific event viewer task that triggers when an event appears in our custom event view. The task needs to be set to “Run whether user is logged on or not”.

After setting up the task, double check the trigger settings to make sure it triggers on our previously created event XPath query.

In the final step we have set the action to launch powershell.exe but you should change it to launch a PowerShell script which emails your administrators explaining that malicious activity is going on and also disables the account.

To test the detection, we execute a Kerberoasting attack and can see powershell.exe launch.

If everything went as expected you now have an effective method to catch attackers carrying out a Kerberoasting attack within your environment. It’s important to simulate this attack vector and the response on a regular basis to make sure the relevent teams know how to react.

Kerberoasting is often carried out fairly early on after gaining a foothold and so if you can identify the attacker at this point then you can potentially block them or identify indicaters of compromose (IOC’s) to detect other implants within the network.