不審なリンクを慎重に調べる方法

リンクを開く前に確認する

最初に確認するのは Web ページではなく、受信したメッセージです。送信者、 メールのヘッダー、表示されたリンクの文言、実際の URL、受信時刻を保存します。 誰かが開いたか、認証情報を入力したか、ファイルをダウンロードしたかも確認します。 単なる不審な連絡か、すでに対応が必要な事故かを判断する材料になります。

URL をデータとして読む。アクセスせずに、通信方式、 ホスト名、パス、クエリ、フラグメントを確認します。パスに有名企業の名前が あっても、無関係なホスト名を信用する理由にはなりません。短縮リンクや 符号化された転送先を展開すると、実際にその先へ接続することがあります。 普段のブラウザではなく、承認された調査用ツールを使ってください。

次の確認方法を選ぶ。既存の評価情報を調べれば、 URL を新たに送信せずに手掛かりを得られます。URL スキャナーはページを 訪問し、共有可能な記録を作る場合があります。リモートブラウザでは画面に 表示される内容を確認できます。どちらもマルウェアの最終判定ではありません。 Google の Chrome セーフブラウジングの説明 によると、警告は選んだ保護レベルと利用できる脅威情報によって変わります。

影響に応じて対応する。誰かが認証情報を入力した、 多要素認証を承認した、またはダウンロードしたファイルを実行した場合は、 速やかに組織のインシデント対応手順に従います。スキャナーが危険と判定する のを待っても、アカウントや端末への影響は消えません。CISA の フィッシング対策資料 も、不審なメッセージを報告し、通常の利用ではそのリンクを開かないよう勧めています。

確認方法ごとの限界

評判の照会、URL スキャナー、隔離されたブラウザでは、確かめられることが 違います。新しいリンク、個人向けのリンク、短時間で失効するリンクでは、 それぞれの限界も調査結果の一部として扱ってください。

評判は既存の情報次第です。「危険との報告なし」は、 まだ誰も報告していないだけかもしれません。転送先やページの内容も、 時間、訪問者、地域によって変わり得ます。Chrome セーフブラウジングの 警告は有用ですが、標準保護と保護強化では確認方法も Google と共有する 情報も異なります。どの方法で調べたかを記録しましょう。

公開スキャンでは URL が開示されます。クエリにはアクセストークン、顧客名、非公開文書のリンクが含まれることがあります。urlscan.io の公開範囲の説明 では Public、Unlisted、Private が区別され、Unlisted でも認証された Pro 利用者は閲覧できます。VirusTotal の プライベートスキャン は、通常の送信とは異なり、提出物を共有の脅威データ群に加えません。 完全な URL やファイルを送る前に、組織の情報取扱規則を確認してください。

閲覧自体がサイトとのやり取りです。サイトはリモートブラウザの出口アドレスを見て、リクエストを受け取り、 Cookie を設定し、クリックに反応できます。隔離はページの実行を 分析者の端末から離しますが、匿名性やページの安全性を保証しません。 保存したプロファイルにはブラウザの状態が残り得ます。また、閲覧タブを 閉じるだけでは Browser.lol のセッションが終了したとは言えません。

閲覧環境を整える

リスクと証拠の取扱規則に合った環境を選びます。リモートブラウザは、 ページのコードを分析者の端末上で実行することによるリスクを減らせますが、 調査全体の一つの対策にすぎません。何を記録し、どこに保存するかを 閲覧前に決めてください。

通信経路。Browser.lol では、対象サイトへの接続は リモートブラウザの出口から行われます。分析者の端末は Browser.lol に接続し、 画面を受け取って操作を送ります。対象サイトに見える接続元は変わりますが、 サービス側から活動が見えなくなるわけではありません。出口の国や地域、 端末側の通信保護も保証されません。

セッションの選択。状態を次回に引き継ぐ必要がなければ、 保存済みプロファイルではなく一時的なセッションを使います。目的に合う、 利用可能なブラウザを選んでください。個人用や本番用のアカウントでは ログインせず、不審なダウンロードを自分の端末へ移さないでください。 分析環境を見分けるサイトもあり、ある訪問では無害に見えても、 被害者には違う内容を見せる可能性があります。

証拠の残し方。Browser.lol が提供するのは 画面を配信するブラウザです。セッションの自動録画、パケットの取得、 SIEM への自動出力はありません。組織の規則で認められるなら、承認された ツールでメモや画面の記録を残します。時刻、URL、確認した転送先、 操作内容を書き留めてください。証拠として使える通信記録や、 不審なファイルの解析が必要なら、専用の承認済みツールを使います。

繰り返し使える調査手順

必要な情報が揃った時点で止められる順序で調べます。誰かがすでに認証情報を入力したり、ダウンロードしたファイルを開いたりした場合は、直ちにインシデント対応を始めてください。

1. 1

   報告内容を確認する

   元のメッセージを保存し、誰かがクリック、ログイン、ダウンロードを したか確かめます。トークン付きリンク、アカウントの認証情報、 ブラウザのセッション ID を通常のチケットに記載しないでください。
