Detecting Golden Ticket and Silver Ticket attacks in Kerberos logs

Kerberos remains one of the most important identity protocols in Windows environments, which is why forged ticket abuse is so valuable to an attacker. Golden Ticket and Silver Ticket attacks both aim to bypass normal authentication controls by abusing trust in Kerberos tickets, but they do so in different ways and leave different traces. For a UK SME, the practical challenge is not understanding the theory alone, but building detections that work with the logs you actually have, the staff you actually have, and the time you can realistically spend on triage.

This article focuses on detection engineering rather than attack mechanics. It assumes you are working with Windows Event Logs, Active Directory, and a SIEM or XDR platform such as Microsoft Sentinel or Splunk. If you are still maturing your logging estate, it may help to review what security logs you actually need and why and retaining evidence and logs for investigations alongside this guidance.

What Golden Ticket and Silver Ticket attacks are

A Golden Ticket is a forged Kerberos Ticket Granting Ticket, usually created after an attacker has obtained the Kerberos service account key material for the domain, commonly the KRBTGT account. Because the ticket is forged rather than issued through the normal path, the attacker can present it to request service tickets for many resources without re-authenticating in the usual way. From a defender’s perspective, this is dangerous because the ticket can be valid for a long time and can impersonate high-privilege identities.

A Silver Ticket is a forged service ticket for a specific service, such as CIFS, HOST, HTTP, or MSSQL. It does not require the attacker to talk to the Key Distribution Centre for that service ticket, which means the domain controller may not see the same issuance pattern you would expect from legitimate Kerberos activity. That makes Silver Ticket detection more dependent on service-side evidence and correlation with host telemetry.

How forged Kerberos tickets differ from normal authentication

In a normal flow, a user authenticates to the Key Distribution Centre, receives a Ticket Granting Ticket, then requests service tickets as needed. The domain controller logs the issuance and renewal activity, and the target service sees the resulting access. With forged tickets, part of that chain is missing or distorted. The ticket may have unusual lifetime values, odd encryption characteristics, or an account context that does not fit the surrounding activity.

The key point for detection is that you are rarely looking for one perfect event. You are looking for inconsistencies across identity, domain controller, and endpoint telemetry. That is why Kerberos detections are usually stronger when they are correlated with logon events, process creation, authentication failures, and service access on the target host.

Why these attacks matter for domain security

Golden Ticket and Silver Ticket abuse are both post-compromise techniques. In practice, they often appear after an attacker has already gained a foothold and wants to move laterally, maintain persistence, or access sensitive systems without repeatedly using stolen passwords. The business impact is not limited to one server. If the domain trust model is undermined, incident response becomes slower, scoping becomes harder, and recovery may require broader credential and key rotation work than a standard endpoint incident.

Where to look for evidence in Windows and Active Directory logs

Good detection starts with the right telemetry. For Kerberos, the most useful sources are domain controller security logs, service host logs, and endpoint telemetry that can show the process and account context around suspicious access. If you only collect endpoint logs but not domain controller logs, you will miss important parts of the authentication story. If you only collect domain controller logs, Silver Ticket activity can be much harder to spot because the forged service ticket may never be issued by the KDC.

Key event IDs and log sources to collect

At minimum, collect the following from domain controllers and relevant servers:

• Event ID 4768 for Kerberos authentication ticket requests.
• Event ID 4769 for Kerberos service ticket requests.
• Event ID 4770 for ticket renewals.
• Event ID 4771 for Kerberos pre-authentication failures.
• Event ID 4624 for successful logons on target systems, especially logon type 3 and 9 where relevant.
• Event ID 4672 for special privileges assigned to new logons.
• Service-specific logs, such as IIS, SQL Server, file server auditing, or application logs, where access should be visible.

On endpoints and servers, Sysmon or equivalent EDR telemetry can help you identify the process that initiated access, the source host, and whether the activity aligns with normal administrative behaviour. For example, a suspicious service access event is more useful when you can tie it to a non-standard workstation, an unusual parent process, or a new remote administration pattern.

Why domain controller visibility is essential

Domain controller logs are the authoritative record for normal Kerberos ticket issuance. They are especially important for Golden Ticket detection because the attacker is trying to operate in a way that should not match the usual KDC-issued lifecycle. They are also useful for baselining normal service ticket volume, encryption types, and account usage patterns. Without that baseline, you will struggle to separate real anomalies from routine noise such as service accounts, scheduled tasks, and legacy applications.

