攻撃者は利用者の端末ではなく認証用Wi-Fiゲートウェイを侵害することで、認証トラフィックを密かにリダイレクトし、Microsoft 365の認証情報を盗み出すことができます。
出張中の企業従業員は要注意です。あの便利な公衆Wi-Fiに接続する前に、もう一度考え直したほうがよいでしょう。
ReliaQuestの脅威リサーチチームによると、少なくとも6月以降、脅威アクターがホテルや会議施設などの共有スペースにある「認証用」Wi-Fiゲートウェイやその他のポータル機器を侵害し、利用者のMicrosoft 365アカウントを乗っ取る攻撃を行っています。
攻撃者はいったんゲートウェイを掌握すると、利用者の端末に触れることも、エンドポイントを侵害することも、フィッシングリンクや悪意のある添付ファイルを送りつけることもなく、利用者の通信を自分たちのインフラへと密かにリダイレクトし、Microsoft 365の認証情報を盗み取ることができます。
「最も危険な点は、この攻撃がネットワークゲートウェイという、利用者や端末が抱くほとんどの信頼の前提より下の層で行われることです」とReliaQuestはCSO Onlineに語っています。「単体で見れば企業レベルの重大な侵害とまでは言えないかもしれませんが、個々のアカウントにとっては非常に現実的なリスクです」
「根本的な信頼」を悪用
虚偽のデータを注入して通常のWebトラフィックを不正なドメインへリダイレクトするDNS(Domain Name System)ポイズニングは、これまで小規模オフィス向けルーターで確認されてきた手法ですが、攻撃者は今、これをより上位のターゲットへと広げつつある、とReliaQuestの研究者はブログ記事で説明しています。
攻撃者はおそらく、脆弱または使い回された管理者認証情報と、SSH(Secure Shell)やSNMP(Simple Network Management Protocol)といった外部に露出したインターフェース、その他のWebコンソールを組み合わせることで、ゲートウェイへのアクセスを獲得しているとみられる、と研究者らは指摘しています。
悪意のある攻撃者にとって必要なのはゲートウェイへの管理者アクセスだけです。というのも、各端末はDNSを本質的に信頼するよう設計されており、DNSはlogin.microsoftonline[.]comのようなドメイン名をIPアドレスに変換して通信経路を決めているからです。したがって、たった一つのゲートウェイを侵害するだけで、攻撃者はそのネットワークにログインするすべてのゲスト利用者の通信をリダイレクトできるようになります。DNS要求に対して正規のIPアドレスではなく、自らが制御するIPアドレスを応答として返すことで、エンドポイントには一切触れずにこれを実現するのです。
「認証用ポータル機器は、そのネットワーク上のすべてのゲスト利用者にとってのネットワーク境界に位置します」と研究者らは記しています。「この攻撃はゲートウェイ側で発生するため、エンドポイントからは可視化できず、本質的に検知が困難です」
ReliaQuestが追跡したこのキャンペーンでは、m365-owa[.]com、owa-ms365[.]com、ms365-device[.]com、ms365-live[.]comという、攻撃者が登録した4つのドメインが、Microsoftを偽装した誘導に使われていました。
侵害されたWi-Fiゲートウェイは、米国内の複数の都市に加え、インドやサウジアラビアでも確認されており、被害を受けた利用者は専門サービス業、金融サービス業、法律関連業、小売業、医療業、エネルギー業の企業に所属していました。この手口が特定の業種に限定されないことを示しています。
「たった一つのアカウントの乗っ取りが、重大なデータ損失へと連鎖しかねないSharePointからの情報流出事例を、これまで数多く見てきました」とReliaQuestは指摘しています。一方でネットワーク運用者側にとっては「評判に関わる側面」もあります。基盤となる攻撃がどれほど高度なものであるかにかかわらず、利用者アカウントの侵害は「深刻な信頼とブランドの問題」となるのです。
「安全な」サービスやDNSSECだけでは不十分
ネットワーク設定をGoogle(8.8.8.8)やCloudflare(1.1.1.1)、クラウドベースのOpenDNSといった「安全な」DNSプロバイダーに固定するだけでは十分な対策とは言えない、とReliaQuestは主張しています。これは、クエリが実際にたどる経路そのものを変えるわけではないからです。
同社の説明によれば、端末は既定でDNSクエリを暗号化されていないプロトコルトラフィックとして送信しており、そのパケットはGoogle、Cloudflare、OpenDNSに到達するまでの間、依然としてホテルのネットワークを経由しなければなりません。ゲートウェイはまさにその経路上に位置しているため、クエリが選択したリゾルバーに到達する前に、それを検査したり、ブロックしたり、リダイレクトしたりすることができてしまいます。
「信頼できるDNSサーバーを指定することは、意図した宛先を変えるだけであって、そこへ至る経路を誰が制御しているかを変えるものではありません」とReliaQuestは指摘しています。
さらに、デジタル署名と公開鍵暗号を用いるDNSSEC(Domain Name System Security Extensions)も、この問題を「部分的」にしか解決しません。DNSSECは署名済みドメインに対する認証と完全性を提供するものであり、検証を行うリゾルバーであれば、偽造されたり改ざんされたりした応答を検知して拒否できます。
「DNSSECが提供しないのは、機密性と可用性です」と同社は述べています。「DNSトラフィックを暗号化するわけでも、攻撃者による要求の傍受・ブロック・リダイレクトを阻止するわけでもありません」
そのため、DNSSECは署名済みゾーンに対する特定の応答偽造攻撃を防ぐことはできても、経路上に位置するゲートウェイは依然としてクエリを閲覧したり、破棄したり、フォールバック動作を強制したりできてしまいます。しかも、この保護層が機能するのはドメインが実際に署名されている場合に限られ、さらにクライアントまたはリゾルバー側が検証を実行している場合にのみ有効です。ReliaQuestによれば「多くのスタブリゾルバーはこの検証を行っていません」。
フルトンネルVPNが必須
この問題に対処するため、企業はすべての社用端末に対し、ネットワーク接続時にフルトンネルVPNの使用を義務付けるべきだ、とReliaQuestは助言しています。トンネルが確立するまではインターネットアクセスを許可しない制御も導入すべきだとしています。
これにより、DNSを含む端末のすべての通信は、他のどこにも到達する前に、信頼できるVPNサーバーへの暗号化接続を経由するようになる、と同社は説明しています。これにより、ホテルのゲートウェイのようなローカルネットワークがDNSやインターネットトラフィックを閲覧したり改ざんしたりすることを防げます。
「事実上、これは信頼の方程式から信頼できないネットワークそのものを排除することになります」とReliaQuestは指摘しています。
ただし、フルトンネル構成はVPNの既定設定ではありません。研究者らが指摘するように、これには「実際のトレードオフ」が伴うからです。すべてのパケットが企業インフラを経由する必要があるため、コスト、遅延、帯域幅の負荷が増大します。したがって、分散した従業員や帯域幅を多く消費する業務を抱える組織にとって、すべての通信を企業のバックボーン経由に強制することは「必ずしも現実的ではありません」。
企業はまた、Entra IDで条件付きアクセスを適用し、デバイスコード認証フローをブロックすべきだ、とReliaQuestは述べています。この認証フローは、ほとんどの環境のほとんどの利用者にとって正当な用途がほとんどありません。
その他の予防策
同社はさらに以下も推奨しています。
- PAC(Proxy Auto-Configuration)ファイルの取得を、承認済みの内部ホストのみに制限すること
- グループポリシーでWPAD(Web Proxy Auto-Discovery)の自動検出を無効化すること(Windowsでは既定で有効になっていることが多い)
- フルトンネルVPNの「補完または代替」として、DoHやDoTなどの暗号化DNSを厳格モードで導入すること。常時接続VPNの実現が難しい組織にとって、これは特に重要です
- 認証情報を入力する前に、それを要求しているページのURLと証明書を確認するよう従業員を教育すること。特に公衆Wi-Fiネットワークの利用時にはこれが重要です
この点においては検知よりも予防のほうが重要だ、とReliaQuestは指摘しています。Microsoft Defender for Endpointのようなツールでは、攻撃者が制御するドメインへのクエリを示す「DnsConnectionInspected」イベントが主要なエンドポイントレベルのシグナルとなりますが、「そうしたイベントが発生する時点では、リダイレクトはすでに完了しているのが通常です。言い換えれば、エンドポイントのテレメトリは、何が起きたかを事後的に確認するものであって、それを未然に防ぐものではありません」。
だからこそ、暗号化通信、条件付きアクセス、そしてWPADやPACの堅牢化といった対策が、検知単体よりも重要になるのだ、と研究者らは強調しています。
