同意画面フィッシング（OAuth同意詐欺）を初心者でも分かりやすく解説

同意画面フィッシング（OAuth同意詐欺）とは？

同意画面フィッシング（OAuth同意詐欺）とは、攻撃者が偽のアプリケーションを作成し、ユーザーをだまして「アプリにアクセス権限を許可」させることで、クラウドサービスのアカウントを乗っ取る不正アクセス手法です。「OAuth」（オーオース）は、GoogleやMicrosoft、Facebookなどのアカウント情報を使って、他のサービスに安全にログインできる仕組みですが、この正規の認証システムを悪用した攻撃が同意画面フィッシングです。

通常のフィッシング攻撃では、偽のログイン画面でユーザーにパスワードを入力させて盗み取りますが、同意画面フィッシングでは、パスワードを盗む必要すらありません。攻撃者は、正規のOAuth認証画面を悪用し、「このアプリがあなたのメールを読む権限」や「カレンダーを編集する権限」を求める「同意画面」を表示させます。ユーザーが「許可」ボタンをクリックしてしまうと、攻撃者のアプリケーションに正規のアクセストークン（許可証）が発行され、攻撃者はパスワードを知らなくてもアカウントにアクセスできるようになります。

この攻撃手法が特に危険な理由は、パスワードを変更しても、多要素認証（MFA）を設定していても、一度許可を与えてしまったアプリケーションの権限は残り続ける点です。ユーザーが明示的に権限を取り消さない限り、攻撃者は半永久的にアカウントにアクセスできる状態が続きます。

同意画面フィッシングは「OAuthフィッシング」「同意詐欺」「OAuth悪用攻撃」「アプリケーション権限詐欺」とも呼ばれます。2025年現在、Microsoft 365、Google Workspace、GitHubといった企業向けクラウドサービスを狙った攻撃が急増しており、国家支援型のハッキンググループ（APT）も積極的にこの手法を活用しています。

同意画面フィッシング（OAuth同意詐欺）を簡単に言うと？

同意画面フィッシング（OAuth同意詐欺）を日常の例えで説明すると、「偽の身分証明書を使って合鍵を作らせる詐欺」に似ています。

想像してください。あなたのマンションに、「管理会社の新しいメンテナンスサービス」と名乗る業者が訪問してきました。業者は「定期的にお部屋の点検をするため、合鍵を預からせてください」と依頼します。管理会社の名前も正しく、書類も本物そっくりです。あなたは「管理会社が依頼したサービスなら大丈夫だろう」と思い、合鍵を渡してしまいます。

実は、この業者は詐欺師で、本物の管理会社とは無関係でした。しかし、あなたが「合意」して合鍵を渡してしまったため、詐欺師はいつでもあなたの部屋に侵入できるようになります。その後、あなたが玄関の鍵を交換しても（パスワード変更）、オートロックを強化しても（多要素認証）、すでに渡してしまった合鍵（アクセス権限）は有効なままです。

同意画面フィッシングも同じ仕組みです。攻撃者は「Google Defender」や「McAfee Email Protection」といった、セキュリティに関連する名前の偽アプリを作成します。ユーザーがフィッシングメールのリンクをクリックすると、本物のGoogleやMicrosoftの認証画面が表示されます（これは偽物ではなく本物です）。そして「このアプリがあなたのメールにアクセスすることを許可しますか？」という同意画面が表示されます。

ここで重要なのは、この同意画面自体は本物のGoogleやMicrosoftのシステムが表示しているという点です。偽物ではなく、正規の認証プロセスです。ただし、アクセス権限を要求しているのが攻撃者の悪意あるアプリケーションなのです。ユーザーが「許可」をクリックすると、攻撃者のアプリに「合鍵」にあたるアクセストークンが発行され、攻撃者はあなたのメール受信箱を自由に読んだり、カレンダーを確認したり、連絡先を盗んだりできるようになります。

さらに悪質なケースでは、攻撃者は「組織内部のアプリケーション」として登録することで、より強力な権限を獲得します。これは、マンションの管理会社の社員になりすまして、マスターキーを手に入れるようなものです。

同意画面フィッシング（OAuth同意詐欺）の現状

同意画面フィッシング（OAuth同意詐欺）は、2025年現在、企業を標的としたサイバー攻撃において急速に増加している脅威です。警察庁が発表した統計によると、2024年のフィッシング詐欺は171万件を超え、その中でOAuthを悪用した攻撃が大きな割合を占めていることが懸念されています。

2024年から2025年にかけて、以下のような最新の攻撃事例が報告されています。

