最近、Salesforceをご利用のお客様の環境におけるフィッシング活動を調査していた際、新たな「OAuthデバイスコードフィッシング」のキャンペーンを発見しました。
Microsoft社はすでに、このキャンペーンの背景にあるOAuthの仕組みや攻撃者のインフラに関する優れた技術分析を公開しています。本記事では、その分析を繰り返すのではなく、同記事では触れられていない新たな観察結果と、なぜこれがSalesforce管理者にとって今なお重要なのかに焦点を当てます。
なじみの手法
デバイスコードフィッシング自体は新しいものではありません。
すでに2024年の初頭には、資格情報（認証情報）を盗み取ることなくOAuthトークンを取得するために、Microsoftのデバイス認可グラント（Device Authorization Grant）を悪用するキャンペーンが観測されていました。しかし、ここ数ヶ月で「Phishing-as-a-Service（PaaS：サービスとしてのフィッシング）」キットが大幅に進化し、サイバー犯罪のエコシステム内でより広く採用されるようになったことで、この手法は急速に主流化しつつあります。現在のキャンペーンでは、標的となるユーザーに違和感を与えないシームレスな体験を提供するため、プロセス全体を正規のコンテンツホスティングやコラボレーションプラットフォーム、テンプレート型のフィッシングページ、そして正規のIDプロバイダー（IdP）による認証の背後に隠蔽する傾向が強まっています。
主な発見
フィッシングフレームワークの分析により、以下の事実が明らかになりました。
- MicrosoftとGoogle両方のデバイスコード認証への対応
- コラボレーションサービスやMicrosoftサービスを騙る30種類以上の囮（ルアー）テンプレート
- ランタイムでのローカライズに対応した14の言語サポート
- 中継地点の囮として、Proton DocsやLark Docsなどの正規のSaaSプラットフォームを悪用
- バックエンドのセッショントラッキングとフロントエンドのポーリングによる、デバイスコードワークフローの自動化
観測されたデバイスコードフィッシングの流れ
Microsoftは根本にあるOAuthの仕組みを詳細にドキュメント化していますが、今回の調査で分析されたサンプルからは、別の興味深い視点が見えてきました。それは、「フィッシングキャンペーンがどのように被害者に届けられるか」という点です。攻撃者は、ユーザーを直接悪意のあるログインページに誘導するのではなく、正規のコンテンツホスティングプラットフォーム、カスタマイズ可能なフィッシングフロントエンド、そして正規のMicrosoftまたはGoogleのデバイスコード認可フローという、複数のステージを連鎖（チェーン）させています。これにより、最初から最後まで信頼できるように見えるワークフローを構築しています。
図1. 分析中に観測された大まかな流れ （※この図は、根本的な認可のやり取りではなく、フィッシングキャンペーンがどのように配信されるかに焦点を当てるため、OAuthプロトコルを意図的に簡略化しています）
すべては1つの文書から始まる
このキャンペーンは、多くの文書ベースのフィッシング攻撃と同様に始まります。
ユーザーは、共有文書を装ったメールの添付ファイルを受け取ります。
図2. スペイン語のメールサンプル
このキャンペーンが幅広い言語をサポートしている点は注目に値します。この言語サポートは、添付ファイルから中継ファイル、そしてフィッシングページに至るまで一貫して見られます。
図3. 複数言語の添付ファイル
多くのフィッシングキャンペーンとは異なり、これらの文書は中継ホストとして正規のSaaSプラットフォームへと誘導します。標的ユーザーをすぐにフィッシングインフラに誘導するのではなく、Proton Docs、Lark Docs、Zoho Writer、Medium、Bookwiz、Mindsmithなどの本物のサービスを使用して、悪意のあるフィッシングインフラへのリンクを含む、一見無害なコンテンツをホストしていました。
図4. さまざまな正規SaaSプラットフォームでホストされている、ローカライズされた中継文書
このアプローチにはいくつかの利点があります：
- 文書自体が正規のSaaSプラットフォームにホストされている
- URLが信頼できるように見える
- レピュテーションベースのフィルタリングで文書がブロックされにくい
- フィッシングインフラがチェーンの「1クリック深い」場所に隠れる
このほか、Appsmith、Playbook、Soloist.ai、7taps、Ouro Foundationなどのプラットフォームも悪用が観測されました。
フロントエンドのフィッシングコンポーネント
元のページは主に、ランタイムデコード、エンコードされたペイロード、動的レンダリングを使用し、高度に難読化されたJavaScriptで構成されていました
デコードすると、これが単なる静的なフィッシングページではなく、フィッシングフレームワークであることが明白になりました。
フィッシングフロントエンドは以下の役割を担っています：
- テンプレートに基づく偽ページのレンダリング
- ローカライズ（多言語化）
- クリップボードへのコピー
- MicrosoftまたはGoogleのデバイスコードページの表示
デコードされたフロントエンドは、OAuthトークンを直接処理していないようです。代わりに、攻撃者が制御するAPIエンドポイントをポーリングしてセッション状態を確認しています。このことから、OAuthデバイスコードの生成とトークンのポーリングは、攻撃者が制御するOAuthクライアントまたはバックエンドアプリケーションを介して、サーバー側で行われている可能性が高いと考えられます。
囮のテンプレート
デコードされたJavaScriptからは、ページのレイアウトと言語・メッセージを分離した、テンプレート駆動型のレンダラーが確認されました。
コードからは、30種類以上の囮テンプレートに対応していることが判明しています。
図5. 囮テンプレートを構築するための関数
その中には、以下のような文書共有サービスが含まれていました：
- OneDrive
- SharePoint
- Dropbox
- Google Drive
- OneNote
- DocuSign
- Adobe
また、以下のようなMicrosoftブランドのワークフローも含まれていました：
- Teams meetings
- Planner
- Forms
- Intune
- Bookings
- Password Reset
- MFA Setup
- Quarantine notifications
- Copilot
- Stream
- Whiteboard
- Yammer
図6. さまざまな囮のテーマ
多言語対応
もう1つの興味深い発見は、ローカライズ（現地語化）のサポートです。
デコードされた翻訳テーブルは、少なくとも以下の14言語に対応していました。
- English
- Dutch
- German
- French
- Spanish
- Portuguese
- Italian
- Turkish
- Polish
- Russian
- Japanese
- Korean
- Chinese
- Arabic
言語ごとに別々のフィッシングページを維持するのではなく、このフレームワークは共通のHTMLテンプレートをレンダリングした後に、インターフェースの文字列をローカライズされた同等の文字列に置き換えます。
図7. ローカライズされた文字列
これにより攻撃者は、同じバックエンドを再利用しながら、さまざまなコラボレーションプラットフォームや業務ワークフローに合わせた、標的ユーザーの言語による囮を提示することができます。
図8. 同じ囮テンプレート、異なる言語
IDプロバイダーのサポート
デコードされたフロントエンドの分析により、このキャンペーンが複数のIDプロバイダー（IdP）に対応していることが示唆されました。
図9. MicrosoftとGoogleへの対応
使用するIDプロバイダーは、構成設定によって決定されます。
Microsoft用設定時: 標的ユーザーを https://login.microsoftonline.com/common/oauth2/deviceauthに誘導します。
図10. 正規のMicrosoftのプロンプト画面
Google用設定時: 代わりに https://www.google.com/deviceを使用します。
図11. 正規のGoogleのプロンプト画面
構成
各フィッシングページをハードコーディングするのではなく、フロントエンドは単純な設定オブジェクトを読み込んで囮のレンダリング方法を決定します。設定には、視覚的なテーマ、文書のメタデータ、送信者名、言語、および認証ワークフローが指定されています。これにより、わずかなパラメータを変更するだけで、同じコードベースから多種多様なフィッシングの囮を生成することができます。
今回のサンプルでは、フレームワークはOneDriveのテーマを選択し、PDF文書を表示し、送信者名と文書タイトルをカスタマイズし、インターフェースをフランス語にローカライズし、デバイスコードのワークフローを使用するようにページを設定していました。
図12. 構成のサンプル
図13. 構成に基づいて生成された囮画面
この設定駆動型のアプローチにより、攻撃者はブランド、言語、文書タイプごとに別々のフィッシングページを管理することなく、数個のパラメータを変更するだけでキャンペーンを迅速に適応させることができます。
攻撃者が制御するOAuthバックエンド／クライアント
インフラのこの部分は外部からは見えませんが、おそらく以下の役割を果たしていると考えられます：
- IDプロバイダーへのデバイスコードの要求
device_code、user_code、セッション情報の保存- ユーザーが認可を完了するまで、IDプロバイダーのトークンエンドポイントをポーリング
- 認可ステータスの監視
- 簡略化したステータスをフロントエンドに公開
- アクセストークンおよびリフレッシュトークンの取得
資格情報を狙う通常のフィッシングとは異なり、デバイスコードフィッシングはユーザーのパスワードを盗んだり、MFAをバイパスしようとはしません。
代わりに、標的となったユーザーは、IDプロバイダーとの間で正規の認証フローを完了します。MFAが必要な場合でも、ユーザーは正規の認証プロセスを進めていることになります。この攻撃が成功するのは、認証（Authentication）ではなく、認可（Authorization）を悪用しているからです。
攻撃の最終ゴールは、単にユーザーに確認コードを入力させることではありません。攻撃者が制御するOAuthアプリケーションを認可することにより、標的ユーザーはそのアカウントへのAPIアクセス権を付与してしまいます。IDプロバイダー、アプリケーション、および付与された権限によっては、攻撃者がメール、ファイル、コラボレーションデータ、またはその他のクラウドリソースにアクセスできるようになる可能性があります。企業環境では、この委任されたアクセス権により、追加の資格情報を必要とせずに、接続されたMicrosoftサービス間を横方向に移動できるようになる場合もあります。盗まれた認可は、最終的にデータの窃盗、ビジネスメール詐欺、組織内でのラテラルムーブメント、あるいは恐喝に悪用される恐れがあります。
オペレーター主導から自動化されたフィッシングへ
以前に私たちが文書化したSalesforceデバイスフロー攻撃との最大の違いの1つは、このフィッシングフレームワークに組み込まれている自動化の度合いです。
過去のSalesforceのキャンペーンでは、標的ユーザーとのリアルタイムのやり取りに大きく依存しており、しばしばビッシング（電話フィッシング）などを用いてユーザーを説得し、有効期限が切れる前に確認ページにアクセスさせて短寿命のデバイスコードを入力させることがよくありました。
初期のMicrosoftデバイスコードフィッシングキャンペーンも、同様の課題に直面していました。デバイスコードは通常、メールやメッセージで直接配信されるため、コードがすぐに失効してしまうことから、タイミングが極めて重要でした。
しかし、今回分析したフレームワークは、その制限をほぼ完全に解消しています。
攻撃者が制御するバックエンドが常に新鮮な認可セッションを管理し、フィッシングフロントエンドがそのステータスをリアルタイムで追跡します。標的ユーザーの視点からは、ワークフローはきわめてシームレスです。ユーザーは単に文書共有の画面を進め、表示されたコードを入力するだけです。
これにより、コードの失効に伴う緊急性が大幅に軽減され、攻撃者がリアルタイムでやり取りを調整する必要がなくなり、キャンペーンの規模を拡大することが格段に容易になります。
Salesforce管理者が注意すべき理由
このキャンペーンは最終的にMicrosoftやGoogleのアイデンティティ（ID）を悪用するものですが、私たちがこれに遭遇したのは、Salesforceのお客様環境を標的としたフィッシング活動を調査しているときでした。
観測されたケースでは、フィッシングメールはSalesforceと連携する業務ワークフローを通じてユーザーに届いていました。これは、最終的な攻撃対象がSalesforceプラットフォームの「外」にある場合でも、Salesforceが攻撃の侵入口になり得ることを示しています。
ユーザーがフィッシングのワークフローに従ってしまうと、攻撃者が次に狙うのはSalesforceではなく、ユーザーのデジタルアイデンティティです。
攻撃者は、Salesforceの運用に影響を与えるために、必ずしもSalesforceへの直接的なアクセスを必要としません。そのアイデンティティが侵害されると、メール、クラウドストレージ、コラボレーションプラットフォーム、内部文書、業務上のコミュニケーションが漏洩する可能性があります。そして、それらと同じリソースが、Salesforceのビジネスプロセスを支えていたり、顧客の機密情報を含んでいたり、取引の承認やSalesforce連携システムとのやり取りに使用されていることが非常に多いのです。
したがって、Salesforceユーザーを保護することは、これらの攻撃がユーザーに到達するまでの「通信チャネル」を保護することでもあるのです。
推奨対策
OAuthの認可は最終的にSalesforceの外部で行われますが、組織はフィッシングキャンペーンがSalesforce連携のワークフローを通じてユーザーに到達する可能性を低減させる必要があります。
Salesforce管理者は以下の対策を検討すべきです：
- Email-to-Case（メールからケース）やその他の受信メールワークフローを、フィッシングの添付ファイルや文書共有の囮から保護する。
- メールの統合機能を通じてSalesforceに取り込まれる外部コンテンツをレビューする。
- 正規のMicrosoftやGoogleの認証ページであっても、フィッシング攻撃の一部である可能性があることをユーザーに教育・訓練する。
- ID管理者と連携し、不審なデバイスコード認可や、新しく認可されたOAuthアプリケーションがないかを調査する。
Cloud Protection for Salesforceをご利用中のお客様は、PHISH/PDF.Agent 検出機能により、これらの文書ベースのフィッシングキャンペーンから保護されています。ユーザーがフィッシングインフラに到達する前に攻撃を阻止することが可能です。
結論
今回の調査は、攻撃者がフィッシングワークフローに正規のクラウドサービスをいかに巧妙に組み込んでいるかを示しています。ユーザーを直接悪意のあるインフラに誘導するのではなく、信頼された文書ホスティングプラットフォーム、カスタマイズ可能なフィッシングフロントエンド、そして正規のMicrosoftまたはGoogleの認証ページを連鎖させることで、最初から最後まで見慣れた安心感のある体験を作り出しています。ワークフローの各ステップは、単体で見ればどれも正規のものに見えます。これらを一連の流れとして捉えて初めて、攻撃の全貌が明らかになります。
このキャンペーンが最終的に狙ったのはMicrosoftとGoogleのアイデンティティ（ID）でしたが、これが発見されたのはSalesforceのお客様環境に影響を与えるフィッシング活動の調査中でした。
現代のクラウド攻撃が単一のプラットフォーム内に留まることは滅多にありません。フィッシングメールがSalesforce連携のワークフローを通じて届き、ユーザーにMicrosoftやGoogleでの認証を促し、最終的には複数のSaaSアプリケーションにまたがるビジネスプロセスを支えるアイデンティティを侵害する、といったことが起こり得ます。
Salesforce管理者にとって、プラットフォームを保護することは、そこに接続されているユーザーや通信チャネルを保護することにほかなりません。ユーザーがフィッシングインフラに到達する前にこれらのキャンペーンを阻止することは、最終的にSalesforceの枠を遥かに超えた広範なアイデンティティの侵害を防ぐことにつながります。
クラウドセキュリティは、もはや個々のプラットフォームだけで定義できるものではありません。Salesforce、Microsoft 365、Google Workspace、その他無数のSaaSアプリケーションは、すべて「同じユーザー」を共有しています。攻撃者はすでにそのことを理解しています。防御側である私たちも、同じように広い視野で考える必要があります。
Salesforceは攻撃の「目的地」ではないかもしれませんが、「攻撃経路」の一部になり得るのです。