メインコンテンツへスキップ
フィッシングリンクをクリックした時の対処法:入力・ダウンロード別の初動対応
チュートリアル 初級

フィッシングリンクをクリックした時の対処法:入力・ダウンロード別の初動対応

チュートリアル 初級

フィッシングメールやSMSのリンクをクリックした時の対処法を、閲覧のみ、パスワード入力、MFA承認、ファイル実行に分けて解説。個人・情シスが最初の10分で行う報告、アカウント保護、端末隔離、記録方法とエスカレーション判断をチェックリストで確認できます。

この記事の目次 12項目から選ぶ

冒頭要約

フィッシングメール、SMS、チャットのリンクをクリックしてしまっても、クリックしただけで直ちにアカウント侵害やマルウェア感染が確定するわけではありません。一方、リンク先でパスワードを入力した、MFA通知を承認した、ファイルやアプリを開いた場合は、対応の優先度が大きく上がります。

最初に、不審なページを閉じ、受信時刻、クリック時刻、入力・承認・ダウンロードの有無を記録します。業務端末や会社アカウントなら、自己判断で履歴やファイルを消す前に、情シスやセキュリティ窓口へ報告してください。

この記事では、個人、情シス、開発者、SaaS管理者が、最初の10分で状況を分け、アカウント保護、端末隔離、証拠保全、エスカレーションへ進む判断基準を整理します。

再確認のためにリンクを開き直さない

リンク先の安全性を自分で確かめようとして、同じURLを再度開いたり、別の端末で試したりしないでください。URL、メール原本、スクリーンショットなどを組織の手順に従って保全し、調査は情シスやCSIRTへ引き継ぎます。


フィッシングリンクをクリックした後、最初に確認すること

初動で最も重要なのは、「リンクを押した」という一言で終わらせず、どこまで操作したかを分けることです。次の4点を思い出せる範囲で確認します。

  1. ページを表示しただけで、何も入力・許可していない。
  2. ID、パスワード、個人情報、カード情報、認証コードを入力した。
  3. MFA通知を承認した、OAuth連携を許可した、QRコードで認証した。
  4. ファイルをダウンロード・実行した、アプリ・拡張機能・構成プロファイルを追加した、遠隔操作を許可した。

分からない項目は「していない」と決めつけず、「未確認」と記録します。ブラウザのダウンロード履歴、アカウントのセキュリティイベント、端末の検知履歴を、正規の管理画面や組織のセキュリティ製品で確認します。

状況別の初動早見表

状況最初に行うこと主な確認先
ページを開いただけページを閉じ、時刻・URL・受信経路を記録して報告するブラウザ履歴、メール原本、組織の報告窓口
ID・パスワードを入力信頼できる端末からパスワード変更とセッション失効を行うサインイン履歴、MFA、回復情報、パスワード再利用先
MFA・OAuthを承認セッションと連携権限を無効化し、不審な認証方法を確認するIdP、SaaS監査ログ、OAuthアプリ、MFA登録
ファイルを保存しただけ開かず、削除前に報告し、組織の検査手順へ渡すダウンロード履歴、メール原本、EDR・アンチウイルス
ファイル実行・アプリ導入端末のネットワーク隔離と情シスへの緊急連絡を優先するEDR、端末ログ、プロセス、外部通信、関連アカウント

読者別の影響

読者・担当まず確認すること次の判断
個人利用者入力した情報、カード・決済情報、ダウンロードやアプリ導入サービス事業者、カード会社、正規サポートへの連絡
一般社員業務アカウント、MFA、端末、メール・Teams・SMSの受信経路情シスへ報告し、指示に沿ってアカウントと端末を保護
情シス・SaaS管理者サインイン、セッション、MFA変更、OAuth同意、メール転送セッション失効、権限取消、同報範囲、監査ログ保全
開発者GitHub、クラウド、CI/CD、保存済みシークレットへの波及開発者権限、トークン、SSH鍵、クラウド操作ログの確認
SOC・CSIRT操作時系列、URL、端末、アカウント、同一メールの受信者優先度、封じ込め、証拠保全、全社検索、注意喚起