Microsoft 365を狙った大規模攻撃キャンペーンが2025年10月に確認されました。攻撃者はOAuth認証プロンプトを巧妙に操作し、ユーザーに悪意のあるアプリケーションへの許可を促します。この攻撃では、フィッシングメールで「アカウントのセキュリティ警告」といった緊急性の高い文面を使い、リンクをクリックさせます。ユーザーがクリックすると、本物のMicrosoft認証画面が表示され、アプリケーションへのアクセス許可を求められます。この画面はMicrosoftの正規のブランドを使用しており、ユーザーが日常的に目にする認証プロセスに従っているため、多くの人が正当なものだと誤解してしまいます。

GitHub 12,000リポジトリへの攻撃も2025年3月に発生しました。攻撃者は偽のセキュリティ通知を利用し、開発者を騙して悪意のあるOAuthアプリを承認させる大規模なフィッシング攻撃を展開しました。偽の通知には「アイスランドのReykjavikからの異常なアクセス試行を検知しました」といったメッセージが含まれており、「アカウントが侵害された」と警告します。推奨される対応策のリンクをクリックすると、「gitsecurityapp」という悪意のあるOAuthアプリの認証ページに誘導され、ユーザーのアカウントやリポジトリへの完全なアクセス権限を要求します。

Proofpointの調査により、パスワード変更後も攻撃が継続する事例が明らかになりました。2025年の報告では、攻撃者が「Adversary-in-the-Middle（AiTM）」と呼ばれる中間者攻撃型のフィッシング手法を使用し、約4日間にわたってアカウント乗っ取り（ATO）を継続したケースが確認されています。攻撃者は侵入後に「test」という名前の内部アプリケーションを登録し、Mail.Readおよびoffline_access権限を付与することで、パスワード変更後も被害者のメールボックスへのアクセスを維持しました。

国家支援型ハッキンググループの活動も活発化しています。ロシアのサイバー攻撃グループ「Pawn Storm（APT28）」は、2015年頃からOAuthを悪用したフィッシング攻撃を実施しています。同グループは「Google Defender」や「McAfee Email Protection」といった、セキュリティ製品を装った偽のアプリケーションを作成し、重要人物のメール受信箱に対する半永久的なアクセス権を取得しました。

攻撃手法の高度化も進んでいます。Microsoftの報告によると、攻撃者は「セカンドパーティーアプリケーション（内部アプリケーション）」と「サードパーティーアプリケーション（外部アプリケーション）」の違いを悪用しています。セカンドパーティーアプリケーションは組織のテナント内に直接登録されるため、ある程度の暗黙の信頼を受け継ぎます。攻撃者が管理者権限を持つアカウントを侵害すると、セカンドパーティーアプリケーションとして悪意あるアプリを登録し、管理者の同意ワークフローを回避できます。

DKIMリプレイ攻撃との組み合わせも確認されています。2024年には、攻撃者がGoogle OAuthアプリケーションの名前に、フィッシングメッセージ全文を含める手法が報告されました。これにより、Google公式から送信されたように見えるメールを生成し、ユーザーの信頼を獲得します。

企業にとって深刻なのは、一度許可を与えてしまったOAuthアプリケーションの権限を発見し、取り消すことが困難な点です。多くの組織では、従業員がどのようなサードパーティーアプリケーションに権限を与えているかを把握していません。また、無害に見えたアプリが後に悪意を持つアプリに変化する可能性もあり、継続的な監視が必要です。

同意画面フィッシング（OAuth同意詐欺）で発生する被害は？

同意画面フィッシング（OAuth同意詐欺）による被害は、従来のフィッシング攻撃よりも深刻かつ長期的です。パスワード盗難の場合はパスワード変更で対処できますが、OAuth権限は明示的に取り消さない限り有効であり続けるため、被害が拡大しやすい特徴があります。

同意画面フィッシング（OAuth同意詐欺）で発生する直接的被害

メールの継続的な監視と情報漏洩が最も深刻な直接被害です。攻撃者がメール受信箱への読み取り権限を獲得すると、過去から現在まですべてのメールを閲覧できます。ビジネスメール、契約書、財務情報、顧客とのやり取り、社内機密情報などが攻撃者に筒抜けになります。さらに、リアルタイムで新着メールも監視されるため、「半永久的な盗聴」状態が続きます。攻撃者はこの情報を利用して、ビジネスメール詐欺（BEC）の次の標的を選定したり、企業秘密を競合他社に売却したりします。

アカウント乗っ取りと不正な操作も重大な被害です。攻撃者が「メール送信権限」を獲得すると、被害者のアカウントから偽のメールを送信できます。社内の他の従業員に対してフィッシングメールを送信したり、取引先に偽の請求書を送付したり、上司になりすまして不正な送金を依頼したりします。被害者本人が送信したように見えるため、受信者は疑いを持たずに指示に従ってしまうことが多く、二次被害が拡大します。

