Foundational Attacks | Radioactive Directory

The Attack Taxonomy

AD attacks generally fall into three categories: credential harvesting (getting password material), credential abuse (using credentials without knowing passwords), and persistence (maintaining access). The foundational attacks below cover all three.

Credential Harvesting

Kerberoasting and AS-REP Roasting extract encrypted material that can be cracked offline to reveal passwords. No privileged access required.

Credential Abuse

Pass-the-Hash and Pass-the-Ticket use captured credential material directly. You don't crack the password; you use the hash or ticket as-is.

Persistence & Escalation

DCSync extracts all domain credentials. Golden/Silver Tickets forge authentication tokens. These are endgame techniques.

KRB

Kerberoasting

"Request a service ticket for any SPN, crack it offline, own the service account."

Kerberos Offline Attack

Discovered by: Tim Medin at DerbyCon 2014 ("Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades"). Later expanded by Sean Metcalf and Will Schroeder (harmj0y). See also: Original DerbyCon video.

Kerberoasting exploits a fundamental feature of Kerberos: any authenticated user can request a service ticket (TGS) for any Service Principal Name (SPN) registered in the domain. The ticket's encrypted portion uses the service account's password hash as the key. Request tickets for SPNs running under user accounts, extract them, and crack offline to recover the plaintext password.

Kerberoasting: Request tickets for SPNs, crack the service account passwords offline

The Attack Flow

1 Enumerate SPNs Query AD for user accounts with servicePrincipalName attribute set LDAP query, no special privs

2 Request Tickets Send TGS-REQ for each SPN to the KDC Any authenticated user can do this

3 Extract Tickets Pull the encrypted ticket from memory or save directly Encrypted with service account's hash

4 Crack Offline Use hashcat/john to brute-force the service account password No lockout, unlimited attempts

Prerequisites

Any valid domain account
Network access to a DC
That's it. No special privileges.

Target Accounts

User accounts with SPNs (not machine accounts—their 120-char random passwords are uncrackable)
Service accounts for SQL, IIS, Exchange
Accounts with weak/old passwords

Common Tools

Rubeus kerberoast
Impacket GetUserSPNs.py
PowerView Invoke-Kerberoast
hashcat -m 13100

Why It Works

Kerberos by design: any user can request any ticket
Ticket encrypted with password hash
User accounts often have weak passwords
Service accounts often over-privileged

The danger multiplier: Service accounts are often over-privileged ("just make it Domain Admin so it works") and have passwords that never expire. One cracked service account can mean instant domain compromise.

Defenses: Use Group Managed Service Accounts (gMSAs) with 240-character random passwords. For user-based service accounts: 25+ character passwords, regular rotation, monitor for mass TGS requests (Event ID 4769), use AES encryption (RC4 tickets are faster to crack). See also Microsoft's Kerberos security guidance.

ASR

AS-REP Roasting

"No pre-authentication required? Free crackable material for anyone."

Kerberos Offline Attack No Auth Required

Documented by: Will Schroeder (harmj0y) on January 17, 2017 ("Roasting AS-REPs"). Builds on Kerberos pre-authentication research and extends the offline cracking concept from Kerberoasting. See also: Microsoft TechNet: Why Pre-Authentication Should Not Be Disabled.

When Kerberos pre-authentication is disabled for an account, anyone can request an AS-REP (Authentication Service Response) for that user. Part of the response is encrypted with the user's password hash. Request it, extract it, crack it. You don't even need valid domain credentials—but you do need to know or enumerate valid usernames.

Normal Pre-Authentication:

Client sends AS-REQ with timestamp encrypted by user's key → KDC verifies → issues TGT
Attacker can't get anything without knowing the password first

Without Pre-Authentication:

Client sends AS-REQ with just the username → KDC returns AS-REP with part encrypted by user's key
Attacker gets encrypted blob to crack without proving identity (but must know valid usernames)

Prerequisites

Network access to a DC
Know/enumerate valid usernames
NO domain credentials needed

Target Accounts

Accounts with "Do not require Kerberos preauthentication"
Often legacy/service accounts
Sometimes set for "compatibility"

Common Tools

Rubeus asreproast
Impacket GetNPUsers.py
hashcat -m 18200

Finding Targets

