【Metasploit】hashdumpとcatの使い分け：Linuxのパスワードハッシュ取得

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 に引き上げること」だと教えてくれています。

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

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

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

侵入テストのフレームワークで標的に送り込む実行ファイル（ペイロード）を作ると、そのサイズがとても小さいことに気づきます。今回 Linux 向けに作った実行ファイルは、わずか 250 バイト程度でした。

ところが、実際にセッションが確立した瞬間には、次のようなメッセージが表示されます。

約 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 を指します。この識別子は、後でクラックツールに「どの方式で照合すべきか」を教える手がかりにもなります。

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

前節で見たツールの自動処理（unshadow と保存）には、確かに価値があります。ただしその価値は、いつでも同じように効くわけではありません。そもそも cat /etc/shadow で直接読むという選択肢があり、どちらが適しているかは状況で変わります。まず、両者が実際には何を取得する手段なのかを整理します。

/etc/shadow からのハッシュ取得は、MITRE ATT&CK では T1003.008（OS Credential Dumping: /etc/passwd and /etc/shadow） という独立した攻撃手法として定義されています。そこでは、cat のようなコマンドで直接読む方法と、ポストエクスプロイトフレームワーク（今回のツール）を使う方法とが、同じ目的を達成する並列の手段として並べられています。つまり「ツールを使う」か「cat で読む」かは、優劣ではなく手段の選択です。

cat の利点：正規コマンドとして紛れ込める

cat の最大の利点は、それがOS に元から入っている正規のコマンドだという点です。cat はシステム管理で日常的に使われるので、ログに記録されても通常の運用と見分けがつきにくい。

これは「Living off the Land（環境に元からあるもので生きる）」と呼ばれる、確立した攻撃の考え方です。攻撃者がわざわざ自前のツールを持ち込まず、標的に最初からあるコマンドで目的を達成しようとするのは、検知を避けることが最大の狙いです。cat や cp のような正規バイナリは、セキュリティ製品が本質的に信頼しているため、悪用を正規の操作から切り分けるのが難しい。実際、MITRE には cat /etc/shadow でハッシュを盗んだ実在の攻撃活動（ShadowRay）も記録されています。

対して Metasploit のような後処理ツールは、標的上に特徴的なプロセスや挙動という足跡を残します。派手な機能と引き換えに、検知されやすくなる。だから「とにかく静かに済ませたい」場面では、cat の方が理にかなっています。

ツールの利点：規模・異種環境・証跡に効く

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

• 複数の標的を扱うとき
  数十台からハッシュを集めるとして、1台ずつ cat して手で unshadow するのは現実的ではありません。セッションに対して同じ処理を回せるツールなら、桁違いに速く、取りこぼしも減ります。
• Windows が相手のとき
  Linux の shadow と違い、Windows のパスワード情報は cat で読めるテキストではありません。レジストリやメモリ上の特定領域から、専用の手順で取り出す必要があります。ツールの本領は、むしろこちらの「単純には読めない対象」で発揮されます。
• 記録と再現性が要るとき
  業務としての侵入テストでは、「何を、いつ、どの標的から取得したか」を報告書に残す必要があります。ツールが取得物を整理して保管してくれると、この証跡管理が楽になります。
• 取得後すぐクラックへ渡すとき
  思い出したいのが、unshadow が「クラックツールにかけるための準備」だった点です。この先 John the Ripper などにかけるなら、cat で読んだ後に自分で passwd と結合する手間が出ます。unshadow 済みで保存してくれるツールなら、「読む」から「クラックする」までが一直線につながります。

「どちらが優れているか」ではなく「どちらを選ぶか」

こうして並べると、cat とツールのどちらを使うかは、道具そのものの優劣では決まりません。両者は、ざっくり次のようなトレードオフの関係にあります。

静かに済ませたいなら cat、規模や異種環境や証跡が絡むならツール。同じ目的に対して、状況次第でどちらが最適かが入れ替わります。

多くの場合はツールの自動処理が活きるでしょうが、どうしても穏便にいきたいといった場合などに 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 のような正規コマンドを選ぶ最大の狙いは検知回避でした。裏を返せば、防御側は「正規コマンドだから安全」とは言えません。cat /etc/shadow のような、正規だが本来その利用者がやらないはずの操作を、振る舞いから捉える必要があります。一方、Metasploit のような後処理ツールは標的上に特徴的なプロセスや挙動という足跡を残すため、そちらはそちらで検知の手がかりになります。加えて、取得した成果物が攻撃側マシンに溜まるという性質は、インシデント対応で攻撃側マシンを解析できた場合、被害範囲を特定する重要な証拠になります。

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

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

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

flowchart TD
    A["侵入直後<br/>非特権ユーザ権限"] --> B{"shadow を<br/>読めるか"}
    B -->|"読めない"| E["権限エラー<br/>Shadow file must be readable"]
    E --> C["root へ昇格"]
    B -->|"root なら読める"| C
    C --> D["ツールで取得<br/>規模・証跡に強い"]
    D --> D1["shadow を読む"]
    D --> D2["passwd と結合<br/>unshadow"]
    D1 --> G["成果物として保存<br/>攻撃側マシンに集約"]
    D2 --> G
    C -.->|"静かに済ませたいなら"| 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）し、クラック用の形式で保存し、成果物を管理してくれる点にある。
• cat で直接読むか、ツールを使うかは優劣ではなくトレードオフ。cat は正規コマンドなので検知されにくい（Living off the Land）。ツールは複数標的・Windows・証跡管理・クラックへの連携に強いが、特徴的な足跡を残す。静かに済ませたいなら cat、規模や異種環境が絡むならツール。
• 取得した成果物は攻撃側マシンに溜まり、ホスト情報と紐づいて一元管理される。これは同時に、フォレンジックで被害範囲を特定する手がかりにもなる。
• 侵入の入口で使うペイロードも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 の構造と、その設計理由
• OS Credential Dumping: /etc/passwd and /etc/shadow（MITRE ATT&CK T1003.008）
  cat による直接読み出しとフレームワーク経由が並列の手段であること、unshadow がクラック準備の工程であること、cat /etc/shadow を使った実在の攻撃事例
• Living off the Land（Vectra AI）
  正規コマンドを悪用する攻撃の狙いが検知回避にあること
• 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