ホテルWi-Fiは結局キケン？ つないだ瞬間に企業アカウントが狙われるワケ：新手の手口を解説（1/2 ページ）

出張先のホテルでWi-Fiにつなぐ。その当たり前の行動が、企業アカウントを狙う攻撃の入り口になるかもしれない。端末ではなくWi-Fiの「裏側」を狙い、接続する利用者を横断して攻撃する手口が流行しているという。

[＠IT]

　セキュリティ企業のReliaQuestは2026年7月23日（現地時間）、ホテルや会議施設などに設置された共用Wi-Fiゲートウェイを侵害し、接続する利用者の通信先を攻撃者が管理する基盤に誘導するサイバー攻撃を確認したと発表した。

　攻撃者はDNSポイズニングを利用し、出張中の従業員を「Microsoft 365」に似せたページに誘導。認証情報やアカウントへのアクセス権を窃取しようとしていたという。活動は少なくとも2026年6月から続いている。米国の複数都市の他、インドとサウジアラビアでも侵害されたゲートウェイが見つかった。

ホテルWi-Fiの「1台」を奪えば、接続する企業ユーザーを横断して狙える

　ReliaQuestが調査したのは、宿泊施設を中心に、利用時の認証画面を表示するキャプティブポータル型Wi-Fiのゲートウェイだ。こうした構成は、空港や会議場、共同利用オフィス、大学、医療施設、イベント会場などでも使われている。

　Wi-Fiゲートウェイは、接続端末のDNS問い合わせや通信経路を管理する。そのため攻撃者がゲートウェイの管理者権限を取得すると、利用者の端末を1台ずつ侵害しなくても、そのネットワークに接続する利用者を横断して通信先を変更できる。

　初期侵入についてReliaQuestは、確度を「低〜中程度」と評価。インターネットに公開されたSSH、SNMP、Web管理画面や、脆弱（ぜいじゃく）な管理者資格情報、使い回された認証情報が悪用された可能性を示している。ただし、個々の機器に対する可視性が限られていたため、実際の侵入経路は確認できていない。

　侵入後、攻撃者はゲートウェイの設定を変更し、正規ドメインへのDNS問い合わせに偽の応答を返していた。調査では、Microsoftを装った誘導先として「m365-owa[.]com」「owa-ms365[.]com」「ms365-device[.]com」「ms365-live[.]com」の4ドメインが確認された。これらは31.57.243.154と104.194.159.150で運用されていたという。

　登録情報の共通点に加え、同じ閲覧セッション内で各ドメインが数秒差で現れたことから、ReliaQuestは4ドメインが同一の攻撃主体によって運用されていた可能性が高いと評価している。

　ここで重要なのは、利用者がどのDNSサーバを指定しているかだけではない。例えば端末でGoogleの公開DNS「8.8.8.8」を指定していても、DNS問い合わせ自体が暗号化されていなければ、その通信はWi-Fiゲートウェイを通過する。そのため、ゲートウェイを侵害した攻撃者は問い合わせを観測し、偽のDNS応答を返すことができる。

　DoH（DNS over HTTPS）やDoT（DNS over TLS）を利用している場合でも、暗号化されたDNS通信が利用できない際に平文DNSにフォールバックする設定では、攻撃者に平文の問い合わせを改ざんされる余地が残る。ReliaQuestは、平文へのフォールバックを認めない厳格なDoHまたはDoTと、全通信を企業ネットワーク経由にするフルトンネルVPNを推奨している。

DNSポイズニングの先に「認証」を狙う　WPADやデバイスコード認証も悪用

　今回確認された手口は、ロシア軍情報機関の活動と評価される「APT28」が関与した「FrostArmada」作戦との共通点もある。FrostArmadaではSOHOルーターのDNS設定を変更し、Microsoftの認証通信やOAuthトークンを狙っていた。今回も、ゲートウェイ単位でDNSを操作し、Microsoft 365のアカウント侵害につなげようとする点が共通している。

　ただし、ReliaQuestは今回の活動をAPT28やFrostArmadaそのものとは断定していない。共通しているのは戦術、技術、手順（TTP）であり、共有インフラやコードの再利用、攻撃者の運用上のミスなど、直接的な技術的関連は確認されていない。また、今回使用されたドメインやIPアドレスも、過去にAPT28で確認された攻撃基盤とは一致しなかった。

　さらに、今回の攻撃では全てのDNS問い合わせを悪性基盤に転送していた点も、キーワードを使って対象を選別していたFrostArmadaとは異なる。

　約3分の1の調査事例では、攻撃者がWPAD（Web Proxy Auto-Discovery）の悪用も試みていた。WPADが無効化されていない「Windows」や「macOS」の端末では、WPADを利用してプロキシ設定を自動取得する場合がある。攻撃者がこれを悪用できれば、ブラウザや認証機能、企業アプリなどの通信を攻撃者が管理するプロキシに誘導できる。

　ただし、今回の調査ではWPADの悪用が実際に成功したことは確認されていない。ReliaQuestも、WPADを今回の攻撃における主たる手法ではなく、環境に応じて試みられる補助的な手法と評価している。

　また、少数の事例ではMicrosoftのデバイスコード認証フローも悪用されていた。

　デバイスコード認証では、利用者が別の端末からMicrosoftの正規サイトにアクセスし、表示されたコードを入力して認証を完了させる。攻撃者はこの仕組みを悪用し、偽のMicrosoft 365関連ページを通じて利用者自身に承認操作をさせていた。

　利用者が攻撃者側で開始された認証セッションを正規のMicrosoft 365関連操作だと誤認して承認すると、Microsoftから正規のOAuthトークンが発行される。攻撃者はこのトークンを利用することで、利用者のパスワードを直接取得したり、暗号化された認証通信を復号したりすることなく、MFA認証済みとして扱われるアクセス権を得られる。

　つまり今回の攻撃は、単純に偽Webサイトに誘導してパスワードを盗むだけではない。Wi-Fiゲートウェイを侵害して名前解決を操作し、その先で利用者の認証・承認操作を悪用することで、企業アカウントへのアクセスにつなげようとしている。