Silver Ticket Attack: Forged Kerberos Service Tickets

A Golden Ticket forges the master key to the domain. A Silver Ticket takes a narrower prize and is harder to see doing it. Instead of stealing the secret that signs every ticket, the attacker steals the secret of one service and forges tickets only for that service. The domain controller never hears about it. For an attacker who already knows which service they want, that quiet is often worth more than reach.

How service tickets normally work

In Kerberos, getting a Ticket-Granting Ticket is only the first step. To actually use a service, a file share, a SQL database, a web application, the client presents its TGT to the domain controller and asks for a service ticket, a Ticket-Granting Service (TGS) ticket, for that specific service.

The domain controller builds that service ticket and encrypts it with the password hash of the account the service runs as. This is the key detail. When the client presents the service ticket, the service decrypts it with its own hash and reads the enclosed Privilege Attribute Certificate (PAC) to learn who the user is and what groups they belong to. The service trusts the ticket because only the domain controller was supposed to know the hash needed to encrypt it.

What a Silver Ticket is

A Silver Ticket exploits that trust. If an attacker holds the password hash of the service account, they can build and encrypt a valid service ticket themselves, entirely offline, and hand it straight to the service. Because the service only checks that the ticket decrypts correctly with its own hash, the forged ticket is accepted.

The forged ticket can claim any identity and any group membership the attacker writes into the PAC, including administrator of the target service. The attacker chooses:

The target service, identified by its Service Principal Name (SPN).
The impersonated user and groups, written into the PAC.
The ticket lifetime, often set far beyond normal policy.

On MITRE ATT&CK this is Silver Ticket (T1558.002).

The scope is the defining limit. A Silver Ticket only works against the service whose hash was stolen. Steal the hash for a SQL service account and you can forge tickets to that SQL service, nothing else. That sounds like a downgrade from a Golden Ticket, and in reach it is, but the target service is frequently valuable on its own, and the stealth changes the calculus.

The domain controller never sees a Silver Ticket in use

Forging a Silver Ticket skips the entire KDC exchange. There is no service ticket request event on the domain controller, because the ticket was never requested from it. Detections that lean on central Kerberos logging on the DC will miss it completely. This is the single most important operational fact about Silver Tickets: the evidence lives on the target service host, not on the domain controller.

Computer accounts are service accounts too

It is easy to picture a Silver Ticket as a threat only to named service accounts running an application. The more dangerous case is the computer account. Every domain-joined machine has an account, and its hash signs service tickets for services running as the machine, including the host's own CIFS file share, its scheduling service, and other core services.

An attacker who recovers a machine account hash can forge Silver Tickets to that machine's services and access it as any user, including a local administrator. Machine account hashes are therefore prime targets, and their default behavior of automatic password rotation is a defense worth preserving rather than disabling.

Where the hash comes from

Like a Golden Ticket, a Silver Ticket depends on an already-stolen hash. The service account or machine account hash typically comes from:

Source	What it exploits	Related technique
Kerberoasting	Weak service account passwords cracked offline from requested tickets	T1558.003
Credential dumping on the service host	Local admin or SYSTEM on the machine running the service	T1003
Extraction of the machine account secret	Local SYSTEM access on a domain-joined host	T1003
Compromise of the service account directly	Reused or weak credentials for the service account	T1078

Kerberoasting is the most common feeder. It targets exactly the weak, human-set service account passwords that make offline cracking, and therefore Silver Tickets, feasible. Our Kerberoasting guide covers that recovery step in detail.

How to detect and defend

Because the domain controller is out of the loop, detection shifts to the endpoints and to hardening the accounts whose hashes sign tickets.

Detection signals

