Kerberoasting Attack & Defense
Simulate Kerberos Attacks
In a computer network, especially within systems like Active Directory, services (like websites, databases, etc.) run on servers. To identify and authenticate these services securely, each service is assigned a unique identifier called a Service Principal Name (SPN). Think of an SPN as a unique label that tells the network, "This specific service is running on this specific server." This helps ensure that when a user tries to access a service, they're connecting to the correct and trusted instance of that service. ​
Kerberoasting is a type of cyberattack that targets the way services are authenticated in networks using the Kerberos protocol (commonly found in Windows environments). Here's a step-by-step breakdown of how this attack works:​
Attacker Gains Access: The attacker first obtains valid user credentials within the network, even if they have limited privileges.
Requesting Service Tickets: Using these credentials, the attacker requests service tickets for services identified by their SPNs. These tickets are encrypted using the service account's password hash. ​
Extracting Tickets: The attacker extracts these encrypted tickets from the network.​
Offline Password Cracking: The attacker then attempts to crack the encryption offline to discover the plaintext password of the service account. ​
Gaining Elevated Access: If successful, the attacker now possesses the service account's password, potentially granting them elevated privileges within the network.
The success of a Kerberoasting attack largely depends on the strength of the service account's password. Weak or easily guessable passwords make the attack more feasible. Additionally, the type of encryption used for the service tickets plays a role; older encryption methods like RC4 or DES are more susceptible to cracking compared to newer standards like AES.
Set Up Lab Environment
Requirements:
A Windows Server as a Domain Controller (DC).
At least one Windows machine as a domain-joined workstation.
A Kali Linux Machine.
On Kali, we need to install a tool called Impacket:
Winlogbeat must be installed on both the Windows Server and the Windows workstation to transmit logs to the ELK stack.
Test accounts that we will use in Active Directory:
jdoe:(a regular user) logged into the Windows machine.admin1: (Domain admin)The
sqlsvcservice account is configured with a weak password ("Password123!"). We will attempt to request a service ticket for this account.
We now need to create a service account (sqlsvc) with a Service Principal Name (SPN) for Microsoft SQL Server (MSSQL).
Before initiating the attack, we need to audit relevant policies to gain a clearer understanding of the situation.
Edit Default Domain Policy or create a new GPO:
Audit Kerberos Authentication Service: Success and Failure (Event ID 4768).
Audit Kerberos Service Ticket Operations: Success and Failure (Event ID 4769).
Audit Process Creation: Success (Event ID 4688, Rubeus execution).
Kerberos uses tickets (TGT and TGS) for authentication:
TGT: Ticket Granting Ticket, issued by the KDC (Key Distribution Center) to authenticate a user.TGS: Service ticket, issued using the TGT to access specific services (e.g., MSSQLSvc).
In this scenario, we will assume that the attacker has obtained the username and password for the user "jdoe" .
Let's confirm whether the attacker possesses both the username and password for the user account "jdoe."
We will now attempt to extract the TGS ticket for the sqlsvc service account using two methods. The first method will be performed from a Kali Linux system, while the second will be executed directly on the compromised Windows machine using tools such as Rubeus or Mimikatz.
We have obtained a Ticket Granting Service (TGS) ticket for the svcsql account, which is encrypted. This ticket can be decrypted using tools such as Hashcat or John the Ripper.
Let's save the ticket to a file named sqlsvc.hash and attempt to decrypt it using Hashcat.
We can also decrypt it using John the Ripper.
Now, let's verify access to the sqlsvc account using the retrieved password.
After successfully obtaining and cracking a Ticket Granting Service (TGS) ticket during a Kerberoasting attack, we retrieve the plaintext password of the associated service account. This access enables various potential attack vectors, including a Golden Ticket attack if the sqlsvc service account possesses local administrative privileges on the Windows client machine. However, we will explore this aspect at a later time.
Now, let's attempt the same process while logged into the Windows machine with the jdoe account, utilizing the Rubeus.exe tool.
First, we need to install the Rubeus.exe tool on Kali and set up a web server to transfer it to the Windows machine.
Next, we will proceed with the installation on our Windows machine.
To obtain crackable tickets, we can utilize Rubeus. By executing the tool with the kerberoast action without specifying a particular user, it will extract tickets for all accounts with a registered Service Principal Name (SPN).
We have obtained a ticket, which we can transfer to our Kali machine and attempt to crack, following the same approach as before.
Before initiating a new session with the obtained credentials, we must first enable the WinRM service and PowerShell Remoting.
Next, let's initiate the new session using the sqlsvc account.
Defend Against Kerberoasting
If unsure, avoid assigning Service Principal Names (SPNs) to accounts that do not require them. Regularly review and remove SPNs associated with outdated or decommissioned services and servers.
When a Ticket Granting Service (TGS) request is made, an event log with ID 4769 is generated. However, Active Directory (AD) also logs this same event ID whenever a user attempts to connect to a service, resulting in a high volume of these events. Due to this, relying solely on event ID 4769 for detection is impractical.
Now, let's filter Event ID 4769 in Event Viewer on the Windows server.
Account Name: User requesting the ticket (jdoe).Service Name: Represents, Whom the requested TGS is for.Client Address: Indicates the machine from which the request originated.Ticket Encryption Type: 0x17 (RC4) or 0x12 (AES-256).
We can also apply a filter for Event ID 4688.
Now, let's configure ELK to create rules that generate alerts when this attack occurs.
Let's execute Rubeus.exe again and analyze the events in ELK.
Rule 1: Detect Rubeus Process Execution (Event ID 4688).
Let's define a rule to generate an alert whenever Rubeus.exe is executed.
To create a new rule, let's navigate to Security → Alerts → Manage Rules, then select Create New Rule.
This rule means:
At each execution (every 1 minute), the rule analyzes data collected over the last 5 minutes (the look-back time).
For example, if the rule runs at 5:21 PM, it will check data from 5:16 PM to 5:21 PM. Then, at 5:22 PM, it will check data from 5:17 PM to 5:22 PM, and so forth.
Let's execute Rubeus.exe on the Client01 machine again to determine whether the alert is triggered.
The alert was triggered upon the execution of Rubeus.exe.
Rule 2: Detect Excessive TGS Requests (Kerberoasting, Event ID 4769)
Legitimate users rarely request multiple Ticket Granting Service (TGS) tickets in rapid succession. Therefore, we can define a rule to trigger an alert if an account generates five TGS tickets within one minute. However, since we currently have only one service account, we will create three additional accounts to facilitate testing and rule implementation.
Service Accounts:
Now, let's run Rubeus again and review the results in ELK.
The user "jdoe" has submitted multiple ticket requests within a short period.
Next, we will create a second rule to generate an alert when a user requests four tickets within short time.
Now, let's save the rule and attempt the attack again to determine if an alert is triggered.
These rules are not the final production-ready versions. When deploying them in real-world environments, they need to be continuously tuned to minimize false positives as much as possible.
Mitigation Strategies
Block Rubeus Execution
There are additional mitigation measures we can implement. Let's review them.
To prevent Rubeus from executing on Windows systems, we can implement AppLocker or Windows Defender Application Control (WDAC).
Attackers often use these folders because they’re writable by regular users and not typically monitored for program execution. Legitimate software usually runs from C:\Program Files or C:\Windows.
C:\Users\*\Downloads (user download directories).
C:\Temp (temporary files).
C:\Windows\Temp (system temp folder).
Let's modify the Default Group Policy to prevent the execution of any executable files from these paths.
Right-click Executable Rules → Create New Rule.
You can repeat for Additional Folders:
Path: C:\Temp, Name: Deny Executables in C:\Temp.
Path: C:\Windows\Temp, Name: Deny Executables in Windows Temp.
Next, we will proceed with enabling AppLocker enforcement.
In AppLocker → Right-click Executable Rules → Properties.
Set Configured to Yes.
Enforcement Mode: Enforce rules (or Audit only for testing).
Next, we need to initiate the Application Identity Service.
Open services.msc → Find Application Identity (AppIDSvc) → Set Startup Type to Automatic → Click Start.
AppLocker requires this service to evaluate and enforce rules. Without it, rules won’t apply.
Enforcement mode prevents execution, while audit mode records attempts without blocking, making it ideal for initial testing.
Now, let's attempt to execute Rubeus.exe again from the Downloads folder.
This error confirms the deny rule prevents execution in the Downloads folder.
Let's also review the AppLocker logs.
Harden Kerberos
We can enhance Kerberos authentication to mitigate Rubeus attacks by enforcing stronger encryption protocols and preventing the use of forged tickets.
Rubeus often exploits weaker RC4 encryption (default in older setups). Forcing AES-256 increases the computational effort needed to crack TGS tickets extracted via Kerberoasting.
Monitor Command Lines
We need to improve logging to capture Rubeus command-line arguments more effectively, enhancing detection and forensic analysis.
By default, Event ID 4688 (Process Creation) does not capture command-line arguments (e.g., "kerberoast"). Enabling this setting allows the logging of arguments, providing visibility into specific actions executed by Rubeus.
Last updated
