Silver Ticket Attack in AD: Detection and Remediation

What Is a Silver Ticket?

A Silver Ticket is a forged Kerberos service ticket (TGS) created with the secret of a target service account. MITRE tracks the technique as T1558.002, Silver Ticket.

The scope is narrower than a Golden Ticket, but the mechanism is important. An attacker who knows the password hash or Kerberos key of a service account can forge a ticket for that service and present it directly to the service host. MITRE is explicit on both points:

the attacker needs the password hash of a target service account
the forged ticket is a service ticket, not a TGT
the ticket can be created without interacting with the KDC

That last point is why Silver Tickets remain valuable. The attacker is not asking a domain controller to mint the service ticket in real time. They are forging the service ticket offline and then presenting it to the target service.

For this article, the scope is Windows Active Directory Kerberos environments. The focus is the real prerequisite chain, the protocol behavior that makes the attack different from Golden Tickets, and the service-account hardening steps that actually remove the opportunity.

How the Silver Ticket Attack Works

Kerberos normally relies on the Key Distribution Center to issue service tickets after a client presents a valid TGT. A Silver Ticket breaks that expected flow by forging the service ticket directly.

MITRE's Silver Ticket technique page states that adversaries who have the password hash of a target service account may forge Kerberos ticket granting service tickets, also known as service tickets. Unlike Golden Tickets, these tickets are limited to a particular resource and the system hosting that resource. But unlike a Golden Ticket, the attacker can create the ticket without interacting with the KDC.

That design difference has two direct consequences:

the forged ticket is scoped to one service principal rather than the whole realm
detection is often harder because the normal domain-controller issuance path is missing

Why the service account secret matters

A Silver Ticket works because the attacker knows the key used by the target service account. That secret may come from:

direct credential dumping after compromise
extraction of a service account password hash from a server where the service runs
Kerberoasting: How Attackers Crack Service Account Passwords, which MITRE explicitly names as one path for obtaining the target service hash

If the attacker cannot obtain the target service secret, they cannot forge a usable Silver Ticket for that service.

Why some forged tickets still reach the service path

Microsoft's Kerberos documentation shows that PAC handling depends on the application model and trust assumptions. In particular, Microsoft notes that PAC validation can be optional for a self-contained application.

That nuance matters, but it should not be overstated. The core Silver Ticket prerequisite is still possession of the target service account secret and a target service path willing to accept the forged ticket. PAC behavior is one part of the service-side processing model, not a complete explanation for every successful forged-ticket case.

Silver Ticket vs. Golden Ticket, Kerberoasting, and Pass-the-Ticket

These terms are often mixed together. They should not be.

Silver Ticket: forged service ticket for a specific service after obtaining the service account secret
Golden Ticket: forged TGT based on the krbtgt secret, which gives much broader domain-wide impact. See Golden Ticket Attack: The Keys to Your Kingdom
Kerberoasting: request legitimate service tickets from the KDC and crack them offline to recover service account secrets. See Kerberoasting: How Attackers Crack Service Account Passwords
Pass-the-Ticket: replay or reuse a real Kerberos ticket that was stolen rather than forged

Silver Ticket often sits after another prerequisite attack. Kerberoasting or credential dumping gets the service account secret. Silver Ticket turns that secret into unauthorized service access.

Why Silver Tickets Still Matter

Silver Tickets are less famous than Golden Tickets, but they remain important because they target a common enterprise weakness: poorly managed service account secrets.

Service accounts are often broader and older than teams think

Service accounts tend to survive for years, back multiple applications, and accumulate SPNs, local rights, and operational exceptions. That creates exactly the kind of long-lived secret an attacker wants.

The attack is quieter than a normal KDC-issued service flow

MITRE highlights the most important detection problem directly: forged Silver Tickets can be created without interacting with the KDC. That means some of the usual domain-controller visibility defenders rely on is missing from the moment the ticket is forged.

Weak service account hygiene still exists

Microsoft's guidance on managed service accounts exists because manual service-account password management is error-prone. A normal user account running a service is still one of the easiest places to accumulate stale keys, weak rotation, and inconsistent encryption settings.

Legacy Kerberos encryption still increases risk

Microsoft's current Kerberos hardening guidance continues to phase out RC4 and recommends auditing and remediating accounts that still depend on it. That is relevant because service accounts with old encryption posture are often the same accounts that remain badly managed operationally.

Preconditions for a Successful Silver Ticket Attack