Local Kerberos logon events on the target host. The service host still logs the logon that the forged ticket produces (event ID 4624 and related Kerberos events on the member server). Anomalies here, especially logons for accounts that never normally touch that host, are the primary signal.
PAC anomalies where validation runs. Forged PACs can carry group memberships or account details that do not match the real directory. Where PAC validation is enforced, mismatches surface.
Impossible ticket properties. Excessive lifetimes, unusual encryption types, or an account context on the host that does not match the ticket are forgery tells, the same class of anomaly seen with Golden Tickets.
Access with no corresponding DC authentication. A service session on a host with no matching TGS request recorded on the domain controller suggests the ticket did not come from the KDC. Correlating member-server logons against DC event 4769 is the highest-value hunt for this technique.

Defensive controls

Use strong, long service account passwords. Silver Tickets and Kerberoasting both feed on weak, static service account secrets. Group Managed Service Accounts (gMSAs) with long automatic passwords remove the crackable-hash problem for supported services.
Let machine accounts rotate their passwords. Machine account passwords rotate automatically by default. Keep that enabled so a stolen machine hash has a short useful life.
Rotate service account passwords on a schedule. For accounts that cannot use gMSAs, periodic rotation limits how long a stolen hash forges tickets.
Enforce PAC validation. Ensuring services validate the PAC signature with the KDC removes the ability to freely rewrite group membership inside a forged ticket for services that honor it.
Ship endpoint logs centrally. Since the domain controller is blind to Silver Tickets, member server security logs must be collected and analyzed centrally, or the activity leaves no reviewable trace.
Reduce SPN exposure. Fewer accounts with SPNs, and none with excessive privilege, shrinks the set of worthwhile Silver Ticket targets. The wider account-hardening picture is covered in our Threat Group Directory and in Active Directory security basics.

Correlate the two ends of the request

The cleanest Silver Ticket hunt compares what the domain controller issued against what member servers accepted. A service logon on a host that has no matching service ticket request on the DC is exactly the gap a forged ticket leaves. Build that correlation once and it catches Silver Tickets that no single log source reveals alone.

A step-by-step walkthrough

It helps to trace the technique end to end at a conceptual level, without a specific tool or command, so the mechanism is clear.

Start from the position the attacker needs: they already hold the password hash of a service account. Say the account runs a SQL database service, and its Service Principal Name is of the form MSSQLSvc/host.domain.local:1433. The attacker also knows a handful of directory facts that are not secret: the domain name, the domain SID, and the username they want to impersonate. None of that requires special access. The domain SID is readable by any authenticated user, and SPNs are published in the directory precisely so clients can find services.

With the hash in hand, the attacker builds a service ticket offline. A Kerberos service ticket is a structured blob containing the client identity, the target service, validity timestamps, session key material, and the Privilege Attribute Certificate that lists the user's groups and privileges. Normally the domain controller assembles this blob and encrypts it with the service account hash. The attacker does exactly the same assembly, then encrypts the result with the stolen hash. Because the service account hash is the only key the target uses to open its tickets, a blob encrypted with that hash is indistinguishable from one the domain controller produced.

The attacker then writes whatever they like into the PAC. They can claim membership in Domain Admins, in the local Administrators group of the host, or in any group that grants access to the database. The service reads the PAC at face value, sees an administrator, and authorizes accordingly.

The final move is presentation. The attacker injects the forged ticket into a logon session and connects to the service as if they were a normal authenticated client. The service decrypts the ticket, confirms it opens cleanly with its own hash, reads the identity and groups, and grants access. At no point did the attacker's machine send anything to the domain controller. The database sees a valid, correctly encrypted ticket and has no independent way to know the domain controller never issued it.

The service trusts encryption, not provenance

The core reason a Silver Ticket works is that a Kerberos service treats successful decryption as proof of authenticity. If a ticket opens with the service's own key and the timestamps are in range, the service accepts it. The protocol offers the service no built-in way to ask the domain controller "did you actually issue this?" for every ticket. PAC validation is the optional mechanism that adds a check back, which is why enforcing it matters so much and why its absence is what the attack relies on.

Silver Ticket versus Golden Ticket in depth

Both attacks forge Kerberos tickets, and both are catalogued under Steal or Forge Kerberos Tickets (T1558), so it is worth being precise about how they differ. The distinction is not cosmetic. It changes what an attacker can reach, what they need to steal first, and where a defender can hope to see them.

