google-like-a-spy

検索オペレーター

オペレーターを使うと、検索ボックスをクロール済みインデックスに対するフィルターとして利用できます。ただし、検索対象はウェブそのものではなく、誰かのインデックスです。カバレッジ、鮮度、オペレーターの忠実度は、検索エンジンによって大きく異なります。初心者がよくする間違いは、入力したとおりに検索が実行されたと思い込むことです。Google は検索語を削除したり、語幹処理したり、同義語に展開したりすることがよくあります。そのため、結果がゼロ件の検索クエリと、気づかないうちに書き換えられた検索クエリは、見た目はまったく違っても、どちらも同じように役に立ちません。

用途別の検索エンジン

求めるもの	使用する検索エンジン	理由
主流のウェブを幅広くカバー	Google	インデックスは最大ですが、オペレーターの忠実度は最低です
信頼性の高い site: の列挙、IP／ホストの探索	Bing	オペレーターをより文字どおりに適用します。ip: と contains: も使えます
非ラテン文字のスクリプト、ロシア語／CIS／トルコ語のコンテンツ、画像関連の検索	Yandex	クロールの優先順位が異なり、画像の照合に最も優れています
匿名での検索、検索エンジン間の素早い切り替え	DuckDuckGo, Startpage	他のインデックスをプロキシし、bang を使うと検索エンジンを切り替えられます
独自のクロール（大手3社が一度もインデックスしていないもの）	Mojeek, Marginalia, Brave	独自のクローラーを使っており、規模は小さいものの、実際に異なる結果が得られます
コード、バケット、ホスト、アーカイブ	専門インデックス	一般的なウェブインデックスでは、その大半がクロールされていません

検索クエリを1つの検索エンジンだけで実行しないでください。クローラーによって見つけたページは異なります。また、URL を一度もクロールしていない検索エンジンに対して、オペレーターを工夫してもその URL を検索対象に含めることはできません。どのオペレーターがどこで使えるのか、また同じオペレーターが別の場所ではどのように異なる意味を持つのかについては、reference/engine-operators.md を参照してください。

現在も機能するオペレーター

• "完全一致するフレーズ" — 最も役立つオペレーターです。書き換えの影響は受けますが（下記参照）、検索語を指定するうえで最も強いシグナルになります。
• site: — 完全なホスト名、登録可能なドメイン（サブドメインにも一致）、または TLD（site:gov.uk）を指定できます。除外する場合は -site: としても使えます。
• filetype: — Google で公式に案内されている形式です。Bing では filetype: と ext: の両方が使えます。ext: は検出されたコンテンツタイプではなく URL の拡張子に一致します。.env、.bak、.sql を探す場合は、通常こちらが適しています。
• intitle:／allintitle:、inurl:／allinurl:、intext:／allintext:。all* 形式は後続するすべての検索語に適用されますが、他のオペレーターとは相性がよくありません。単独で使ってください。
• YYYY-MM-DD を指定する before:／after: — Google が推定したドキュメントの日付で絞り込みます。この日付は推定値であり、間違っていることもよくあります。これは大まかなふるい分けであって、証拠ではありません。
• -term で除外、OR（大文字）または | で選択、括弧でグループ化、フレーズ内の単一トークンのワイルドカードとして * を使用できます。

今では使う意味がないのに、いまだに紹介されるオペレーター

cache: と info: は廃止され、link: はかなり前に廃止されており、残っている挙動もノイズにすぎません。また、related: の動作は一貫していません。inanchor: と AROUND(n) は公式に案内されたことがなく、予測不能な動作をします。強制的に含める + と同義語展開の ~ は完全に削除され、前者の代わりに引用符が使われるようになりました。daterange: は before:／after: に置き換えられました。これらを使った検索クエリ集では、エラーではなく一般的な検索結果が返されます。

リテラル一致を強制する

Google の検索レイヤーは、キーワードフィルターを後付けしたセマンティックマッチャーです。 有用性が低いと判断した語句を除外したり、類義語に置き換えたり、誤字だと思った箇所を修正したりします。これは、ユーザー名やエラー文字列を探すときには、まさに避けたい動作です。