同じリンクでも、一般的な情報ページを開いただけの場合と、管理者アカウントの認証情報を入力した場合では、影響が異なります。クリック回数ではなく、入力した情報、許可した権限、端末で実行したもの、対象アカウントの重要度で判断します。


最初の10分チェックリスト

1. 追加操作を止める

  • 不審なページを閉じ、リンク先で表示されたボタンや電話番号を使わない。
  • 同じメッセージへ返信せず、添付、QRコード、別リンクも開かない。
  • ブラウザが通知許可、拡張機能、アプリ、構成プロファイルを求めても許可しない。
  • 不審な相手から電話やチャットが続いても、遠隔操作を許可しない。

正規サービスか確認する場合は、メッセージ内のリンクではなく、普段使っているブックマーク、公式アプリ、自分で確認した公式サイトからアクセスします。

2. 行った操作を記録する

  • メール、SMS、チャットを受信した日時。
  • リンクをクリックした日時と、使用した端末・ブラウザ。
  • 表示された画面の概要と、分かる範囲のURL。
  • 入力した情報の種類。実際のパスワードやカード番号は記録欄へ再掲しない。
  • MFA承認、OAuth同意、QRコード読み取りの有無。
  • ダウンロード、ファイル実行、アプリ・拡張機能導入の有無。
  • その後に表示された警告、不審なログイン通知、端末の変化。

URLを共有する場合は、誤クリックを防ぐため、組織指定の方法やIOCのdefangを使います。外部のオンライン解析サービスへ、社内URLや認証情報を無断で送らないでください。

3. 正規の報告窓口へ連絡する

業務端末・業務アカウントでは、メールを削除する前に、社内の報告ボタン、情シス、SOC、CSIRTなどへ連絡します。報告時は、次のように短く伝えると初動が進みやすくなります。

2026-07-29 10:20ごろ、業務メールのリンクを開きました。Chromeでページを表示しましたが、入力・MFA承認・ファイル実行はしていません。メール原本とURLを保全しています。

不明点がある場合は「なし」と書かず、「ファイル保存の有無は未確認」のように伝えます。報告の書式はフィッシング報告テンプレートを利用できます。


状況別の初動対応

ケース1:リンクを開いただけで、入力もダウンロードもしていない

ページを表示しただけなら、認証情報を渡したケースより一般に優先度は低くなります。ただし、アクセス時刻やブラウザ情報が相手側へ伝わる可能性、ブラウザの脆弱性、意図しないダウンロードなどは切り分けが必要です。

  1. ページを閉じ、同じリンクを再度開かない。
  2. 受信メッセージ、クリック時刻、URL、端末を記録する。
  3. ダウンロード履歴と、ブラウザが表示した警告の有無を確認する。
  4. OS、ブラウザ、セキュリティ製品が組織の管理下で最新になっているか確認する。
  5. 業務環境では情シスへ報告し、同一リンクの組織内検索とブロックを依頼する。

この時点で、すべてのパスワードを慌てて変更する必要があるとは限りません。何を入力・許可したか、認証セッションが発生したかを先に確認します。

ケース2:ID・パスワード・認証コードを入力した

入力した認証情報は、第三者へ渡った可能性があるものとして扱います。フィッシングページを開いた端末にマルウェアの懸念がある場合は、その端末で新しいパスワードを入力せず、信頼できる別端末または管理者の手順を使います。

  1. 対象サービスの正規サイトまたは管理画面から、パスワードを変更する。
  2. 同じパスワードを使い回しているサービスを洗い出し、それぞれ異なる値へ変更する。
  3. 既存セッション、信頼済み端末、アプリパスワードを失効する。
  4. MFA方法、回復用メール、電話番号、パスキー、セキュリティキーに不審な追加・変更がないか確認する。
  5. サインイン履歴、メール転送ルール、送信済みメール、SaaSの監査ログを確認する。