Property	Golden Ticket	Silver Ticket
Secret required	The krbtgt account hash	One service or computer account hash
Ticket type forged	Ticket-Granting Ticket (TGT)	Service ticket (TGS)
Scope of access	The entire domain, any service	Only the one service whose hash was stolen
Contacts the domain controller	Yes, to exchange the forged TGT for service tickets	No, the forged service ticket goes straight to the service
Central log footprint	Produces DC events when the TGT is used	Leaves no DC record at all
Blast radius if the secret leaks	Total domain compromise	Limited to the target service
Typical detection point	Domain controller and directory anomalies	Target host local logs

The trade is visible in that table. A Golden Ticket is more powerful and noisier. A Silver Ticket is narrower and quieter. An attacker who already knows which service they want, and who cares about staying undetected, frequently prefers the Silver Ticket for exactly that reason. It also demands a smaller theft: one service hash rather than the krbtgt secret, which is far better protected and usually only reachable after full domain compromise. In many intrusions the Silver Ticket is the earlier, more achievable move, and the Golden Ticket comes later if at all.

Why the usual defenses fall short

Several controls that defenders rely on for other Kerberos attacks do little against a Silver Ticket, and understanding why prevents a false sense of safety.

Domain controller monitoring is the first casualty. Most Kerberos detection guidance centers on the domain controller because that is where tickets are normally issued. Event 4769, the service ticket request, is the backbone of many Kerberoasting and anomaly detections. A Silver Ticket produces no 4769 because no request is made. A detection strategy built entirely on the domain controller is blind to it by construction.

Ticket lifetime policy is the second. Domain policy caps how long tickets are valid, and short lifetimes are a good hygiene control. A forged ticket ignores policy entirely. The attacker sets the validity period themselves, so a maximum ticket age configured on the domain does nothing to a ticket the domain never issued. The excessive lifetime becomes a detection signal on the host rather than a preventive control.

Password rotation helps, but only within its window. Rotating a service account password invalidates any hash stolen before the rotation, which is genuinely useful. The gap is timing. Between the moment a hash is stolen and the moment the password changes, the forged tickets work. For accounts that rotate rarely, or for machine accounts where automatic rotation has been disabled, that window can stretch for months.

Multi-factor authentication does not enter the picture at all. Kerberos service authentication happens with tickets, not interactive credential prompts, so a second factor on user login is never consulted when a forged service ticket is presented. This mirrors the reason stolen sessions bypass MFA elsewhere: the challenge was already satisfied, or in this case never part of the ticket path.

Common mistakes and misconceptions

A few beliefs about Silver Tickets lead teams to misjudge the risk.

The first is treating the limited scope as harmless. Because a Silver Ticket only reaches one service, it is easy to file it as a minor issue. The service in question is often a database holding regulated data, a file share with sensitive documents, or an application server that itself has paths to further access. A forged administrator ticket to that single service can be the whole objective. Scope being narrow does not make it low value.

The second is assuming computer accounts are safe because nobody manages their passwords by hand. Computer account passwords rotate automatically, which is a strength. Teams sometimes disable that rotation for compatibility reasons, or restore machines from images that reset the password to an old value, and both actions extend the life of a stolen machine hash. A machine hash forges tickets to that host's own services, including its file share and remote management, so a stale machine password is a standing Silver Ticket opportunity.

The third is believing that patching the domain controller closes the technique. Silver Tickets exploit a design property of how services validate tickets, not a specific software bug. There is no single patch that removes them. The mitigation is configuration and hygiene: PAC validation, strong and rotated secrets, and endpoint visibility. Waiting for a patch that fixes it misunderstands the mechanism.

The fourth is conflating a Silver Ticket with Kerberoasting. They are linked, because Kerberoasting is a common way to recover the hash a Silver Ticket needs, but they are different steps. Kerberoasting is the offline cracking of a service ticket to recover a password. The Silver Ticket is what an attacker does with the resulting hash. Stopping Kerberoasting reduces Silver Ticket opportunities, and the two share the root cause of weak service account passwords, yet they are distinct techniques with distinct detections.

