ホテルWi-Fi経由のDNSポイズニング攻撃、フィッシングなしでMicrosoft 365アカウントを乗っ取り

攻撃者は、ホテルや会議施設のWi-Fiゲートウェイを侵害しDNSをポイズニングすることで、フィッシングメールも悪意ある添付ファイルもエンドポイントマルウェアも使わずに、Microsoft 365アカウントを密かに乗っ取っています。

ReliaQuestの評価によると、この手口は過去にAPT28関連とされたルーター攻撃キャンペーンと酷似しており、それを出張中の企業従業員が利用するキャプティブポータルインフラにまで拡張したものです。

少なくとも2026年6月以降、脅威アクターはホテルや会議施設をはじめとする公共Wi-Fi拠点のキャプティブポータル機器を侵害し、それを使って全てのウェブトラフィックを攻撃者が管理するインフラ経由にリダイレクトしています。

ゲートウェイの制御権を奪うと、攻撃者はDNS応答を偽造し、正規のMicrosoftドメイン宛てのリクエストが攻撃者運用のホストであるm365-owa[.]com、owa-ms365[.]com、ms365-device[.]com、ms365-live[.]comに解決されるようにします。これらは31.57.243[.]154と104.194.159[.]150上でホストされています。

ReliaQuestは、米国内の複数都市に加え、インドやサウジアラビアなど国外からの被害者も確認しており、金融サービス、法律、医療、エネルギー、小売、専門サービスといった幅広い業種にまたがっていることを観測しました。これは特定業種を狙った作戦ではなく、出張中の従業員を対象とした日和見的な標的選定であることを示しています。

ReliaQuestは中程度の確度で、初期侵入はキャプティブポータルゲートウェイの管理インターフェース（SSH、SNMP、Web管理コンソール）が外部に露出しており、それが脆弱または使い回された管理者認証情報と組み合わさっていることに起因すると評価しています。

この手法は、FrostArmadaキャンペーンで確認されたルーター標的型の攻撃パターンと一致します。同キャンペーンでは、APT28（Forest Blizzard/Fancy Bear）がSOHOルーターを侵害し、DNS設定を改ざんしてMicrosoft 365の認証情報を窃取し、AiTM（Adversary-in-the-Middle）プロキシ経由でOAuthトークンを奪取していました。

今回のホテルWi-Fiキャンペーンは、FrostArmadaのいくつかの特徴を踏襲しています。すなわち、ゲートウェイレベルでのDNSハイジャック、Microsoft認証ドメインの標的化、そして後続のAiTM型Microsoft 365アカウント侵害です。

FrostArmadaと同様、DNS操作によって通常のログインフローが認証情報・トークン窃取の経路へと変貌し、トラフィックは静かに攻撃者管理下のインフラを経由してプロキシされます。

ReliaQuestは、広範囲に及ぶキャンペーンを特定しました。これは、以前SOHO（スモールオフィス／ホームオフィス）ルーターで確認され「APT28」に帰属するとされた認証情報窃取のDNSポイズニング手法を拡張したものです。

今回のキャンペーンが従来と大きく異なるのは、防御側にとって重要な点です。まず、主な標的はコンシューマー向けSOHOルーターではなく、ホスピタリティ業界や会議施設のキャプティブポータル機器であり、企業ユーザーが出張中に日常的に接続する地点そのものが攻撃対象となっています。

第二に、攻撃者のドメイン登録情報やIPブロックは、これまで報告されてきたAPT28のインフラとは異なっています。

ホテルWi-FiのDNSポイズニング攻撃

DNSの挙動は単純明快です。キーワードに基づいて選択的にリダイレクトするのではなく、侵害されたゲートウェイは全てのDNSリクエストを悪意あるインフラに解決します。これは、あまり選別を行わない運用者、あるいは異なる任務プロファイルを示唆しています。

攻撃者がキャプティブポータルゲートウェイの管理者権限を取得すると、そのネットワークに参加する全デバイスのDNSを事実上支配下に置くことになります。

ゲートウェイはDHCPで割り当てられるリゾルバーであるため、任意のドメインへのクエリに対して応答を密かに偽造でき、エンドポイントを一切変更することなくユーザーを攻撃者がホストするなりすましページへリダイレクトできます。

ReliaQuestは、microsoft.comやlogin.microsoftonline[.]comといったドメインへのリクエストが、38.146.28[.]75などの攻撃者IPにマッピングされる偽造応答を確認しており、そこではMicrosoft 365風のログイン画面が提供され、認証情報の窃取やデバイスコード悪用フローの誘導に利用されています。

