GTFOBins

• Unixバイナリの一覧が機能別に整理されており、各バイナリで可能な動作へ 詳細ページとアンカーリンク で直接移動できるようになっている
• 繰り返し付与される分類は Shell、File read、File write、Command、Inherit、Upload、Download、Reverse shell、Library load で、一部の項目には Bind shell も付く
• File read と Shell は非常に広く分布しており、dd・sed・sqlite3 のようなツールは 読み取りと書き込み を併せ持つため、単純な参照系ツールとの境界があいまいになる
• apt・git・journalctl・systemctl のようなツールは Command と Inherit をよく含み、bee・pipx・sqlmap・vim 系のように ネットワーク転送とシェル動作 を併せ持つ多機能バイナリも繰り返し現れる
• Privilege escalation は別リンク付きの一部バイナリに限って現れ、7z から zypper まで続く幅広い一覧が 一般的なツールの動作組み合わせの違い を一目で示している

---

代表的な機能分布

• ファイル読み取り 専用、または読み取り中心の項目が非常に広く分布している
  • 7z, cat, grep, jq, od, tail, wc, zcat などは File read を中心に結び付けられている
• シェル実行 が可能な項目も非常に多い
  • bash, awk, find, less, python, ruby, tar, vi, zsh などが Shell を持つ
• ファイル書き込み と読み取りを併せ持つ項目が多く、単純な参照系ツールとの境界があいまいになる
  • dd, cpio, ed, emacs, nano, sed, sqlite3, xxd などがここに属する
• コマンド実行 や 権限継承 は、パッケージマネージャー、システムツール、対話型プログラムでよく見られる
  • apt, apt-get, git, journalctl, man, systemctl, timedatectl, zless が代表的である

多機能バイナリ

• 複数の動作を同時に持つ 多機能バイナリ が繰り返し登場する

• Inherit ベースの多機能項目

  • apport-cli, batcat, cargo, crash, gcloud, git, journalctl, man, opencode, psql, run-mailcap, systemd-resolve は Inherit とともに Shell、Command、File read、File write がまとまっている

• ネットワークとファイル移動まで含む項目

  • bee, byebug, dstat, easy_install, facter, irb, knife, pipx, poetry, rake, sqlmap, vagrant, volatility は Reverse shell、Upload、Download、Library load まで併せ持つ

• エディタとデバッガ系

  • gdb, nvim, rvim, view, vim, vimdiff は Inherit とともに、Shell、Reverse shell、Bind shell、または File read/write、Upload、Download、Library load をまとめて持つ

• パッケージマネージャーとランタイム系

  • apt, apt-get, bundle, bundler, pip, rpm, rpmdb, rpmquery, rpmverify, yum は、シェル、ファイルアクセス、ネットワーク動作が併せて付くことが多い

ネットワーク、シェル、ライブラリロード

• アップロード/ダウンロード 機能は、ネットワークツールだけでなくシェルや言語ランタイムにも付いている

• 転送中心のツール

  • ab, curl, finger, ftp, nc, scp, sftp, smbclient, ssh, tar, tftp, wget, whois が Upload または Download を持つ

• Reverse shell と Bind shell

  • bash, gawk, go, jjs, julia, ksh, lua, nawk, nc, nmap, node, openssl, pandoc, php, ruby, socat, socket, tclsh, telnet, zsh などがここに含まれる

• Library load が付く項目

  • bash, byebug, curl, ffmpeg, gdb, gem, gimp, irb, knife, ldconfig, mysql, nginx, nvim, openssl, pip, python, rake, ruby, ssh-keygen, tclsh, vim, volatility, wish, yum などが含まれる

権限昇格項目

• Privilege escalation は別項目として付いたバイナリに限って現れる

• 権限昇格リンク一覧

  • chattr
  • chmod
  • chown
  • cp
  • getent
  • install
  • ln
  • mount
  • mv
  • passwd
  • setcap
  • setfacl
  • unsquashfs
  • unzip

[GN⁺]

Hacker Newsの意見