カレンダーと連絡先情報の窃取により、組織の活動が丸見えになります。攻撃者がカレンダーへのアクセス権限を獲得すると、重要な会議のスケジュール、出張予定、取引先との商談の日時などが把握されます。これらの情報は標的型攻撃（APT）の偵察段階で非常に価値があります。連絡先情報を盗まれると、社内外の関係者のメールアドレスや電話番号が流出し、さらなるフィッシング攻撃の標的リストとして悪用されます。

クラウドストレージへの不正アクセスも深刻です。Google DriveやOneDriveへのアクセス権限を許可してしまうと、企業の重要文書、設計図、財務データ、顧客情報などが大量に流出します。攻撃者はファイルをダウンロードするだけでなく、ファイルを削除したり、ランサムウェアで暗号化したりすることも可能です。2024年には、ランサムウェア攻撃の前段階として、OAuthアプリを使ってバックアップファイルの場所を特定し、破壊する手法が確認されています。

同意画面フィッシング（OAuth同意詐欺）で発生する間接的被害

検知と対応の遅延による被害拡大が深刻な間接被害です。従来のフィッシング攻撃では、異常なログイン試行や不審なIPアドレスからのアクセスとして検知されることがありますが、OAuthアプリケーションを経由したアクセスは「正規の認証プロセス」を経ているため、セキュリティ製品による検知が困難です。攻撃者は数週間から数ヶ月にわたって気づかれずに活動を続け、その間にさらなる侵害を進めます。

パスワード変更や多要素認証が無効であることによる継続被害も問題です。通常、アカウント侵害が発覚した場合、パスワード変更とアカウントロックで対処できます。しかし、同意画面フィッシングでは、パスワードを変更しても、多要素認証を有効にしても、すでに発行されたアクセストークンは有効なままです。Proofpointの事例では、パスワード変更後も約4日間にわたって攻撃者がアクセスを継続していました。組織がOAuthアプリケーションの権限を確認し、明示的に取り消すまで、被害は続きます。

組織全体への感染拡大とサプライチェーン攻撃のリスクも高まります。攻撃者が一人の従業員のアカウントを侵害すると、そのアカウントから社内の他の従業員にフィッシングメールを送信します。同僚からのメールは信頼されやすいため、次々とOAuthアプリケーションへの権限が付与され、組織全体に被害が広がります。さらに、取引先企業に対しても同様の攻撃を展開することで、サプライチェーン攻撃の起点となります。

法的責任とコンプライアンス違反も避けられません。企業が管理する顧客の個人情報や取引情報が、OAuthアプリケーションを通じて漏洩した場合、個人情報保護法やGDPR（EU一般データ保護規則）などの規制により、企業は適切な管理責任を問われます。「従業員が不注意で権限を許可してしまった」という理由は免責にならず、高額の制裁金や損害賠償請求につながる可能性があります。

信頼関係の崩壊と評判の毀損は金銭的損失以上に深刻です。取引先企業が「御社のアカウントから不審なメールが送られてきた」と報告した場合、企業のセキュリティ管理体制への信頼が失われます。特にIT企業やセキュリティ関連企業がこのような被害を受けた場合、顧客からの信頼を大きく損ない、契約解除や新規顧客の獲得機会の損失につながります。

フォレンジック調査と修復にかかる膨大なコストも見逃せません。OAuth権限の悪用が発覚した場合、どのアプリケーションに権限が付与されているか、誰がいつ許可したか、どの情報が漏洩したかを調査する必要があります。Microsoft Entra ID（旧Azure Active Directory）やGoogle Workspaceの監査ログを詳細に分析し、すべての不正なアプリケーションを特定して権限を取り消す作業は、専門知識を持つセキュリティチームでも数週間かかることがあります。

同意画面フィッシング（OAuth同意詐欺）の対策方法

同意画面フィッシング（OAuth同意詐欺）への対策は、従来のフィッシング対策とは異なるアプローチが必要です。パスワード管理やアンチウイルスソフトだけでは防げないため、OAuthアプリケーションの権限管理とユーザー教育を中心とした多層的な対策が求められます。

OAuthアプリケーションの厳格な管理とホワイトリスト化が最も効果的な対策です。組織では、Microsoft Entra IDやGoogle Workspaceの管理コンソールで「ユーザーが自由にサードパーティーアプリケーションに同意できる設定」を無効にし、管理者の承認が必要な仕組みに変更します。これにより、従業員が不注意で悪意のあるアプリに権限を付与することを防ぎます。さらに、業務で使用するアプリケーションを事前にホワイトリストに登録し、承認されたアプリのみ使用できるようにします。

