Silver Ticket Attacks: Complete Guide for CISSP Candidates

Silver Ticket attacks are the quiet member of the Kerberos attack family. They do not seize the domain, they do not trip the alarms a domain admin compromise usually trips, and in most environments they leave no trace on any domain controller at all. By forging service tickets with a stolen service account hash, an attacker gains durable access to a specific application, database, or file share while the authentication infrastructure remains entirely unaware.

For CISSP candidates the attack teaches a design lesson the exam keeps returning to: a control you never audit is a control you do not have. Kerberos services validate tickets locally and, by default, never ask the KDC whether the ticket was genuinely issued.

This is the third article in the Kerberos attack chain series. It assumes the six step flow from the Kerberos authentication guide, because the whole attack is defined by which of those steps it skips.

What is a Silver Ticket attack?

Start with the normal process. A user requests a Ticket Granting Ticket from the Authentication Server in steps 1 and 2, uses that TGT to request a service ticket from the Ticket Granting Server in steps 3 and 4, and presents the service ticket to the target service in steps 5 and 6. Every one of those decisions is made or validated by the Key Distribution Center.

A Silver Ticket attack forges the service ticket outright, using a compromised service account password hash. The attacker skips straight to step 5 and presents a ticket that the KDC never issued and has never seen.

Key concept: the counterfeit room key

A Golden Ticket is a forged master key to the whole building. A Silver Ticket is a counterfeit key to one room. It will not open anything else, but the lock on that door has no way to tell it is counterfeit, and nobody at reception is notified that the door was opened. When an attacker holds a service account’s password hash, they can forge tickets for that service indefinitely, and those tickets look completely legitimate to it.

Why “silver”?

The name captures both value and precision. Where Golden Tickets reach the whole domain, Silver Tickets are deliberately targeted:

• They aim at high value services such as databases, file servers, and mail infrastructure
• They persist until that service account’s password changes
• They operate below the visibility of standard Kerberos monitoring
• They need far fewer privileges than a Golden Ticket

CISSP Exam Note

Silver Ticket persistence ends when the specific service account password is changed. That single sentence explains why service account password rotation is a control the exam expects you to reach for. Contrast it with Golden Tickets, which persist until the krbtgt password has been reset twice, and the two attacks become easy to tell apart in a scenario question.

Prerequisites and attack path

Silver Tickets need less than Golden Tickets, which is what makes them common. The core requirement is the password hash of the target service account, and obtaining that does not require domain administrator rights. The attacker also needs the service’s Service Principal Name and the domain SID, both of which any authenticated domain user can look up. That low barrier is the point: a Silver Ticket is often established long before the attacker gets anywhere near a domain controller.

How service account hashes get compromised

• Kerberoasting: request service tickets for accounts with SPNs and crack the encrypted portion offline to recover the password. This is the most common route, and the next article in this series.
• Local credential extraction: compromise a server where the service runs and pull credentials from memory, the registry, or configuration files.
• Password spraying: service accounts are frequently exempted from lockout policy, precisely because a locked out service account breaks an application.
• Application weaknesses: SQL injection and similar flaws often surface database credentials sitting in plaintext connection strings.

High value target services

Attackers choose targets by the value of what sits behind them:

• SQL Server databases: business and customer data, often the reason the attacker is there at all
• Web application service accounts: access to user data and application logic
• File shares over CIFS and SMB: confidential documents, and a common route to further credentials
• Exchange services: email and calendar content, reconnaissance gold as well as sensitive in itself
• Custom enterprise applications: proprietary data, and usually the least monitored of the lot

Important

Service Principal Names uniquely identify service instances within the Kerberos realm, and the forged ticket must carry the right one. Attackers enumerate SPNs with ordinary directory queries using tools such as PowerView or BloodHound. Note that computer accounts hold SPNs too, so a stolen machine account hash lets an attacker forge tickets for services running on that host, including its file shares.

How Silver Ticket attacks work

The attack runs in three steps.

Step 1: Service account reconnaissance

The attacker identifies valuable service accounts and their Service Principal Names, then gathers what the forgery needs: the service account name and domain, the SPN, the account’s password hash, and the location of the service itself.

None of this is unusual traffic. Querying Active Directory for accounts with SPNs is something any domain member is entitled to do.

Step 2: Service ticket forgery

The ticket itself is a more focused piece of work than a Golden Ticket, but no less effective against its target:

• Create a service ticket naming a chosen user identity
• Set a realistic validity period so the ticket does not stand out
• Include group memberships that the target service will honour
• Sign the ticket with the compromised service account hash

CISSP Exam Note

Golden Tickets can claim any group in the domain because domain controllers act on the claims inside the TGT. Silver Tickets are limited to what the target service itself recognises and enforces. The forged ticket is signed with that service account’s hash, so it is cryptographically valid to that service and worthless everywhere else.

Step 3: Direct service access

The forged ticket goes straight to the service at step 5. Steps 1 through 4 never happen. The service decrypts the ticket with its own key, finds it valid, reads the identity and group claims inside, and grants access accordingly.

This works because Kerberos services are designed to trust a ticket they can decrypt. The authorisation data in a ticket sits in a structure called the Privilege Attribute Certificate, and although the protocol lets a service ask a domain controller to validate it, most historically did not, because it costs a round trip on every connection. Microsoft has been progressively hardening PAC signature validation in response to exactly this attack, but treat “the service validates locally and asks nobody” as the default mental model.

Key concept: the KDC bypass

Four of the six steps are skipped. Everything the KDC would normally do, authenticate the user, authorise the request, record both, is bypassed. This is the single most important fact about Silver Tickets and the reason they are so hard to find.

Detection challenges and indicators

