【Metasploit】hashdumpの中身：なぜcatで済む場面でもツールを使うのか

Metasploit のような侵入テストのフレームワークには、標的に入り込んだ後、パスワードのハッシュを「自動で取得」してくれる機能があります。コマンド一つで結果が出るので、つい中身を意識せずに使ってしまいがちです。ですが、その裏で何が起きているのかを分解すると、Linux がパスワードをどう守っているか、そしてツールに任せるべき場面とそうでない場面の見分け方が見えてきます。
この記事では、ハッシュ取得という一つの操作を通して、それを整理していきます。

はじめに：ポストエクスプロイトの「ハッシュ自動取得」とは何か

侵入テストのフレームワークには、標的に入り込んだ後の作業を助ける「ポストエクスプロイト（post-exploitation）」の機能があります。侵入そのものを行う機能とは別カテゴリで、すでに足がかりを得た状態から、情報を集めたり権限を広げたりするための道具群です。

その代表格が「パスワードハッシュの取得」です。Linux では、各ユーザのパスワードはそのままの文字列ではなく、ハッシュ化された状態で保存されています。ハッシュは元に戻せない一方向の変換なので、それ自体を見てもパスワードは分かりません。しかし、このハッシュを手に入れれば、後からオフラインでじっくり突き合わせ（クラック）にかけられます。だから攻撃側にとって、ハッシュの取得は侵入後の定番作業になります。

ここで面白いのは、後処理ツールの「ハッシュ自動取得」機能が、実は単にファイルを1つ読んでいるだけではない、という点です。そして root 権限さえあれば、その中身は標準コマンド一発でも読めてしまう。「ツールが自動でやってくれること」の中身を分解すると、Linux のパスワード保管の設計思想と、ツールを使う意味・使わない方がいい場面がはっきり見えてきます。本記事ではそこを追いかけます。

Linux はパスワードをどこに、どう隠しているか

まず土台として、Linux がパスワード情報をどう保管しているかを押さえます。鍵になるのは「2つのファイルへの分離」です。

かつて初期の Unix では、パスワードのハッシュはユーザ情報と一緒に /etc/passwd に書かれていました。ところが /etc/passwd は、ユーザ ID と名前の対応など多くのプログラムが日常的に参照するため、**全ユーザが読める（world-readable）**必要があります。ハッシュがそこに置かれていると、誰でもコピーして、手元でゆっくり総当たり攻撃にかけられてしまう。これが問題でした。

そこで登場したのが「シャドウパスワード」の仕組みです。パスワードのハッシュだけを /etc/passwd から切り離し、root しか読めない /etc/shadow に移しました。/etc/passwd のパスワード欄には x という印だけが残り、実体は /etc/shadow にある、という構成です。

両者の役割を整理すると次のようになります。

両者は先頭のユーザ名フィールドで結びついています。この「分離しておいて、必要なときに突き合わせる」設計が、後で出てくる unshadow の話につながります。

/etc/shadow の権限はディストリビューションごとに異なる

ここで一つ、実機で確認して初めて気づいた点があります。「shadow は root だけが読める」と単純化されがちですが、正確にはディストリビューションによって設定が異なります。

今回触れた標的は Ubuntu で、shadow の権限は次のようになっていました。

-rw-r----- 1 root shadow 1240 ... /etc/shadow

所有者が root、グループが shadow、パーミッションが 640。つまり root は読み書き可、shadow グループに属するユーザは読み取り可、その他のユーザは一切アクセス不可、という状態です。Linuxize の解説によると、これは Debian・Ubuntu 系の標準で、一方 Fedora・RHEL 系では所有者・グループともに root、パーミッションは 0000（root 以外は完全に不可）になっているとのことです。

どちらの場合でも、一般ユーザがハッシュを読めないという結論は変わりません。そして root は、そもそもファイルのパーミッションチェックを飛び越えるので、権限表記がどうであれ読めます。この「root は権限を素通りする」性質が、後の話の前提になります。

「読めない」という壁 ――― 権限エラーの意味