How the technique fits the broader Kerberos picture

Silver Tickets sit inside a family of Kerberos abuses that share a common root: the protocol distributes trust across secrets held by many accounts, and any leaked secret can be turned into forged authentication. Kerberoasting recovers service account passwords. Golden Tickets forge from the krbtgt secret. Silver Tickets forge from a service or machine secret. Overpass-the-hash and pass-the-ticket reuse credentials and tickets without forging new ones. Each technique targets a different secret or a different stage of the exchange, and defenders who understand the shared root can reason about all of them together.

The practical consequence is that service account hygiene is a load-bearing control across the whole family. Strong, long, automatically managed secrets make Kerberoasting fail, which starves Silver Tickets of the hashes they need. Protecting the krbtgt account and rotating it after any suspected compromise limits Golden Tickets. Reducing the number of privileged SPNs shrinks the target list for all of them. The same handful of disciplines pay off repeatedly, which is why they appear again and again in Active Directory security basics.

Frequently asked questions

Does a Silver Ticket require domain administrator rights to create?

No. That is part of what makes it dangerous. Creating a Silver Ticket requires the hash of the target service or machine account, plus public directory facts like the domain SID and the SPN. It does not require domain admin. An attacker who has cracked a weak service account password through Kerberoasting, or who has local SYSTEM on a single host to extract that host's machine hash, has everything they need to forge tickets to the relevant service.

Can a Silver Ticket be used to move across the whole domain?

Not directly. A single Silver Ticket only reaches the one service whose hash was used to forge it. An attacker can chain multiple Silver Tickets if they hold multiple service hashes, and a Silver Ticket to a high-value host can be a stepping stone to further credential theft, but the forged ticket itself does not grant domain-wide access the way a Golden Ticket does.

Will enabling PAC validation stop Silver Tickets completely?

It removes the freedom to rewrite group membership for services that honor PAC validation, because the service checks the PAC signature against the domain controller. It is a strong control and worth enforcing. It is not a universal switch, because not every service validates the PAC in every configuration, and the effectiveness depends on the service honoring the check. Treat it as one important layer alongside strong secrets and endpoint logging.

How do I detect a Silver Ticket if the domain controller sees nothing?

Move the detection to the target host. The service host still records the logon that a forged ticket produces. Collect member server security logs centrally, watch for logons by accounts that never normally touch that host, and correlate host logons against domain controller service ticket requests. A service session on a host with no matching 4769 on the domain controller is the signature gap a forged ticket leaves.

Are Group Managed Service Accounts immune to this?

They are far more resistant. A gMSA uses a long, complex password that the directory rotates automatically, which defeats the offline cracking that usually recovers a service hash. If an attacker cannot recover the hash, they cannot forge a Silver Ticket for that account. gMSAs do not change the underlying protocol behavior, so the technique still exists in principle, but they remove the practical path to the secret for supported services.

Does a longer or more complex password on a service account help?

Yes, significantly, because the most common route to the hash is cracking a Kerberoasted ticket offline. A long, random password makes that cracking infeasible in practice, which cuts off the supply of hashes. This is the same reason strong service account passwords are the top recommendation for Kerberoasting. The two techniques share this defense.

Is a Silver Ticket a Windows-only concern?

The technique is described in terms of Active Directory because that is where Kerberos service accounts and computer accounts of this kind are most common. The underlying idea, that whoever holds a service's key can forge tickets that service will accept, is a property of Kerberos itself. Any Kerberos realm where a service key is compromised faces the same class of forgery, though the tooling and account model differ outside Active Directory.

The bottom line

A Silver Ticket is a focused, quiet forgery. It gives up the domain-wide power of a Golden Ticket in exchange for skipping the domain controller entirely, which strips away the central logging most defenders rely on. The countermeasures are unglamorous and effective: strong service account passwords, machine account password rotation, PAC validation, and endpoint log collection so the one place the attack is visible is actually being watched.