具体的には、Microsoft 365では「ユーザーの同意設定」を「管理者の同意が必要」に変更します。Google Workspaceでは「信頼できるアプリのみ許可」設定を有効にし、組織外のアプリケーションへのアクセスを制限します。また、「リスクベースのアクセス制御」を導入し、未検証のアプリケーションや危険な権限（Mail.ReadWrite、Files.ReadWrite.Allなど）を要求するアプリは自動的にブロックします。

既存のOAuthアプリケーション権限の定期的な監査も不可欠です。多くの組織では、従業員がどのようなアプリケーションに権限を与えているかを把握していません。定期的（少なくとも月次）に、すべてのユーザーが許可しているOAuthアプリケーションのリストを確認し、不審なアプリや不要になったアプリの権限を取り消します。Microsoft Defender for Cloud Appsのような専用ツールを使用すると、組織全体のOAuthアプリケーションを可視化し、リスク評価を自動化できます。

監査では特に以下の点に注目します。発行者が不明なアプリケーション、異常に広範な権限を要求するアプリ（例：全メールの読み書き、全ファイルへのアクセス、ユーザー管理など）、最近登録されたばかりで使用実績が少ないアプリ、一般的な製品名やセキュリティ製品を装った名前のアプリ（例：「Google Security」「Microsoft Defender」「Email Protection」など）です。

ユーザー教育とセキュリティ意識の向上が根本的な対策となります。従業員に対して、OAuthの仕組みとリスクを理解させる教育プログラムを実施します。具体的には、「アプリに権限を与える前に、本当にそのアプリが必要か確認する」「セキュリティ関連の名前を持つアプリでも、実際には攻撃者のアプリである可能性がある」「緊急性を煽るメールやリンクには注意する」といった基本原則を教育します。

実践的な訓練として、擬似的なOAuthフィッシング攻撃を実施し、従業員がどのように反応するかを評価します。クリックしてしまった従業員には個別にフィードバックを提供し、同意画面の確認ポイント（発行者の確認、要求される権限の範囲、アプリの評価やレビューなど）を具体的に指導します。

多要素認証（MFA）と条件付きアクセスの強化も重要です。多要素認証だけではOAuthフィッシングを完全には防げませんが、攻撃者がアカウントに最初に侵入する難易度を上げることができます。さらに、「条件付きアクセス」ポリシーを設定し、信頼できないデバイスや通常とは異なる場所からのアクセス時には、管理者の承認を必須とします。

Microsoft Entra IDでは「リスクベース条件付きアクセス」を有効にし、不審なサインインパターンが検出された場合に、OAuthアプリケーションへのアクセスを自動的にブロックします。Google Workspaceでは「コンテキストアウェアアクセス」を利用し、デバイスのセキュリティ状態に基づいてアプリケーションへのアクセスを制限します。

メールフィルタリングとURLレピュテーション検査の強化により、フィッシングメール自体をブロックします。OAuthフィッシング攻撃の多くは、フィッシングメールのリンクから始まります。高度なメールセキュリティソリューション（例：Proofpoint、Mimecast、Barracuda）を導入し、メール本文のリンク先URLをリアルタイムで検査します。特に、google.comやmicrosoft.comといった正規ドメインのサブドメインやパスを悪用したフィッシングリンクを検出する機能が重要です。

セキュリティ情報・イベント管理（SIEM）とログ分析で異常を早期発見します。Microsoft Entra IDやGoogle Workspaceの監査ログを継続的に監視し、以下のような異常なパターンを検出します。短期間に複数のユーザーが同じOAuthアプリケーションに権限を付与した、通常の業務時間外にOAuthアプリケーションが作成された、過度に広範な権限を要求するアプリが登録された、外国のIPアドレスからOAuthアプリケーションが登録された、といった兆候を早期に発見し、対処します。

ゼロトラストアーキテクチャの導入により、たとえOAuthアプリケーションが侵害されても、被害を最小限に抑えます。「すべてのアクセスを信頼しない」という前提に立ち、OAuthアプリケーションであっても、アクセスするリソースごとに認証と認可を要求します。データ損失防止（DLP）ポリシーを設定し、機密情報を含むメールやファイルがOAuthアプリケーションを通じて外部に送信される際には、管理者の承認を必須とします。

インシデントレスポンス計画の整備と訓練も欠かせません。OAuthフィッシング攻撃が発生した場合の対応手順を明確にします。具体的には、不審なOAuthアプリケーションを発見した際の報告ルート、影響を受けたアカウントの特定方法、悪意のあるアプリの権限取り消し手順、フォレンジック調査の実施方法、ユーザーへの通知と再教育の実施などを事前に定めておきます。

