How to detect Silver Ticket attacks

Threat snapshot

A Silver Ticket is a forged Kerberos service ticket. Where a Golden Ticket forges a TGT and can impersonate any user against any service in the domain, a Silver Ticket forges a TGS directly, granting persistent authenticated access to one specific service on one specific host. The scope is narrower, but the stealth advantage is significant: forging a TGS does not require contacting the KDC. The entire attack happens offline and then locally, with no network traffic to the domain controllers that would generate Kerberos authentication events.

To forge a Silver Ticket, the attacker needs the NTLM hash of the service account that runs the target service. For machine account services such as CIFS, HOST, or RPCSS running on a domain-joined computer, this means the machine account hash. For database services, web services, or application services running under dedicated service accounts, it means that service account's hash. These hashes are available to an attacker who has performed DCSync, dumped LSASS on the target machine, or extracted credentials from the Active Directory database.

Once forged, the Silver Ticket is presented directly to the target service. The service validates it using its own key (derived from its account hash) without consulting the KDC. A valid KDC signature is not present in the ticket, which is the forensic anomaly that modern Kerberos implementations can detect, but which most environments do not monitor for. The result: the attacker authenticates to the target service as any domain user they choose, including domain administrators, with the session appearing entirely legitimate from the service's perspective.

Silver Ticket attacks, at a glance

How Silver Ticket attacks work

A Silver Ticket attack has two phases: service account hash acquisition, and ticket forging followed by service access. The diagram below illustrates both phases and the critical difference between legitimate and forged Kerberos service authentication.

Phase 1: Acquiring the service account hash

A Silver Ticket requires the NTLM hash of the account whose key is used to encrypt the target service ticket. For Windows built-in services such as CIFS (file sharing), HOST (remote management), RPCSS, HTTP, or MSSQL, this is typically the machine account hash (machinename$). For application services running under dedicated service accounts, it is that account's hash. The attacker obtains this hash via one of three routes: DCSync using Mimikatz's lsadump::dcsync command to replicate the hash directly from Active Directory (requires domain admin or replication rights), LSASS memory dump on the target machine or a DC to extract cached hashes, or Kerberoasting which requests a TGS for service accounts with SPNs and then offline-cracks it to recover the cleartext password and derive the NTLM hash.

Log signals for hash acquisition: Windows Security Event 4662 (operation performed on AD object) with replication GUIDs for DCSync. Sysmon Event 10 (process accessed) with lsass.exe as the target for LSASS dumping. Windows Security Event 4769 (TGS request) with RC4 encryption type for Kerberoasting. Sysmon Event 1 for Mimikatz or Rubeus process creation.

Phase 2: Forging and using the ticket

With the hash in hand, the attacker uses Mimikatz's kerberos::golden command (despite the name, it also forges Silver Tickets when the /service parameter is specified) or Rubeus's silver command to create a forged TGS. The ticket specifies the target service (e.g., cifs/fileserver01.domain.com), the impersonated user (typically Administrator or a domain admin), and is signed with the service account's hash. When the ticket is injected into the current session using /ptt (pass-the-ticket), the attacker can access the target service as the impersonated user.

The critical forensic property is what the forged TGS does not contain: a valid KDC Privilege Attribute Certificate (PAC) signature. Modern Windows DCs running in PAC validation mode can detect this, but this validation is not universally enabled. Environments that do not have PAC validation enforced have no service-side protection against Silver Tickets. Log360's detection focuses on the tooling layer (Mimikatz and Rubeus process creation and file artifacts) and the network anomaly layer (Kerberos service authentication that bypasses the normal TGT exchange pattern).

Log signals for ticket use: Sysmon Event 11 for .kirbi file creation in user-accessible paths (Mimikatz writes the forged ticket to disk when using the /ticket parameter). Windows Security Event 4624 with logon type 3 (network) for successful service access. The absence of corresponding Event 4768 (TGT request) or Event 4769 (TGS request) from the KDC for the same client and timeframe is the KDC-bypass anomaly that the Uncommon Outbound Kerberos Connection rule targets.

KrbRelay and KrbRelayUp: Kerberos service ticket relay

KrbRelay and KrbRelayUp are Kerberos relay tools that coerce SYSTEM-level Kerberos authentication from a Windows machine and relay it to a local or remote service to escalate privileges or gain unauthorized service access. They leverage the same fundamental property as Silver Tickets: a valid Kerberos service ticket can be obtained without the user's knowledge or consent by coercing the SYSTEM account to authenticate. KrbRelayUp specifically targets local privilege escalation by relaying SYSTEM authentication to the local LDAP service to grant DCSync or other elevated rights. Both tools produce distinctive process creation signatures detectable via Sysmon Event 1.

Real-world campaigns

APT actors: Silver Tickets for persistent, low-noise lateral movement

