Kerberoasting, Silver Tickets, and Golden Tickets: Different Keys, Different Risks

Summary

Kerberoasting, Silver Tickets, and Golden Tickets all involve Kerberos, but they cross different trust boundaries. I find them easier to reason about by starting with the secret an attacker needs.

Kerberoasting targets the password-derived key of a service account through an offline guessing attack. A Silver Ticket involves forging a service ticket using a compromised service key. A Golden Ticket involves forging a ticket-granting ticket using a compromised krbtgt key.

My original article mixed those steps together. Requesting a service ticket is not forging one. Having permission to register an SPN is not the same as possessing the service's key. Harvesting a cached ticket does not reveal the krbtgt password hash.

Those corrections change how I test the techniques and how I describe the resulting exposure.

How Kerberos fits together

In an Active Directory domain, the key distribution center runs on a domain controller. A client uses a ticket-granting ticket, or TGT, to request service tickets. A service ticket is presented to the relevant service.

The details of ticket validation matter. I do not assume that possessing an artifact grants unrestricted access. The target service, account permissions, ticket contents, supported encryption, and validation rules all affect acceptance.

I keep password spraying separate. Spraying attempts online authentication and can trigger lockouts. It is not a prerequisite that belongs at the start of every Kerberoasting demonstration.

Conditions and affected versions

These are credential and trust abuses, rather than one vulnerability with a single affected version range. A useful lab needs a domain controller, a domain client, a deliberately configured service account, and a service to test.

I record the domain and client builds, update levels, encryption policy, service configuration, and tool versions. Modern validation and hardening can make an old ticket-forgery recipe fail. That result deserves explanation, rather than an instruction to disable protections.

I also check DNS and time synchronization first. Kerberos errors caused by a wrong hostname, service principal, or clock difference can look like an exploit failure when the actual problem is the lab setup.

Reproduce in a lab

Request a service ticket for Kerberoasting

On a test workstation with Impacket installed, I check the local entry point:

impacket-GetUserSPNs -h

Some installations expose the upstream script as GetUserSPNs.py instead. I use the name available in the recorded environment.

For the lab example, I request tickets for discovered service accounts and save the crackable material:

impacket-GetUserSPNs 'example.com/labuser' \
  -dc-ip 192.168.1.100 -request -outputfile kerberoast.txt

The domain, username, and IP are placeholders for the isolated lab. Omitting a command-line password allows the tool to prompt for it. I use a test account rather than putting a reusable secret in shell history.

The upstream GetUserSPNs implementation documents the request and output options.

The output is not a plaintext password or an extracted service-account password hash. It contains ticket material that can support offline password guessing.

If the captured material is specifically Kerberos TGS etype 23, the original Hashcat mode applies:

hashcat -m 13100 -a 0 kerberoast.txt passwords.txt

passwords.txt is a controlled lab dictionary. I do not apply this mode to every Kerberos ticket format. The Hashcat example-hash reference is where I check the matching mode.

My original output claimed a recovered password without enough trustworthy context to reproduce that result. I need the actual lab evidence before presenting a recovery as a demonstrated outcome.

Understand the Silver Ticket prerequisite

A Silver Ticket test starts after the relevant service key is available. That might follow service-account compromise, including a successful offline recovery in a deliberately weak lab. It does not follow merely from discovering an SPN.

The old article labelled this Rubeus command as Silver Ticket generation:

./Rubeus.exe kerberoast /outfile:kerberoast.txt

That command performs Kerberoasting. It does not forge a service ticket. The Rubeus documentation separates those actions.

For a controlled forgery experiment, I first document the exact SPN, domain SID, test user's identifiers, service key type, and target validation behavior. Impacket's ticketer implementation supports generating TGTs and service tickets; its local help exposes the parameters for that installed version:

impacket-ticketer -h

I test the intended service operation and compare service-side logs. A generated ticket file proves generation. Acceptance and useful authorization are separate observations.

Understand the Golden Ticket prerequisite

A Golden Ticket requires a compromised krbtgt key. That is a domain-level secret and a much more serious starting condition than an ordinary authenticated user's ability to request a service ticket.

The original post described Rubeus harvest as a way to obtain that key. In fact, it monitors and renews accessible cached TGTs. Those tickets are not the krbtgt long-term key.

The original DCSync step also needs its missing prerequisite: directory-replication privileges. It is not a command an ordinary domain account can use successfully just because it knows the domain controller's name.

I keep the ticket-generation and acceptance steps tied to a known lab key and the current domain configuration. I do not combine a Golden Ticket example with service-ticket parameters and label the result successful.

On a Windows test client, I can inspect the current ticket cache:

klist

A cached ticket is not a Windows access token. Its presence alone does not prove that a service accepted it. Similarly, opening a remote shell requires the necessary service access and privileges; it is not an automatic consequence of a successful klist command.

Impact

A recovered service-account password gives the permissions of that account. I evaluate its real access rather than assuming every service account is a domain administrator.

A forged service ticket can threaten the resources accepted by the relevant service. A compromised krbtgt key undermines domain authentication and calls for a coordinated recovery plan.

I also remove the printer-spooler coercion command from this sequence. Coercion can be part of other attack chains, but the original post did not establish the relay, delegation, or privilege conditions connecting it to key compromise.

Detection

I correlate domain-controller ticket events with client and service activity. Microsoft's Event 4769 documentation describes service-ticket requests and encryption fields. Updated Windows builds can expose additional fields, so parsers need to match the collected event schema.

Unusual request patterns, encryption choices, and service-account use are investigation leads. They need a baseline. A Silver Ticket may not have a corresponding legitimate KDC issuance event for the forged artifact, so service-side telemetry matters as well.

I avoid claiming that one event ID proves a forgery. I need the account, service, source, timing, and validation outcome together.

Fix and mitigation

I reduce service-account privileges and use long, managed secrets where supported. I review service encryption support and plan removal of weaker options with compatibility testing.

For a compromised service key, I rotate that account's secret and investigate where it was exposed. For krbtgt compromise, I follow a domain recovery plan. Microsoft's krbtgt reset guidance covers the need for two resets and the replication and timing considerations. I do not treat them as two back-to-back password changes.

The evidence I want at the end is specific: which key was at risk, what the attacker could do with it, and which retest shows that access has been removed.