ベンダーとの連携と脅威インテリジェンスの活用により、最新の攻撃手法に対応します。MicrosoftやGoogleは、既知の悪意のあるOAuthアプリケーションに関する情報を提供しています。これらの脅威インテリジェンスフィードを活用し、自動的にブロックリストを更新します。また、セキュリティベンダーが提供するOAuthアプリケーション分析サービス（例：Microsoft Defender for Cloud Apps、Google Cloud Identity）を活用し、リスクの高いアプリを自動的に検出します。

同意画面フィッシング（OAuth同意詐欺）の対策を簡単に言うと？

同意画面フィッシング（OAuth同意詐欺）の対策を日常の例えで説明すると、「合鍵を渡す前に業者の身元を厳重に確認する」方法に似ています。

想像してください。マンションの管理会社が「合鍵を預かるサービス業者は、事前に管理会社が認定した業者のみ」というルールを導入します。業者が訪問してきても、住人が勝手に合鍵を渡すことはできず、必ず管理会社に確認の連絡をする必要があります。管理会社は業者の身元を確認し、本当に信頼できる業者かどうかを調査してから、「この業者には合鍵を渡しても問題ない」と承認します。

さらに、すでに合鍵を渡してしまった業者についても、定期的に「本当に今でも必要な業者か」「不審な動きをしていないか」をチェックします。もし怪しい業者が見つかれば、すぐに合鍵を返却させ、鍵を交換します。

同意画面フィッシングの対策も同じです。企業では「従業員が勝手にアプリケーションに権限を与えることを禁止」し、必ず管理者（IT部門）の承認を必須とします。管理者は、アプリケーションの発行者が本当に信頼できる企業か、要求される権限が業務上必要な範囲か、他のユーザーの評価やレビューはどうかを確認してから許可します。

また、定期的に「現在どのアプリケーションに権限が与えられているか」をリストアップし、不要になったアプリや不審なアプリの権限を取り消します。従業員には「セキュリティツールという名前のアプリでも、実は偽物かもしれない」「緊急性を煽るメールには注意」といった教育を繰り返し実施します。

このように、「事前の確認」「定期的な監査」「継続的な教育」の3つを組み合わせることで、同意画面フィッシングから組織を守ります。

同意画面フィッシング（OAuth同意詐欺）に関連した攻撃手法

同意画面フィッシング（OAuth同意詐欺）は、単独で使用される攻撃手法ではなく、他の不正アクセス手法と組み合わせて使われることが多くあります。特に、以下の3つの攻撃手法とは密接な関連があります。

OAuth／SSOの悪用

OAuth／SSOの悪用は、GoogleやMicrosoftなどのIDプロバイダーを利用したシングルサインオン（SSO）の仕組みそのものを攻撃する手法です。SSOでは、一度ログインすれば複数のサービスにアクセスできる利便性がありますが、その反面、一つのアカウントが侵害されると、連携しているすべてのサービスに影響が及びます。

同意画面フィッシング（OAuth同意詐欺）は、このOAuth／SSOの仕組みを悪用した具体的な攻撃手法の一つです。両者は密接に関連しており、攻撃者はOAuthの認証フローを理解した上で、その弱点を突いています。

具体的な関連性として、攻撃者は正規のOAuth認証フローを悪用します。OAuth／SSOでは、ユーザーがサードパーティーアプリケーションに権限を与える際、IDプロバイダー（GoogleやMicrosoft）の認証画面を経由します。同意画面フィッシングでは、攻撃者が悪意のあるアプリケーションを作成し、正規のOAuth認証フローを利用してユーザーの同意を得ます。ユーザーから見ると、「GoogleやMicrosoftの正規の画面」で承認しているため、安全だと誤解してしまいます。

さらに、SSOを利用している組織では、被害が連鎖的に拡大します。例えば、Google Workspaceのアカウントに対してOAuthフィッシングが成功すると、攻撃者はそのアカウントでSSOログインできるすべてのサービス（Slack、Salesforce、Zoomなど）にもアクセスできるようになります。攻撃者は一つのOAuthトークンを取得するだけで、組織が使用している複数のクラウドサービスを侵害できるのです。

実際の攻撃シナリオでは、攻撃者はまずフィッシングメールでOAuthアプリケーションへの同意を誘導します。ユーザーが「許可」をクリックすると、攻撃者のアプリケーションにアクセストークンが発行されます。攻撃者はこのトークンを使って、ユーザーのメール、カレンダー、ドライブなどにアクセスします。さらに、そのアカウントでSSOログインできる他のサービスにも侵入し、組織全体のシステムに横展開していきます。

Microsoftの報告によると、OAuthアプリケーションの悪用は、Exchangeサーバーの制御やスパムの拡散にも使われています。攻撃者が管理者権限を持つアカウントを侵害し、組織のテナント内にセカンドパーティーアプリケーション（内部アプリ）として悪意のあるOAuthアプリを登録することで、組織全体のメールシステムを制御できるようになります。

