Kerberoasting Examples: 5 Commands for T1558.003
Updated on October 26, 2025
Understanding practical Kerberoasting examples is crucial for any security professional looking to defend an Active Directory environment. This post-exploitation technique, outlined in MITRE ATT&CK T1558.003, allows attackers to request service tickets for accounts with Service Principal Names (SPNs) and crack their passwords offline. Here, we dive into five diverse command-line simulations to help you recognize and mitigate this threat.
 |
| Kerberoasting - T1558.003 Emulation |
Table of Contents
1. In-Memory Kerberoasting with PowerShell & .NET
The Scenario
An attacker has gained initial access to a workstation as a standard domain user. They want to find and crack the password hash of a high-privilege service account without dropping any tools to disk, using only built-in Windows capabilities.
The Command
# Find a target user with a Service Principal Name (SPN)
$SPNUser = "svc_mssql"
# Request the service ticket using .NET classes
$ErrorActionPreference = "SilentlyContinue"
Add-Type -AssemblyName System.IdentityModel
$SPN = (Get-ADUser -Identity $SPNUser -Properties ServicePrincipalName).ServicePrincipalName[0]
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $SPN
How It Works
- Add-Type -AssemblyName System.IdentityModel: This loads the necessary .NET assembly into the current PowerShell session, giving access to Kerberos-related classes.
- $SPN = ...: This line retrieves the SPN string for the target user (svc_mssql) from Active Directory.
- New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken: This is the core of the attack. It uses a .NET method to request a Kerberos Ticket Granting Service (TGS) ticket for the specified SPN. Windows caches this ticket in memory. An attacker would then use a second tool (like Mimikatz) to extract the ticket from memory to crack it offline.
Purple Team Focus: What to Look For
Log Source: Windows Security Event ID 4769 (A Kerberos service ticket was requested) on the Domain Controller.
Detection Logic: Look for a high volume of 4769 events from a single source host, especially if the user is requesting tickets for multiple, distinct services in a short period. Correlate this with PowerShell Script Block Logging (Event ID 4104), which would show the use of System.IdentityModel.Tokens.KerberosRequestorSecurityToken. The service name in the 4769 event will match the SPN being targeted.
SIEM/EDR Alerts: "Suspicious Kerberos Ticket Request," "Potential Kerberoasting via .NET," "Anomalous PowerShell Activity."
Mitigation: Use strong, long (25+ characters), and complex passwords for all service accounts. Implement Group Managed Service Accounts (gMSA), which have automatically managed, complex passwords that are not susceptible to offline cracking in the same way. For more details, review [Microsoft's documentation on securing service accounts](INSERT_INTERNAL_URL).
2. The Classic: Kerberoasting with Rubeus
The Scenario
An attacker has uploaded their offensive toolkit to a compromised server. They now use Rubeus, a popular C# tool, to automate the process of finding all Kerberoastable accounts and dumping their service ticket hashes into a file for offline cracking.
The Command
# Execute Rubeus from memory if possible, otherwise from disk
.\Rubeus.exe kerberoast /outfile:hashes.txt /format:hashcat
How It Works
- .\Rubeus.exe: Executes the Rubeus tool.
- kerberoast: This is the specific action module within Rubeus that performs the attack. It automatically discovers all users with SPNs, requests a TGS ticket for each one, and extracts the encrypted portion.
- /outfile:hashes.txt: Specifies that the extracted hashes should be saved to a file named hashes.txt.
- /format:hashcat: Instructs Rubeus to format the hashes in a way that is immediately usable by the Hashcat password cracking tool.
Purple Team Focus: What to Look For
Log Source: Sysmon Event ID 1 (Process Creation) and Windows Security Event ID 4769 (A Kerberos service ticket was requested).
Detection Logic: Create a rule that alerts on the execution of Rubeus.exe or any process with command-line arguments containing kerberoast. Correlate this process execution with a subsequent flood of Event ID 4769s originating from the same machine. Look for tickets requested with the RC4-HMAC encryption type, as this is often targeted because it's faster to crack.
SIEM/EDR Alerts: "Known Offensive Security Tool Detected: Rubeus," "Potential Kerberoasting Activity," "Anomalous TGS Ticket Requests."
Mitigation: Use Application Control policies (like AppLocker or WDAC) to block the execution of unauthorized or known malicious tools. Ensure service accounts use modern encryption standards like AES-256 by configuring the msDS-SupportedEncryptionTypes attribute on their user objects in AD.
3. The Cross-Platform Attack: Impacket from Linux
The Scenario
An attacker on a Linux machine within the corporate network has compromised a user's credentials. They use the popular Impacket suite to perform Kerberoasting against the domain controller without needing to be on a Windows host.
The Command
# Ensure you have a valid Kerberos ticket for the user first (kinit lowprivuser)
# Or provide credentials directly
impacket-GetUserSPNs -dc-ip 10.10.1.5 contoso.local/lowprivuser -request
How It Works
- impacket-GetUserSPNs: This is a Python script from the Impacket collection designed specifically for Kerberoasting.
- -dc-ip 10.10.1.5: Specifies the IP address of the Domain Controller to target directly, avoiding DNS lookups which might be logged.
- contoso.local/lowprivuser: Provides the credentials of the compromised user in the format domain/username. The script will prompt for the user's password.
- -request: This flag tells the script to not only discover the SPNs but also request the TGS tickets for them. The output will be the hashes ready for cracking.
Purple Team Focus: What to Look For
Log Source: Domain Controller Security Event ID 4769. Network traffic logs from firewalls, Zeek/Bro, or other network security monitoring (NSM) tools.
Detection Logic: Monitor Kerberos TGS-REQ (KRB_TGS_REQ) traffic originating from non-Windows source IPs or unexpected network segments. The user-agent string in the Kerberos traffic generated by Impacket may be different from native Windows traffic. Correlate Event ID 4769 logs with the source network information; an alert should be triggered if the "Client Address" is a Linux host.
SIEM/EDR Alerts: "Kerberoasting from Non-Windows Host," "Impacket Tool Usage Detected," "Anomalous Cross-Platform Authentication."
Mitigation: Network segmentation can limit the ability of compromised Linux hosts to communicate with Domain Controllers. Use strong, complex passwords for service accounts. Consider implementing an Intrusion Detection System (IDS) with signatures for tools like those discussed in Red Team vs. Blue Team exercises.
4. Stealthy Reconnaissance with PowerView
The Scenario
Before launching a noisy Kerberoasting attack, a cautious attacker wants to first identify which accounts are even vulnerable. They use PowerView, a common Active Directory enumeration tool, to quietly query the domain for users with SPNs.
The Command
# Assumes PowerView.ps1 is loaded in the session via Import-Module or IEX
Get-NetUser -SPN | Select-Object samaccountname,serviceprincipalname
How It Works
- Get-NetUser: A cmdlet from the PowerView script that is used to gather information about users in the domain.
- -SPN: This is a switch that filters the results to only return user objects that have a value set for their servicePrincipalName attribute.
- Select-Object samaccountname,serviceprincipalname: This formats the output to be clean and readable, showing only the username and their associated SPNs. This command does not request any tickets; it only performs a read-only LDAP query.
Purple Team Focus: What to Look For
Log Source: PowerShell Script Block Logging (Event ID 4104), Sysmon Event ID 22 (DnsQuery) and Event ID 3 (NetworkConnect). Domain Controller LDAP query logs (if enabled).
Detection Logic: Monitor for PowerShell script blocks containing strings like Get-NetUser, -SPN, or other PowerView cmdlet names. On the network level, look for unusual LDAP queries originating from workstations, especially those with filters like (servicePrincipalName=*). This query asks the DC for all objects with an SPN, which is highly indicative of Kerberoasting reconnaissance.
SIEM/EDR Alerts: "PowerView Reconnaissance Activity Detected," "Anomalous LDAP Query for Service Accounts," "Potential Pre-Kerberoasting Behavior."
Mitigation: Restrict who can run PowerShell scripts via Constrained Language Mode. Enabling detailed PowerShell logging is critical for detection. While you cannot block legitimate LDAP queries, monitoring for broad queries characteristic of reconnaissance can provide an early warning. Learn more about Active Directory Privilege Escalation Attacks
5. Native Windows Kerberoasting with setspn and klist
The Scenario
An attacker wants to perform the entire Kerberoasting attack using only native Windows command-line tools ("living off the land"). This multi-step process uses setspn for discovery and klist to inspect tickets, making it appear more like legitimate administrative activity.
The Command
:: Step 1: Discover SPNs using the built-in setspn tool
setspn.exe -T contoso.local -Q */*
:: Step 2: Once a target SPN is identified (e.g., MSSQLSvc/db.contoso.local), request the ticket
:: Note: This step doesn't directly use a command, it's triggered by any application trying to access the service.
:: We can force it by simply trying to connect or mapping a drive.
:: For emulation, the PowerShell/.NET method from Command #1 is the closest programmatic trigger.
:: Step 3: View the cached ticket using klist
klist
How It Works
- setspn.exe -T contoso.local -Q */*: This command queries the entire contoso.local domain (-T) for all accounts that have any type of SPN registered (*/*). This is the reconnaissance phase.
- Implicit Ticket Request: Unlike other methods, there isn't a simple command-line tool to request a TGS ticket. The ticket is requested automatically when a client attempts to authenticate to the service. An attacker would trigger this by, for example, trying to connect to the SQL server.
- klist: This command lists all the Kerberos tickets currently cached in the user's session. After triggering the ticket request, the attacker runs klist to confirm the ticket is in the cache, ready to be extracted with another tool like Mimikatz.
Purple Team Focus: What to Look For
Log Source: Sysmon Event ID 1 (Process Creation), Windows Security Event ID 4688 (Process Creation), and Event ID 4769.
Detection Logic: The execution of setspn.exe with the -Q or -L switches from a standard user workstation is highly suspicious and indicative of reconnaissance. Correlate this activity with subsequent 4769 events. Alerting on setspn.exe execution alone can be a high-fidelity signal.
SIEM/EDR Alerts: "Kerberoasting Recon via Setspn," "Suspicious Service Discovery," "Living-off-the-Land Attack Pattern Detected."
Mitigation: Audit and limit who has the setspn.exe tool available or who can execute it. Monitor for its execution from non-administrative hosts. Use strong passwords for service accounts and enable AES encryption.
Enjoyed this guide? Share your thoughts below and tell us how you leverage these Kerberoasting examples in your projects!
No comments:
Post a Comment