【Oktane25】セッションレポート：脅威インテリジェンスが暴く新たな脅威「Void Proxy」の発見と対策

フィッシング耐性のある認証（FastPass）によって「脅威のシグナル」を発見した

FastPassは、ユーザーのデバイス（Okta Verify）とOktaサービス間に暗号化による強力な紐付けを生成します。

これにより、正規のサイト以外（フィッシングサイトなど）からサインインしようとすると、認証は失敗します。この失敗イベントがシステムログに記録され、同時に、その同じイベントがOkta社のキューにチケットを発行します。これが、Okta社のアナリストが調査を開始するトリガーとなります。

今回の話は、まさにその一つのトリガーから始まった壮大な調査についてになります。

不審なアラートを発見！！

Void Proxyの発見はOkta社のHoussem Eddine Bordjiba氏が、ある顧客システムでFastPassが検知したフィッシングを調査していたことから始まります。

Houssem氏は、そのアラートのURLのドメイン構造が、ほぼ同時期に全く無関係の別のお客様に対して使われたフィッシングドメインと酷似していることに気づきました。※以下キャプチャ参照

複数のインシデントの関連付けと調査の開始

これを単なる偶然ではないと考えたHoussem氏は「single activity cluster（単一のアクティビティクラスター）」、つまり共通の攻撃基盤が存在する可能性が高いと判断し、本格的な調査を開始し、発見したドメインパターン (securedauth[...] など) を基に、類似のドメインをさらに探索しました。

すると、newnewdom[...] といった亜種のパターンも次々と見つかり、攻撃キャンペーンが想定よりも広範囲に及んでいることが明らかになりました。

これを契機にHoussem氏はフィッシング・アズ・ア・サービス（PhaaS）「Void Proxy」を発見するのですが、発見までの流れの前に、Void Proxyがどのように機能するかを説明します。

Void Proxyの巧妙な攻撃フロー：詳細解説

1. 計算されたフィッシングメール
攻撃の起点となるのは、給与明細等をテーマにしたフィッシングメールです。スピーカーはこのテーマが選ばれる理由を「人々は給料に関心があり、クリックする可能性が高いから」と述べていました。また、侵害済みで評判の高いメールアカウントを利用することで、匿名性と耐性を確保し、メールフィルタを回避して到達率を高めるという二重の効果が狙われていました。

2. リダイレクトによる隠蔽
メール内のリンクは、URL短縮サービスと複数回のリダイレクトを挟むことで、ユーザーからフィッシングページの真の宛先を隠し、ユーザーがリンクをクリックして攻撃者の意図した宛先に到達する可能性を高めます。また、メール自体の自動分析ではフィッシングドメインが明らかにならないようにする効果もあります。

3. 自動スキャナーの排除
次の段階では、CloudflareのCAPTCHAチャレンジを悪用します。攻撃者は、自動スキャナーに自分たちのフィッシングインフラを見られたくありません。自動化されたツールでテストされた場合に、それらのリクエストを行き止まりに追いやる（CAPTCHAチャレンジは人間しかクリアできない）ことでコアサービスの分析を回避しています。

4. Cloudflare Workersの悪用とモジュール設計
さらに、Void ProxyはCloudflare Workersを悪用し、「どのフィッシングページ（MicrosoftかGoogleか）をユーザーに見せるか」を判断するロジックを実行します。このロジックは、後に説明するフィッシングプロキシのロジックとは意図的に分離されています。このように各コンポーネントをモジュールとして独立させることで、システム全体の耐障害性を高めています。

5. 核心機能：Okta連携を検知するフィッシングプロキシ（AitMプロキシサーバー）
第一段階の偽ログインページを突破した後、Void Proxyの最も高度な機能が作動します。
セッションの説明によると、もしターゲットのアカウントがOktaと連携していない場合、プロキシは認証情報を窃取し、MicrosoftやGoogleのサーバーへ直接リクエストを中継します。しかし、アカウントがOktaと連携している場合、インフラはそれを検知し、Microsoft/GoogleとOktaの両方を巧みに模倣した第二段階のフィッシングページへとユーザーをリダイレクトします。この外部IDプロバイダーへのリダイレクトを処理できる能力が、Void Proxyを特に危険なものにしています。
※AiTM（Adversary in the middle）：多要素認証を通過した状態のセッションCookieを盗み出すフィッシング攻撃で、中間者攻撃の一種です