アカウント乗っ取り（ATO）

アカウント乗っ取り（ATO: Account Takeover）は、攻撃者が正規ユーザーのアカウントを不正に取得し、本人になりすまして悪用する攻撃です。フィッシング、パスワードリスト攻撃、総当たり攻撃など、様々な手法でアカウントが侵害されますが、同意画面フィッシング（OAuth同意詐欺）は、最も検知が困難なATO手法の一つです。

従来のATO手法では、攻撃者はユーザーのパスワードを盗み取る必要がありました。しかし、同意画面フィッシングでは、パスワードを知らなくてもアカウントを乗っ取ることができます。ユーザーがOAuthアプリケーションに権限を許可すると、攻撃者はアクセストークンを取得し、そのトークンを使ってアカウントにアクセスします。このアクセスは「正規の認証プロセス」を経ているため、セキュリティシステムは不正なログインとして検知しません。

Proofpointが報告した事例では、攻撃者は中間者攻撃（AiTM）でユーザーのセッションを傍受し、その後OAuthアプリケーションを登録することで、約4日間にわたってアカウント乗っ取りを継続しました。被害者がパスワードを変更した後も、攻撃者が登録したOAuthアプリケーションは有効なままだったため、アクセスが維持されました。これは、従来のATO対策（パスワード変更、アカウントロック）では防げない、新しいタイプの攻撃です。

さらに悪質なケースでは、攻撃者はアカウント乗っ取りとOAuthフィッシングを組み合わせます。まず、一人の従業員のアカウントを侵害します（パスワードスプレー攻撃や総当たり攻撃で）。次に、そのアカウントから社内の他の従業員に対してフィッシングメールを送信し、OAuthアプリケーションへの同意を促します。同僚からのメールは信頼されやすいため、多くの従業員が「許可」をクリックしてしまいます。こうして、組織全体にアカウント乗っ取りが連鎖的に広がります。

実際の被害では、攻撃者は乗っ取ったアカウントを使って、ビジネスメール詐欺（BEC）を実行します。経理部門の従業員のアカウントを乗っ取り、「緊急の送金依頼」メールを送信する、CEOのアカウントを乗っ取り、「機密プロジェクトの資料を送ってほしい」と依頼する、といった手法で、金銭的被害や情報漏洩を引き起こします。

同意画面フィッシングによるATOの特徴は、「永続性」です。パスワードを盗まれた場合、パスワード変更で対処できますが、OAuthトークンは明示的に取り消さない限り有効です。攻撃者は数週間から数ヶ月にわたって、気づかれずにアカウントにアクセスし続けることができます。

トークン窃取・再利用

トークン窃取・再利用は、攻撃者がアクセストークン、リフレッシュトークン、セッショントークンなどの認証情報を盗み取り、それを使って正規ユーザーになりすます攻撃です。トークンベースの認証が広く使われるようになった現在、パスワードではなくトークンを狙う攻撃が増加しています。

同意画面フィッシング（OAuth同意詐欺）は、トークン窃取の一形態です。攻撃者は、ユーザーに悪意のあるOAuthアプリケーションへの同意を促すことで、正規の手順でアクセストークンを「発行させ」ます。ユーザーが「許可」をクリックすると、OAuthプロバイダー（GoogleやMicrosoft）が攻撃者のアプリケーションにアクセストークンとリフレッシュトークンを発行します。攻撃者はこのトークンを使って、ユーザーのリソースにアクセスします。

特に危険なのは「リフレッシュトークン」の存在です。アクセストークンは通常、短時間（数時間）で期限切れになりますが、リフレッシュトークンは長期間（数週間から数ヶ月、場合によっては無期限）有効です。攻撃者がリフレッシュトークンを取得すると、アクセストークンの期限が切れても、リフレッシュトークンを使って新しいアクセストークンを自動的に取得できます。これにより、ユーザーが気づかないまま、長期間にわたってアクセスが継続されます。

Microsoftの報告では、攻撃者が「offline_access」という権限を要求するOAuthアプリケーションを使用していました。この権限により、ユーザーがログアウトした後でも、攻撃者はアクセスを維持できます。さらに、攻撃者がセカンドパーティーアプリケーション（内部アプリ）として登録することで、より強力なトークンを取得できます。

実際の攻撃では、攻撃者は取得したトークンを「トークンリプレイ攻撃」に使用します。例えば、GitHubの攻撃事例では、攻撃者が「gitsecurityapp」というOAuthアプリを作成し、開発者のGitHubアカウントへのフルアクセストークンを取得しました。このトークンにより、攻撃者はソースコードの閲覧、コミット履歴の確認、プライベートリポジトリへのアクセス、さらにはコードの改ざんまで可能になりました。