A Silver Ticket is not a one-click Kerberos trick. Several conditions have to line up.

1. The attacker must obtain the target service account secret

This is the non-negotiable prerequisite. MITRE explicitly says the attacker needs the password hash of the target service account. Common acquisition paths are credential dumping and Kerberoasting.

2. The target service must rely on that service principal

The forged ticket has to match a real service identity the host accepts. The scope is therefore narrower than a Golden Ticket.

3. The forged ticket has to be accepted by the service path being targeted

Microsoft's PAC documentation shows why service-side processing can vary by application design. That nuance is useful for understanding the protocol, but it does not remove the need for the attacker to target the right service principal with the right secret.

4. The service account is valuable enough to matter

A forged ticket for a low-value service is still a problem, but the real concern is a service account tied to a sensitive application, administrative workflow, or privileged host.

5. The environment still has weak service-account hygiene

Long-lived user-based service accounts, missing gMSA adoption, weak rotation, over-privileged service accounts, or old RC4-only keys make Silver Ticket prerequisites more realistic than they should be.

The Attack Chain

A practical Silver Ticket intrusion chain usually looks like this.

Step 1 - Identify a service account worth targeting

The attacker maps SPNs, services, and systems to find a service principal that would give useful access if compromised.

Step 2 - Obtain the service account hash or key

The attacker gets the secret through dumping, offline cracking after Kerberoasting, or another credential-access path.

Step 3 - Forge the service ticket offline

Using the service secret, the attacker creates a Kerberos service ticket for the chosen service principal.

Step 4 - Present the forged ticket directly to the service

This is where Silver Ticket diverges from the normal Kerberos path. MITRE notes that the forged ticket can be used without interacting with the KDC.

Step 5 - Use the resulting access within the service scope

The access is narrower than a Golden Ticket, but it can still be operationally serious if the service runs on a sensitive host, exposes administrative functions, or enables lateral movement.

This is also why Silver Ticket belongs in the same review as Active Directory Attack Paths to Domain Admin. Even a scoped service ticket can become part of a much larger chain.

Detection

Detection for Silver Tickets is difficult for one simple reason: the attacker may never ask the KDC for the service ticket they use.

The right model is therefore anomaly detection plus prerequisite detection, not a single event ID that magically proves the case.

Look for service-ticket use that does not line up with expected KDC activity

MITRE's 2025 Silver Ticket detection strategy describes one of the best high-level approaches: look for anomalous service ticket activity, including activity that appears without expected KDC validation patterns.

Operationally, that means you should investigate cases where:

a service account is used on a host or resource outside its normal scope
the target service sees Kerberos-authenticated activity that does not line up cleanly with expected KDC-side service ticket issuance patterns
malformed or unusual fields appear in logon or ticket-processing data

This is not a trivial rule to implement. It depends on having a baseline for which hosts and resources each service account should actually touch.

Monitor the prerequisite attacks, not only the forged ticket itself

MITRE's detection strategy also points directly at suspicious LSASS access and credential dumping as useful data sources. That matters because the service account secret usually has to be stolen before the Silver Ticket exists.

If you already monitor:

suspicious access to LSASS
credential-dumping behavior
Kerberoasting: How Attackers Crack Service Account Passwords
unusual service-account authentication patterns

then you are much closer to catching the real attack chain than if you only search for one final forged ticket indicator.

Use Kerberos event context carefully

Microsoft's Kerberos guidance on event 4769 is still useful because it documents that a normal service ticket request is visible at the KDC as a service ticket event. That makes 4769 valuable context for normal Kerberos activity.

For Silver Ticket investigations, the point is not "alert when 4769 is missing" in the abstract. The point is to understand that a forged service ticket may not follow the same KDC issuance path as a legitimate service ticket. Any detection based on this idea needs baseline context, not a simplistic one-event rule.

Watch for service accounts outside their expected blast radius

MITRE's Silver Ticket detection strategy specifically calls out access attempts using service accounts outside expected hosts or resources. This is one of the most operationally useful detections because it is understandable to defenders and tied to real service-account scope.

Correlate with privileged follow-on activity

If the forged ticket reaches a service with administrative impact, the next signals may show up as:

unusual access to admin functions on the target application
logons to the service host from identities that should not be present there
downstream privileged actions after the ticket is accepted
surrounding anomalies already covered in Active Directory Monitoring: Security Event IDs That Matter

Remediation

Silver Ticket mitigation is mostly service-account hardening. If the attacker cannot obtain a reusable service account secret, they cannot forge the ticket.

