** 本記事は、Stealing user credentials with evilginx の翻訳です。最新の情報は英語記事をご覧ください。**
Evilginx は、正規の (広く使われている) オープンソースの nginx Web サーバーをベースにしたツールで、ユーザー名、パスワード、およびセッショントークンの窃取に使用できます。このツールを利用することで、攻撃者が多要素認証 (MFA) をバイパスできる可能性があります。本記事では、Evilginx がどのように動作し、どのような情報を取得することができるかについてお伝えします。また、このツールの使用を検出するためのアドバイスや、その使用に対する有効な緩和策も紹介します。
Active Threat Response の仕組み
Evilginx は、広く利用されている正規の Web サーバー「nginx」を利用して、Microsoft 365ŭ などのサービスを模倣するために攻撃者が作成したサイトを経由して Web トラフィックをプロキシし、中間者攻撃 (Adversary-in-the-Middle、AitM) を行います。ソフォスは検証のため、悪意のあるドメインを設定しました。図 1 に示すように、そのドメインのサブドメインとして Microsoft フィッシュレットを配置しています。(本記事で使用した関連 IP アドレス、ユーザー名、パスワード、およびドメインは、本記事公開前にすべて破棄されました。)このフィシュレットには標的を誘導するルアーが含まれており、攻撃者がユーザー名とパスワードを窃取しようとする際に標的ユーザーが目にするのがこのルアーです。
図 1: Evilginx の画面。悪意のあるドメイン、フィッシュレット、標的を誘導するルアーが確認できます。
標的ユーザーが目にするフォームや画像は Microsoft 由来のものであり、Evilginx サーバーを経由してユーザーへとリレーされます。バックエンドでは、Evilginx はユーザーエクスペリエンスを設定するオプションを攻撃者に与えています。ソフォスのテストでは、MFA で保護されたユーザーアカウントを模倣し、すぐにバイパスしました。ユーザーには 「通常の」ログイン画面が表示されます。画面左側のアプリをクリックした場合、再度ログインを求められるため、勘の良いユーザーは何かがおかしいと気づくかもしれません。
ソフォスが設定した Evilginx サーバーを確認すれば、何が起こっているかを理解できます。
図 2: Evilginx サーバーはキャプチャした情報を表示し、後で悪用するためデータベースに追加します。
ユーザー名とパスワードの傍受に加えて、Microsoft のプロンプトが表示された際に攻撃者が有効化した「サインイン状態を維持する」機能から渡されたセッショントークンも収集されました。Evilginx はこのデータを各セッションの情報を収集するデータベースに保存します。その中には、サーバーへのアクセスに使用されたパブリック IP アドレス、使用中のユーザーエージェント、さらに重要な要素である Cookie も含まれます。Cookie を所持している攻撃者は、正規のログインページのウィンドウを開き、Cookie をインポートするだけで正規のユーザーとしてサインインできます。
この手順を踏むことで、攻撃者はユーザーのメールボックスアカウントに完全にアクセスできます。典型的な攻撃活動として、メールボックスルールの追加が挙げられます。アクセスが可能であれば、攻撃者は MFA デバイスのリセット、パスワードの変更、その他多くのアクションを実行し、アカウントを常駐化できます。
検出手段
防御側がこの種のアクティビティを発見する方法はさまざまです。まず、Azure と Microsoft 365 では、主に 2 箇所で異常なアクティビティを確認し、ログとイベントを追跡できます。1 つ目は、Entra ID (旧称 Azure ID) のサインインと監査ログです。図 3 の 2 つの例では、ユーザーの認証が Evilginx サーバー (54.225.206.84) から発信され、次にデモに使用した Tor 出口ノード (45.80.158.27) から発信されています。監査ログは、このログインの後、攻撃者が「自分」のアカウントに新しい認証アプリを追加したことを示しています。
図 3: 「Completely Legitimate Forwarder (100% 正規の転送ルール)」と名付けられた受信トレイルール。怪しさは感じさせません。
2 つ目は、Microsoft 365 のログ (別名「統合監査ログ」または「UAL」) です。セッション中に不正なユーザーが Completely Legit Forwarder という新しい受信トレイルールを追加したことを示しています。(これらのログの確認を支援するため、Microsoft 365 はセキュリティセンター内に詳細なハンティングエリアも提供しています。ここでは、Kusto クエリ言語を使用してさまざまな基準でフィルタリングし、疑わしいアクティビティを発見できます。)
不審な活動が検出されると、セキュリティアラートとインシデントも生成されます。例として、sophos_mfa アカウントが不審な IP アドレスからサインインを試み、そのセッションの 1 つで異常なトークンが使用されたことが図 4 から確認できます。
図 4: 異常なトークン、匿名 IP アドレス、不審なリダイレクトルールがすべてフラグされます。
ソフォスのお客様には、Azure と Microsoft 365 から Sophos Central にイベントとアラートをインポートするための統合機能が用意されています。特定の XDR 統合 パックでは、カスタム ID 関連の検出がパッケージの一部となります。MDR のお客様の場合、これらの検出はサービスの一部として MDR チームによってトリアージされます。
考えられる緩和策と懸念事項
考えられる緩和策は、予防的な策と事後的な策の 2 つに大別されます。考えられる緩和策を網羅することは本記事の範囲をはるかに超えていますが、これまでと同様に、一般に利用可能かつ自らの環境において価値の高いアプリケーションやサービスを防御することに関しては、綿密かつ重層的なアプローチが最善です。
それでも、セキュリティ業界は、トークンベースやプッシュ型 MFA をやめ、堅牢でフィッシングに強い FIDO2 ベースの認証方式に移行するなど、より強力な対策に目を向ける時期に来ています。
幸いにも、有効な対策がさまざまな形で利用できます。たとえば、Yubikey タイプのハードウェアキー、最新のハードウェアに搭載された Apple Touch ID、ビジネス向けの Windows Hello、さらには iPhone や Android を活用した認証オプションなどです。(MFA の今後の方向性については、パスキーに関する Chester Wisniewski の最近のエッセイを参照してください。)
条件付きアクセスポリシーは、Azure と Microsoft 365 環境のセキュリティを確保するためのもう 1 つのステップです。理論的には、従来通り手作業でホワイトリストを作成し、信頼できない IP アドレスをブロックする方法もありますが、現実的にはデバイスを管理し、組織として信頼できるデバイスだけが企業システムにログインできるようにする必要があります。(もちろん、ソフォスや他のベンダーはサービスの一環として、既知の悪質なサイトを常に監視し、ブロックしています。監視は終わりのない作業であり、ブロックリストの方がホワイトリストよりも管理が容易であることは間違いありません。)
とはいえ、最終的にはユーザーの意識や注意喚起だけに頼ることはできません。人間はミスを犯すものであり、文字通り誰もが遅かれ早かれフィッシングに遭うでしょう。今後進むべき道は、人間による失敗に耐えられる堅牢なアーキテクチャにあります。
事後的な緩和策における最初のステップは攻撃者の入口を塞ぐことです。この場合、完全に入口が閉じていることを確認するために必要なステップがいくつかあります。まず、Entra ID と Microsoft 365 を介してすべてのセッションとトークンを失効させ、獲得したアクセスを削除します。これらのアクションは、「セッションの破棄」および「すべてのセッションからサインアウト」を使用することで Entra ID と Microsoft 365 両方のユーザーアカウントで実行できます。
次に、ユーザーパスワードと MFA デバイスをリセットしましょう。ログで確認したように、攻撃者はユーザーのアカウントに新しい MFA デバイスを追加しました。追加された MFA デバイスのタイプによっては、パスワードなしでアカウントにアクセスできるようになるため、パスワードの変更およびセッション破棄の効果がなくなっています。Microsoft 365 のログを使用して、攻撃者が実行したすべての活動を調べてください。新しい受信トレイルールの追加など、気づかれにくい変更を発見することは、ユーザーのアカウントからさらに情報が漏れないようにするために重要です。IT 管理者は、トークンの窃取に関する Microsoft 独自の調査ガイダンスも参照してください。
結論
Evilginx は、MFA をバイパスして認証情報を侵害する手ごわい手法であり、複雑な攻撃テクニックを実行可能にします。そのため、この手法は広く利用される可能性があります。幸いにも、各組織が導入済みであろう緩和策とセキュリティプラクティスが、攻撃者がインフラストラクチャに対してこのツールを展開しようとする際の強力な抑止力になります。