1. 検索結果のヘッダーを確認します。Google は、語句を除外した場合、「Must include:」リンクとともに「Missing: <term>」と表示します。このリンクをクリックすると、その語句を必須にして再検索します。これが表示された場合、ドークは意図したとおりに実行されていません。
2. 特に分かりにくいトークンは、フレーズ全体だけでなく、個別にすべて引用符で囲みます。
3. Verbatim モードに切り替えます（Tools を選び、「All results」ドロップダウンを開きます）。ステミング、類義語、スペル修正、パーソナライズが無効になります。これを使わないドーキングは当てずっぽうです。
4. 重複フィルターを拡張します。Google は「非常によく似た」検索結果をまとめて表示し、最後のページの末尾に、それらも含めて検索を繰り返すリンクを表示します。site: で列挙する場合、これによって表示される結果が倍増することがよくあります。
5. 修正後のスペルが依然として優先される場合、クエリはナビゲーション目的だと解釈されています。それを覆すため、2 つ目の珍しいトークンを追加します。

対象のサイト以外で対象の資料を探す

組織が漏えいさせた情報の多くは、別の場所でホストされています。そのため、対象ドメインでドークして見つかることを期待するのではなく、ホストをくまなく調べます。たとえば、ペーストサイトやデッドドロップサイト、コードサンドボックス、ウェブ公開されたオフィス文書、全文検索可能なドキュメントリポジトリ、s3.amazonaws.com や blob.core.windows.net などプロバイダー所有のホスト名にあるクラウドオブジェクトストレージ、公開共有がデフォルトのサードパーティ製 SaaS（カンバンボード、Wiki、フォームのバックエンド、ステータスページなど）です。site: では顧客ではなく、プロバイダーを指定します。

防御を目的とした探索ドーキング

評価の許可を得ているドメイン、または自分が管理する環境に対して実行してください。検索結果を読むのは受動的な行為です。検索エンジンがすでにページをクロールしているためです。見つけたファイルを取得したり、バックアップをダウンロードしたり、パネルにログインしたりする行為は受動的ではありません。そこに法的な境界があります。

ヒット率のおおよその高い順に、効果の高い検索パターンを示します。移行後も残っているディレクトリ一覧（intitle:"index of"）、拡張子で探す設定ファイルや環境ファイル、データベースダンプやバックアップのファイル、インデックス化されたテキスト内の認証情報らしき文字列、プロバイダーのホスト名にあるオブジェクトストレージ、ホスト名からアクセスできる管理インターフェースや監視インターフェースです。人やドキュメントを探すクエリを含む全一覧は、reference/dork-cookbook.md にあります。

検索エンジンがインデックス化するのは、何かからリンクされているものだけです。そのため、リンクされていないパネルやバケット一覧は、インデックスにほとんど含まれません。稼働中のサービスを調べるには、find-exposed-servers を使ってスキャンしてください。現在は 404 を返す検索結果も、依然として証拠になります。その URL を read-deleted-pages に渡してください。

レート制限、CAPTCHA、そして自動化が失敗する理由

検出は主にリクエストの頻度に基づくものではありません。エンジンはクライアントのフィンガープリントを識別します。 TLS ハンドシェイクの特性、ヘッダーの順序、JavaScript が実行されたかどうか、 タイミングの挙動、送信元 IP のレピュテーションなどです。JavaScript を一度も レンダリングしたことのないデータセンターの IP は最初のリクエストでチェックに引っかかりますが、 人間のペースで実際のブラウザーを操作する住宅用 IP なら、一日中 dork できます。だからこそ、 同じクエリを手入力すればうまくいくのに、ループを遅くしても失敗することがよくあります。

最も厄介なのは CAPTCHA ではなく、正常に見える結果セットの劣化です。検索演算子が ひそかに無視され、結果が切り詰められても、何の表示もありません。スクリプトによるクエリが ブラウザーと同じ結果を返したと思い込まないでください。

