【Google Dork編】検索演算子で機微情報を引き出す受動偵察|CTF思考フレームワーク R05

Google Dork って、検索演算子の魔法?🔮

魔法というより『検索の上級活用』。site:、filetype:、inurl: などの演算子を使って、Google が無自覚にインデックスした機密ファイル・設定ファイル・露出パスワードを発見する技術。Google Hacking Database (GHDB) に何千ものパターンが登録されています。
Google Dorking は、検索演算子(site: filetype: inurl: intitle:)を駆使して、機微情報を引き出す受動偵察。Google Hacking Database(exploit-db.com/google-hacking-database)には『filetype:pem private』『intitle:index.of passwd』など、機密情報を狙うクエリが何千も登録されています。
広告・PRを含みます。この記事にはアフィリエイトリンクが含まれます。掲載内容は編集方針に基づいて作成していますが、価格・在庫・キャンペーン内容はリンク先で最新情報を確認してください。

Google が機密ファイルを索引してることもあるんだ…
この記事は、CTF思考フレームワーク Recon編 R05。Google Dork の代表クエリと、自社サイトから漏れている可能性のあるファイルの探し方、robots.txt / noindex の正しい設定、CSE(Custom Search Engine)の活用を整理します。
Google Dork(Googleハッキング)は、検索演算子を駆使して「公開検索エンジンに引っかかってる機微情報」を見つける受動偵察の代表格。スキャンせずに、ブラウザだけで衝撃的な情報が拾えてしまう怖くも便利な世界です🔎
ツールも特殊な権限も要らない。それなのに、漏洩したクレデンシャル、内部URL、バックアップファイルが検索結果に並ぶことがあります。
先に意味を押さえておくと読みやすい用語です。
- CTF: セキュリティの練習問題を解く競技。必ず許可された環境だけで試します。
難易度:★☆☆(初級) / この枝ルートの記事は、必要な回だけ選んで読めます。
👀 観察フェーズ:まず何を見る?
演算子は組み合わせて使うのが本領。site:target.com filetype:pdf intext:”confidential” のように複合化すると一気に絞り込めます。
🤔 仮説フェーズ:攻撃者は何を考える?
攻撃者はまず「この組織は何を出してはいけないファイルを、Webサーバの公開ディレクトリに置いていそうか」を考えます。具体的には、開発者が忘れた .env や config.php.bak、エクスポートし損ねた database.sql、社内向けに作った社員一覧 Excel あたりが筆頭候補です。さらに『site:target.com -site:www.target.com』で開発・検証用サブドメインだけを抽出したり、『intitle:”index of” “parent directory” site:target.com』でディレクトリリスティングが残っているホストを炙り出したりと、組織の癖を読みに来ます。
「自分は出してない」と思ってても、第三者(協力会社、退職者、外部ツール)経由で公開されてる事例はとても多いです。
🔬 検証フェーズ:どうやって確かめる?
実際の検証は、広いクエリから絞り込むのが定石です。まず『site:target.com』で Google にインデックスされているページ全体を眺め、ヒット件数とサブドメインの分布を把握します。次に『site:target.com filetype:pdf OR filetype:xlsx OR filetype:docx』で配布されている文書だけを抜き出し、社内向けらしいタイトルが混じっていないかを見ます。最後に『site:target.com inurl:admin OR inurl:login OR inurl:debug』『site:target.com intext:”BEGIN RSA PRIVATE KEY”』のように具体的なシグナルでピンポイント検索する、という三段構成が定番です。
⚔️ 攻撃フェーズ:実際の手口
よくあるシナリオは、ステージング環境からの情報漏洩です。攻撃者が『site:*.target.com -site:www.target.com』を叩くと dev.target.com がヒットし、さらに『site:dev.target.com filetype:env』を重ねると、Basic 認証を掛け忘れた dev サーバから .env が一発で落ちてきます。中身には本番と同じ DB パスワードや Stripe の sk_live キーが書かれていた、という事故が実際に何度も報告されてきました。Google のキャッシュには削除後しばらく残るため、消したつもりでも 1〜2 週間は閲覧可能、という点も攻撃側に有利に働きます。
CTF{public_search_engines_index_secrets_too}
Google Dorkは「攻撃者が一番最初にやる調査」かもしれません。コストゼロで成果が出ることがあるので、外せない手順です。
🛡️ 防御フェーズ:どう守る?
守る側はまず、自社ドメインに対する Dork を週次で自動実行する仕組みを持つのが出発点です。Pagodo や custom スクリプトで『site:yourdomain.com filetype:env|sql|bak|log』『intitle:”index of” site:yourdomain.com』などを Google・Bing・Yandex に投げ、新規ヒットを Slack に流します。並行してアプリ側では、.env や .git をそもそも公開ディレクトリに置かない CI ルール、Web サーバ側で .bak や .sql を 403 にする設定、そして Search Console から『古いコンテンツの削除』を即時申請できる手順書を整備しておくと、検出から消し込みまでのリードタイムが大きく縮みます。
🧪 自分で検証ラボを作る
Reconコマンドを安全に試すには、自分専用の検証ラボが一番。🏗️ ConoHa VPSなら月額数百円からLinux環境を立てられ、nmapやgobusterなどのツールを「自分のサーバ」に打ち込んで安全に試せます。
※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。
⚠️ よくある落とし穴
Dork 対策でつまずきやすいのは、検知の網が狭すぎるパターンです。Google だけ監視していて Bing や Yandex に残った古いキャッシュを見逃したり、メインドメインだけ見て買収子会社や旧サービスのドメインを放置していたり、というケースが目立ちます。また robots.txt に Disallow を書けば隠せると誤解して、逆に「ここに機密がありますよ」と教えてしまう設定もよく見かけます。Disallow ではなく noindex メタタグや認証必須化、そして根本的にはファイル自体を公開領域に置かない設計、この三段で考えるとミスを減らせます。
- 「うちは小さい会社だから検索されない」と思い込む(攻撃者は無差別に拾う)。
- 本番設定ファイルをWebサーバから直接配信できる場所に置く。
- GitHub上で「private repo」と思って実はpublicだった、を放置。
- 古い案件で使った資料がGoogleにキャッシュされ続けるのを放置。
- Dork監視を「Googleだけ」に頼り、Bing・Yandex・GitHub検索を見ない。
- 漏洩時の対応SLAを定めず、発見後も無効化が遅れる。
🧰 ツール早見表
Dork まわりで実用度の高い道具を整理しておきます。受動偵察の入口は Exploit-DB の Google Hacking Database、自社ドメインへの定期スキャンには Pagodo や dorkbot、コードリポジトリ側の漏洩検知には trufflehog と gitleaks、継続監視には Google Alerts と GitHub Secret Scanning がそれぞれ役割を持ちます。一つで全部やろうとせず、検索エンジン側・コード側・通知側で別々に組み合わせるのが結果的に運用しやすい構成です。
| ツール | 用途 | ひと言 |
|---|---|---|
| Google Hacking Database (GHDB) | Dork事典 | Exploit-DB管理、定番 |
| Pagodo / dorkbot | Dork自動化 | 自社向け定期スキャンに |
| trufflehog / gitleaks | GitHub漏洩検出 | 過去コミットも対象に |
| Google Alerts | 継続監視 | 機微キーワード+ドメイン |
| GitHub Secret Scanning | プッシュ保護 | GitHub Advanced Security |
🎓 本気で学びたい人へ
Recon・OSINTを絵空事だけで終わらせず、セキュリティエンジニアをキャリアとして目指したい方に。🎓 ササエルは現場で使えるスキルを体系的に学べるスクールです。
📚 もっと深く学びたい人へ
体系的に攻撃と防御の両面を学びたいなら『ホワイトハッカー入門 第2版』が分かりやすい入口です📚
📚 次に読みたい
- 【Recon統合運用編】偵察結果を攻撃計画に落とすASMの発想|CTF思考フレームワーク R06
- 【GitHub・コードリポジトリ偵察編】コミットに眠るシークレットを掘る|CTF思考フレームワーク R07
- 【ログイン画面の攻撃者目線】何を狙う?どう守る?|CTF思考フレームワーク #01
✍️ 学んだことを発信する
セキュリティブログを自分で始めたい方へ。🌐 ConoHa WINGなら初期費用無料でWordPressを起こせ、学んだことをアウトプットしていけます。



