Unlike Pass-the-Hash, which abuses password hashes in compatible authentication scenarios, Pass-the-Ticket focuses on the theft and reuse of Kerberos authentication tickets.

• Primary risk: Unauthorised authentication using stolen Kerberos tickets.

• Common targets: Active Directory domain users, service accounts and privileged administrators.

• Potential impact: Lateral movement, unauthorised resource access and privilege abuse.

• Key investigation evidence: Kerberos event logs, endpoint telemetry, ticket activity and unusual service access.

• Primary defences: Protect credentials and tickets, restrict privileged access, monitor Kerberos activity and secure domain controllers.

1. When an Authentication Ticket Falls into the Wrong Hands

Imagine an organisation where employees use Windows domain accounts to access file servers, internal applications and other corporate resources.

When a user authenticates to Active Directory, Kerberos can issue a Ticket Granting Ticket (TGT). The client can use this ticket to request service tickets for specific resources without repeatedly submitting the user's password.

This process improves security and usability, but it also creates an opportunity for attackers.

If an attacker compromises a workstation and obtains a valid Kerberos ticket, they may be able to reuse that ticket to authenticate to resources accessible to the associated account.

The attacker may not need to recover the original password. Instead, they abuse the authentication material already issued by the domain.

This is the core principle behind Pass-the-Ticket (PtT).

For a SOC analyst, the key question is whether Kerberos tickets are being used in a way that is inconsistent with the account's normal behaviour, the ticket's properties or the organisation's authentication architecture.

2. Understanding Kerberos Authentication

Kerberos is a network authentication protocol that uses tickets and a trusted Key Distribution Center (KDC) to authenticate users and services.

In a typical Active Directory environment, the KDC runs on domain controllers.

Two ticket types are particularly important.

Ticket Granting Ticket (TGT)

A TGT allows a client to request service tickets from the KDC. It is generally issued during the initial Kerberos authentication process.

A TGT is not itself a universal credential for accessing every application. Its use depends on the account, ticket validity, domain configuration and subsequent authentication exchanges.

Service Ticket

A service ticket is issued for a particular service, such as a file server or an application using Kerberos authentication.

The client presents the service ticket to the target service to establish an authenticated session.

The ticket is associated with a service principal and contains information that the target service can validate using its configured Kerberos keys.

Simplified authentication flow

<box border radius="lg" padding={3} gap={2}> <box background="surface-secondary" radius="md" padding={3} align="center" gap={1}> <icon name="monitor" size="xl" /> **User's Windows Endpoint** <text color="secondary" size="sm">Requests domain authentication</text> </box> <box align="center"> <icon name="arrow-down" size="lg" color="secondary" /> </box> <box border radius="md" padding={3} align="center" gap={1}> <icon name="shield-check" size="xl" /> **Domain Controller / KDC** <text color="secondary" size="sm">Issues a Ticket Granting Ticket</text> </box> <box align="center"> <icon name="arrow-down" size="lg" color="secondary" /> </box> <box border radius="md" padding={3} align="center" gap={1}> <icon name="ticket" size="xl" /> **Service Ticket Request** <text color="secondary" size="sm">The client requests access to a specific service</text> </box> <box align="center"> <icon name="arrow-down" size="lg" color="secondary" /> </box> <box background="surface-secondary" radius="md" padding={3} align="center" gap={1}> <icon name="server" size="xl" /> **Target Service** <text color="secondary" size="sm">Validates the ticket and applies access permissions</text> </box> </box>

If an attacker steals a usable ticket, they may be able to interfere with this trust model by reusing the ticket from a compromised endpoint or another environment where the necessary conditions are met.

3. How a Pass-the-Ticket Attack Unfolds

Stage 1: Initial access

An attacker compromises a workstation or server through phishing, exploitation, stolen credentials or another method.

The initial access method is separate from Pass-the-Ticket itself.

Stage 2: Ticket access

The attacker attempts to obtain Kerberos ticket material available within the compromised environment.

The opportunities available depend on the account's session, endpoint protections, process privileges and how credentials are managed.

Stage 3: Ticket theft

The attacker obtains a usable TGT or service ticket.