• コメント欄で混同している人がいるようなので、これがセキュリティ/CTF文脈でいつ使われるかを例で言うとこんな感じ
  制限付きシェルや、一部のコマンド/バイナリしか実行できない環境では、たいてい引数はかなり自由に与えられる
  そこでGTFOBinsを使うと、ファイルの読み書きやコマンド実行までつなげて、制限されたコンテキストを抜け出しシェルを取得できる
  誰かがsudoを開けていたり、GTFOBinにSUID bitを与えていたりすると、設定した本人も想定していなかった方法で機密ファイルを読み書きしたり、権限付きコマンドを実行できてしまうこともある

  • こういう話はclaude-codeのようなツールにもかなり当てはまる
    権限処理が block-list と allow-list 中心なので、かなり原始的な部類
    あるセッションでうっかり Claude にpowershellの権限を与えたことがあるが、その後 git のようなツールがブロックされると、同じことをする powershell スクリプトを書いて実行し、塞がれていた権限を回避していた
    普通のシステムなら powershell を一般的な allow-list に入れはしないだろうが、ツールごとの許可レベルに隙があるなら、このページの手法で十分回ってしまいそう
  • 権限昇格の仲介をうたう一部のエンタープライズ向けセキュリティソフトウェアも、同様に危険になりうる
    ある会社で見た展開方法では、管理者が追加した allowlist のプログラムはパスワードなしで sudo 実行できるようになっていて、最初からvimやbashのような汎用ツールが入っていた
    在宅勤務していた身としてはむしろ助かると感じたが、自分のコンピュータを「保護」すると称するこのソフトが、ちょっと席を外して画面ロックを忘れたときに、誰かが来て何かを実行するのをずっと簡単にしていたからだ
  • これは結局、restricted shellが実際にはどれほど突破されやすいかを示す、かなり包括的なガイドに見える
  • 具体例もある
    数年前、サポートチームが tcpdump でネットワークキャプチャを取る必要があり、急いでいたので引数をある程度開放した sudo ルールを入れたことがあった
    ポートや NIC が変わる可能性があるので、そのときは自然に思えたが、実際には tcpdump の -z オプションで圧縮コマンドを指定できるため、そこに「特別な」コマンドを入れるとサーバーをそのまま掌握できる
    sudo tcpdump -i any -z '/home/despicable_me/evil_cmd.sh' -w /tmp/dontcare.pcap -G 1 -Z root
    些細に見えても、本当に見落としやすい
    今はapparmorのようなレイヤーがこうしたリスクを減らしてくれることもあるが、そのぶん別の厄介さも増え、依然として誤設定しやすい
  • これを見ていると、AI がサンドボックス回避手法を学ぶために整理された一覧のようにも思える

• 最後にこういう似たものを使ったのは1995年ごろの Windows 3.11が入った中学校のコンピュータだった
  承認された数個のアプリしか実行できないようにしてあり、そのうちの1つが Word だった
  Word ではマクロを使え、shell で別のアプリを実行できた
  そのため、数個のアプリしか見えないロックされたコンピュータが、実質的には何でも実行できる状態になっていた
  当時はかなりスリリングで、それ以降こういうものはほとんど見ていない
  たまに店舗やショッピングモールのタッチ式案内ディスプレイでkiosk modeを抜けられるという話を聞くが、それも似た系統だと思う

• restic - Shell, Command, Upload を見ると、バックアップを root で走らせないように調整したのが少し正当化された気がする
  その代わり一般ユーザーとして実行し、read-all-files capabilityだけ与えてログインシェルはなくした
  もちろんデスクトップではやりすぎかもしれないし、そこまで突破された攻撃者ならどうせほぼすべてのファイルを読めるし、バックアップにバックドアを仕込むこともできる
  [0] https://man7.org/linux/man-pages/man7/capabilities.7.html

  • 制約を見ると、単に「じゃあ回避用ヘルパーを1つ使って迂回すればいい」と判断する LLM の傾向が、昔の世界の前提をかなり崩しているように思える
    リモートの人間攻撃者、リモートのボット攻撃者、ある程度まではローカルの人間攻撃者に対する対処法はあるが、ローカルで自分でコードを書くボット攻撃者は、以前よりはるかに気を配るべき対象になった
    これはマルウェアとも完全に同じカテゴリではない
    私もコンテナを関連する境界と見て内部プロセスをすべて root で動かすようにしたことがあるが、LLM が絡むと OS レベルのセキュリティが急に重要になったのか、それとも逆に無意味になったのか、よく判断がつかない