身に覚えのないログインがある場合は、不審なログイン通知の初動対応へ進みます。セッションCookieやトークンの不正利用が疑われる場合は、セッションハイジャックの初動対応も併用します。

ケース3:MFA通知、OAuth同意、QRコード認証を承認した

パスワードを入力していなくても、MFA通知やOAuth同意を承認すると、セッションやSaaS権限が第三者へ渡る場合があります。「MFAがあるから大丈夫」と判断しないでください。

  • 既存セッションを失効し、サインイン中の端末を確認する。
  • 身に覚えのないMFA方法、パスキー、回復情報を削除する。
  • 承認したOAuthアプリやSaaS連携の権限を取り消す。
  • メール、ファイル、チャット、クラウド管理へのアクセス履歴を確認する。
  • MFA通知を誤承認した場合は、MFA疲労攻撃の初動対応へ進む。

管理者アカウント、経理、採用、開発者、SaaS管理者の権限がある場合は、通常ユーザーより高い優先度でCSIRTへ連携します。

ケース4:ファイルをダウンロードしたが、開いていない

  • ファイルを開かず、プレビューや展開もしない。
  • ファイル名、保存時刻、保存先、受信メッセージを記録する。
  • 組織の手順がある場合は、削除前に情シスやEDR担当へ連絡する。
  • 個人環境では、OSと信頼できるセキュリティ製品を更新し、公式機能で検査する。
  • 同じファイルを別端末へコピーしたり、外部解析サイトへ無断でアップロードしたりしない。

「ダウンロードしただけ」と「開いた・実行した」は区別します。ブラウザやOSが自動的に開いた可能性が分からない場合は、未確認として報告します。

ケース5:ファイルを開いた、アプリを入れた、遠隔操作を許可した

端末侵害の可能性があるため、アカウント変更より先に、端末から新しい認証情報が再び取得されない状態を作ります。

  1. 業務端末は、可能なら会社の手順でネットワークから隔離する。
  2. 端末を使い続けず、別の手段で情シス・SOCへ緊急連絡する。
  3. 電源は一律に切らず、隔離できないまま被害が進む場合を除き、担当者の指示を待つ。
  4. 信頼できる端末から、重要アカウントのセッションと認証情報を保護する。
  5. EDR、アンチウイルス、OS、ブラウザ、ネットワーク、IdPのログを同じ時刻で確認する。

詳細はマルウェア感染時の初動対応インシデント時の証拠保全に整理しています。


やること・やらないこと・記録すること

区分内容
やること追加操作を止め、正規窓口へ報告し、信頼できる端末から必要なアカウント保護を行う
やらないこと同じリンクの再クリック、漏えいした認証情報の動作確認、自己流のファイル実行、証拠を残さない削除
記録すること受信・クリック・入力・承認・実行の時刻、端末、アカウント、URL、表示内容、実施した対応

やってはいけないこと

  • 「安全か確認するため」にリンクを別端末で開く。
  • メールをそのまま転送して、別の人にもリンクをクリックさせる。
  • パスワードや認証コードを、報告チケットやチャットへ貼る。
  • 感染が疑われる端末で、新しいパスワードやシークレットを入力する。
  • 情シスへ知らせず、履歴・メール・ファイル・検知ログをすべて削除する。
  • 不審サイトに表示された電話番号やサポート窓口へ連絡する。
  • 警告が消えたことだけを根拠に、端末やアカウントが安全だと断定する。

判断基準とエスカレーション条件

優先度状況推奨対応
緊急管理者・経理アカウントを入力、MFA承認、ファイル実行、遠隔操作許可、身に覚えのないログイン直ちに情シス・SOC・CSIRTへ連絡し、端末隔離、セッション失効、ログ保全を開始
一般アカウントの認証情報入力、OAuth同意、カード・本人確認情報入力速やかに認証情報と連携権限を無効化し、利用履歴と関係先を確認
リンクを開いたが操作内容やダウンロード有無が不明未確認事項を明示して報告し、端末・ブラウザ・メールログを確認
閲覧のみ、入力・承認・保存なしを確認でき、端末警告や不審ログインもない記録と報告を残し、組織の判断に従って監視・注意喚起