The security implications depend on the ticket type, the associated identity, the ticket's lifetime and the services for which it can be used.

Stage 4: Ticket reuse

The attacker attempts to use the stolen ticket to authenticate to a network resource.

Successful reuse depends on ticket validity, target service behaviour, account permissions, domain configuration and other security controls.

Stage 5: Lateral movement

If the account has access to additional systems, the attacker may use the ticket to access file shares, remote services or internal applications.

A stolen ticket does not automatically grant administrator privileges. Access remains constrained by the identity and permissions associated with the ticket and the target service's authorisation controls.

Stage 6: Further compromise

The attacker may attempt to obtain additional tickets, access other accounts or compromise further systems.

These actions depend on the attacker's access and should be investigated as separate behaviours.

4. Why Kerberos Tickets Are Valuable to Attackers

Kerberos tickets are designed to reduce the need for users to repeatedly enter their passwords. However, a stolen ticket may represent an opportunity to impersonate the associated identity within the ticket's usable scope.

Several factors can increase the potential impact.

Privileged accounts

Tickets associated with domain administrators or other highly privileged accounts may enable access to sensitive systems.

Protecting privileged sessions and preventing administrative logons to lower-trust endpoints are therefore important defensive measures.

Long-lived or renewable tickets

Kerberos tickets have validity periods, and some tickets may be renewable under configured conditions.

Longer validity can increase the window during which stolen ticket material may remain useful. Actual usability depends on ticket type, domain policy, service behaviour and other controls.

Weak endpoint security

If an attacker can access sensitive authentication material from a compromised endpoint, the risk of ticket theft increases.

Credential protections, endpoint detection and restrictions on privileged access can reduce the likelihood and impact of such access.

Broad service permissions

If accounts can access more systems than their duties require, ticket theft can create a larger opportunity for lateral movement.

Least privilege and network segmentation reduce the number of resources available to a compromised identity.

5. Types of Kerberos Ticket Abuse

Pass-the-Ticket is related to several other Kerberos attacks, but these techniques are not interchangeable.

TechniqueDescriptionKey distinctionPass-the-TicketReuses stolen Kerberos ticket materialAbuses an already issued ticketKerberoastingRequests service tickets and attempts to recover service-account passwords offlineTargets service-account credentialsAS-REP RoastingTargets accounts configured not to require Kerberos pre-authenticationCan allow offline password guessing against captured authentication materialGolden TicketAbuses forged TGTs created using compromised domain Kerberos secret materialInvolves forging a TGT rather than simply reusing a stolen ticketSilver TicketAbuses forged service tickets created using compromised service-account or computer-account key materialTargets a particular service's authentication trustPass-the-HashUses password-hash material to authenticate through compatible mechanismsAbuses a different type of authentication material

These techniques may appear in the same intrusion. For example, an attacker may steal credentials, request tickets, reuse tickets and later attempt to compromise service-account keys.

However, evidence of unusual Kerberos activity does not automatically establish Pass-the-Ticket or a forged-ticket attack.

6. Investigating Pass-the-Ticket in a SOC

Consider a hypothetical alert: an account accesses a file server from an unfamiliar workstation, followed by Kerberos service-ticket activity involving several internal services.

The account normally accesses only a small set of systems. EDR telemetry also reports suspicious access to authentication-related processes on the original workstation.

The SOC team must determine whether the activity represents legitimate user movement, administrative activity or stolen-ticket reuse.

Step 1: Identify the account and affected systems

Establish:

• The user or service account involved.

• The source endpoint and IP address.

• The destination host and service.

• The authentication timestamps.

• The account's normal access patterns.

• Whether the account has privileged access.

Correlate the account and device with asset inventories, identity records and approved administrative workflows.

Step 2: Review Kerberos Event ID 4768

Event ID 4768 — A Kerberos authentication ticket (TGT) was requested records TGT request activity on a domain controller when the relevant auditing is enabled.

Review available fields such as:

• Account name.

• Client address.

• Ticket encryption type.

• Status or failure information.

• Timestamp.

• Other ticket-related details available in the event schema.

Unexpected TGT requests may provide useful context, but Pass-the-Ticket can involve reuse of a previously issued ticket. Therefore, the absence of an unusual 4768 event does not rule out ticket theft.