認可された手段を、優先順位順に示します。エンジンが提供している場合は公式の検索 APIを 使います。利用規約の範囲内ですが、割り当て量が設けられており、一般向け UI と同等の結果は 期待できません。API のインデックスとランキングは、別の製品であることがよくあるためです。 商用 SERP プロバイダーは、プロキシインフラを運用し、構造化された結果を返します。有料であり、 それでも誰かの利用規約のもとでスクレイピングを行っています。自分で運用する SearXNG インスタンスは、 複数のエンジンの結果を正規化します。公開インスタンスは使わないでください。他人のレート制限に関する レピュテーションを引き継ぎ、検索条件をその運営者に渡すことになります。そして、ブラウザーで手動検索します。 実際の調査に必要な 20～50 件のクエリなら、自動化を構築するよりこちらが優れています。

検出を逃れるための IP ローテーションは、技術的なアクセス制御の回避にあたります。 スクレイピングとは法的な立場が大きく異なるため、ここでは扱いません。 クエリ自体も記録され、追跡可能です。機微な検索条件は、ログを記録しないエンジンか 隔離された環境を経由させてください。詳しくは investigate-without-getting-made を参照してください。

特化型インデックス

これらはそれぞれ異なるコーパスを取り込み、Google では答えられない質問に答えます。

• コード検索。 GitHub のコード検索は公開リポジトリを対象とし、grep.app と searchcode は複数のホストをまたいでインデックス化しています。名前ではなく、内部ホスト名、 キーのプレフィックス、対象のメールドメインを検索してください。secrets-in-git-history を参照してください。
• クラウドストレージのインデックス。 Grayhat Warfare などのバケットインデックスは、 エンジンよりはるかに多くの公開オブジェクトストレージを列挙します。リスティングページは、 クロール可能な場所からリンクされていないことが多いためです。
• ドキュメントリポジトリ。 Scribd、Issuu、SlideShare、DocumentCloud、学術論文の アグリゲーターは、アップロードされたファイルを全文インデックス化し、自社ドメインには まったく掲載されていない PDF に埋もれた企業名を見つけ出します。
• 生 HTML のインデックス。 Publicwww などはページのソースを検索できるため、 アナリティクス ID やタグマネージャーのコンテナを手掛かりに探索できます。共有 IP よりも、 共有トラッカー ID のほうが共同所有の証拠として有力です。1 つのアカウントで両方が設定されています。
• アーカイブのインデックス。 Wayback CDX API と Common Crawl のインデックスは、 ランキング付き検索ではなく、クエリ可能な URL コーパスです。クローラーが観測したパスを、 長い間削除されたものも含めて列挙します（read-deleted-pages）。スキャナーはページではなく ホストをインデックス化します（find-exposed-servers）。漏えいコーパスについては find-leaks-in-the-wild を参照してください。

うまくいかない場合

• 入力したクエリと実際に実行されたクエリは異なります。 ステミング、同義語、スペル修正、検索語の削除がデフォルトで適用されます。Verbatim を使わなければ、結果がゼロでも意味がありません。
• 結果がゼロでも、あるインデックスが「ない」と判断したにすぎません。それは、そのエンジンのクロール状況と演算子のサポートについての説明であり、ウェブ全体についての説明ではありません。存在しないことを記録する前に、3つのエンジンとアーカイブで確認してください。
• site: ですべてを網羅することはできません。 Google は大幅に切り詰めて重複を除外し、Bing はより深く検索しますが、どちらも網羅的ではありません。検索結果数は推定値なので、決して引用してはいけません。正確な件数が必要なら、最後までページをたどってください。
• インデックスは古いミラーです。 ヒットした結果が示すのはクロール時点のページです。現在のページは異なる場合や、すでに消えている場合があります。また、スニペットだけが残っている唯一のコピーかもしれません。現在の URL で確認し、すぐにアーカイブしてください。
• before:／after: は推定された日付で絞り込みます。 CMS を使ったサイトでは、ページの表示時に日付が更新されることがあります。公開時期を確定するために、これらを使わないでください。
• パーソナライズと地域によって結果は変わります。 同じ検索演算子を使っても、調査担当者によって異なるページが表示されます。そのため、エンジン、クエリ、日付を記録してください。
• コピーされた検索演算子のライブラリは、気づかれないまま劣化します。 廃止された演算子がエラーではなく検索語として扱われると、もっともらしい一般的な結果が返り、フィルターが適用されなくなったことに気づけません。
• クローキングとインデックス汚染。 クローラーにはユーザーと異なるコンテンツが提供されることがあり、SEO スパムによって対象の名前が無関係なページに埋め込まれることもあります。名前が記載されていても、関係があるとは限りません。

