【デシリアライズ編】信頼できないデータを蘇らせるな｜CTF思考フレームワーク #15
安全に生きたい編集部
安全に生きたい
【SMB・ファイル共有編】共有フォルダから情報が漏れる条件と守り方｜CTF思考フレームワーク #25
安全に生きたい編集部
こんにちは、アンペンです。
今回は、SMB・ファイル共有を題材にして、CTFでよく出てくる「共有フォルダから情報が漏れる」流れを整理します。
SMBは、Windowsのファイル共有で使われる代表的な仕組みです。社内で「共有フォルダに資料を置く」「部署のメンバーだけが見られる場所を作る」「バックアップ用の置き場を作る」といった用途で使われます。便利な反面、設定を間違えると、ログインしていない人から共有名が見えたり、誰でも読めるフォルダに機密情報が残ったりします。
CTFでは、この「見えてはいけない共有」「読めてはいけないファイル」「置きっぱなしの認証情報」が次の足がかりになります。この記事では、単にコマンドを並べるのではなく、どこを見て、何を疑い、どの結果を手がかりに次へ進むかを中心に見ていきます。
注意：この記事の確認は、CTF、公式ラボ、自分で用意した検証環境だけで行ってください。実在する第三者のサーバに対して共有列挙や接続確認を行うことは避けてください。ここで扱う目的は、攻撃の乱用ではなく、設定不備に気づき、防御に戻すための学習です。
Contents
SMBは「社内の共有棚」だと考える
SMBを初めて学ぶときは、ネットワーク越しに置かれた共有棚だと考えると分かりやすいです。棚そのものがサーバで、棚板ごとの区切りが共有フォルダです。共有フォルダには名前があり、そこにファイルやフォルダが置かれています。
問題は、棚の場所を知っている人が、どこまで中を見られるかです。理想は、必要な人だけが、必要な棚だけを、必要な権限で使える状態です。ところが、設定が甘いと、ログインしていない人にも棚の名前が見えたり、棚の中身まで読めたりします。さらに悪い場合、書き込みまでできてしまいます。
共有フォルダって、社内にあるものだから外からは関係ないんじゃないの？
本来はそうあるべきです。ただ、CTFでも実環境でも、VPN、誤公開、内部侵入後の横展開などでSMBに到達できる場面があります。だから「SMBが見えたら何を確認するか」を知っておく価値があります。
SMBで最初に見るのは、「共有があるか」ではなく、「誰に、どの共有が、どの権限で見えているか」です。
観察：まず何が見えているのかを確認する
CTFでSMBらしいポートが開いていたら、最初に確認したいのはサービスの存在とバージョンです。代表的にはTCPの445番ポートが使われます。古い環境では139番ポートが関係することもあります。
nmap -p 139,445 -sV 10.10.10.10ここで見るべきなのは、「445が開いている」という事実だけではありません。Windows系なのか、Sambaなのか、古そうな実装なのか、ドメインやワークグループらしい情報が見えるか、という周辺情報も重要です。CTFでは、サービス名やバージョンが次の仮説につながります。
たとえば、Sambaが動いているならLinuxサーバの共有かもしれません。Windows Serverらしい応答なら、ドメイン環境や管理共有の存在を考えます。バージョンが極端に古いなら、既知の脆弱性を疑う前に、まず設定不備で読める情報がないかを見ます。CTFでは、いきなり脆弱性を探すより、認証なしで見える情報を丁寧に集める方が早いことが多いです。
仮説：匿名アクセスで共有名が見えるかもしれない
SMBで最初に立てる仮説は、「匿名または空の認証情報で、共有名だけでも見えるかもしれない」です。これは、いわゆるNULLセッションや匿名アクセスの確認に近い考え方です。
重要なのは、ここで「ログインできるかどうか」を見ているのではなく、「認証されていない状態で、どれだけ情報が返ってくるか」を見ていることです。ログインに失敗しても、共有一覧やサーバ名、ワークグループ名が返るなら、それ自体が手がかりです。
共有名が見えるだけなら、まだファイルは読めていないよね？それでも危ないの？
危ないです。共有名は地図です。backup や users のような名前が分かるだけでも、次に狙う場所を絞られてしまいます。
smbclient -L //10.10.10.10/ -N-L は共有一覧を見るための指定です。-N はパスワードなしで試す指定です。結果として、共有名が何も出ずに拒否される場合もあれば、IPC$ や print$ だけが見える場合もあります。CTFでは、public、backup、share、users、anonymous のような名前が出てきたら、優先して確認する価値があります。
| 観察した結果 | そこから立てる仮説 | 次に見ること |
|---|---|---|
| 共有一覧が見えない | 匿名列挙は閉じられているかもしれない | 別ポート、Web上のヒント、取得済みユーザー名の有無を確認する |
IPC$ だけ見える |
通常の管理・プロセス間通信用共有だけが見えている | 追加情報が取れるかを慎重に確認する |
public や anonymous が見える |
匿名で読める共有があるかもしれない | その共有へ接続し、ファイル名と権限を見る |
backup や users が見える |
認証情報や個人ファイルが残っている可能性がある | 読み取り可否、ファイル名、更新日を確認する |
検証：共有に入れるか、何が読めるかを確認する
共有名が見えたら、次は実際にその共有へ接続できるかを確認します。ここでも目的は、むやみにファイルを漁ることではありません。CTFで必要なのは、「次の手がかりになる情報があるか」を判断することです。
smbclient //10.10.10.10/public -N接続できたら、まずは ls で一覧を見ます。ファイル名だけでも多くの情報が得られます。readme.txt、notes.txt、backup.zip、users.txt、passwords.txt のような名前は、CTFではかなり強い手がかりです。逆に、何も見えない場合や権限がない場合は、その共有は現時点の足がかりではないと判断できます。
smb: \> ls
smb: \> get readme.txt
smb: \> get backup.zipここで大事なのは、取れたファイルの中身だけに飛びつかないことです。どの共有から取れたのか、匿名で取れたのか、特定ユーザーの認証情報で取れたのか、読み取りだけだったのか、書き込みもできたのかを記録します。CTFのWriteupでも、ここを残しておくと「なぜ次の行動に進んだのか」が読み手に伝わります。
記録：SMB調査では「どの権限で見えたか」を残す
SMBのWriteupで抜けやすいのが、権限の記録です。「共有に入れた」「ファイルが読めた」とだけ書くと、読み手にはその発見の重みが伝わりません。匿名で読めたのか、手に入れたユーザー名とパスワードで読めたのか、読み取りだけなのか、書き込みまでできたのかで、意味が大きく変わるからです。
たとえば、匿名で backup.zip を取得できたなら、それは設定不備としてかなり強い発見です。一方、Webから得た一般ユーザーの認証情報で共有に入れた場合は、「このユーザーに必要以上のファイル共有権限があるかもしれない」という別の問題になります。CTFであっても、この違いを意識して記録すると、単なる手順ではなく、判断の流れが残ります。
おすすめは、コマンド、認証状態、見えた共有、取得したファイル、次に使った場所を短く並べて残すことです。長いログを全部貼る必要はありません。あとで読み返したときに、「なぜSMBからSSHへ進んだのか」「なぜこのファイルを重要だと判断したのか」が分かれば十分です。
失敗しやすい見方：共有名だけで結論を出さない
SMBの確認でありがちな失敗は、共有名だけを見て「これは当たりだ」と決めつけることです。backup という共有が見えても、認証が必要で読めない場合があります。public という名前でも、中身が空の場合があります。反対に、目立たない名前の共有に重要なメモが置かれていることもあります。
もう一つの失敗は、いきなり総当たりや侵入系の発想に飛ぶことです。CTFでは派手な攻撃より、公開されている情報を正しく読む方が先です。匿名で読めるファイル、Webページに書かれたユーザー名、設定ファイルに残った接続情報など、最初の認証情報は意外と静かな場所から見つかります。
backup という共有があったら、そこが正解だと思ってよい？
名前は強いヒントですが、結論ではありません。読めるか、何が入っているか、どの権限で見えたかまで確認して初めて判断できます。
SMBで詰まったときは、「共有一覧」「共有へ入れるか」「ファイル名」「ファイルの中身」「取得したユーザー名やパスワードをどこで使うか」の順に戻って考えると、見落としを減らせます。
CTFでの考え方：SMBは次の入口を探す場所
SMB単体で終わる問題もありますが、多くの場合、SMBは次の入口を探す場所として使われます。共有フォルダからユーザー名が分かる。メモからパスワードの癖が分かる。バックアップからWebアプリの設定ファイルが見つかる。SSHの秘密鍵や、古いパスワードリストが置かれている。こうした情報が、Webログイン、SSH、RDP、管理画面、権限昇格へつながっていきます。
だから、SMBを調べるときは「このファイルにフラグがあるか」だけでなく、「この情報はどこで再利用できるか」を考えます。CTFの序盤でSMBが見えた場合、共有から得た情報を別サービスに横展開する流れはよくあります。
| SMBで得た情報 | 次に試す場所 | 考え方 |
|---|---|---|
| ユーザー名らしい文字列 | SSH、Webログイン、RDP | 同じユーザーが別サービスにも存在するか確認する |
| パスワードらしいメモ | ログイン画面、SSH、管理画面 | 使い回しや初期パスワードの可能性を見る |
| Webアプリの設定ファイル | Web、DB、管理画面 | DB接続情報や秘密鍵が含まれていないか読む |
| バックアップファイル | ローカル解析 | 展開して、古い設定・履歴・認証情報を探す |
守る側なら、共有の見え方を棚卸しする
守る側で見ると、SMBの防御は「使わないなら閉じる」「使うなら見える範囲を狭くする」「必要な人だけに最小権限を与える」という地味な作業の積み重ねです。
まず、外部からSMBに到達できる構成は原則として避けます。インターネットに445番ポートを公開する必要は通常ありません。VPNや社内ネットワークからのみ使う場合でも、誰がどの共有にアクセスできるのかを定期的に見直します。
次に、匿名アクセスを無効にします。共有一覧が見えるだけでも、攻撃者にとっては地図になります。共有名に backup や admin のような意味の強い名前を使う場合は、権限設定を特に厳しく確認します。
最後に、共有フォルダの中身を点検します。過去のバックアップ、退職者の作業ファイル、テスト用の認証情報、古い設定ファイルは、忘れられたまま残りがちです。SMBの危険は、プロトコルそのものだけではなく、「共有された場所に何を置いたか」から生まれます。
| 確認項目 | 良い状態 | 危ない状態 |
|---|---|---|
| 到達範囲 | 社内・VPNなど必要な範囲だけ | インターネットから445番へ到達できる |
| 匿名アクセス | 共有一覧も中身も見えない | 未認証で共有名やファイルが見える |
| 権限 | 読み取り・書き込みが役割ごとに分かれている | Everyoneに広い権限が付いている |
| 中身 | 公開してよいファイルだけがある | パスワード、鍵、バックアップ、個人情報が混在している |
| 古い機能 | SMBv1を無効化している | 古い互換性のためにSMBv1が残っている |
まとめ：SMBでは「見える範囲」と「読める範囲」を分けて考える
SMB・ファイル共有の問題では、いきなりフラグや脆弱性を探すより、まず見える範囲を丁寧に確認します。ポートが開いている。共有一覧が見える。共有に入れる。ファイル名が見える。ファイルを読める。この一段ずつの違いが、CTFでは次の判断材料になります。
攻撃者目線では、SMBは「内部の棚に残ったヒント」を探す場所です。守る側の目線では、SMBは「誰に何を見せているか」を定期的に棚卸しすべき場所です。便利な共有ほど、古いファイルや広すぎる権限が残りやすい。だからこそ、SMBを見つけたら、共有名だけで終わらせず、権限と中身まで観察する必要があります。
- SMBでは、445番ポート、共有一覧、共有への接続可否を順に確認する。
- 匿名で共有名やファイルが見える場合、それ自体が重要な手がかりになる。
- CTFでは、SMBから得たユーザー名・設定ファイル・バックアップを別サービスの入口につなげて考える。
- 守る側は、匿名アクセス無効化、最小権限、SMBv1廃止、共有フォルダの中身の棚卸しを行う。
次に読みたい記事
SMBで共有ファイルの扱いを学んだら、次はRDPのようなリモートアクセスの入口を見ていきます。共有フォルダと同じく、便利な入口は、公開範囲と認証の設計を間違えると大きなリスクになります。
RDP編｜リモートデスクトップを外部公開する危険と守り方 →
参考資料
SMBの防御を実務で確認する場合は、MicrosoftのSMBセキュリティ関連ドキュメント、CIS Benchmarks、組織内のファイル共有運用ルールを合わせて確認してください。CTFでは、公式ラボの範囲内で、共有の見え方と権限の違いを記録しながら学ぶのが安全です。