さて、侵入後に一般ユーザ権限のセッションからハッシュ取得ツールを走らせると、次のように弾かれることがあります。

Post aborted due to failure: no-access: Shadow file must be readable in order to dump hashes

「ハッシュを吸い出すには shadow ファイルが読めないといけない」というエラーです。これはツールの不具合でも操作ミスでもなく、今のセッションの権限が /etc/shadow に届いていないというだけの、極めて素直な結果です。

前節のとおり /etc/shadow は一般ユーザには読めません。侵入直後に得られるのは、多くの場合その標的上の非特権ユーザの権限です。だからこの壁にぶつかる。裏を返せば、このエラーは「まだ権限が足りていませんよ」という明確なサインであり、次にやるべきことは「権限を root に引き上げること」だと教えてくれています。

今回のケースでは、操作しているユーザが sudo を使える設定で、かつパスワードも判明していたため、正攻法で root に昇格できました。ハッシュ取得はその後であっさり成功します。権限の壁は、乗り越え方さえ分かっていれば行き止まりではありません。

ここで押さえておきたいのは、順序として「権限 → 取得」であって、その逆ではないということです。ツールが失敗したとき、ツールの使い方を疑う前に「そもそも読める権限があるか」を確認する。この切り分けの癖は、他の場面でも効きます。

侵入の入口も「足がかりと本体」の2段構えだった

ハッシュ取得の中身に入る前に、その手前で使った「侵入の入口」にも、実は同じ「ツールが裏で自動でやっている」構造が隠れていた話を挟みます。これを知っておくと、後の unshadow の話がより立体的に見えます。

侵入テストのフレームワークで標的に送り込む実行ファイル（ペイロード）を作ると、そのサイズが驚くほど小さいことに気づきます。今回 Linux 向けに作った実行ファイルは、わずか 250 バイト程度でした。ところが、実際にセッションが確立した瞬間には、次のようなメッセージが表示されます。

Sending stage (3106788 bytes) to (標的のIP)

約 300 万バイト、つまり 3 MB 近いデータが「stage（ステージ）」として送られています。250 バイトの実行ファイルから、なぜ 3 MB のものが出てくるのか。ここに「staged payload（ステージド・ペイロード）」という仕組みがあります。

標的に送り込んだ 250 バイトのファイルは、多機能な本体そのものではなく、本体を呼び込むための最小限の足がかりでした。この足がかりを「stager（ステージャ）」と呼びます。stager の仕事はただ一つ、攻撃側マシンへ接続を張り、そこから本体を受け取ってメモリ上で起動することだけです。Metasploit の公式ドキュメントでも、staged payload は「できるだけコンパクトに作られ、より大きなものをアップロードする手段を提供するという単一の役割を果たすペイロード」と説明されています。

なぜこんな2段構えにするのか。公式ドキュメントは、その理由の一つとして「バイナリを使ったエクスプロイトでは、シェルコードを置けるスペースがごくわずかしかないことが多い」点を挙げています。脆弱性を突いて一瞬だけコードを実行できる隙間は、たいてい非常に狭い。そこに 3 MB の本体は入りません。だから、まず極小の stager だけを送り込んで足がかりを作り、本体（多機能なセッション）は接続確立後に後から送り込む。この分割によって、狭い隙間からでも高機能なセッションを立ち上げられるわけです。

これが「Sending stage」の正体です。250 バイトの実行ファイルはあくまで呼び出し役で、あなたが最終的に手にする多機能なセッションの実体は、接続後に攻撃側から送られてきたもの。「小さな入口から、本体は後で自動で送り込まれる」という構造は、この後で見る「ツールが shadow を読んだ後、自動で unshadow して保存する」という自動処理と、根っこは同じ発想です。ツールは、目に見える一手の裏側で、いくつもの工程を勝手にこなしてくれています。

ツールは内部で何をしているのか

権限さえ通れば、ハッシュ取得ツールはあっさり結果を返します。ここで肝心なのが、「では、このツールは cat /etc/shadow と何が違うのか」という問いです。

結論から言うと、root 権限で実行する限り、得られる生のハッシュ文字列そのものは同じです。ツールが shadow の内容を読んでいるのは間違いありません。しかし、ツールの仕事はそこで終わりません。