Why Silver Tickets are harder to detect

Because the attack bypasses the Ticket Granting Server, no TGS-REQ or TGS-REP events are ever written: those are steps 3 and 4, and they did not occur. The forged ticket appears at step 5, at the service, where most organisations have no authentication logging at all.

Traditional Kerberos monitoring is built on domain controller logs. Against a Silver Ticket those logs are not merely incomplete, they are empty. And because the ticket is cryptographically valid, nothing about it looks wrong to the service either.

The critical visibility gap

Many organisations have no service level authentication monitoring at all. That is not a tuning problem, it is a missing control, and it is the blind spot this attack sits in. On the exam, a scenario describing unexplained access to one application with clean domain controller logs is pointing straight at this gap.

Key detection indicators

• Service access with no corresponding TGS request: correlate service logons against KDC ticket issuance. Access with no matching ticket request is the defining signature.
• Unusual service account authentication patterns: access from several locations at once, or outside plausible working hours
• Suspicious ticket timing: creation and usage times that do not fit a normal authentication sequence
• Access from unexpected sources: connections from network segments or identities with no business reason to reach the service

Advanced detection techniques

• Service level authentication monitoring: log and forward authentication events from the applications themselves. This is the control that closes the gap.
• Network traffic analysis: identify sessions reaching a service without the Kerberos exchanges that should have preceded them
• Behavioural analysis: baseline normal service usage per identity and alert on deviation
• Honeypot services: a decoy service with an attractive SPN that no legitimate user should ever touch. Any authentication against it is worth investigating immediately.

Mitigation and defence strategies

Immediate response: reset the service account password

Changing the compromised service account’s password invalidates every forged ticket for that service at once. The order of work matters, because doing this carelessly takes the application down:

1. Identify the affected service accounts and every service depending on each one
2. Coordinate downtime with the application owners before touching anything
3. Reset the passwords on the suspected accounts
4. Update every service configuration that stored the old password, or the application will fail to start

Preventive controls

• Managed Service Accounts: let Active Directory own the password so no human ever sets or knows it
• Regular password rotation: shrinks the window in which a stolen hash remains useful
• Privilege minimisation: a service account should reach only what its service needs, and should never be a domain admin
• Delegation restrictions: unconstrained delegation turns one compromised service into a route to many others

Best practice

Deploy Group Managed Service Accounts wherever the application supports them. A gMSA password is long, random, machine generated, and rotated automatically by default every 30 days, and it can be shared across multiple servers. It removes the weak static password that makes both Kerberoasting and Silver Ticket persistence practical.

Advanced protection measures

Privileged Access Management brings service credentials under controlled, recorded access rather than leaving them in configuration files. Just in time access replaces standing credentials with temporary ones. Network segmentation caps what a compromised service can reach even when the forgery succeeds.

Organisational controls

Technical controls need governance behind them. Maintain an accurate service account inventory: purpose, owner, privileges, and rotation status for every one. You cannot rotate or retire accounts you cannot list, and the accounts nobody remembers are reliably the ones with a password from 2014. Regular assessments find weak and unnecessary service accounts, and incident response procedures should already name the application owners you will need to call.

Silver Ticket versus Golden Ticket

Key concept: choosing defence priorities

Silver Tickets need less privilege but offer narrower access, which suits a targeted attack on one valuable system. Golden Tickets need far more privilege and unlock everything, but at least leave service ticket requests behind. A defence programme that only watches domain controllers is well positioned against one of these attacks and blind to the other.

Conclusion

Silver Tickets exploit a trust decision built into Kerberos: a service accepts any ticket it can decrypt. Steal one service account’s key and you can manufacture that ticket at will, for as long as the password stands. The narrow scope makes the attack less dramatic than a Golden Ticket, but the missing audit trail often makes it more durable.

For the exam, hold on to four things: it forges service tickets rather than TGTs, it requires only a service account hash, it bypasses the KDC and therefore produces no domain controller logs, and it ends the moment the service account password changes.

Recognising Silver Tickets in a scenario means noticing what is absent from the evidence rather than what is present, a harder habit than it sounds. The LSM CISSP practice tests are written to exercise exactly that reasoning across Domain 5.

Quick reference for the CISSP exam

Core concepts

• Silver Ticket: a forged Kerberos service ticket built with a compromised service account hash. See the Kerberos glossary entry for the underlying protocol.
• KDC bypass: the attack skips steps 1 to 4 and presents the forged ticket directly at step 5
• Service specific access: unlike a Golden Ticket, it reaches only the targeted service

Attack requirements

• Service account password hash: obtained via Kerberoasting, credential extraction, or password attacks
• Service Principal Name: identifies the target service within the realm
• Domain SID: the security identifier the forged ticket must carry

Detection challenges

• No KDC logs: TGS-REQ and TGS-REP events are never generated because steps 3 and 4 are bypassed
• Cryptographically valid: the forged ticket is indistinguishable from a legitimate one to the target service
• Service level monitoring required: domain controller monitoring alone cannot see this attack

Key mitigations

• Managed and Group Managed Service Accounts: automatic password rotation, by default every 30 days for gMSAs
• Service account password reset: immediately invalidates every existing Silver Ticket for that service
• Service level authentication monitoring: log authentication at the applications themselves
• Honeypot services: detect unauthorised access attempts against a decoy SPN

Exam tips

• Silver Tickets target one service, Golden Tickets grant domain wide access
• A common mistake is assuming KDC logs can detect Silver Tickets. They cannot, because the KDC is bypassed.
• Silver Tickets need less privilege than Golden Tickets but reach far less
• Persistence ends with a service password change for Silver, and only after a double krbtgt reset for Golden