Kerberos Attack Paths: AS-REP Roasting to Domain Compromise

Kerberos is the load-bearing authentication protocol of the modern enterprise, and it is built on a small number of cryptographic primitives that, when misconfigured, will cheerfully hand you the keys to a domain. Most internal compromises that end in Domain Admin pass through three or four well-understood steps. Each step exploits a specific design choice that made sense in 1993 and ages poorly when the network has 30,000 service accounts and a flat trust model.

This post walks the canonical chain - AS-REP roasting, Kerberoasting, delegation abuse, Silver Ticket - and pulls out the one fundamental mistake that repeats at every step. Once you can name it, the chain stops being a sequence of disconnected magic tricks and becomes a single misconfiguration class that you can systematically hunt.

AS-REP roasting

Pre-authentication is the part of the Kerberos AS exchange where the client proves it knows the user's password before the KDC issues a TGT. It exists to prevent exactly what we're about to do. Some accounts have it disabled - sometimes for legacy compatibility, sometimes because somebody once flipped the bit in 2009 and nobody noticed.

When pre-auth is disabled, you can request a TGT for any user without proving anything. The KDC returns an AS-REP encrypted with the user's NTLM hash, which you can crack offline at your leisure. No interaction with the user, no failed login events on most domains, and the attack runs from any unauthenticated network position.

$ Rubeus.exe asreproast /format:hashcat /outfile:asrep.txt
[*] Action: AS-REP roasting
[*] Target Users:
[*] svc_legacy_print  → no preauth required, hash captured
[*] svc_old_iis        → no preauth required, hash captured

The remediation is one PowerShell line per affected account, and the cost of doing it is zero. The fix has been in every Active Directory hardening guide since 2014. It still finds open accounts in 4 of every 10 domains we review.

Kerberoasting

Once you have any authenticated user - even a low-privilege one - you can request service tickets (TGS) for any account with a Service Principal Name. The KDC encrypts the ticket with the service account's NTLM hash, and gives it to you. There is no privilege check on the request. There is no event log entry that distinguishes a normal request from a roasting one in default audit policy.

The key fact: every service account in the domain that runs as a user (rather than as a managed Group MSA) is potentially crackable, and you only need any low-privilege account to start. Service accounts historically have weak, never-rotated passwords for operational reasons; in our reviews, between 25% and 60% of harvested service tickets fall to a 6-hour offline crack.

$ Rubeus.exe kerberoast /outfile:tgs.txt
[*] SamAccountName: svc_sql_prod
[*] DistinguishedName: CN=svc_sql_prod,OU=Service Accounts,DC=corp,DC=local
[*] Hash: $krb5tgs$23$*svc_sql_prod...

$ hashcat -m 13100 tgs.txt rockyou.txt
svc_sql_prod:Summer2018!     ← cracked in 4 minutes

Constrained delegation abuse

Delegation lets a service act on behalf of a user to a downstream service. There are three flavours: unconstrained (still around in 2026, somehow), constrained, and resource-based constrained delegation (RBCD). Each has its own abuse path, but the fundamental shape is the same - if you control any account configured for delegation, you can request tickets for any user accessing the configured downstream service.

Resource-based constrained delegation is the most exploitable in modern environments because it can be configured by the target service's owner, not just by Domain Admins. If you can write to the target's msDS-AllowedToActOnBehalfOfOtherIdentity attribute - and many GenericWrite ACLs end up granting this in practice - you can configure a controlled service to delegate to it, and impersonate any user against it, including Domain Admins.

Silver Tickets

Once you have a service account's NTLM hash - from Kerberoasting, AS-REP roast, DPAPI dump, anywhere - you can forge service tickets directly without the KDC's involvement. These are Silver Tickets, and they are particularly nasty because the only authority required to forge one is the secret key for the target service. The KDC never sees the ticket, never logs the request, and many SIEM rules specifically wait on KDC-side events that never fire.

Silver Tickets persist across password resets - if the service account password isn't actually changed (a common operational gap on legacy services where a rotation 'broke things' once), the forged ticket remains valid for whatever lifetime the attacker put in it. A Silver Ticket good for a decade is a perfectly valid Silver Ticket if nobody is checking.

The fundamental mistake

Walk back through the chain. AS-REP roasting works because pre-authentication is disabled on accounts where it shouldn't be. Kerberoasting works because service account passwords are weak. Delegation abuse works because permissions are over-granted. Silver Tickets work because service account credentials live too long.

These are not four bugs. They are one bug: privileged accounts are managed by humans, and humans operate on a different time scale than attackers. Every single step of the chain is a place where an account was put into production and the operational risk of touching it again outweighed the security benefit of doing so. Every six months, somebody promised to clean it up. They never did.

What works

• Inventory and audit pre-authentication on every account quarterly. Anything with pre-auth disabled is a finding by default.
• Enforce minimum password length (25+ characters) on service accounts and enable AES-only encryption types - this alone removes the productive Kerberoasting surface for most attackers.
• Move service accounts to gMSAs aggressively. The migration is real work; the alternative is shipping cracked passwords to attackers indefinitely.
• Audit msDS-AllowedToActOnBehalfOfOtherIdentity changes as a high-fidelity signal. Configuration changes here are rare, sensitive, and usually a step in an active intrusion.
• Deploy Honey Service Principals - service accounts with strong but observable hashes that fire on any attempt to roast or use them. Bluespawn and the BloodHound community have published variants. They are extremely high-signal and trivial to stand up.

The cumulative effect of these is to deny the attacker the slack the chain depends on. None of them is hard. All of them are unglamorous. That's why they keep being undone.