思い出してほしいのが、パスワード情報が2つのファイルに分離されていたことです。ハッシュは /etc/shadow にありますが、そのハッシュがどのユーザのどんな設定に紐づくかという情報は /etc/passwd にあります。ハッシュをクラックツール（John the Ripper や hashcat）にかけるには、この2つを突き合わせて1つの形式に戻す必要があります。この結合作業を「unshadow」と呼びます。

ハッシュ取得ツールは、この unshadow を自動でやってくれます。shadow を読むだけでなく、passwd と結合し、クラックツールがそのまま食べられる形式に整えて出力してくれます。手作業なら「passwd を読む」「shadow を読む」「結合する」「ファイルに保存する」と数手かかる工程を、ツールは一度の実行でまとめて片付けます。

cat とツールの違いを整理すると、こうなります。

つまりツールの価値は「shadow を読むこと」そのものではなく、「読んだ後の面倒な整形と管理をまとめて肩代わりすること」にあります。

補足として、ハッシュ文字列の見た目からも情報が読み取れます。今回得られたハッシュは $6$ で始まっていました。この先頭の記号はハッシュ方式の識別子で、Baeldung の解説によると $6$ は SHA-512 crypt を表します。ちなみに $1$ は MD5、$5$ は SHA-256 を指します。この識別子は、後でクラックツールに「どの方式で照合すべきか」を教える手がかりにもなります。

こうして見ると、ツールは shadow を読むだけでなく、その後の整形も保存もまとめて肩代わりしてくれる、頼れる存在に思えます。ただ、ここで一度立ち止まる価値があります。この自動処理は、いつでも必要なのでしょうか。

ツールの価値は、状況によって変わる

前節で見たツールの自動処理（unshadow と保存）には、確かに価値があります。ただしその価値は、いつでも同じように効くわけではありません。効く場面と、効かない場面があります。順に見ていきます。

効かない場面：1台だけなら cat で足りる

まず、ツールのありがたみが薄い場面から。標的が1台だけで、root も取れていて、ただハッシュを覗きたいだけなら、cat /etc/shadow が最短です。ツールを起動する手間もいらず、余計な痕跡も残しにくい。root にも昇格できる状況では、直接読む方が理にかなっています。

前節で「ツールは unshadow まで自動でやってくれる」と書きましたが、1台を覗くだけならその unshadow すら要りません。ハッシュを目で確認したいだけなら、cat で出てきた内容をそのまま見ればいい。ツールの自動処理は、この状況ではオーバースペックなのです。

効く場面：規模・異種環境・証跡が絡むとき

では逆に、ツールの自動処理が明確に「正解」になるのはどういう場面か。ここが分かると、なぜこの機能が用意されているのかが見えてきます。

複数の標的を扱うとき。 数十台に侵入して全台からハッシュを集めるとして、1台ずつ cat して手で unshadow するのは現実的ではありません。セッションに対して同じ処理を指定して回せるツールなら、桁違いに速く、取りこぼしも減ります。

Windows が相手のとき。 Linux の shadow と違い、Windows のパスワード情報は cat で読めるテキストではありません。レジストリやメモリ上の特定領域から、専用の手順で取り出す必要があります。ハッシュ取得ツールの本領は、むしろこちらの「単純には読めない対象」で発揮されます。

記録と再現性が要るとき。 業務としての侵入テストでは、「何を、いつ、どの標的から取得したか」を報告書に残す必要があります。ツールが取得物を整理して保管してくれると、この証跡管理が楽になります。

取得後すぐ次工程へ渡すとき。 unshadow 済みで保存されていれば、そのままクラックツールに投入できます。「読む」から「クラックする」までが一直線につながります。

「要るか要らないか」ではなく「どちらを使うべきか」

こうして並べると、ツールを使うべきかどうかは「ツールが優れているか、cat が優れているか」という道具そのものの優劣では決まらないことが分かります。決めるのは状況です。1台を覗くだけなら cat、規模や異種環境や証跡が絡むならツール。同じ道具が、状況次第で最適にも過剰にもなります。

