Silver Ticket attacks occupy a frustrating position in the detection landscape. Golden Ticket attacks — where attackers forge a Ticket Granting Ticket using the krbtgt hash — generate event traffic at the domain controller and have well-established detections. Silver Tickets are quieter. An attacker who forges a service ticket using a compromised service account’s NTLM hash can authenticate to that specific service without any request ever reaching the domain controller. No TGS event. No KDC log entry. Just a logon event on the target service that looks, at first glance, like a legitimate session.

This guide covers what detection surface does exist, and how to build rules against it.

How Silver Tickets Work

When a legitimate user authenticates to a service via Kerberos, the flow is:

  1. Client requests a Ticket Granting Ticket (TGT) from the KDC — event 4768
  2. Client presents the TGT and requests a service ticket (TGS) — event 4769 at the DC
  3. The service ticket is encrypted with the target service account’s key (NTLM hash)
  4. Client presents the service ticket to the target service — event 4624 on the service host

Silver Ticket bypasses steps 1-3 entirely. The attacker already has the service account’s NTLM hash (from Kerberoasting, DPAPI credential theft, LSASS dump, or secretsdump against a DC). They use a tool like Mimikatz (kerberos::golden /service:<svc> /target:<host> /rc4:<hash>) to forge a service ticket locally. The forged ticket is presented directly to the target service.

Since the KDC is never consulted, events 4768 and 4769 never appear at the domain controller. What you get is event 4624 on the target host, showing a Kerberos logon, without any corresponding KDC activity.

The attacker can forge the Privilege Attribute Certificate (PAC) inside the ticket — claiming group memberships, including Domain Admin — or forge the ticket with a non-existent or expired user account that the service will accept because it trusts the ticket’s encryption rather than verifying the user’s current status.

Detection Opportunities

Silver Ticket detection is hard precisely because the primary evidence source — the KDC — is bypassed. What remains:

1. Logon without corresponding TGS request at the DC

If you collect event 4769 (TGS request) at domain controllers and event 4624 (logon type 3, Kerberos) at hosts, you can correlate them. A Kerberos logon on a host without a preceding 4769 at any DC within the expected window is anomalous. This is the theoretical ideal detection. In practice it requires high-confidence collection from all DCs and accurate time correlation. Noisy at scale, but high-value when the signal fires.

2. PAC validation failure (Event 4769 with failure code)

When the KDC receives a request to validate a PAC — which happens in some service configurations with PAC validation enabled — a forged PAC may produce validation failures. Event 4769 with result code 0x1F (no credentials are available in the security package) or unexpected failure codes can be indicative.

3. Anomalous ticket properties at the service host

Event 4624 with logon type 3 (network) using Kerberos auth, where the user account shows characteristics inconsistent with a real account — non-existent SPN, account that hasn’t been used in months, account from a foreign domain — is worth alerting on.

4. Microsoft Defender for Identity PAC validation alerts

MDI enables PAC validation on selected services and alerts on Silver Ticket use directly. If you have MDI deployed, the “Forged PAC” alert covers this. Not all environments have MDI, so rules remain relevant.

5. Kerberos ticket encryption type

Silver Tickets forged with RC4 (NTLM hash) will show encryption type 0x17 in event 4624. If your environment has mandated AES (0x12/0x11) across all service accounts and you see a Kerberos logon with RC4 encryption, that is worth investigating. Many legacy environments still allow RC4, limiting this signal.

6. Service ticket for non-SPN or unusual target

Mimikatz silver ticket creation requires specifying /service and /target. Commonly forged services include cifs, host, http, wsman, and ldap. Ticket usage for these services where the target machine isn’t in the expected set for that account, or where the service name doesn’t match a registered SPN, is anomalous.

Sigma Rules

Kerberos Logon Without Preceding TGS at DC (Correlation)

title: Kerberos Logon Without Corresponding TGS Request
id: b7f8a123-4d56-78ef-ab12-cd34ef567890
status: experimental
description: Detects a Kerberos network logon (type 3) on a host where no matching TGS request
             (4769) appears at the domain controller within the expected time window. Requires
             correlated alerting across DC and endpoint log sources.
references:
  - https://attack.mitre.org/techniques/T1558/002/
author: SOC Analyst Hub
date: 2026/08/06
tags:
  - attack.credential_access
  - attack.t1558.002
logsource:
  product: windows
  service: security
detection:
  kerberos_logon:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: 'Kerberos'
  filter_legitimate_tgs:
    # Requires external correlation: exclude events with matching TGS at DC
    # Implement via SIEM correlation rule, not pure Sigma
  condition: kerberos_logon
falsepositives:
  - Requires DC-level TGS correlation; standalone produces high FP rate
level: medium

RC4 Encryption Kerberos Logon Where AES Is Mandated

title: Kerberos Logon with RC4 Encryption in AES-Only Environment
id: c8e9b234-5e67-89fa-bc23-de45fa678901
status: experimental
description: Detects Kerberos authentication with RC4 encryption (0x17) where the environment
             policy mandates AES. Silver Tickets forged from NTLM hashes use RC4 by default.
author: SOC Analyst Hub
date: 2026/08/06
tags:
  - attack.credential_access
  - attack.t1558.002
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: 'Kerberos'
    KeyLength: 0  # RC4 shows 0 key length in some logging implementations
  filter_rc4_allowed:
    # Tune: exclude service accounts known to still use RC4
    SubjectUserName|startswith: 'excluded-svc-'
  condition: selection and not filter_rc4_allowed