1. Move eligible services to gMSAs

Microsoft's guidance on group Managed Service Accounts is the clearest primary-source mitigation here.

Microsoft documents that gMSAs:

let Windows handle password management for service accounts
periodically change the keys used for the account
let member hosts obtain current and previous password values from the domain controller
reduce the need for administrators to manage password synchronization manually

That directly addresses one of the biggest Silver Ticket prerequisites: static or poorly managed service-account secrets.

2. Configure AES support for managed service accounts

Microsoft's gMSA documentation is explicit: managed service accounts depend on Kerberos supported encryption types, and you should always configure AES for MSAs. If the host is configured not to support RC4, authentication fails, which is exactly why you need to make the encryption posture explicit rather than assuming it.

3. Reset old service account passwords to generate AES keys

Microsoft's Kerberos RC4 remediation guidance explains that accounts created before AES support may be missing AES keys if their passwords were never reset after AES support was added. Microsoft is explicit that changing the account password generates these keys.

This matters because many legacy service accounts are old enough to carry exactly that problem.

4. Reduce RC4 dependence where possible

Microsoft's current guidance continues to phase out RC4 and provides specific auditing and remediation steps for accounts still using it. That does not make Silver Ticket impossible by itself, but it removes one more legacy weakness from service-account Kerberos handling and improves the overall Kerberos baseline. It also pairs directly with AS-REP Roasting: Harvesting Hashes Without Credentials and other Kerberos hardening work.

5. Minimize service account privilege and scope

A forged ticket is only as useful as the service account behind it. Even if the service account has to exist, it should not also carry unnecessary local admin rights, privileged group membership, or broad access to unrelated systems.

6. Inventory SPNs and service-account ownership

You cannot defend service account secrets you do not understand. A real hardening program should know:

which SPNs map to which accounts
which hosts are expected to use those accounts
who owns each service account operationally
whether the account can be moved to gMSA
whether the account still depends on RC4 or legacy settings

That is why How to Audit Active Directory Security: Practical Checklist for Internal Teams belongs next to this topic. If you are scaling that review across the estate, Active Directory Security Audit Tools: What to Compare Before You Choose is also relevant.

7. Treat credential dumping and Kerberoasting as direct Silver Ticket precursors

If an attacker can dump a service account secret or crack one offline, the Silver Ticket path is now open. That is why this article should be read together with Kerberoasting: How Attackers Crack Service Account Passwords, Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse, and Golden Ticket Attack: The Keys to Your Kingdom.

Validation After Hardening

Do not close Silver Ticket risk because you changed one password once. Validate the service-account model directly.

confirm which service principals still use traditional user accounts rather than gMSAs
confirm whether each service account has AES keys and whether RC4 is still in use
verify msDS-SupportedEncryptionTypes where relevant and compare it with the actual Kerberos usage observed on domain controllers
review event 4769 data on KDCs to understand which service accounts are still requesting service tickets and which encryption types they use
verify that sensitive services are not backed by stale, shared, or undocumented service identities
confirm service accounts are not granted broader privileges than the service actually needs

The real success condition is not just better Kerberos policy. It is that compromise of one service account no longer yields a stable, reusable secret with broad operational value.

There is no exact Silver Ticket vulnerability type in the current catalogue, so the closest useful findings are the prerequisites and surrounding Kerberos weaknesses that make the technique practical.

The most relevant related findings are:

KERBEROASTING_RISK, because offline recovery of a service account secret is one of the clearest Silver Ticket precursors
KERBEROS_RC4_FALLBACK, because legacy Kerberos encryption posture often overlaps with the same unmanaged service-account population
privileged or over-scoped service accounts that make a forged service ticket far more damaging
surrounding attack-path conditions already captured in Active Directory Attack Paths to Domain Admin

That is the right mental model: Silver Ticket is a forged-ticket technique, but its real fix surface is service-account hygiene.

If you are reviewing Silver Ticket risk, also review Golden Ticket Attack: The Keys to Your Kingdom, Kerberoasting: How Attackers Crack Service Account Passwords, AS-REP Roasting: Harvesting Hashes Without Credentials, Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse, Active Directory Monitoring: Security Event IDs That Matter, Active Directory Attack Paths to Domain Admin, How to Audit Active Directory Security: Practical Checklist for Internal Teams, and Active Directory Security Audit Tools: What to Compare Before You Choose.

Silver Ticket Attack: Forged Kerberos Service Tickets in Active Directory