ハクソク

世界を動かす技術を、日本語で。

GTFOBinsの翻訳は「GTFOBins」となります。これは特定のプロジェクト名や用語であるため、翻訳せずそのまま表記します。

概要

このリストは、LinuxやUnix系システムにおけるコマンドやプログラムの権限や機能別分類を示しています。
各コマンドの特徴(シェル実行、ファイル操作、アップロード/ダウンロード、特権昇格など)が明記されています。
セキュリティ監査や脆弱性評価、権限昇格の調査時に役立つ情報。
実際の攻撃経路や防御策の検討材料として活用可能。
理解しやすい体言止め形式で用途や危険性を整理。

Linux/Unixコマンド権限・機能別分類

  • Shell実行:

    • bash, sh, ash, csh, tcsh, fish, zsh, dash, ksh, rc, elvish, sash, etc.
    • シェルアクセス獲得やコマンド実行の起点
  • ファイル読み込み/書き込み:

    • cat, less, more, tail, head, grep, awk, sed, tee, cp, mv, dd, split, join, sort, uniq, etc.
    • 任意ファイルの閲覧や編集、情報収集
  • アップロード/ダウンロード/ネットワーク通信:

    • curl, wget, ftp, sftp, scp, rsync, nc (netcat), socat, ssh, smbclient, lftp, aria2c, git, etc.
    • ファイル転送や外部サーバとの通信経路
  • リバースシェル/バインドシェル:

    • bash, nc, socat, perl, python, ruby, php, node, gawk, lua, nmap, etc.
    • 外部からのシェル接続やリモート操作の実現
  • 特権昇格:

    • sudo, su, pkexec, chown, chmod, chattr, setcap, setfacl, mount, cp (SUID), ln (ハードリンク), etc.
    • 一般ユーザーからroot権限取得の経路
  • ライブラリロード:

    • python, perl, ruby, node, gdb, ffmpeg, openssl, etc.
    • 任意コード実行や外部モジュール読み込み
  • コマンド実行/スクリプト実行:

    • make, cmake, autoconf, ansible-playbook, puppet, chef, docker, kubectl, npm, pip, gem, cargo, etc.
    • スクリプトや自動化ツールによるコマンド連携
  • プロセス・システム操作:

    • ps, top, htop, systemctl, journalctl, dmesg, crontab, at, loginctl, etc.
    • システム情報取得やスケジューリング、サービス管理
  • パッケージ管理:

    • apt, apt-get, aptitude, yum, dnf, zypper, rpm, dpkg, snap, pip, gem, npm, etc.
    • ソフトウェアインストールやアップデート経路
  • 暗号化/証明書/ネットワーク関連:

    • openssl, gpg, ssh-keygen, ssh-agent, ssh-add, certbot, etc.
    • セキュア通信や認証情報の生成・管理
  • その他ユーティリティ:

    • file, strings, hexdump, cmp, diff, patch, iconv, base64, base32, jq, etc.
    • ファイル解析・変換やデータ処理

セキュリティ観点での注意点

  • SUID/SGID属性root権限で実行可能なコマンドは特に危険性が高い
  • 外部通信ファイル転送機能を持つコマンドは情報漏洩リスク
  • シェル実行ライブラリロードが可能なコマンドは任意コード実行経路
  • パッケージ管理コマンドは悪意あるソフトウェア導入の温床
  • サービス管理スケジューラは永続化やバックドア設置に利用されやすい

利用シーン例

  • 脆弱性診断時の攻撃経路特定
  • 権限昇格や情報漏洩のリスク評価
  • SOC/CSIRTによるログ監査やアラートルール策定
  • セキュリティ教育や運用手順策定の参考資料

このリストは攻撃者視点でも防御者視点でも活用できるため、
自組織のシステムにどのコマンドが存在し、どの権限で動作しているか定期的な棚卸し・監査が重要。

Hackerたちの意見