falsepositives:
  - Legacy service accounts with RC4 still enabled
  - Applications not yet migrated to AES
level: high

Silver Ticket Forgery Tool Activity (Mimikatz Artifacts)

title: Mimikatz Silver Ticket Command Artifacts in Process Arguments
id: d9f0c345-6f78-90ab-cd34-ef56ab789012
status: experimental
description: Detects Mimikatz silver ticket creation via command-line artifacts. kerberos::golden
             with /service and /rc4 parameters is used for both Golden and Silver Ticket creation.
author: SOC Analyst Hub
date: 2026/08/06
tags:
  - attack.credential_access
  - attack.t1558.002
  - attack.t1558.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains|all:
      - 'kerberos::'
      - '/service:'
  selection_rc4:
    CommandLine|contains:
      - '/rc4:'
      - '/ntlm:'
  condition: selection and selection_rc4
falsepositives:
  - Authorized red team operations
level: critical

Suspicious CIFS or HOST Service Ticket for Non-Domain Machine

title: Kerberos Service Ticket for Unusual Target Host
id: e0a1d456-7a89-01bc-de45-fa67bc890123
status: experimental
description: Detects Kerberos logon where the service ticket target (WorkstationName or
             TargetServerName) doesn't match known domain-joined machines. May indicate Silver
             Ticket use against a non-existent or spoofed host.
author: SOC Analyst Hub
date: 2026/08/06
tags:
  - attack.credential_access
  - attack.t1558.002
  - attack.lateral_movement
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: 'Kerberos'
  filter_known_workstations:
    WorkstationName|endswith:
      - '.yourdomain.com'
      - '.yourdomain.local'
  condition: selection and not filter_known_workstations
falsepositives:
  - Legitimate cross-domain or external Kerberos authentication
  - Devices with non-standard naming conventions
level: medium

KQL for Microsoft Sentinel / Defender for Identity

Kerberos Logon RC4 Encryption Alert

SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where AuthenticationPackageName == "Kerberos"
| where KeyLength == 0  // RC4 logons may show 0 key length
| where SubjectUserName !endswith "$"  // filter machine accounts
| where TimeGenerated > ago(1h)
| summarize
    Count = count(),
    Accounts = make_set(TargetUserName),
    TargetHosts = make_set(Computer)
    by bin(TimeGenerated, 10m)
| where Count > 0
| project TimeGenerated, Count, Accounts, TargetHosts
| order by TimeGenerated desc

TGS Request Correlation — Kerberos Logon Without Preceding 4769

let TGS_requests = SecurityEvent
    | where EventID == 4769
    | where TargetUserName !endswith "$"
    | project DC_Time = TimeGenerated, ServiceName, TicketEncryptionType, TargetUserName, IpAddress;
let kerberos_logons = SecurityEvent
    | where EventID == 4624
    | where LogonType == 3
    | where AuthenticationPackageName == "Kerberos"
    | where TargetUserName !endswith "$"
    | project Logon_Time = TimeGenerated, TargetUserName, WorkstationName, Computer, IpAddress;
kerberos_logons
| join kind=leftanti (
    TGS_requests
    | where DC_Time between (ago(2h) .. now())
) on TargetUserName
| where Logon_Time > ago(1h)
| project Logon_Time, TargetUserName, WorkstationName, Computer
| order by Logon_Time desc

Unusual Encryption Type on Service Logon

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"  // RC4-HMAC
| where TargetUserName !endswith "$"
| where ServiceName !startswith "krbtgt"
| summarize
    Count = count(),
    Services = make_set(ServiceName),
    SourceIPs = make_set(IpAddress)
    by TargetUserName, bin(TimeGenerated, 1h)
| where Count > 2
| order by Count desc

Investigation Steps

When a potential Silver Ticket alert fires:

  1. Identify the service account. Which service account’s NTLM hash would be needed to forge this ticket? Check when that account last had its password rotated and whether its hash appears in any threat intelligence feeds.

  2. Check for prior credential theft. Was there recent LSASS access, Kerberoasting activity, or secretsdump-style operations that could have produced the service account hash? Correlate with EDR telemetry around the time the silver ticket was used.

  3. Identify the target service. Which service did the forged ticket target? If it’s CIFS on a file server, the attacker likely went for file access. If it’s HTTP or WSMAN, they may have targeted web applications or WinRM.

  4. Check lateral movement. Silver Ticket use is typically lateral movement, not initial access. If the ticket is valid, the attacker has been in the environment long enough to compromise a service account. Treat this as an indication that the initial access vector is upstream from this event.

  5. Engage MDI if available. Microsoft Defender for Identity has specific Silver Ticket detection logic that analyzes PAC validation patterns. If MDI is deployed, pull the alert timeline.

Tuning Notes

Silver Ticket detection generates significant false positives without environmental tuning. The RC4 encryption detection requires a mature environment where AES-only has been enforced and RC4 is actually abnormal — many environments still have legacy RC4 consumers that need to be baselisted. The TGS correlation approach requires comprehensive DC event collection and accurate clock synchronization, and even then will produce false positives from cross-forest authentication and legitimate Kerberos delegation scenarios.

Start with the Mimikatz artifact detection as a high-confidence, low-volume rule, then build toward the correlation approaches as you tune your event collection and baselines.