トークンの窃取と再利用は、以下の方法でも行われます。攻撃者がマルウェアを使って、ブラウザに保存されているトークンを盗み取る、中間者攻撃（MITM）でHTTPS通信を傍受し、トークンを取得する、フィッシングサイトでユーザーが入力した認証情報を使って、正規のAPIからトークンを発行させる、といった手法です。同意画面フィッシングは、これらの中でも最も「正規の手順」に見えるため、検知が困難な手法です。

組織がこの脅威に対抗するには、トークンのライフタイム管理、トークンの使用状況の監視、異常なトークン使用パターンの検出、定期的なトークンの失効とローテーション、が重要です。Microsoft Entra IDでは「トークンライフタイムポリシー」を設定し、リフレッシュトークンの有効期限を短くすることで、長期的なアクセスを防ぎます。Google Workspaceでは「セッション管理」機能を使い、不審なトークン使用を検出した際に自動的に失効させます。

同意画面フィッシング（OAuth同意詐欺）のよくある質問

同意画面フィッシングと通常のフィッシングはどう違うのですか？

通常のフィッシングは、偽のログイン画面を作成してユーザーにパスワードを入力させ、それを盗み取る手法です。一方、同意画面フィッシング（OAuth同意詐欺）は、正規のOAuth認証画面を使い、ユーザーに「アプリケーションへのアクセス許可」をクリックさせる手法です。最も重要な違いは、同意画面フィッシングでは「偽のページ」を作る必要がなく、GoogleやMicrosoftの本物の認証画面が表示される点です。ユーザーから見ると完全に正規の手順に見えるため、見抜くことが非常に困難です。また、通常のフィッシングではパスワード変更で対処できますが、OAuthフィッシングでは一度許可を与えてしまうと、パスワードを変更しても攻撃者のアクセスは継続されます。明示的にアプリケーションの権限を取り消さない限り、被害が続くという点が大きな違いです。

OAuthアプリケーションの権限を確認する方法はありますか？

GoogleアカウントとMicrosoftアカウント、それぞれで確認方法が異なります。Googleアカウントの場合、Googleアカウントの管理ページ（myaccount.google.com）にアクセスし、左メニューの「セキュリティ」をクリックします。下にスクロールして「サードパーティ製のアプリとサービス」を選択すると、現在権限を与えているすべてのアプリのリストが表示されます。各アプリをクリックすると、どのような権限が付与されているか（メールの読み取り、ドライブへのアクセスなど）を確認できます。不要なアプリや不審なアプリは「アクセス権を削除」ボタンで権限を取り消せます。Microsoftアカウントの場合、Microsoftアカウントのページ（account.microsoft.com）にログインし、「プライバシー」タブから「アプリとサービス」を選択します。許可しているアプリの一覧が表示されるので、各アプリの権限を確認し、不要なものは削除します。企業のMicrosoft 365アカウントの場合、管理者はMicrosoft Entra ID管理センターで、組織全体のOAuthアプリケーションを一覧表示し、管理できます。

どのようなアプリケーション名や権限要求が怪しいですか？

以下のような特徴を持つアプリケーションは特に注意が必要です。まず、セキュリティ製品を装った名前（Google Defender、Microsoft Security、Email Protection、Account Guardなど）は非常に怪しいです。これらは正規のサービスではなく、攻撃者が信頼性を装うために使う典型的な名前です。次に、発行者が「未確認」や「個人」となっているアプリも警戒すべきです。正規の企業が提供するアプリは通常、発行者名が明記されています。権限の面では、「すべてのメールの読み書き」「すべてのファイルへのアクセス」「ユーザー管理権限」など、過度に広範な権限を要求するアプリは危険です。特に「offline_access」という権限は、ユーザーがログアウトした後も攻撃者がアクセスを維持できるため、非常に危険です。また、業務上の必要性が不明瞭なアプリ（例：単純な計算ツールなのにメールへのアクセスを要求するなど）も疑うべきです。アプリの評価やレビューが極端に少ない、または全くない場合も注意が必要です。

すでにOAuthアプリケーションに許可を与えてしまった場合、どうすればよいですか？