大事なのは、この判断を自分でできることです。ツールの手順をなぞるだけの段階から、「この道具は今この状況で本当に必要か」を判断する段階へ。「便利そうだから使う」ではなく「今は効く側か、効かない側か」を見極める。この問いを持てるかどうかが、手順の暗記と実務の分かれ目になるのかと思います。

取得した成果物はどこに溜まるのか

後処理ツールが自動でやってくれることの一つに「取得物の保存」がありました。ここで、その保存先について整理しておきます。

侵入テストのフレームワークには、標的から集めたデータを保管する仕組みがあります。Rapid7 の公式ドキュメントでは、成功した攻撃が返してきた「定義しづらい情報」を保存する仕組みとして説明されています。今回のハッシュのような「標的から抜いてきた成果物」を、整理して貯めておく場所です。

重要なのは、これらの成果物が保存されるのは攻撃側のマシンであって、標的ではない、という点です。今回、ハッシュ取得ツールは結合済みのファイルを次のような場所に出力しました。

/root/.msf4/loot/ ... linux.hashes_...txt

このパスは攻撃側マシンの root ホームディレクトリ配下です。標的の中ではなく、手元に成果物が落ちてくる構成になっています。

そして、これは単なるファイル置き場ではありません。Rapid7 のドキュメントによれば、この成果物はデータベースと紐づいて管理され、専用コマンドで保存・取り出しができます。Hacking Articles の解説では、複数の標的を同時に扱うと成果物のテーブルはすぐ膨れ上がるため、データベース内で特定のエントリを検索・管理することが重要になる、と説明されています。

つまり、この成果物管理の本質は「どの標的から、いつ、何を取得したか」をホスト情報と結びつけて一元管理する点にあります。1台なら「ファイルが1個できた」程度の話ですが、多数の標的を相手にすると「このハッシュはどのホストのものだったか」が分からなくなる。それを追跡可能にしてくれる。前節で挙げた「複数ホストへの横展開」「証跡の一元管理」という価値は、まさにこの仕組みで実現されています。

守る側から見ると

ここまで攻撃側の視点で書いてきましたが、この一連の流れは守る側にとっても意味を持ちます。

一つは、/etc/shadow の権限そのものの点検です。ここまで見てきたとおり、shadow が一般ユーザに読める状態になっていれば、攻撃者は root を取る手間すらかけずにハッシュを持ち出せます。これは攻撃者が作り出すものというより、管理者側のミスで生まれる穴です。バックアップスクリプトの雑な処理や手作業のミスで、644（-rw-r--r--）のようにその他ユーザへ読み取りが漏れることは実運用で起こりえます。だから守る側は、shadow のパーミッションと所有者が想定どおり（Ubuntu/Debian なら 640 の root:shadow、RHEL 系なら 0000 の root:root）に保たれているかを、定期的に点検する価値があります。

もう一つは、後処理ツールの利用そのものが残す痕跡です。攻撃側が cat ではなく専用ツールを使うということは、標的上にツール特有のプロセスや挙動という足跡を残すということでもあります。攻撃側にとっての「作業を楽にする自動化」は、防御側にとっては「引っかけるための特徴」になる。そして、取得した成果物が攻撃側マシンに溜まるという性質は、インシデント対応で攻撃側マシンを解析できた場合、被害範囲を特定する重要な証拠になります。攻撃側の便利機能は、そのままフォレンジックの手がかりでもある、という対応関係です。

攻撃の手順を知ることは、攻撃するためだけでなく、その痕跡を見抜くためにも役立ちます。

図で見る「読めない壁」とツールの内部処理

ここまでの流れを一枚にまとめます。非特権ユーザのままでは shadow の壁に阻まれ、root 昇格を経て初めて、ツールが passwd と shadow を結合して成果物として保存できる、という道筋です。