• 混乱しているのだが、これは cat がないときに cat /path/to/input-file の代わりに base64 /path/to/input-file | base64 --decode を使えという意味なのか
  それとも base64 /path/to/input-file | base64 --decode がファイル読み取り権限そのものを回避するという意味なのか

  • 前者が正しい
    呼び出されたプロセスは通常、それを実行したユーザーの権限をそのまま引き継ぎ、setuid bitがあるときだけ例外が生じる
    要するに、標準的な Unix ツールを無効化して攻撃者のlateral movementを防ごうとする環境でも、別のツールで同じことができるという話
  • ブラックリスト方式のコマンド制限で権限を抑えるやり方は、昔からうまく機能せず、今も同じということ
  • 後者ではなく前者
    権限そのものを突破する話ではなく、少数のコマンドだけが許された制限付きシェルで、同じ結果を別のバイナリで得るという話
    こういうのは CTF で本当によくある
  • ただし、読めないファイルがあり、その代わりroot として base64 を実行できるなら話は変わる
    root 権限で base64 を走らせてファイル内容を base64 でエンコードし、その出力を別の base64 プロセスでデコードすれば、結局ファイル内容を見ることができる
    結果的には手順が増えただけの cat と同じ
  • そうならtar パイプのほうが軽いのでは、とも思う

• 昔こうしたツールの1つのメンテナだったのだが、それでシェルを取る人を見たときは笑ってしまった
  創造的で面白いし、資料としても良い

• hackthebox.eu をやっていたとき、これをものすごく使った

• GTFOBinsはかなり前からあり、AI 以前から有用な資料だった

  • だからこそ今後がさらに心配
    AI が有用なのは結局、こうした既存の資料を引き上げて使えるからでもある

• base64 が一覧にあるのを見て、いまいち理解できない
  私の考えでは、それはユーザーがすでにアクセスできるファイルを読むことしかできないはずだが、勘違いしているのだろうか
  それとも誤設定されたシステムのローカルなセキュリティ制限の回避という説明が、自分の理解している意味とは違うのか

  • 重要なのは、誤設定された制限付きシェルや、コマンドへのアクセスだけが与えられた場合でも、その一覧のツールによって、そのユーザーが本来非制限環境で持っていたアクセス範囲の一部を取り戻せるという点
    最も単純な例では、デフォルトシェルをrbashに変えてあっても、ユーザーが単に bash を実行して通常のシェルに入れるなら意味がなくなる
  • たとえば sudoers がbase64 を root として実行できるよう許可しているかもしれない
    なぜそうするのかは分からないが、もしそうなら意図された権限制限を回避してシステム上の任意のファイルを読めるようになる
    あるいはClaude Codeに base64 実行をレビューなしで許可しているなら、.env のような秘密ファイルまで読ませることを開いているのかもしれない
  • よくある状況は、いくつかのツールがroot 権限で実行可能であること
    sudo -l で明示的に許可されている場合もあれば、別の何かが root でそのツールを呼び出している場合も多い

• こうした回避への緩和策も一緒に示してほしい
  たとえば more でシェルを取れる場合なら
  more 実行前に SHELL を /bin/false に設定する
  secure mode の less に置き換える
  sudo で more を使うならNOEXEC flagを使う、といった具合

  • 最善の緩和策は、ユーザーが読んだり書いたりしてはいけないファイルの実際の権限を適切に設定すること
    それ以外の方法は結局、運任せな面が大きい

• かなり良くできていて、予想外に創造的なアプローチも見える
  たとえばyt-dlpのようなものは思いつかなかった
  ただ入れておくだけでも見直したほうがよさそう