Step 3: Examine Event ID 4769

Event ID 4769 — A Kerberos service ticket was requested records service-ticket request activity.

Investigate:

• The account requesting the ticket.

• The requested service or service principal.

• The client address.

• The ticket encryption type.

• Success or failure details where available.

• Unusual service access compared with the account's baseline.

A burst of service-ticket requests may indicate reconnaissance or unusual access, but it can also result from normal application activity.

Importantly, a reused service ticket may be presented directly to a service without generating a new corresponding service-ticket request at that moment.

Step 4: Examine Event ID 4624 on target systems

Event ID 4624 — An account was successfully logged on records successful logon activity on the destination system.

Review:

• Logon type.

• Account and domain.

• Source network address.

• Authentication package.

• Logon process.

• Logon ID and related fields where available.

A network logon using Kerberos may support the investigation, but Event ID 4624 does not by itself prove that a stolen ticket was used.

Step 5: Review endpoint telemetry

Examine EDR records from the suspected source system.

Look for:

• Suspicious access to authentication-related processes.

• Credential theft or memory-access alerts.

• Unusual execution of administrative or credential-access tools.

• Unexpected changes to logon sessions.

• Remote access activity that follows suspected ticket theft.

The evidence should establish whether an attacker had an opportunity to access ticket material and whether suspicious authentication followed.

Step 6: Correlate access across systems

Build a timeline covering the source endpoint, domain controllers and destination services.

Investigate whether the account accessed systems outside its normal scope, especially when those accesses follow suspicious endpoint activity.

Review file-share access, remote service execution, administrative changes and other post-authentication behaviour.

Step 7: Assess whether ticket theft is confirmed

Distinguish between:

• Unusual Kerberos activity: Authentication patterns differ from the account's baseline.

• Probable ticket abuse: Suspicious authentication is supported by endpoint or lateral movement evidence.

• Confirmed Pass-the-Ticket: Forensic evidence supports theft and reuse of Kerberos ticket material.

In many environments, ordinary authentication logs alone cannot prove that a ticket was stolen and replayed. Document the evidence limitations and avoid claiming confirmation without sufficient support.

7. Evidence and Indicators to Review

Pass-the-Ticket does not have one definitive event ID or universal indicator of compromise. Investigations should correlate authentication logs with endpoint and network evidence.

Evidence sourceWhat to investigateWindows Security Event 4768TGT requests, account activity and client informationWindows Security Event 4769Service-ticket requests and unusual service accessWindows Security Event 4770Kerberos service-ticket renewal activity, where auditedWindows Security Event 4624Successful logons on affected systemsWindows Security Event 4625Failed logons that may precede successful accessEDR telemetrySuspicious access to authentication-related processesDomain controller logsAuthentication anomalies and ticket-request patternsFile server logsUnusual access to shares or sensitive dataRemote administration logsUnexpected service access or remote executionNetwork telemetryConnections between the source endpoint and unusual destinations

Behavioural patterns that may warrant investigation

• A privileged account accesses an unfamiliar endpoint or server.

• An account connects to multiple sensitive services outside its normal pattern.

• Unusual service access occurs shortly after suspicious endpoint activity.

• Authentication from one endpoint is followed by unexpected activity from another.

• Kerberos activity is followed by suspicious remote administration or data access.

• EDR reports credential-access behaviour around the same time as unusual authentication.

These patterns are investigative leads, not definitive proof of Pass-the-Ticket. Legitimate user mobility, service accounts, application behaviour and administrative tasks can produce similar activity.

8. Detection Engineering and MITRE ATT&CK

A practical detection strategy correlates Kerberos events with identity context, endpoint alerts and remote access activity.

Example detection logic

1. Monitor successful Kerberos authentication to sensitive systems.

2. Baseline account-to-host and account-to-service relationships.

3. Detect unusual access to privileged services or multiple systems within a short period.

4. Correlate the activity with endpoint credential-access alerts.

5. Enrich alerts with account privilege, device identity and ticket-related event information.

6. Escalate cases where independent evidence supports ticket theft or lateral movement.