flowchart TD
    A["侵入直後<br/>非特権ユーザ権限"] --> B{"/etc/shadow を<br/>読めるか"}
    B -->|読めない| E["権限エラー<br/>Shadow file must be readable"]
    E --> C["root へ昇格"]
    B -->|root なら読める| C
    C --> D["ツールが内部処理"]
    D --> D1["/etc/shadow を読む"]
    D --> D2["/etc/passwd と結合<br/>unshadow"]
    D1 --> G["成果物として保存<br/>攻撃側マシンに集約"]
    D2 --> G
    C -.->|1台だけなら| H["cat で直接読む<br/>でも十分"]

    classDef normal fill:#6474ef,color:#ffffff,stroke-width:0px
    classDef goal fill:#1f7a8c,color:#ffffff,stroke-width:0px
    classDef error fill:#fdecec,stroke:#c1121f,stroke-width:2px,color:#c1121f

    class A,C,D,D1,D2,H normal
    class G goal
    class E error

まとめ

• Linux はパスワードのハッシュを、world-readable な /etc/passwd から切り離し、root しか読めない /etc/shadow に保管している。この分離自体がセキュリティ設計である。
• shadow の権限はディストリで異なり、Ubuntu/Debian は 640（root と shadow グループ）、Fedora/RHEL は 0000（root のみ）。いずれも一般ユーザは読めず、root はパーミッションを素通りして読める。
• 「shadow が読めない」というエラーは権限不足のサイン。ツールを疑う前に権限を疑い、「権限 → 取得」の順で切り分ける。
• 後処理ツールが cat と違うのは、shadow を読むだけでなく passwd と結合（unshadow）し、クラック用の形式で保存し、成果物を管理してくれる点にある。
• root が取れて標的が1台なら cat /etc/shadow で足りる。ツールの真価は、複数標的・Windows など単純に読めない対象・証跡管理・次工程への連携といった条件が揃って初めて発揮される。
• 取得した成果物は攻撃側マシンに溜まり、ホスト情報と紐づいて一元管理される。これは同時に、フォレンジックで被害範囲を特定する手がかりにもなる。
• 侵入の入口で使うペイロードも2段構え（staged payload）。250 バイトの小さな stager がまず足がかりを作り、多機能な本体は接続確立後に「stage」として送り込まれる。狭い隙間から高機能なセッションを立ち上げるための設計であり、「入口は小さく、本体は後から自動で」という点でハッシュ取得の自動処理と発想が共通する。
• 守る側の要点は2つ。shadow の権限が正常（640/0000）に保たれ、ミスで緩んでいないかを点検すること。そして、攻撃側の自動化ツールは標的上に足跡を残し、成果物は攻撃側マシンに残るため、いずれも検知・追跡の手がかりになること。

参考にしたサイト

• Understanding the /etc/shadow File in Linux（Linuxize）
  shadow ファイルの権限がディストリビューションで異なること
• /etc/shadow and Creating yescrypt, MD5, SHA-256, and SHA-512 Password Hashes（Baeldung on Linux）
  ハッシュ先頭の $6$ が SHA-512 crypt を表す
• Meterpreter Stageless Mode（Metasploit 公式ドキュメント）
  staged payload の構造と、その設計理由
• passwd(5) man page（centos）
  /etc/passwd が world-readable である必要性と、shadow へハッシュを分離した経緯
• Database Support（Metasploit 公式ドキュメント / Rapid7）
  取得した成果物を保存する仕組み（loot）の位置づけ
• Scanning and Managing Hosts（Metasploit ドキュメント / Rapid7）
  成果物がデータベースに保存され、専用コマンドで管理できること
• Metasploit for Pentester: Database & Workspace（Hacking Articles）
  複数標的での成果物の検索・管理

海洋

NWエンジニア

XContact

ネットワーク・セキュリティを中心に、業務や検証環境で実際に触れた内容を記録しています。
現職ではネットワークの運用・構築を担当。

保有資格
ネットワーク：ネットワークスペシャリスト / CCNA
セキュリティ：情報セキュリティマネジメント / ISC2 CC
クラウド　　：AZ-104 / AZ-305
その他　　　：応用情報技術者 / LinuC レベル1

記事の内容に誤りなど見つけられた際は、ご指摘いただけると助かります。