Silver Tickets are preferred by sophisticated threat actors for post-compromise lateral movement to specific high-value services because they generate no KDC authentication events. An APT group that has obtained machine account hashes via DCSync can forge CIFS tickets for file servers or HTTP tickets for internal web applications and access those services repeatedly over extended periods without any authentication traffic appearing on domain controllers. This makes Silver Ticket-based access particularly difficult to detect via standard KDC log analysis and explains why detection must focus on the tooling layer and anomalous Kerberos network behavior rather than traditional authentication event monitoring.

Ransomware pre-deployment: CIFS Silver Tickets for mass file server access

Several ransomware operators have been documented using Silver Tickets targeting the CIFS service on file servers as part of their pre-encryption data staging phase. With a forged CIFS ticket for the file server's machine account, the attacker has authenticated access to all file shares on that server as an Administrator, without triggering any authentication events on the domain controllers. The files can be enumerated, staged for exfiltration, or directly targeted for encryption using this access. The absence of corresponding KDC events for what appears to be a successful file server authentication is the primary network anomaly indicator.

Attack technique reference table

Business impact

• No KDC visibility means standard Kerberos monitoring fails entirely. The defining property of Silver Ticket attacks is that the KDC is not involved in ticket validation. Every detection strategy that relies on KDC logs, Event 4768, or Event 4769 will see nothing. The only monitoring layers that catch Silver Tickets are endpoint-level tooling detection (Mimikatz, Rubeus process creation) and network anomaly detection for Kerberos service presentations without corresponding TGT requests.
• Persistent service-specific access that survives password resets. A Silver Ticket forged from a machine account hash remains valid until the machine account password is rotated, which by default happens every 30 days automatically. During that window, the attacker has persistent access to all services on that machine. Rotating domain admin passwords, krbtgt passwords, or even the service account's AD password does not invalidate a Silver Ticket already in use, because the ticket is validated by the service using its own cached key, not by querying AD.
• Targeted access to high-value services. Silver Tickets can target any Kerberos-enabled service: CIFS for file access, HTTP for internal web applications, MSSQL for database access, HOST for remote desktop sessions, RPCSS for remote procedure calls. An attacker with the hash for a database server's machine account has authenticated SQL access to that server as any user they choose. The specificity of targeting makes Silver Ticket attacks harder to detect via volume-based anomaly detection because access volume may match normal patterns.
• Compliance and breach assessment complexity. Because Silver Ticket access generates no KDC authentication events and presents as a legitimate service session from the service's perspective, determining the full scope of what an attacker accessed using a Silver Ticket requires endpoint-level forensic analysis of the affected service's logs rather than centralized KDC or domain controller log review. This significantly complicates breach scope determination and extends the time required for accurate incident assessment.

Detecting Silver Ticket attacks with Log360

Log360's seven detection rules for Silver Ticket attacks cover three distinct detection layers. The first layer catches the tooling used to forge tickets (Mimikatz execution and Kirbi file creation, Rubeus execution). The second layer catches the relay tools that obtain service tickets via coercion (KrbRelay, KrbRelayUp). The third layer catches the behavioral anomaly of Kerberos service authentication that bypasses normal KDC interaction (Uncommon Outbound Kerberos Connection). For endpoint-based rules, Sysmon must be deployed on domain-joined endpoints with process creation (Event 1) and file creation (Event 11) logging enabled and forwarding to Log360.

Ticket forging tool detection

Kerberos relay tool detection

Anomalous Kerberos network behavior

Attack chain visibility

The two sequences below show what Silver Ticket attacks look like in the logs, covering both the Mimikatz-based and Rubeus-based forging paths. The defining feature in both sequences is what is absent: no Event 4768 or 4769 from the KDC corresponding to the service access.

Sequence A: Mimikatz Silver Ticket against file server CIFS service

Sequence B: KrbRelayUp local privilege escalation

Investigation playbook

Silver Ticket investigations are complicated by the absence of KDC logs. The investigation must be reconstructed from endpoint-level evidence: the tooling artifacts (Mimikatz/Rubeus process creation, .kirbi files), the network anomaly signals from the Uncommon Outbound Kerberos Connection rule, and the service-level access logs on the targeted hosts.

Step 1: Triage - identify the detection layer and scope

Step 2: Identify which service accounts and hashes are compromised

• If Mimikatz DCSync commands were detected, identify all accounts whose hashes were requested from the Event 4662 records on domain controllers. Each account whose hash was extracted should be treated as compromised for Silver Ticket purposes: the attacker can forge service tickets for any service running under those accounts.
• If LSASS dumping was detected (Sysmon Event 10 targeting lsass.exe), identify all accounts with active sessions on the compromised host at the time of the dump. Those accounts' hashes were in LSASS memory and should be treated as extracted.
• Check whether machine account hashes for high-value servers (file servers, database servers, domain controllers) were included in the scope of any DCSync or LSASS dump operation. Machine account hashes enable Silver Tickets for CIFS, HTTP, HOST, RPCSS, and other built-in services on those machines.
• Query the Uncommon Outbound Kerberos Connection alerts to identify which specific services have already been accessed using Silver Tickets. Each anomalous Kerberos connection to a service that lacks corresponding KDC records represents confirmed Silver Ticket access to that service.