▼ Microsoft 365の攻撃フロー 

このように、SSO環境にまで対応した高度なロジックを備えている点が、Void Proxyの特異性です。

以降は、Houssem氏が執筆した（https://sec.okta.com/articles/uncloakingvoidproxy/）より抜粋します。
また、記事にはVoid Proxyのコンソール画面なども載っています。ぜひご覧ください！※セッションでも紹介されていたのですが取り損ねました。。。

"The server acts as a reverse proxy to capture and relay information — including usernames, passwords, and MFA responses — to legitimate services like Microsoft, Google, and Okta. When the legitimate service validates the authentication and issues a session cookie, the VoidProxy proxy server intercepts it. A copy of the cookie is exfiltrated and made available to the attacker via their admin panel. The attacker is now in possession of a valid session cookie and can access the victim's account."
（そのサーバーはリバースプロキシとして動作し、ユーザー名、パスワード、MFAの応答といった情報を捕捉して、Microsoft、Google、Oktaなどの正規サービスに中継します。正規のサービスが認証を検証してセッションクッキーを発行すると、VoidProxyのプロキシサーバーがそれを傍受します。傍受したクッキーのコピーは外部に送信され、攻撃者は自身の管理パネルからそれを入手できるようになります。これにより、攻撃者は有効なセッションクッキーを手に入れ、被害者のアカウントにアクセスすることが可能になります。）

以上がVoidProxyによりAiTM攻撃が成立するまでの流れとなります！

さて、Void Proxyの機能をご理解いただいた上で、Houssem氏がいかにしてこの複雑なインフラを発見したか、その調査プロセスを記載します。

スピーカーは「思い出してください、彼は最初から始めたわけではありません」と前置きし、調査が攻撃の終点から始まったことを強調しました。
（つまり、フィッシングメールの情報は無く、Oktaのログ上に残されたフィッシングページの情報のみから調査を始めたという意味だと思います）

そこから「何がこのページにリダイレクトさせたのか」を突き止めることで第一段階のページを発見し、次に「なぜMicrosoftとGoogleのページを出し分けるのか」というロジックを解明し…と、数週間にわたり、毎日数時間、地道な逆引き調査を続けたのです。

結果的にはこの逆引き調査を実施したのが幸運だったと語っていました。なぜなら、Void Proxyの運営者は、リサーチャーがフィッシングメールからインフラまで、これらすべての回避層を突破するのを非常に困難にするように全体を設計していたからです。（複数のリダイレクトを行うなど）

セッションの中で特に衝撃的だったのが、このVoid Proxyの価格です。なんと月額わずか250ドルでした。これほど高度な攻撃が、これほど安価に「サービス」として利用できてしまうのは、とても恐ろしいですね。

しかし、こうした脅威に対しての希望も紹介されました。それは、「攻撃者はFastPassを心底嫌っている」という事実です。

スピーカーは、最近観測されたフィッシングメールの実例をスクリーン（以下キャプチャ）に映し出しました。そこには、攻撃者からターゲットに対し、「お願いです、FastPass機能は利用しないでください」というメッセージが書かれていました。フィッシング耐性を持つ認証が、スピーカーの言葉を借りれば「攻撃者がFastPassを心底嫌っている」ことが明確にわかる、非常に興味深い事例でした！

そしてセッションの最後には、今後の重要な脅威として「MFAダウングレード攻撃」が挙げられました。これは、攻撃者がユーザーを騙して、意図的にセキュリティレベルの低い認証方法（パスワードやSMSなど）を使わせる手口です。
※上記のキャプチャでも「Slackには通常通りサインインしてください」などの文言が書かれています。

この脅威に対し、スピーカーは我々が取るべき対策を力強く訴えかけました。

「ユーザーを（FastPassに）登録するだけでは不十分です。ポリシーでフィッシング耐性のある認証要素のみを強制し、他の弱い認証要素を取り除くのです。」

おわりに