信頼度の評価

• 確認済み — ライブ文書またはそのアーカイブを取得して読み、文書の内容が事実を直接述べており、そのメタデータまたはホストによって出所が裏付けられている。
• 可能性が高い — 権威あるホストに特徴的な完全一致の文字列がある、または独立した2つのクロールで同じ事実が確認できる。開けなかったスニペットからの情報は、せいぜい「可能性が高い」にとどまります。
• 未確認 — スニペットのみの情報、他者のコンテンツを転載するサイトでのヒット、一般的な単語の一致、Verbatim で実行していないクエリから得られた情報。
• 棄却 — Verbatim を使わない場合にのみ一致するもの、または内容が機械生成の名前収集によるページでの言及。

URL、エンジン、クエリ文字列、取得日を記録してください。誰も再実行できない結果は証拠ではありません。

例

目的：サプライヤーデューデリジェンス用ファイルのために、Example Corp で調達を担当している人物を特定します。ウェブサイトには、取締役会より下の役職者の名前が掲載されていません。

Verbatim で site:example.com filetype:pdf procurement を実行すると、4件の文書が返されます。そのうち1件はサプライヤー向けオンボーディング資料で、PDF のプロパティに作成者文字列 m.okafor と、部門のネットワーク共有上にあるテンプレートのパスが含まれています。本文には誰の名前もありませんが、これにより新たな検索条件が2つ見つかりました。

行き詰まり："m.okafor" site:linkedin.com/in では何も見つかりません。ハンドル名だけで検索しても同様です。プロフィールが存在しないか、インデックスに含まれていないのでしょう。

メールアドレスの形式に書き換えるとうまくいきます。"[email protected]" を検索すると、無関係なドメインにある公開メーリングリストのアーカイブが見つかります。同じ人物が、技術的な質問にフルネームと役職を添えて投稿しています。さらに、対象ホストを Bing で ext:xlsx を使って調べると、役職を裏付けるサプライヤー登録簿が見つかります。

評価：役職は確認済みです。取得して読んだ2つの文書で裏付けられています。個人の特定は可能性が高いにとどまります。ハンドル名と名前の対応を裏付けているのは、本人が署名した投稿1件だけだからです。

ピボット

新しいセレクター	遷移先
filetype: で見つかった文書ファイル	secrets-in-file-metadata
インデックスされた URL 内のホスト名とサブドメイン	find-hidden-subdomains、who-owns-this-domain
検索結果の背後にある稼働中のサービスとバケット	find-exposed-servers
リポジトリ、gist、キーのプレフィックス	secrets-in-git-history
インデックスされたテキスト内のハンドル名とユーザー名	hunt-a-handle
文書から収集されたメールアドレス	what-an-email-reveals
スタッフページから得られる名前と役職	find-anyone、x-ray-a-company
ペーストサイトの検索結果と漏えいしたセレクター	find-leaks-in-the-wild
404 になった検索結果	read-deleted-pages
そこから判明したホストと身元情報のクラスター	graph-the-network

法的事項と ToS に関する注意

自動クエリは、主要な検索エンジンすべての利用規約に違反します。これは契約上の問題であり、通常の結果はブロックされることです。しかし、IP をローテーションしたり CAPTCHA をプログラムで解いたりしてそのブロックを回避する行為は、技術的なアクセス制御の回避にあたり、複数の法域でより重大な問題となります。

公開されているファイルを見つけても、それを取得する権限が与えられるわけではありません。検索結果は公開されていますが、その背後にあるファイルは、コンピューター不正利用法において依然として保護対象のコンピューターに該当する場合があります。「Google に載っていた」という主張は抗弁として認められていません。許可された評価の範囲内では、記録を残し、持ち出さず、合意済みの窓口を通じて報告してください。それ以外の場合は、運営者または各国の CERT に通知し、そこでやめてください。

インデックスされた個人データも個人データであり、検索してもその性質が変わることはありません。検索結果からの削除申請によって、欧州の検索結果には意図的に表示されず、他の地域では表示される状態になることもあります。そのため、何かが消えたと結論づける前に、地域ごとに比較してください。../../ETHICS.md に従い、最小限にとどめてください。