一般的なエンドポイント中心のDNS保護策では、このシナリオを確実に防ぐことはできません。8.8.8[.]8のような公開リゾルバーをハードコードしても、暗号化されていないDNSトラフィックはゲートウェイ側で依然として可視かつ改変可能な状態にあります。

プレーンテキストへのフォールバックを許容する日和見的なDNS over HTTPS/TLS実装も同様に脆弱です。ゲートウェイは単純にフォールバックを強制または乗っ取り、応答を偽造します。

ReliaQuestは、この攻撃の連鎖を確実に断ち切る構成は2つしかないと強調しています。すなわち、全てのDNSが企業ネットワークを経由することを保証する強制フルトンネルVPNと、平文フォールバックを無効化した厳格モードの暗号化DNS（DoH/DoT）です。

副次的な手法により、攻撃対象範囲はさらに広がっています。観測された事例のおよそ3分の1では、攻撃者はDHCPオプション252と偽造したDNSの「wpad」レコードを使い、悪意あるPACファイルを配信することで、WindowsおよびmacOSのアプリケーショントラフィックを悪意あるプロキシ経由に誘導するWPAD（Web Proxy Auto-Discovery）の悪用を試みていました。

これが成功すると、Chrome、Microsoft 365クライアント、その他の企業アプリケーションが攻撃者管理下のプロキシに切り替わり、通常のHTTPSトラフィックを装いながら認証フローを盗み見たり改ざんしたりされる恐れがあります。

ReliaQuestはまた、ms365-live[.]com上でMicrosoftのデバイスコード認証フローが悪用されていることも確認しており、これにより攻撃者はパスワードを直接窃取することなく、OAuthトークンとMFA認証済みのアクセス権を取得できます。

デバイスコードフローは、特に管理外環境やフィッシングのシナリオにおいて高リスクであることが、Microsoftや独立系研究者によってすでに認識されており、Microsoft Entra IDの条件付きアクセスポリシーで明示的にブロックすることが可能です。

ms365-device[.]comで観測されたDOMコンテンツは、おとりの準備・切り替え、テレメトリの追跡、IP許可リストによるコンテンツの選択的な制限などに使われる運用者用パネルを示唆しており、このキャンペーンが現在も活動中で継続的に管理されていることを物語っています。

ReliaQuestの核心的な評価は明快です。企業デバイスに常時稼働のフルトンネルVPNを強制している組織は、この特定のゲートウェイDNSポイズニング手法から事実上保護されています。なぜなら、DNSを含む全トラフィックが、悪意あるインフラに傍受される前に信頼できる企業リゾルバー経由でルーティングされるためです。

業務上デバイスコードフローが不要な環境では、IDプロバイダー側でEntra IDの条件付きアクセスを通じてこれを無効化することで、近年増加しているアカウント侵害経路の一つを排除できます。

設定変更にとどまらず、ReliaQuestはDNS、認証、エンドポイントの挙動にまたがる多層的な可視化を提唱しています。GreyMatter Transitのようなプラットフォームを用いて、異常なDNS解決やサインインのルーティングをほぼリアルタイムで検知し、個別には無害に見えるシグナルを相関分析することを推奨しています。

同社の検知コンテンツは、攻撃者が登録したドメインや不審なIPに焦点を当てており、自動化された対応プレイブックが影響を受けたホストを隔離し、露出したアカウントを無効化し、アクティブなセッションを終了させ、Entra IDから攻撃者が登録したデバイスを削除することで、持続的なアクセス経路を遮断します。

セキュリティチームにとっての教訓は、公共Wi-Fiは構造的に信頼できないものであり続けており、ゲートウェイにおけるDNSがMicrosoft 365侵害における第一級の攻撃対象領域になっているという点です。

Securityincident response

出張中の従業員に依存する組織は、常時稼働のフルトンネルVPN、厳格な暗号化DNS、WPADの堅牢化、デバイスコードフロー制御を、任意の追加対策ではなく基本要件として扱うべきです。

IOCs

注: IPアドレスおよびドメインは、誤って解決やハイパーリンク化されるのを防ぐため、意図的にディファング処理（例: [.]）を施しています。再ファング化は、MISP、VirusTotal、SIEMなどの管理された脅威インテリジェンスプラットフォーム内でのみ行ってください。

2026年、AI SOCに備えるべき機能とは？ 完全チェックリスト : AI SOC機能チェックリストをダウンロード