次に該当する場合は、個人で完結させず、早めにエスカレーションします。

  • 管理者、役員、経理、採用、開発者、顧客対応など重要権限を持つ。
  • 顧客情報、決済、クラウド、ソースコード、機密文書へアクセスできる。
  • 複数のサービスで同じパスワードを使用していた。
  • 不審なMFA方法、回復情報、メール転送、OAuthアプリが追加されている。
  • 同じメッセージを複数人が受信・クリックしている。
  • 何を入力・実行したか思い出せず、ログでも確認できない。

初動記録テンプレート

発見・報告日時:
受信経路: メール / SMS / Teams / Slack / SNS / その他
送信者表示・件名:
クリック日時:
使用端末・ブラウザ:
表示された画面:
入力した情報の種類:
MFA・OAuth・QR認証:
ダウンロード:
ファイル実行・アプリ導入:
不審なログイン・端末警告:
実施した対応:
保全した証跡:
未確認事項:
担当者・次回確認時刻:

パスワード、カード番号、認証コード、Cookie、トークンなどの値そのものは記録しません。必要な証跡は、組織のアクセス制御された保管先へ保存します。


よくある誤解

「クリックしただけで必ずウイルス感染する」

必ず感染するとは限りません。情報入力、ファイル実行、権限許可がなければ影響が限定的な場合もあります。ただし、意図しないダウンロードやブラウザ脆弱性などを自己判断で除外せず、操作履歴と端末状態を確認します。

「パスワードを変更すれば対応完了」

パスワード変更後も、既存セッション、MFA方法、回復情報、OAuthアプリ、メール転送ルールが残る場合があります。サインイン履歴と設定変更を合わせて確認します。

「MFAが有効なら認証情報を入力しても安全」

MFAは重要ですが、偽サイトで認証コードを入力したり、プッシュ通知を承認したり、OAuth同意を与えたりすると、保護を回避される場合があります。今後の対策としては、パスキーとパスワードの違いも確認できます。

「メールを削除すれば被害を止められる」

受信メールを削除しても、入力済みの認証情報や端末上のファイルは無効になりません。メール原本は同報範囲の検索やURLブロックにも使うため、組織の報告手順に従って保全します。


関連用語・関連ページ

次に行うことCyberLensのページ
受信メールを確認するフィッシング確認チェックリストメールヘッダーの見方
報告と記録を行うフィッシング報告テンプレート証拠保全
URLを安全に共有するURL構造解析ツールIOC正規化・defangツール
アカウントを確認する身に覚えのないログイン通知セッションハイジャック初動対応
端末を確認するマルウェア感染時の初動対応EDRとアンチウイルスの違い
基礎から学ぶフィッシングとAI脅威インシデントレスポンス
判断を練習するフィッシングメール判定トレーニングセキュリティクイズ
用語を確認するフィッシングMFAセッションハイジャック

公式情報・参考情報


まとめ

フィッシングリンクをクリックした後は、慌てて同じリンクを調べ直すのではなく、追加操作を止める、どこまで操作したかを分ける、記録して正規窓口へ報告することが最初の一歩です。

閲覧のみなら記録と確認、認証情報入力ならパスワード・セッション・MFAの保護、MFAやOAuth承認なら権限取消、ファイル実行なら端末隔離を優先します。確認できた事実、未確認事項、実施時刻を分けて残すことで、情シスやCSIRTが同報範囲、アカウント、端末への影響を素早く判断できます。

実作業を始める場合は、フィッシング確認チェックリストで操作内容を確認し、フィッシング報告テンプレートへ時系列と未確認事項を記録してください。

関連テーマを体系的に学ぶ インシデント対応ガイド:検知から復旧までの判断順序
ESC