Kerberos Attacks in Active Directory: Technical Guide

Kerberos attacks are the family of techniques that produces the most critical findings in any internal pentest against Active Directory: they exploit the design of the protocol itself, not software bugs. In most domains carrying the usual configuration debt they let an unprivileged user reach Domain Admin in hours. They are mapped in MITRE ATT&CK under technique T1558 Steal or Forge Kerberos Tickets and its sub-techniques.

This guide explains how Kerberos works in Active Directory step by step, the seven attacks that show up over and over in Red Team and internal pentest reports (Kerberoasting, AS-REP Roasting, Pass-the-Ticket, Silver Ticket, Golden Ticket, delegation abuse and DCSync), how they are detected in SIEM or EDR and which mitigations actually close the door. It targets blue teams, red teams and security leads with a legacy AD who want to understand the real risk footprint.

How Kerberos works in Active Directory

Kerberos is the default authentication protocol in Active Directory since Windows 2000. It replaced NTLM in modern scenarios because it adds three properties NTLM did not provide: mutual authentication, no passwords sent over the network, and support for delegation.

The protocol actors:

• KDC (Key Distribution Center). Service running on every domain controller (DC). Internally it has two services: AS (Authentication Server) and TGS (Ticket Granting Service).
• Client. The user or computer authenticating.
• Service. The resource the client wants to access (file server, SQL, IIS site, share).
• Tickets. Encrypted structures proving who the client is: TGT (Ticket Granting Ticket) and ST/TGS (Service Ticket).

The simplified flow of a normal authentication, when a user logs into a domain machine and opens a share \\fileserver01\data:

1. AS-REQ. The client sends a request to the AS asking for a TGT. It encrypts a timestamp with the hash of its password as proof of identity (preauthentication).
2. AS-REP. The AS validates and returns a TGT signed and encrypted with the key of the domain's krbtgt account. The client stores the TGT in memory.
3. TGS-REQ. When the client wants to access the service, it sends the TGT to the TGS asking for a ticket for cifs/fileserver01.
4. TGS-REP. The TGS returns an ST encrypted with the NT hash of the service account (the machine account or the service account tied to the SPN).
5. AP-REQ. The client presents the ST to the service.
6. The service decrypts the ST with its own key and lets the client in without going back to the DC.

Three ideas matter for understanding the attacks: the TGT is signed by krbtgt, STs are encrypted by service accounts with their NT hash, and the whole model assumes those account keys are well protected. Every attack below breaks one of those assumptions.

Kerberoasting (T1558.003)

The most profitable and easiest attack to execute. Tim Medin disclosed it in 2014 and since then it shows up in roughly 80% of the internal pentests we run.

Vector. Any authenticated domain user can request a TGS for any service account that has a registered SPN (Service Principal Name). The returned ST is encrypted with the NT hash of that service account's password. If the password is weak, the attacker cracks it offline without generating anomalous traffic.

Typical steps:

1. Enumerate accounts with SPN: Get-ADUser -Filter "ServicePrincipalName -ne '$null'" -Properties ServicePrincipalName or GetUserSPNs.py from Impacket.
2. Request the TGS: Rubeus.exe kerberoast or GetUserSPNs.py -request.
3. Crack offline with hashcat -m 13100.

Why it works. Service account passwords get set once and never rotated. In a large share of real ADs you still find an account with Service123 or the company name plus a year.

Effective mitigation:

• Replace traditional service accounts with gMSA (Group Managed Service Accounts): 240-byte passwords generated by the domain, rotated automatically every 30 days.
• For ones that cannot be migrated, 25+ character random passwords with documented rotation.
• Audit of ServicePrincipalName to find forgotten SPNs (accounts no longer used but still active).

Detection. Event 4769 (Kerberos service ticket requested) with encryption type 0x17 (RC4) targeting user accounts is a classic canary. Modern DCs can enforce AES and drop RC4, which breaks the simple version of the attack. Public Sigma rules map the pattern.

AS-REP Roasting (T1558.004)

A variant of Kerberoasting that does not require being authenticated in the domain.

Vector. Accounts with the DONT_REQ_PREAUTH flag enabled (Kerberos preauthentication disabled) respond to an AS-REQ with an AS-REP containing material encrypted with the NT hash of the account. Anyone with connectivity to the DC can request it and crack it offline.

Steps:

1. List vulnerable accounts: GetNPUsers.py domain.local/ -no-pass -usersfile users.txt.
2. Request AS-REP from any that return material.
3. Crack with hashcat -m 18200.

Why it shows up. The flag is usually set when a legacy application doesn't support preauthentication. Time passes, the application retires, and the account remains with the flag on but no longer protected by anyone.

Mitigation: review userAccountControl and remove the flag unless there's documented and signed justification. If there is, gMSA password or 25+ characters rotated.

Pass-the-Ticket

Once the attacker has a TGT or ST stolen from the memory of a compromised machine, they inject it into their own session and authenticate as the original user without knowing the password.

Typical steps:

1. Gain access to an endpoint and elevate local privileges.
2. Dump tickets from memory with mimikatz sekurlsa::tickets /export or with Rubeus.
3. Inject into your own session: Rubeus.exe ptt /ticket:file.kirbi.
4. Access the resource as the victim.

Why it matters. The legitimate account keeps working without disruption, no credential is exposed, and incident traceability gets complicated because the log says the real user logged in.

Mitigation: restrict local privileges (a standard user should not be able to dump memory), Credential Guard on Windows 10/11 and Server 2016+, segmentation of privileged accounts (Tier 0 / Tier 1 / Tier 2), reduce TGT lifetime.

Silver Ticket

The attacker forges a Service Ticket without contacting the DC, if they know the NT hash of the service account or machine account.

Vector. Since the ST is encrypted with the service account's key, anyone holding that hash can mint arbitrary tickets. It doesn't go through the DC, so it generates no 4769 event.

Steps:

1. Get the NT hash (via prior Kerberoasting, SAM dumping on a machine, or memory of a compromised host).
2. Forge the ST: mimikatz kerberos::golden /sid:... /target:... /service:... /rc4:... /user:Administrator.
3. Access the service as any user, even fabricated.

Why it's dangerous. DC-side detection sees nothing. If the attacker targets cifs (file shares) or host (services on the machine), they have full control of that asset.

Mitigation: rotating the service account's NT hash invalidates issued Silver Tickets. gMSA rotates on its own. Logging on the service itself (not just on the DC) detects strange access.

Golden Ticket (T1558.001)

The most impactful. The attacker forges a TGT signed with the hash of the domain's krbtgt account. Since the TGT is both issued and verified by the domain itself, any TGT signed with krbtgt is accepted. Equivalent to holding a permanent Domain Admin pass.

Vector. Obtain the NT hash (or AES keys) of krbtgt.

Steps:

1. Compromise the DC or run DCSync with sufficient permissions (more below).
2. Dump krbtgt: mimikatz lsadump::dcsync /user:krbtgt.
3. Forge a TGT with arbitrary TTL (years) and Domain Admins SID: mimikatz kerberos::golden /user:anyname /domain:dom.local /sid:... /krbtgt:hash /id:500 /groups:512 /ptt.
4. Access any resource in the forest as administrator.

Why it's hard to eradicate. The krbtgt hash is rarely rotated. Once exfiltrated, it remains valid forever absent a double rotation. And double rotation breaks active sessions if done wrong, so it gets postponed.

Mitigation:

• Periodic rotation of krbtgt (Microsoft's official Reset-KrbtgtKeys.ps1 script). Double rotation with 24h spacing to invalidate forged TGTs without tearing down the domain.
• Reduce the path to DCSync. Audit replication, remove Replicating Directory Changes and Replicating Directory Changes All permissions from non-DC accounts.
• Microsoft tier model: Tier 0 accounts (domain administrators) never log in to Tier 1 or Tier 2.
• Protected Users group for administrators: no RC4, no cached credentials, short-lived TGTs.

Diamond Ticket and Sapphire Ticket

Modern variants (Charlie Bromberg / SpecterOps, 2021-2022) that obfuscate better than the classic Golden Ticket. Instead of forging the TGT from scratch, the attacker requests a legitimate TGT, decrypts it with the krbtgt hash, and modifies only the critical fields (SID, groups). The result is a TGT that looks more authentic and can bypass detection that hunts for Mimikatz forgery patterns.

Sapphire adds that the modified TGT contains a PAC requested from the DC itself, instead of one built by the attacker, which reduces noise even more. The mitigation is the same as for Golden Ticket: if krbtgt is rotated, the attack falls apart.

Unconstrained Delegation

A configuration that lets a service act on behalf of the client connecting to it. When a user accesses a service with unconstrained delegation, their full TGT is stored in the service server's memory. If the attacker controls that server, they can wait for a Domain Admin to connect and steal their TGT.

Steps:

1. Identify machines with the TRUSTED_FOR_DELEGATION flag: PowerView Get-NetComputer -Unconstrained or BloodHound.
2. Compromise one of those machines.
3. Wait (or force via PetitPotam, SpoolSample) for a privileged user to connect.
4. Dump TGTs and reuse.

Mitigation. Eliminate unconstrained delegation except for justified cases. Mark Domain Admins as Account is sensitive and cannot be delegated (flag NOT_DELEGATED). Add critical admins to the Protected Users group.

Constrained Delegation and RBCD

Constrained delegation limits delegation to specific services (msDS-AllowedToDelegateTo field). Safer than unconstrained, but if the attacker controls the account holding the delegation, they can pivot to those services impersonating any user, including Domain Admins, via the S4U2Self + S4U2Proxy trick with Impacket's getST.py.

Resource-Based Constrained Delegation (RBCD) gives control of the delegation to the target resource instead of the source. More manageable, but abusable: if the attacker gets WriteProperty privilege over msDS-AllowedToActOnBehalfOfOtherIdentity of a machine, they can write their own account as authorised and impersonate anyone against that machine.

Mitigation. Audit every existing delegation. Reduce to the strictly necessary. Protect administrators with NOT_DELEGATED and Protected Users.

DCSync

Not strictly a "Kerberos" attack, but the usual entry to Golden Ticket. It lets an attacker with Replicating Directory Changes and Replicating Directory Changes All permissions ask the DC to replicate credentials (including krbtgt) using the MS-DRSR protocol, without physically compromising a DC.

Steps:

1. Check permissions: Get-ObjectAcl -DistinguishedName "DC=dom,DC=local" | Where-Object {$_.ActiveDirectoryRights -match "GenericAll|Replicating"}.
2. Run: mimikatz lsadump::dcsync /domain:dom.local /user:krbtgt.
3. Result: NT hash and AES keys of krbtgt. From there, Golden Ticket.

Mitigation. Audit and restrict those permissions. Only DC machine accounts and legitimate audit tools should hold them. Any other grant is potentially exploitable.

Detection with SIEM and EDR

Key events in the Windows Security log:

• 4768: TGT requested (AS-REP). Useful for spotting active accounts and anomalous patterns.
• 4769: TGS requested. A spike of 4769 with EncryptionType 0x17 (RC4) targeting user accounts marks classic Kerberoasting.
• 4624 / 4625: logon success / failure. Combined with logon type, reveals use of stolen tickets.
• 5136: directory change. DCSync leaves traces if replication is properly audited.
• 4742 / 4738: changes on user and machine accounts. Useful to detect delegation modification.

Platforms like Microsoft Defender for Identity, Wazuh with custom rules, commercial SIEMs and EDRs with identity modules (CrowdStrike Falcon Identity, SentinelOne Singularity Identity) ship with prebuilt detection for Kerberoasting, AS-REP Roasting and Pass-the-Ticket patterns. Coverage is usually good on Kerberoasting and Golden Ticket; weaker on delegations and RBCD, where the line between legitimate traffic and abuse is thinner.

How they map in MITRE ATT&CK

The family lives under T1558 Steal or Forge Kerberos Tickets with sub-techniques:

• T1558.001 Golden Ticket
• T1558.002 Silver Ticket
• T1558.003 Kerberoasting
• T1558.004 AS-REP Roasting
• T1558.005 Ccache Files (relevant on Linux with Kerberos client)

DCSync lives under T1003.006 OS Credential Dumping: DCSync. Delegations are covered under T1550.003 Use Alternate Authentication Material: Pass the Ticket. Keeping a live coverage map of these identifiers in ATT&CK Navigator is the standard way to measure whether the SOC actually detects them.

Mitigations that really close the door

A practical summary, ordered by impact:

• gMSA on every service account that supports it. Closes Kerberoasting in one move.
• Periodic rotation of krbtgt with the official script. Invalidates old Golden Tickets. Reasonable cadence is every 6-12 months, double rotation with spacing.
• Microsoft tier model. Strict separation of Tier 0 / Tier 1 / Tier 2 accounts. Domain administrators never connect to workstations or intermediate servers.
• Protected Users for every critical administrator. Blocks RC4, NTLM and delegation.
• Eliminate unconstrained delegation except for justified cases with a signed waiver.
• Audit userAccountControl and remove DONT_REQ_PREAUTH when not justified.
• Credential Guard on endpoints to prevent ticket dumping from memory.
• Force AES and disable RC4 in Kerberos where possible.
• Replication privileges (Replicating Directory Changes) reviewed, audited and minimised.

No single point closes the problem. Defence against Kerberos attacks is layered, and configuration debt in AD gets cleaned up over successive annual rounds.

Compliance fit

For European companies under regulation, demonstrating domain identity management is an explicit part of the framework:

• NIS2 (article 21). Access control, identity management and monitoring measures. An AD full of trivial Kerberoasting does not pass a serious audit. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (articles 9, 10). Technical and organisational measures, logical access control. Financial entities face additional scrutiny over privileged identities. More in DORA compliance guide for financial entities 2026.
• ENS (Spanish Royal Decree 311/2022). Measures op.acc (access control), op.exp.8 (user activity logging). On paper, covers what is needed to detect Kerberos abuse.
• ISO 27001:2022 (controls 8.5, 8.7, 5.18). Secure authentication, privilege management, logging and monitoring.
• PCI DSS v4.0 (req. 7, 8, 10). Access control, authentication and traceability. AD serving PCI environments has to pass specific review.

Frequently asked questions

What exactly is the krbtgt account?

An account created automatically when the first DC of the domain is promoted. It is never used for interactive logon; its only function is to sign and encrypt the TGTs issued by the KDC. Its NT hash is the domain's "master key". That is why an attacker holding that hash can mint Golden Tickets indefinitely.

How often should krbtgt be rotated?

Microsoft recommends reactive rotation after an incident and proactive rotation every 6 to 12 months, always with double rotation separated by at least 24 hours so legitimate TGTs in circulation are not invalidated abruptly. There is an official Microsoft script to automate it safely.

Does it help to disable Kerberos and use only NTLM?

No. NTLM has worse problems (Pass-the-Hash, NTLM Relay) and many modern services require Kerberos. The correct line is hardening Kerberos (AES only, gMSA, Protected Users, no unconstrained), not removing it.

Does BloodHound find all these issues?

BloodHound visualises relationships, ACLs and paths to Domain Admin from enumerated data. It detects unconstrained delegation, potential RBCD, dangerous ACLs, Kerberoastable users and AS-REP Roastable users in one pass. It is the first step, but real exploitation (forging, cracking, delegation abuse) requires specific tooling (Rubeus, Impacket, Mimikatz) and experience.

Does Entra ID (Azure AD) remove these risks?

Only partially. Entra ID does not use Kerberos for cloud authentication, but Kerberos still exists in synchronised on-premise resources (local AD servers, file shares, legacy applications). As long as a company runs hybrid AD, Kerberos attacks still apply to that part of the environment. Cloud-first migration shrinks the surface but does not remove it until on-premise AD retires.

Can a vulnerability scanner detect Kerberoasting?

Not reliably. Nessus or Qualys flag generic weak configurations but do not enumerate SPNs nor request TGS to validate. The realistic way to find it is to execute the attack in controlled mode (standard part of an internal pentest) or deploy specific AD audit tools (PingCastle, Purple Knight, Semperis DSP).

Related resources

• What is a penetration test: the technical methodology that includes Kerberos attacks against Active Directory as standard scope.
• What is MITRE ATT&CK: tactics, techniques: the framework that catalogues T1558 and lets you measure defensive coverage.
• What is threat hunting and how it works: the discipline that hunts Kerberoasting or Pass-the-Ticket patterns when they have not fired an alert.
• What is SIEM and how it works: the platform where 4768/4769 events get centralised and detections are built.
• What is EDR (Endpoint Detection and Response) and What is MDR (Managed Detection and Response): controls that add identity detection on top of DC events.
• What is OSINT: cycle, sources, tools: the discipline that supplies the prior reconnaissance feeding internal AD attacks.

Active Directory auditing at Secra

At Secra we run internal pentesting with specific focus on Active Directory: enumeration with BloodHound and PowerView, audit of delegations, execution of Kerberoasting, AS-REP Roasting and detection validation with purple team, tier model review, mapping of findings to MITRE ATT&CK and a deliverable oriented to prioritised remediation. If your organisation has never audited the domain, is on its third admin and nobody is sure which SPNs are live, or needs to validate AD before a NIS2 or DORA audit, get in touch through contact or check our infrastructure audit service.