Detection patterns for Golden Ticket activity

Golden Ticket detections work best when they combine ticket characteristics with identity and host context. A single unusual event is not enough. You want to look for clusters of behaviour that make sense only if a forged TGT is being used.

Signs of abnormal ticket lifetime, encryption, or account use

One common indicator is a ticket lifetime that does not match your environment’s policy or historical baseline. If your estate normally issues tickets with a standard lifetime and you suddenly see outliers, that is worth investigating. Another useful signal is encryption type. Legacy or unexpected encryption values can indicate older systems, misconfiguration, or forged ticket use, so this signal should be treated as a triage lead rather than a standalone alert.

Account use is another strong clue. Golden Ticket activity often appears as privileged or high-value account usage from a workstation that should not normally perform that role. Look for:

• Privileged accounts authenticating from unusual source hosts.
• Service ticket requests for many different services in a short period.
• Access occurring outside normal administrative windows.
• Logon patterns that do not match the user’s usual device, subnet, or jump host.

Event ID 4769 is often the most useful event for this analysis because it shows service ticket requests. A sudden burst of requests for multiple services, especially from one source host, can be a useful hunting lead. However, you should expect some legitimate administrative tools and service accounts to generate similar patterns, so baselining matters.

Correlating Kerberos events with host and identity telemetry

Golden Ticket detections become much stronger when you correlate Kerberos events with endpoint and identity data. For example, if a high-privilege account appears in 4769 events from a workstation that has no administrative tooling, and the same workstation shows suspicious process activity or remote execution behaviour, the combined signal is more meaningful than any individual event.

Useful correlations include:

• 4769 service ticket requests plus 4624 logons on the target host.
• 4769 activity plus unusual process creation on the source endpoint.
• 4768 or 4771 anomalies plus failed access to sensitive shares or services.
• Privileged logons plus lateral movement indicators such as remote service creation or scheduled task creation.

If you already map detections to MITRE ATT&CK, Golden Ticket activity usually aligns with credential access and lateral movement techniques, but the exact mapping should reflect your own environment and detection logic. If you are building a structured programme, mapping detections and controls to MITRE ATT&CK is a useful companion approach.

Detection patterns for Silver Ticket activity

Silver Ticket detection is often harder because the KDC may not see the service ticket being forged. That means you need to pay closer attention to the target service and the host that receives the access. In many cases, the best evidence is the absence of expected KDC traces combined with the presence of suspicious service-side activity.

Why service-side anomalies are often more useful than KDC events

Because the forged ticket is presented directly to the service, the domain controller may not log a corresponding service ticket request. That absence is not proof by itself, but it becomes useful when paired with target-host evidence. For example, if a server shows successful access to a service from a source host that has no matching normal authentication trail, that is worth investigating.

Service-side anomalies can include:

• Successful access to a service without the expected preceding ticket issuance pattern.
• Access from a host or subnet that rarely uses the service.
• Logons that appear valid but are inconsistent with the user’s normal device or role.
• Repeated access to one service with no broader authentication activity on the domain controller.

For file servers, database servers, and web applications, service logs often provide the clearest evidence. If a service account is being impersonated, the target service may record access that looks legitimate at first glance, so you need to compare it with the surrounding identity context and the source host’s behaviour.

Spotting unusual service access and missing ticket-issuance traces

A practical hunting pattern is to compare service access on the target host with the expected KDC events. If a host shows access that should normally be preceded by 4769 activity, but no corresponding issuance is visible, that is a useful lead. This is particularly relevant for high-value services such as file shares, administrative interfaces, and database services.

Another pattern is to look for access that is technically successful but operationally odd. For example, a workstation account accessing a database service it never uses, or a service account authenticating from a new source host, may indicate ticket forgery or at least credential misuse. In environments with strong segmentation, these anomalies should stand out more clearly.

Practical hunting approaches in SIEM and XDR

In a SIEM, the goal is to turn noisy Kerberos telemetry into a manageable set of investigations. In an XDR platform, the goal is similar, but you may have richer endpoint context and automated entity correlation. Either way, the best approach is to start with a baseline, then layer in rules that look for outliers rather than trying to detect every possible forged ticket directly.

Example correlation ideas for Microsoft Sentinel and Splunk

In Microsoft Sentinel, a useful KQL pattern is to summarise 4769 events by account, source host, service name, and time window, then flag unusual fan-out or unusual source hosts. You can also join Kerberos events to 4624 logons and endpoint alerts to see whether the source host is behaving like an administrative system or a compromised workstation. A simple logic pattern is:

• Identify accounts with a sudden increase in distinct service names requested.
• Flag source hosts that have not previously generated Kerberos traffic for those accounts.
• Correlate with privileged logons or suspicious process activity on the same host.

In Splunk, the same idea can be implemented with stats, transaction, or tstats searches over Windows Security logs. A practical SPL pattern is to aggregate 4769 events by user, client address, and service name, then compare the current period against a historical baseline. You can enrich the result with endpoint telemetry and asset criticality so that a suspicious request from a domain admin workstation is treated differently from a routine service account on a server.

For teams already using Sigma, it is often cleaner to express the first-stage logic as a portable rule and then adapt it to the SIEM backend. That keeps the detection maintainable if you later move platforms or need to share logic across environments.

Using baselines to reduce false positives

Kerberos environments are full of legitimate exceptions. Backup systems, monitoring tools, scheduled tasks, service accounts, and legacy applications can all generate unusual-looking ticket patterns. Baselines help you distinguish expected high-volume behaviour from suspicious outliers. Build baselines for:

• Normal service ticket volume per account.
• Typical source hosts for privileged accounts.
• Common encryption types and ticket lifetimes.
• Usual service access windows by business unit or server role.

When a detection fires, compare the event to the baseline before escalating. If the account, source host, and service are all outside the normal profile, the alert deserves more attention. If only one attribute is unusual, it may still be worth a review, but the likelihood of a benign explanation is higher.

How to tune detections for better fidelity

Tuning is where many Kerberos detections either become useful or become ignored. The aim is not to eliminate all false positives, which is unrealistic, but to make sure the alerts that remain are actionable. A detection that fires on every backup job will not help your team respond to a real incident.

Common benign causes of Kerberos anomalies

Some of the most common benign causes include:

• Service accounts used by backup, monitoring, or patching tools.
• Jump hosts and administrative workstations that legitimately access many services.
• Legacy systems with older encryption settings.
• Application pools or scheduled tasks that generate repetitive authentication patterns.
• Time synchronisation issues or clock skew causing authentication noise.

Document these exceptions and maintain an allowlist with ownership. Avoid building permanent blind spots without review. A service account that is legitimate today can become a useful indicator tomorrow if its behaviour changes unexpectedly.

Validation steps using MITRE ATT&CK mapping and purple-team testing

Map each detection to the behaviour it is intended to catch and test it against realistic scenarios. Purple-team validation is especially valuable here because Kerberos detections are often highly environment-specific. You do not need to simulate a real intrusion to test the logic. Instead, validate that the rule fires when the expected telemetry pattern appears and stays quiet for known-good administrative activity.

Good validation questions include:

• Does the rule fire on the intended account and host combinations?
• Does it suppress known backup and monitoring systems?
• Can an analyst understand why the alert fired within a few minutes?
• Does the alert include enough context to support triage without extra hunting?

If you already run detection engineering as code, keep the test cases alongside the rule. That makes regression testing easier when you change log sources, SIEM parsers, or domain policy settings.

Response actions when you suspect forged Kerberos tickets

If you suspect forged Kerberos ticket use, the response should be deliberate and evidence-led. The first priority is to contain further abuse without destroying the evidence you need to understand scope. The second priority is to determine whether the issue is isolated to one host, one account, or a broader domain compromise.

Immediate containment priorities for domain administrators

Start by identifying the affected accounts, source hosts, and services. If the suspicious activity is tied to a workstation, isolate that endpoint through your EDR or network controls. If a privileged account is involved, disable or reset it according to your incident process. If you suspect KRBTGT compromise, treat the situation as a domain-wide issue and involve your senior identity and infrastructure owners immediately.

Containment actions may include:

• Isolating suspected source endpoints.
• Disabling or resetting compromised accounts.
• Reviewing privileged group membership for unauthorised changes.
• Checking for lateral movement to domain controllers, file servers, and management hosts.
• Preserving relevant logs before they roll over.

Do not rush into broad password resets without understanding the likely blast radius. In Kerberos incidents, poorly sequenced remediation can make recovery harder and can obscure the evidence you need to confirm what happened.

Evidence preservation and investigation scoping