でも、そのコマンドを実行するには、すでにシステムにシェルアクセスが必要だよね?
でも、そういうアクセスはちょっとしたソーシャルエンジニアリングで得られるからね。人は今でもメールの中のリンクをクリックしたり、コンピュータがそう言ったからってコマンドを実行したりするし。
シェルアクセスだけじゃなくて、サーバーがユーザーにこれらのバイナリをrootとして実行できるように設定されてる必要があるんだよね(例えば、管理者がsudoersファイルに追加するみたいに)。だから、これはかなりニッチな攻撃ベクトルで、しばしば怠慢なシスアドのせいで発生することが多いんだ。
サイトの前文にも書いてあるけど、これを単なるエクスプロイトの集まりだと思わないで、緊急時に使うための昇格技術に関する知識の集大成だと思ってほしい。80年代に若いUnix開発者だったころ、間違ってuntarしたり、'rm -rf /'を打ち間違えたりして、どれだけ指を焼いたかわからないよ。再起動する前に修正しないと壊滅的なことになるシステムが動いてて、シェルはまだアクティブで…どうする?この素晴らしいアドバイスのリストを参考にして、システムを再構築したり、他にできないことをやるために使ったりするんだ… GTFOBinsはハッキングだけのためじゃなくて、システムの修復や復旧にも使える。ハッカー攻撃の後にこの知識ベースを参考にするのも、前にするのと同じくらいあり得るよ。
mtrにWiFiアクセスがあれば、rootとしてtracerouteできるけど、シェルを起動したりファイルを読んだりはできないかも。でも、これらのツールを使えば昇格できるよ。
…あるいはCGIコマンドを実行する何か。Bashスクリプトはインターネットの接着剤みたいなもので、たくさんのスクリプトが雑に書かれてる。まだまだPHPで動いてるものや、裏でちょっとしたPythonのcronジョブに依存してるものがたくさんある。こういうものが機能する方法の多くは、脆弱性をつなげることに依存してるんだよね…データベースへのエスケープされていないクエリが、夜間のcronジョブにパイプされて何かを同期したりバックアップしたりすることが攻撃ベクターになる。
ちょっと混乱してるんだけど、これは`cat`にアクセスできない場合、`cat /path/to/input-file`の代わりに`base64 /path/to/input-file | base64 --decode`を使えるってこと?それとも、`base64 /path/to/input-file | base64 --decode`がファイルの読み取り権限をバイパスできるってこと?
最初に言いたいのは、呼び出されたプロセスは、それを呼び出したユーザーの権限を引き継ぐってこと(setuidビットがない限り)。これは、攻撃者の横移動を防ぐために、標準のUnixツールが無効にされているコンピュータにアクセスした場合のためだよ。
あなたのユーザーが読み取りアクセスを持っていないファイルがあっても、rootとして`base64`バイナリを実行できるなら、rootとして`base64`を実行して(ファイルの内容をbase64でエンコードして)、その出力を別のbase64プロセスにパイプしてファイルの内容をデコードできる。だから、最終的にはちょっと手間がかかるけど、結果的には`cat`と同じだよ。
tarパイプの方がもっと軽いんじゃない?
前者だね。権限をバイパスするんじゃなくて、ほんの数個のコマンドに制限されたシェルの中での話。みんなが言ってるように、CTFではめちゃくちゃよくあることだよ。
これは、コマンドをブラックリスト化して権限を制限するのは効果がない(そして、今まで効果があったこともない)って言ってるんだ。
よくわからないな。base64はリストに入ってるけど、ユーザーがすでにアクセスできるファイルを読む以外のことはできないと思うんだけど。私が間違ってるのかな?それとも「誤設定されたシステムでローカルセキュリティ制限をバイパスするために使えるUnixライクな実行可能ファイルのキュレーションされたリスト」って、私が思ってる意味とは違うの?
たぶん、誤設定された制限付きシェルやコマンドアクセスを与えられた場合、リストにあるツールを使って、そのユーザーが通常は無制限の環境でアクセスできる一部にアクセスできるってことなんだと思う。これの非常にシンプルな例は、ユーザーのデフォルトシェルを「rbash」に設定しても、ユーザーが「bash」を実行して本物のシェルを得られる場合だね。
もしかしたらsudoersがbase64をrootとして実行できるように設定されてるかも。なんでそんなことする人がいるんだろう?全然わからないけど、もしそんな状況にいるなら、意図された権限を回避してシステム上のどんなファイルでも読める方法を知ったことになるね。あるいは、Claude Codeにレビューなしで`base64`を実行する権限を与えちゃって、これが.envの秘密ファイルとかも読めることに気づいてないかもしれない。
コメントの混乱を見て、これがセキュリティやCTFの文脈でどんな状況で起こるかの例をいくつか挙げたいな:* 制限されたシェルや、制限されたコマンドやバイナリのセットを実行する方法がある場合、しばしば任意のパラメータを使って。GTFOBinsを使って、ファイルを読んだり、書き込んだり、さらにはコマンドを実行して、最終的には制限されたコンテキストからシェルに抜け出すことができる。* 誰かがsudoアクセスを許可したり、GTFOBinにSUIDビットを設定した場合。このトリックを使えば、設定した人が知らなかった方法で機密ファイルを読み書きしたり、特権コマンドを実行できるかもしれない。
これはclaude-codeみたいなものに結構関係してるよ。claude-codeはブロックリストと許可リストを使ったかなり基本的な権限管理をしてるからね。あるセッションでうっかりclaudeに「powershell」の権限を与えちゃったことがあって、その後はツールの使用がブロックされるたびに、例えばgitみたいに、同じことをするpowershellスクリプトを書いて実行して、ブロックされた権限を回避してたんだ。普通のシステムなら「powershell」が一般的な許可リストに入ってることはないけど、このページのテクニックを使って、ツール間で許可されているレベルに差があることを想像できるよね。
これがキュレーションされたリストだと思ってたから、AIがサンドボックスをバイパスする方法を学ぶためのものだと思ってたのに。
具体的な例を挙げると、数年前、うちのサポートチームがtcpdumpでネットワークキャプチャをする必要があったんだ。これを許可するための簡単で自然な方法は、sudoルールを追加して引数を開放することだった(ちょっとリスキーだけど、tcpポートやNICは変わるかもしれないからね)。これで十分良さそう?いや、そうじゃない… tcpdumpでは、"-z"オプションを使って圧縮コマンドを指定できるんだ。でも、特別な圧縮コマンドを実行してサーバーを完全に乗っ取ることを防ぐものは何もない:> sudo tcpdump -i any -z '/home/despicable_me/evil_cmd.sh' -w /tmp/dontcare.pcap -G 1 -Z root これって一見簡単そうだけど、実際には見逃しやすいことなんだよね。最近は、apparmorのようなセキュリティレイヤーがこのリスクを軽減してるけど(その過程でちょっとした頭痛の種にもなってる)、それでもミスをするのは比較的簡単なんだ。
> 誰かがsudoアクセスを許可したり、GTFOBinのSUIDビットを設定したりしたんだね。こういうトリックを使うと、設定した人が知らなかった方法で、機密ファイルを読んだり書いたり、特権コマンドを実行できるかもしれない。特権昇格を「調整」するために設計された企業向けのセキュリティソフトウェアには、管理者によって設定された許可リストが含まれてる。ある会社でこれが導入されたときの経験では、許可リストに載っているソフトウェアは、`sudo`で実行するのにパスワードが不要になってた。もちろん、許可リストには、vimやbashみたいな広く使われるソフトウェアが最初から含まれてた。私はその会社で在宅勤務してたんだけど、これが良いことだと思ったのを覚えてる。なぜなら、私のコンピュータを「安全」にするために導入されたソフトウェアが、キーボードから離れてロックを忘れたときに、誰かが近づいて何かを実行しようとするのを、逆に大幅に弱くしてしまってたから。
ハハ、これらのツールの元メンテナだったから、誰かがシェルをポップさせるのを見ると笑っちゃうよ。クリエイティブだし、いい仕事だね、いいリソースだ。
AirBnBでコンピュータのgrub編集をしなきゃいけなかったことがあるんだけど、ゲストアカウントで周辺機器が全部めちゃくちゃになってて(インターネットも音もなし、画面の一部しか見えない状態で、どうやってこんなことになったのか本当にわからない)、このリソースを見つけてすごく嬉しいよ。こういうのは、まあ、できれば必要ないけど、いざという時に持ってるとめちゃくちゃ役立つよね。
hackthebox.euでこれをめっちゃ使ったことあるよ。
> restic - Shell, Command, Upload うーん、バックアップがrootで動かないようにいじってたから、ちょっと自己満足感があるよ。普通のユーザーとして、全ファイルを読み取る権限を持って動いてるし、ログインシェルはないからね。もちろん、デスクトップではやりすぎかもしれないけど、そこまで来た攻撃者は基本的にコンピュータ上のほとんどのファイルを読めて、バックアップにバックドアを仕込むこともできるだろうね… [0] https://man7.org/linux/man-pages/man7/capabilities.7.html
これでLLMを微調整すべきだね。
最後にこんなのを使ったのは1995年頃の中学校で、Windows 3.11のコンピュータを使ってたときだったかな。あれは、限られた数の認可されたアプリケーションしか起動できないように設定されてた。その中の一つがWordだった。Wordではマクロを書いたり、シェルを使って他のアプリを起動したりできたんだ。突然、制限されたコンピュータが数個のアプリを公開してたのに、何でも(まあ、1995年のWindows 3.11マシンで動くものなら)実行できるようになった。あの時は結構ワクワクしたけど、それ以降は同じような問題には遭遇してないな。たまに、店舗やショッピングセンターのタッチスクリーン情報ディスプレイが、キオスクモード(アプリにロックされてる状態)から抜け出す方法があるって言ってる人を見かけるけど、それも似たような感じかな。