Step 3: Investigate using the Incident Workbench

• Click on the affected hostname or compromised account in the alert to open the Incident Workbench. Use the Process analytics tab on the host where Mimikatz, Rubeus, or the relay tools were detected. The process tree shows what spawned the attack tool, providing the prior compromise chain that gave the attacker access to the machine.
• Use the User analytics tab for any domain accounts impersonated in Silver Ticket sessions. UEBA anomaly scores will spike for accounts that are simultaneously showing normal activity on their assigned workstations and Silver Ticket-based access to services from a different source IP.
• Use Advanced Threat Analytics on external IPs involved in any C2 activity identified from the process tree to pull threat feed risk scores and confirm the attack infrastructure context.
• Save the Incident Workbench session to an incident. Silver Ticket incidents almost always represent a deeper compromise than the initial alert suggests; the saved session documents the scope of the investigation for stakeholder reporting.

Step 4: Scope the forged ticket exposure window

• Identify the time of earliest Mimikatz or Rubeus detection. Any service access from the attack source IP to high-value services after that time should be reviewed as potentially Silver Ticket-based, even if no Kerberos anomaly rule fired for it.
• Review service-level logs on each targeted host for access attributed to high-privilege accounts (Administrator, domain admin accounts) from the attack source IP or from unexpected sources. These access events are the forensic record of what the attacker did using the Silver Ticket access.
• Determine whether any .kirbi files were exfiltrated from the compromised machine. .kirbi files can be used from any machine with network access to the target service; if the file was exfiltrated, the Silver Ticket access window extends beyond the original compromised host.

Step 5: Collect evidence and build the timeline

• Export Sysmon Event 1 (process creation with full command line), Event 10 (LSASS access), and Event 11 (file creation of .kirbi files) from the compromised host for the attack window.
• Export Windows Security Event 4662 from domain controllers for DCSync operations in the attack window. These records document which account hashes were extracted.
• Export service access logs from targeted hosts showing access by high-privilege accounts from the attack source IP during the Silver Ticket window.
• Export the Incident Workbench session and UEBA risk score history as the evidence record for incident documentation and breach assessment.

Response and remediation

Immediate containment

• Rotate all service account passwords and machine account passwords for any account whose hash was extracted. Service account password rotation is straightforward. Machine account password rotation requires forcing a password change on the machine account via Reset-ComputerMachinePassword on the affected machine, which invalidates any outstanding Silver Tickets forged using the old hash.
• Rotate the krbtgt password twice as part of Silver Ticket remediation when DCSync was confirmed. This ensures no outstanding Golden Tickets remain valid, and it forces re-issuance of all TGTs, which invalidates any pass-the-ticket sessions derived from legitimate TGTs that may have been injected alongside Silver Tickets.
• Isolate the host where Mimikatz or Rubeus ran from the network immediately. The machine is compromised and is the attacker's operational platform for the current phase of the attack. Isolation prevents the use of already-forged tickets still in the attacker's possession.
• Delete any .kirbi files identified on compromised or accessible machines. .kirbi files are portable and reusable; their presence on any machine means that machine or any machine it can reach has the material for Silver Ticket replay.

Response actions by trigger

Hardening

• Enable PAC validation on all domain controllers. Setting the ValidateKdcPacSignature registry value to 1 on domain controllers enables server-side validation that TGS tickets include a valid KDC PAC signature. Forged Silver Tickets do not have this signature and will be rejected. This is the most direct preventive control against Silver Ticket attacks but requires testing in environments with legacy applications that may not produce valid PAC signatures.
• Use Group Managed Service Accounts (gMSAs) for all service accounts. gMSAs use 240-character randomly generated passwords that rotate automatically, making offline cracking and hash reuse for Silver Tickets impractical. Replacing traditional service accounts with gMSAs eliminates the hash acquisition step for those accounts.
• Enable Credential Guard on domain-joined endpoints. Windows Defender Credential Guard stores NTLM hashes and Kerberos tickets in a virtualization-based security enclave that is inaccessible to Mimikatz's sekurlsa module, blocking the LSASS dump hash acquisition path for Silver Tickets.
• Implement a tiered administration model that prevents domain admin credentials from ever being cached on workstations or application servers. If domain admin hashes are never present in LSASS outside of designated Tier 0 management machines, the scope of potential Silver Ticket targets is significantly reduced.

False positive tuning