Avoid treating every unusual service-ticket request as malicious. Kerberos is widely used by Windows applications, and normal service behaviour can generate substantial authentication traffic.

MITRE ATT&CK mapping

• T1550.003 — Pass the Ticket: The specific technique for using Kerberos tickets to authenticate without necessarily possessing the account's password.

• T1003 — OS Credential Dumping: Relevant when evidence indicates that credentials or ticket material were extracted from an operating system.

• T1021 — Remote Services: Potentially relevant when an attacker uses remote services for lateral movement.

• T1078 — Valid Accounts: Potentially relevant when compromised account access is used to reach systems or services.

These techniques describe different behaviours. Credential dumping may precede Pass-the-Ticket, but it is not required in every case where an attacker obtains ticket material by another route.

9. Preventing Pass-the-Ticket Attacks

Effective prevention combines endpoint hardening, privileged access controls, identity monitoring and protection of Kerberos authentication material.

Protect privileged sessions

Avoid logging privileged accounts into lower-trust workstations. Use dedicated administrative workstations or other appropriately isolated administrative environments.

Limit the number of systems from which highly privileged accounts can be used.

Enable credential protections

Where supported, enable and properly configure Windows Defender Credential Guard and other relevant Windows security protections.

These controls can reduce exposure of sensitive authentication material, although their effectiveness depends on platform compatibility, configuration and the attack path.

Reduce privileged account exposure

Use separate administrative accounts, restrict unnecessary administrator rights and review group membership regularly.

Avoid granting broad domain privileges to accounts that need access to only a small number of systems.

Monitor Kerberos activity

Collect relevant authentication events from domain controllers and endpoints. Establish baselines for account-to-service access and investigate unexpected changes.

Use event data together with endpoint telemetry rather than relying on ticket-request counts alone.

Apply least privilege and segmentation

Restrict access to sensitive servers, administrative interfaces and file shares. Use network controls to limit unnecessary communication between workstation and server networks.

Even if a stolen ticket is accepted, effective authorisation and segmentation can restrict what the associated identity can reach.

Maintain secure Active Directory configuration

Review domain security settings, service-account privileges, ticket policies and the protection of domain controllers.

Use managed service accounts where appropriate and minimise unnecessary privileges assigned to service identities.

Prepare for credential compromise

Maintain procedures for isolating affected endpoints, investigating compromised sessions and responding to suspected privileged-account abuse.

Credential resets and account containment should be coordinated with the incident response team because existing tickets and active sessions may require additional steps to invalidate or terminate.

10. Incident Response Checklist

When Pass-the-Ticket is suspected:

1. Preserve evidence: Collect Kerberos events, Windows Security logs, EDR telemetry and relevant network records.

2. Identify the identity: Determine the affected user or service account and its permissions.

3. Map authentication activity: Identify source systems, target services and the sequence of logons.

4. Investigate ticket access: Review endpoint evidence for suspicious access to authentication-related processes.

5. Contain compromised systems: Isolate affected endpoints where appropriate and restrict suspicious access.

6. Protect affected accounts: Apply suitable account and session containment measures, including credential rotation where warranted.

7. Investigate lateral movement: Review remote service activity, file access and administrative changes.

8. Validate recovery: Confirm that suspicious authentication has stopped and monitor for renewed activity.

Conclusion

Pass-the-Ticket demonstrates how authentication can be abused even when an attacker does not know the user's plaintext password. By obtaining and reusing Kerberos ticket material, an attacker may access services available to the associated identity and potentially move between systems.

For SOC analysts, the challenge is to distinguish ordinary Kerberos activity from stolen-ticket abuse by correlating domain controller events, target-system logons, endpoint telemetry and subsequent access.

For defenders, the priority is to protect authentication material, reduce privileged session exposure, enforce least privilege and monitor access to sensitive services.

The key lesson: A valid Kerberos ticket is sensitive authentication material and must be protected accordingly.

Further Reading

• MITRE ATT&CK — T1550.003: Pass the Ticket

• Microsoft Learn — Kerberos authentication overview

• Microsoft Learn — Windows Security auditing and Event ID 4768

• Microsoft Learn — Windows Security auditing and Event ID 4769

• Microsoft Learn — Windows Defender Credential Guard