LDAP: userAccountControl DONT_REQ_PREAUTH
BloodHound: "ASREP Roastable"
PowerView: Get-DomainUser -PreauthNotRequired

Compared to Kerberoasting: AS-REP Roasting requires no domain authentication, but targets are rarer (most accounts have pre-auth enabled by default) and you must know valid usernames. Kerberoasting works on any SPN but requires a valid domain account. Both result in offline-crackable material, and both target RC4-encrypted responses when possible (RC4 is significantly faster to crack than AES).

Defenses: Don't disable pre-authentication. Audit accounts with this flag (it's almost never needed). If you must, use extremely strong passwords. Monitor for AS-REQ without pre-auth data (Event ID 4768 with pre-auth type 0). See Microsoft: Audit Kerberos Authentication Service.

PTH

Pass-the-Hash

Pass-the-Hash (PtH)

"The hash IS the credential. No cracking required."

NTLM Direct Access

Discovered by: Paul Ashton in 1997 (posted to NTBugTraq with modified Samba SMB client). Native Windows implementation by Hernan Ochoa in 2008 with the Pass-the-Hash Toolkit at HITB and Ba-Con, which introduced LSASS hash extraction. See also: Black Hat 2012: Still Passing the Hash 15 Years Later.

In NTLM authentication, the password is never sent over the network. Instead, the NT hash (MD4 of the password) is used to compute the challenge response. If you have the hash, you don't need the password. You can authenticate directly using the hash itself.

Why This Works:

In NTLM, the challenge-response is computed as: Response = NTLM_Function(NT_Hash, Challenge)
The password is only used to compute the hash. If you already have the hash, you skip straight to authentication.

Prerequisites

NT hash of target account
NTLM authentication accepted at target
Network access to target

Hash Sources

LSASS memory (Mimikatz)
SAM database (local accounts)
NTDS.dit (domain accounts)
LLMNR/NBT-NS/mDNS poisoning
Cached credentials

Common Tools

Mimikatz sekurlsa::pth
Responder (capture hashes)
Impacket psexec/wmiexec/smbexec
CrackMapExec
evil-winrm -H

Works Against

SMB (file shares, PsExec)
WMI/WinRM
LDAP (if NTLM allowed)
Any NTLM-accepting service

Local Admin = Lateral Movement: If the same local admin password is used across multiple machines (common without LAPS), one compromised machine yields a hash that works on all of them. This is how ransomware spreads.