不審なOAuthアプリケーションに許可を与えてしまった場合、迅速に以下の対応を取る必要があります。第一に、該当アプリケーションの権限を直ちに取り消します。Googleの場合はmyaccount.google.comから、Microsoftの場合はaccount.microsoft.comから、該当アプリを探して「アクセス権を削除」します。第二に、パスワードを変更します。これだけでは攻撃者のアクセスを完全に遮断できませんが、追加の侵入経路を塞ぐために重要です。第三に、アカウントのアクティビティログを確認します。Googleの場合は「セキュリティ」ページの「最近のセキュリティイベント」、Microsoftの場合は「サインインアクティビティ」を確認し、不審なアクセスがないか調べます。不審なアクセスがあれば、すべてのアクティブセッションを強制的にログアウトさせます。第四に、組織のIT部門またはセキュリティチームに直ちに報告します。他の従業員も同様の攻撃を受けている可能性があり、組織全体での対応が必要です。第五に、メールの転送設定や自動返信ルールが勝手に追加されていないか確認します。攻撃者がメールを外部に転送する設定を追加している可能性があります。

多要素認証（MFA）を使っていても、同意画面フィッシングの被害に遭うのですか？

残念ながら、多要素認証（MFA）だけでは同意画面フィッシング（OAuth同意詐欺）を完全には防げません。MFAは、ログイン時にパスワードに加えて追加の認証要素（スマートフォンの認証アプリ、SMSコード、生体認証など）を要求することで、パスワードが漏洩しても不正ログインを防ぐ仕組みです。しかし、OAuthフィッシングでは、攻撃者はユーザーのパスワードを盗む必要がありません。ユーザー自身が「正規の認証プロセス」を経て、攻撃者のアプリケーションに権限を許可してしまうため、MFAは機能しません。具体的には、ユーザーがフィッシングメールのリンクをクリックし、Googleの正規の認証画面が表示され、MFAでの認証も完了します。その後、「このアプリがあなたのメールにアクセスすることを許可しますか？」という同意画面が表示され、ユーザーが「許可」をクリックすると、攻撃者のアプリにアクセストークンが発行されます。この時点で、MFAは既に通過しており、攻撃者は正規の権限を持ったアプリとしてアカウントにアクセスできるようになります。ただし、MFAは他のタイプの攻撃（パスワードリスト攻撃、総当たり攻撃など）を防ぐために依然として重要です。OAuthフィッシング対策としては、MFAに加えて、OAuthアプリケーションの管理者承認制度、定期的な権限監査、ユーザー教育を組み合わせる必要があります。

中小企業でもOAuth同意詐欺の標的になりますか？

はい、中小企業も同意画面フィッシング（OAuth同意詐欺）の標的になります。従来、高度なサイバー攻撃は大企業や政府機関が主な標的でしたが、近年は中小企業も狙われるケースが増えています。理由は主に3つあります。第一に、サプライチェーン攻撃の起点として狙われます。攻撃者は、大企業と取引関係にある中小企業を侵害し、その信頼関係を利用して大企業にフィッシングメールを送信します。取引先からのメールは信頼されやすいため、攻撃成功率が高まります。第二に、中小企業はセキュリティ対策が不十分なことが多く、「狙いやすい標的」と見なされます。専任のIT担当者がいない、従業員へのセキュリティ教育が不足している、最新のセキュリティツールを導入していない、といった状況は攻撃者にとって好都合です。第三に、中小企業もGoogle WorkspaceやMicrosoft 365といったクラウドサービスを広く利用しており、OAuthフィッシングの攻撃対象となりうる環境が整っています。中小企業ができる対策としては、まず従業員へのセキュリティ教育を徹底すること、OAuthアプリケーションの管理者承認を必須にすること、定期的に許可されているアプリを確認すること、不審なメールやリンクに注意すること、が重要です。

OAuthフィッシング攻撃が発生した場合、法的な報告義務はありますか？

OAuthフィッシング攻撃により個人情報や機密情報が漏洩した場合、法的な報告義務が発生する可能性があります。日本では、個人情報保護法により、個人情報を取り扱う事業者は、個人データの漏洩、滅失または毀損が発生し、個人の権利利益を害するおそれがある場合、個人情報保護委員会への報告と本人への通知が義務付けられています。OAuthフィッシングにより顧客の個人情報を含むメールやファイルに攻撃者がアクセスした場合、これに該当する可能性が高いです。報告は、事案を知った日から速やかに（原則として30日以内）行う必要があります。また、EUのGDPR（一般データ保護規則）が適用される場合（EU居住者の個人データを扱っている場合）、より厳格な報告義務があります。個人データ侵害を認識してから72時間以内に監督機関に通知し、高いリスクがある場合は本人にも通知する必要があります。違反した場合、最大で全世界年間売上高の4%または2000万ユーロのいずれか高い方の制裁金が科される可能性があります。米国の各州法（カリフォルニア州のCCPAなど）、金融業界の規制（金融商品取引法、銀行法など）、医療分野の規制（HIPAAなど）も、それぞれ報告義務を定めています。したがって、OAuthフィッシング攻撃が発生した場合、組織の法務部門や外部の弁護士に相談し、適用される法令に基づいた適切な対応を取ることが重要です。