Preserve domain controller logs, endpoint telemetry, and service logs for the suspected time window. If possible, capture memory and volatile artefacts from the suspected source host, especially if you believe the attacker may still be active. Build a timeline that starts before the first suspicious Kerberos event and extends through any lateral movement or privilege escalation indicators.

Scope the investigation by asking three questions: which accounts were used, which hosts were involved, and which services were accessed. That gives you a practical way to separate a single compromised workstation from a broader identity compromise. If you need a structured approach to evidence handling, the article on retaining evidence and logs for investigations is a useful reference point.

Reducing the risk of ticket forgery in Active Directory

Detection is important, but reducing the chance of ticket forgery in the first place is just as valuable. The strongest controls are usually the boring ones: reduce privilege, protect domain controller access, improve logging, and make recovery steps clear before you need them.

Hardening privileged accounts and Kerberos-related configuration

Use tiered administration and separate privileged accounts from day-to-day user accounts. Limit where privileged accounts can log on, and prefer dedicated administrative workstations or jump hosts. Review service account design so that high-value services do not rely on unnecessarily broad privileges. Where possible, reduce legacy authentication and older encryption dependencies that complicate monitoring and increase attack surface.

For Kerberos specifically, focus on the settings and practices that improve visibility and reduce abuse potential:

• Restrict privileged logon locations.
• Minimise the number of accounts with elevated rights.
• Audit service accounts and their delegated permissions.
• Keep domain controller time synchronisation accurate.
• Document and review ticket-related configuration changes.

These measures do not eliminate the risk of forged tickets, but they make abuse harder and detection more reliable.

Improving logging, monitoring, and recovery readiness

Make sure domain controller security logs are forwarded reliably and retained long enough for investigation. Monitor for changes in ticket request patterns, privileged logons, and unusual service access. If you use a SIEM, ensure the parsing and field extraction for Windows Security logs are tested after any platform or agent change.

Recovery readiness matters too. If a Golden Ticket incident is confirmed, you may need to coordinate account resets, service validation, and domain trust review. That is much easier if you already know who owns identity infrastructure, who can approve emergency changes, and how you will preserve evidence while restoring normal operations.

Implementation checklist for small security teams

For smaller teams, the most practical approach is to start with a small set of high-value detections and improve them over time. You do not need a perfect Kerberos analytics programme on day one. You do need a repeatable baseline and a clear ownership model.

Minimum logging and alerting baseline

• Forward domain controller Security logs, especially 4768, 4769, 4770, 4771, 4624, and 4672.
• Collect endpoint telemetry for source host context and process activity.
• Build one Golden Ticket-oriented correlation rule around unusual 4769 patterns.
• Build one Silver Ticket-oriented rule around suspicious service access with weak or missing KDC correlation.
• Track a baseline of normal privileged account source hosts and service ticket volume.
• Document known-good service accounts and administrative systems.

Operational ownership and review cadence

Assign an owner for the detection logic, an owner for the identity platform, and an owner for incident response decisions. Review the detections at least monthly, or after any major change to domain controllers, SIEM parsers, or privileged access workflows. Revisit false positives, add new allowlist entries only with justification, and remove stale exceptions when systems are retired.

It is also worth testing the detection logic after major identity changes, such as new domain trusts, service account migrations, or changes to administrative tooling. Those changes often alter the Kerberos pattern enough to affect alert quality.

For teams that want to improve detection coverage more systematically, the article on measuring detection quality and false positives is a useful companion to this one.

Golden Ticket and Silver Ticket detection is rarely about a single perfect indicator. It is about building enough context around Kerberos events that suspicious behaviour stands out from the normal rhythm of your domain. With the right logs, sensible baselines, and a disciplined response process, even a small security team can make these attacks much harder to hide.

If you would like help reviewing your Kerberos logging, SIEM correlation, or identity monitoring approach, speak to a consultant.

Frequently asked questions

What is the difference between a Golden Ticket and a Silver Ticket?

A Golden Ticket is a forged Kerberos Ticket Granting Ticket that can be used to request multiple service tickets, while a Silver Ticket is a forged service ticket for one specific service. Golden Ticket abuse is usually broader and more visible in domain controller patterns, whereas Silver Ticket abuse often shows up more clearly on the target service and host.

Can you detect forged Kerberos tickets from logs alone?

You can often detect strong indicators from logs alone, but confidence improves when you correlate Kerberos events with endpoint telemetry, service logs, and identity context. Silver Ticket activity in particular may be difficult to prove from domain controller logs alone because the KDC may not issue the forged service ticket.