2. 2

   開く前に URL を調べる

   URL を開かずに文字列として取り出します。実際のホスト名と送信者の 名乗りを比べ、既存の報告を確認します。普段のブラウザで短縮リンクを 展開しないでください。外部スキャナーに完全な URL を渡してよいかも 判断します。
3. 3

   必要なら慎重に閲覧する

   実際の表示を確認する必要があれば、一時的なリモートセッションを 始め、そこで URL を入力します。転送先と入力フォームを観察します。 簡単なリンク調査のために本物の認証情報を入力したり、多要素認証を 承認したり、ダウンロードしたファイルを実行したりしないでください。
4. 4

   確認した情報を記録する

   最終的なドメイン、表示された要求、ダウンロードの提示を記録します。 観察したことだけを事実として残してください。画面の記録やブラウザの 開発者ツールは役立ちますが、Browser.lol が自動でフォレンジック記録を 作るわけではありません。
5. 5

   終了して必要な対応につなぐ

   終了用の操作でリモートセッションを明示的に終了します。得られた証拠と その限界を案件に記します。認証情報の窃取やマルウェアの実行が疑われる 場合は、評判の照会結果が不明確でも組織のインシデント対応に進みます。

記録すべき情報

情報は出所まで説明できて初めて役立ちます。受信したメッセージの 元の URL と、スキャナーやブラウザで確認した転送先を区別します。 直接見たことと、そこから推測したことも分けて書きます。

接続先の情報として、元と最後のホスト名、 観察した転送経路、DNS の応答、証明書の詳細などを記録できます。 IP アドレスの所有者やドメインの登録日も参考になりますが、 共有ホスティングや CDN のアドレスだけで攻撃者を特定できません。 結果は時刻や接続元のネットワークによって変わる場合があります。

画面上の挙動には、認証情報の入力欄、 多要素認証の要求、ダウンロードの提示、偽装された企業名、クリック後の 転送などがあります。専用スキャナーの HTTP 通信記録や DOM の写しを 使うなら、出所がそのスキャナーであることを明記してください。 報告者本人が見た画面とは異なる可能性があります。urlscan.io は 結果と画面画像の API を文書化しています。

観察結果を報告書にまとめる

短い報告書でも、次の担当者が判断の根拠をたどれるようにします。 元の報告、実施した確認、観察時刻、使ったツールやブラウザを記します。 ログインが必要なページ、地域限定の表示、使い捨てリンクなど、 確認できなかった範囲も明示してください。

観察したドメインや挙動と、攻撃者や目的についての推測は分けます。 画面画像を添える場合は、閲覧者に見せてよい内容か確認します。 チーム外に共有するときは組織の規則に従ってください。FIRST の Traffic Light Protocol は、TLP の区分ごとに再共有できる範囲を説明しています。 トークン付きリンクやセッションの認証情報を、広く共有する情報源に 貼り付けないでください。

最後に判断を示します。確認できた接続先を遮断するか、関連する活動を 監視するか、追加資料を求めるか、結論を保留して案件を閉じるか。 報告者がリンクを開いていた場合は、取るべき対応も伝えます。 フィッシングらしい画面が表示されたことだけでは、情報が送信された とも、端末が侵害されたとも言えません。

SOC の運用に組み込む

最初に尋ねる項目と証拠の記録欄を通常のチケットに組み込みます。 評判の照会だけで十分な場合、制御された閲覧が必要な場合、 インシデント対応に移る場合の基準を明確にしてください。

自動化を作るなら、承認された API を使い、案件との対応付けは 自分たちのシステムで管理します。Browser.lol にはセッション用の API がありますが、チケットシステムのボタン、事故タグ付け、 証拠の自動出力は標準では備わっていません。報告された URL を 連携先で処理する前に、権限とデータの取扱いを確認してください。

対応を引き上げる条件も決めておきます。利用者が認証情報を入力した、 予期しないログインを承認した、ダウンロードしたファイルを実行した、 既知の攻撃活動と一致した、といった場合です。ダウンロードを促す画面と ファイルの実行、入力欄の表示と認証情報の窃取は、それぞれ別の事実です。

完了した案件をいくつか選び、元の報告と残した証拠を見直します。 見逃した転送先、断定しすぎた結論、公開スキャナーに送った機密性の 高い URL がないか確認してください。Browser.lol には再生用の セッション録画がありません。後で見直す必要があるなら、調査時に 許可された方法で証拠を残します。

手順を評価する

自分たちの案件記録から集計できる指標を選びます。目的は手順の弱点を見つけることであり、隔離すればどんな調査も安全になると示すことではありません。

定義を揃えて継続的に見てください。認証情報を入力した利用者を 見落としているなら、判断が速くなっても改善とは言えません。 また、リモートブラウザは端末側の一部のリスクを減らせても、 あらゆる悪質なページやダウンロードを封じ込めた証拠にはなりません。

調査手順を実務に生かす

まずはアクセスせずに確認し、URL を外部に渡すことによる情報漏えいも 考えます。実際の閲覧は、答えたい問いがある場合に限ります。 ファイルの解析やフォレンジック用の証拠収集には専用ツールを使います。

Browser.lol は、閲覧の段階で使えるリモートブラウザを提供します。 セッションを明示的に終了し、承認されたツールで観察結果を残してください。 その環境では確認できなかったことも、報告書に正直に記します。