Defenses: For LLMNR, disable via GPO (Turn off multicast name resolution). For NBT-NS, GPO alone is insufficient—deploy a startup script to set NetbiosOptions=2 on all interfaces (new adapters added later won't be covered otherwise). To prevent NTLM relay: require (not just enable) SMB signing, enable LDAP signing and channel binding, and configure EPA on web services. Deploy Credential Guard to protect LSASS. Use LAPS for unique local admin passwords. Add privileged accounts to Protected Users.

Mitm6/DHCPv6 Mitigation: The safest approach is blocking DHCPv6 and Router Advertisements via Windows Firewall GPO (set "Core Networking - DHCPv6-In/Out" and "Router Advertisement ICMPv6-In" to Block). Network-level protection via DHCPv6 Guard/Shield (RFC 7610) on switches is even better. Disabling IPv6 entirely will stop mitm6, but Microsoft advises against it—IPv6 is deeply integrated into Windows and disabling it can cause subtle, hard-to-diagnose issues with certain services. Preferring IPv4 over IPv6 (common advice) does not stop the attack—the attacker's DNS server wins the race condition regardless.

WPAD Mitigation: If you don't use WPAD, disable it. Per Project Black's verified guide, Microsoft's original documentation was incorrect—two registry keys are required, not one: (1) HKLM\...\Internet Settings\WinHttp\DisableWpad = 1 (DWORD), and (2) HKCU\...\Internet Settings\AutoDetect = 0 (DWORD). Deploy via two GPOs (one for computers, one for users). Two reboots are required for full effect. Do not disable the WinHttpAutoProxySvc service—this breaks Tailscale, causes thread exhaustion, and other issues. Trade-off: Disabling WPAD means proxy settings must be configured manually per machine. If your environment requires a proxy, either configure it explicitly via GPO, or keep WPAD but ensure your legitimate WPAD server is properly configured and secured—don't leave auto-discovery open to attackers.

PTT

Pass-the-Ticket

Pass-the-Ticket (PtT)

"Steal someone's Kerberos ticket, become them."

Kerberos Direct Access

Implemented by: Benjamin Delpy (gentilkiwi) in Mimikatz. The technique leverages Kerberos ticket extraction and injection capabilities that Delpy developed as part of his Windows security research. See also: Mimikatz blog.

Kerberos tickets (TGTs and service tickets) are stored in memory. If you can extract them, you can import them into your own session and use them. Steal a user's TGT, and you can request service tickets as them. Steal a service ticket, and you can access that specific service.

Stealing TGTs

A TGT lets you request service tickets for any service. Steal a Domain Admin's TGT, and you can access any service in the domain as them. TGTs typically last 10 hours (default, configurable via Group Policy).

Stealing Service Tickets

A service ticket grants access to one specific service. More limited than TGT theft, but still useful. Valid until expiration (typically same as TGT).

Prerequisites

Local admin on machine with tickets
Or: compromise of a process with tickets
Network access to use the tickets

Ticket Sources

LSASS memory (current sessions)
Kerberos ticket cache
Session of logged-in user

Common Tools

Mimikatz sekurlsa::tickets /export
Rubeus dump / ptt
Impacket ticketer.py

Limitations

Tickets expire (TGT: 10hrs default)
Only works for Kerberos auth
Need to extract before logout/reboot

TGT vs Hash: A stolen TGT is more versatile than a hash for Kerberos environments, but it expires. A hash doesn't expire (until password change). Choose your credential theft based on your persistence needs.

Defenses: Credential Guard, shorter ticket lifetimes (4hr for Protected Users), monitor for ticket usage from unexpected hosts, avoid interactive logons on untrusted systems (this is why PAWs exist).

Protected Users—Multi-Attack Defense: Adding privileged accounts to the Protected Users security group mitigates several attacks at once: no NTLM authentication (stops Pass-the-Hash), no delegation (limits lateral movement), AES-only Kerberos (slows cracking), no caching credentials on workstations, and 4-hour TGT lifetime (240 minutes—shrinks Pass-the-Ticket window). It's one of the highest-value hardening steps for privileged accounts. See Microsoft: How to Configure Protected Accounts.

DCS

DCSync

"Request replication data from a DC. Get every password hash in the domain."

Domain Compromise Legitimate Protocol

Developed by: Benjamin Delpy and Vincent Le Toux in August 2015, added to Mimikatz. Detailed analysis by Sean Metcalf. Uses the MS-DRSR protocol that Domain Controllers use for legitimate replication.

DCSync abuses the Directory Replication Service (DRS) protocol that Domain Controllers use to synchronize data. If you have replication rights (DS-Replication-Get-Changes-All), you can request any object's secrets from a DC—including password hashes for every account in the domain.

The Replication Rights:

DS-Replication-Get-Changes: Replicate non-secret data
DS-Replication-Get-Changes-All: Replicate secret data (password hashes)
Both are required. By default: Domain Admins, Enterprise Admins, Administrators, DCs

Prerequisites

Account with both replication rights
Network access to a DC (port 135, dynamic RPC)
That's it. No malware on DC needed.

What You Get

NT hashes for all users
KRBTGT hash (Golden Ticket!)
Computer account hashes
Password history if stored

Common Tools

Mimikatz lsadump::dcsync
Impacket secretsdump.py
DSInternals Get-ADReplAccount

How Attackers Get Rights

Compromise Domain Admin
Compromise account with WriteDACL on domain
Find misconfigured replication rights
Exploit delegation to DC

This is game over. DCSync gives you the KRBTGT hash (Golden Ticket = persistent domain compromise) and every user's hash (impersonate anyone). If an attacker achieves DCSync, assume total domain compromise.

Defenses: Strictly limit accounts with replication rights. Monitor for DRS traffic from non-DCs (Event ID 4662 with Replication rights). Alert on any account granted these rights. Consider Microsoft Defender for Identity which specifically detects DCSync. See also: Microsoft: Advanced Security Auditing.

GTK

Golden Ticket

"Forge a TGT with the KRBTGT hash. Become anyone, persist indefinitely."

Kerberos Persistence Hard to Detect

Discovered by: Benjamin Delpy (gentilkiwi) in 2014, presented at Black Hat USA 2014 with Skip Duckwall. Enhanced Golden Tickets (with SID History for cross-domain attacks) added in 2015 based on research by Sean Metcalf. See also: Black Hat slides.

A Golden Ticket is a forged TGT (Ticket Granting Ticket). With the KRBTGT account's hash, you can create TGTs for any user with any group memberships. The KDC will trust these tickets because they're encrypted with the correct key. You become anyone you want, and the ticket persists until KRBTGT is rotated twice.

What You Need:

KRBTGT hash: The password hash of the krbtgt account (from DCSync or NTDS.dit extraction)
Domain SID: The Security Identifier of the domain
Domain name: FQDN of the target domain

What You Forge:

Username: Any user (real or fake)
User ID: Any RID (500 for Administrator, or anything)
Group memberships: Domain Admins, Enterprise Admins, whatever you want
Lifetime: 10 years? Sure, why not.

Prerequisites

KRBTGT account hash
Domain SID
Domain FQDN
Network access to domain

How to Get KRBTGT Hash

DCSync (most common)
NTDS.dit extraction + SYSTEM hive
Compromise of a DC

Common Tools

Mimikatz kerberos::golden
Impacket ticketer.py
Rubeus golden

Persistence Power

Survives password resets (of target users)
Survives account disabling
Only dies when KRBTGT rotated TWICE
Can be used from anywhere with network access

The ultimate persistence: A Golden Ticket survives password resets, account disabling, even account deletion (you can use fake usernames). The ONLY remediation is rotating the KRBTGT password twice (once to invalidate old tickets, twice to clear the previous hash from the password history). Wait at least 10 hours between resets (the default TGT lifetime) to avoid breaking legitimate authentication. Most organizations have never rotated KRBTGT.

Defenses: Rotate KRBTGT regularly (at least every 180 days per Microsoft guidance). Monitor for TGTs with abnormal lifetimes or created outside normal flows. Use PAC validation where possible. If Golden Ticket is suspected, rotate KRBTGT twice with a 10+ hour gap between rotations. Use the Microsoft KRBTGT reset script by Jorge de Almeida Pinto for safe rotation.

STK

Silver Ticket

"Forge a service ticket with the service account hash. Skip the KDC entirely."

Kerberos No KDC Contact

Discovered by: Benjamin Delpy (gentilkiwi) in 2014, presented alongside Golden Tickets at Black Hat. Detailed by Sean Metcalf in his Silver Ticket research.

A Silver Ticket is a forged service ticket. With the hash of a service account (or machine account), you can create service tickets for that specific service without ever contacting the KDC. The ticket goes directly to the service, which trusts it because it's encrypted with the correct key.

Golden vs Silver

Golden Ticket: Forged TGT → Access ANY service as ANY user
Silver Ticket: Forged service ticket → Access ONE service as any user
Silver is more limited but stealthier (no KDC logs).

The Stealth Advantage

Golden Tickets generate TGS-REQ logs when used. Silver Tickets never touch the KDC—they go straight to the service. Harder to detect, but only useful for services whose hash you have.

Prerequisites

Service account/machine account hash
Service Principal Name (SPN)
Domain SID
Network access to the service

Common Targets

CIFS (file shares) - machine account
HTTP (web services) - service account
MSSQL - SQL service account
HOST (general) - machine account

Common Tools

Mimikatz kerberos::golden /service:
Impacket ticketer.py
Rubeus silver

Limitations

Only works for that one service
Expires with service account password change
PAC validation catches it (see note below)

Machine account Silver Tickets: Every computer has a machine account with a 120-character random password that rotates every 30 days by default. If you extract a machine account hash, you can forge Silver Tickets for services on that machine (CIFS, HOST, etc.) until the password rotates.

PAC Validation Update (2022-2024): Microsoft has progressively strengthened PAC validation through patches starting November 2022, introducing the FullPAC Checksum. As of late 2023, enforcement has been phased in automatically. This significantly reduces the effectiveness of Silver Tickets in patched environments—the service will validate the PAC signature with the KDC, defeating the stealth advantage. Check KB5020805 for enforcement timeline.

Defenses: Ensure all DCs and servers are patched for PAC validation enforcement. Monitor for access without corresponding TGS-REQ. Rotate service account passwords. Use gMSAs which auto-rotate. Machine account password rotation is automatic (30 days by default) but can be forced.