こんにちは、ひろかずです。
仕事柄、海外でのホテルWi-Fiをはじめとするネットワーク接続について問い合わせを受けることが時々あります。今回の記事は、その答えとなりそうなので共有します。
忙しい人向けの要約
- 問い：ホテルWi-FiのDNSポイズニング攻撃はどう防げばよいのか？
答え：フルトンネルVPN/SASEの常時接続、厳格モードの暗号化DNS、WPAD無効化、Entra ID条件付きアクセスによるデバイスコードフローのブロックの4点で対処し、なかでも設定変更だけで着手できるデバイスコードフローのブロックを最優先にします。ホテル・会議場のWi-Fiゲートウェイ（キャプティブポータル機器）が侵害され、DNS応答を改ざんして宿泊客を偽のMicrosoft 365ログインページへ誘導する攻撃が、2026年6月以降継続しています。ReliaQuestが2026年7月23日に報告しました。 - 被害は米国複数都市・インド・サウジアラビアで確認され、金融・法務・医療・エネルギー・小売など業種を問いません。狙われているのは「特定の業界」ではなく「出張する社員」です。
- 一部のケースではデバイスコードフロー（OAuth 2.0 Device Authorization Grant）が悪用され、パスワードを一切盗まずにMFA済みの正規トークンが攻撃者へ発行されました。MFAは破られたのではなく、正しく動いた上で悪用されています。
- パブリックDNS（8.8.8.8等）の指定やスプリットトンネルVPNでは防げません。有効なのはフルトンネルVPN/SASEの常時接続、厳格モードの暗号化DNS、WPAD無効化、Entra ID条件付きアクセスによるデバイスコードフローのブロックです。
- クラウドネイティブは、この4点のうちEntra IDのデバイスコードフローブロックを最優先と判断します。設定変更だけで完結し、今日から着手できるためです。
何が起きているの？
出張先のホテルでWi-Fiにつなぎ、いつも通りMicrosoft 365にログインする。フィッシングメールは受け取っていない。添付ファイルも開いていない。それでも資格情報が攻撃者の手に渡る。ReliaQuestが2026年7月23日に公開した脅威レポートが記録したのは、そういう攻撃です。
今回の攻撃では、ホテルや会議場のWi-Fiゲートウェイ（宿泊客に部屋番号入力や利用規約同意を求めるキャプティブポータル機器）そのものが侵害されました。ゲートウェイは配下の全端末のDNS解決を握っており、DNSポイズニングの標的となります。1台の機器を落とせば、その日ログインした宿泊客全員の認証トラフィックの名前解決を差し替えられるわけです。
活動は少なくとも2026年6月から継続しています。侵害されたゲートウェイは米国の複数都市に加えインドとサウジアラビアでも確認され、被害組織の業種は金融、プロフェッショナルサービス、法務、医療、エネルギー、小売に及びます。ReliaQuestはこれを「業種を狙った攻撃ではなく、出張する社員をどこであろうと狙う攻撃」と評価しました。【要確認：地域・業種の出典はReliaQuest一次レポートに存在するため二次媒体PCMagリンクの一次ソース差し替え要否を確認】
- 攻撃者は偽ログインページ用に少なくとも4つのドメイン（m365-owa[.]com、owa-ms365[.]com、ms365-device[.]com、ms365-live[.]com）を登録していました。【要確認：4ドメインの出典はReliaQuest一次レポートに存在するため二次媒体リンクの一次ソース差し替え要否を確認】
手口はロシア軍情報機関系のAPT28に帰属された過去の作戦「FrostArmada」（2026年4月に摘発）と重なりますが、ReliaQuestは今回の活動をFrostArmada本体とは評価しておらず、「少なくとも手口の再利用を示唆する」に留めています。帰属はどうあれ、手口はもう公開されました。模倣は前提に置くべきです。
攻撃を成立させる仕組み：デバイスコードフローの悪用
この攻撃の中でも特に重いのが、デバイスコードフローの悪用です。デバイスコードフローとは、キーボードを持たないデバイス（会議室ディスプレイ等）のために、別の端末でコードを入力して認証を完了させるOAuth 2.0の認可方式（Device Authorization Grant、RFC 8628）です。
正規の流れは次の通りです。
- 入力手段が限られたデバイス（会議室ディスプレイ、デジタルサイネージ、CLIツール等）が、Microsoftの認可サーバーにデバイスコードとユーザーコードを要求する。
- デバイスの画面に短いユーザーコードと「microsoft.com/devicelogin でこのコードを入力してください」という案内が表示される。
- ユーザーが手元のスマートフォンやPCで本物のMicrosoftのサインインページを開き、コードを入力して認証（MFAを含む）を完了する。
- コードを要求したデバイス側に、そのユーザーの権限を持つアクセストークンが発行される。
押さえるべき点は、トークンが「コードを承認した端末」ではなく「コードを要求したクライアント」に発行される仕様だということです。攻撃者はここを突きます。手順1を攻撃者自身が実行してコードを入手し、DNSポイズニングで誘導した偽ページでそのコードの入力・承認をユーザーに促す。ユーザーが操作するのは本物のMicrosoftページであり、URLも証明書も正規のものです。ReliaQuestは「ユーザーには、承認が攻撃者の開始したセッションを許可しているとは見えない」と指摘しています。資格情報の窃取もトークンの傍受もなしに、MFAを満たしたアクセスが成立します。【要確認：ReliaQuest引用文の出典は一次レポートに存在するため二次媒体リンクの一次ソース差し替え要否を確認】
なぜ情報システム・セキュリティ担当者に関係するの？
ここまで見た攻撃の領域とメカニズムは、防御の主導権が利用者ではなく管理側にあることを意味します。
この攻撃には、多くの企業が対策の主戦場としてきた要素が登場しません。メールゲートウェイは通過するものが何もなく、端末上でマルウェアが動かないためEDRも発火しにくいです。
ユーザーは「正しい行動」しかしていません。防御の成否を分けるのは、端末とテナントに事前に入っている設定だけです。防御線は利用者の注意力ではなく、情シス・セキュリティ担当者の設計判断そのものです。
担当領域との対応を整理すると、次の通りです。
- 予防：条件付きアクセスの認証フロー制限、VPN/SASEのトンネル方式、WPADや暗号化DNSの既定値は、いずれもユーザーが選べるものではなく、管理側だけが変えられる設定です。設定していなければ、出張者の注意力以外に防御はありません。
- 検知：フィッシングメールもマルウェアもないため、メールゲートウェイやEDRのアラートは期待できません。手がかりはEntra IDのサインインログに残るデバイスコードフローの利用と、不審な位置からのトークン利用にほぼ限られます。
- 初動：資格情報は盗まれていないため、パスワードリセットだけでは攻撃者のセッションが残ります。発行済みトークンの失効とセッション無効化を含む初動手順が必要です。
パスワードは盗まれていない。MFAも正常に完了している。それでもテナントには攻撃者が入っています。出張者が1人でもいる組織であれば、業種を問わずこの構図の当事者です。サインインログの見方と初動手順を事前に用意しているかが問われます。
よくある誤解
「端末のDNSを8.8.8.8にしているから大丈夫」
参照先DNSの固定化は、この攻撃には通用しません。平文のDNSクエリはゲートウェイを通過する時点で読まれ、リゾルバーに届く前に偽装されるためです。
暗号化DNS（DoH/DoT)も、既定の日和見（opportunistic）モードでは暗号化接続の確立に失敗すると平文へフォールバックするため、ゲートウェイ側が握手を妨害すれば同じ結果になります。厳格（strict）モードでなければ防御になりません。【要確認：DoH日和見フォールバックの記述は一次レポートに存在するため二次媒体TechTimesリンクの一次ソース差し替え要否を確認】
「VPNを配っているから大丈夫」
この手法も効果は条件付きです。スプリットトンネル構成でDNSや認証トラフィックがトンネル外へ出る例外があれば、そこが今回の攻撃面そのものになります。キャプティブポータル認証中のVPN未接続の時間帯も残ります。
「MFAがあるから大丈夫」
前節の通り、対策として成立しません。
実務で注意すべきポイント
対策の方向は明確なのに、実装でつまづいたり、見落とされたりする論点がいくつかあります。
フルトンネル常時接続とキャプティブポータルの相性問題
ホテルWi-Fiは規約同意画面を通過するまで外部通信を許さないため、常時VPNを厳格にすると「そもそもWi-Fiにつながらない」という問い合わせが増えます。キャプティブポータル検出時の例外挙動をどう設計するかは、製品仕様の確認を含めて事前に詰めておくべき点です。
放置されたスプリットトンネルの例外リスト
スプリットトンネルの例外リストは、導入時に性能目的で追加されたまま棚卸しされていないことはよくあります。
また、Microsoft 365のトラフィックを負荷対策でトンネル外へ逃がす設計は広く使われてきましたが、その例外にDNSと認証エンドポイントが含まれていないかを、今回の手口を前提に見直す必要があります。
WPAD（Web Proxy Auto-Discovery）の無効化検討
WPADはWindowsで既定有効であり、今回の攻撃でも観測ケースの約3分の1で悪用が試行されたとReliaQuestが報告しています。
プロキシ設定を中央管理している企業でWPADが必要な場面はまずありません。誰も使っていないのに有効、という典型的な棚卸し漏れです。
デバイスコードフローのユースケース洗い出し
デバイスコードフローをブロックする前に「正当な利用の洗い出し」が先に必要です。
会議室デバイスやCLIツールなど、実際に使っている箇所を特定せずに全面ブロックすると業務が止まります。ここは監査モード（レポート専用）での観測から入るのが定石です。
技術的・運用的な確認ポイント
- Entra ID条件付きアクセスで「認証フロー」条件のデバイスコードフローをブロックするポリシーを作成する。
- Microsoftは「可能な限り全面ブロックに近づける」ことを推奨しており、まずレポート専用モードで既存利用を監査し、正当用途のみ例外化する手順が公式ドキュメントに示されています。
- VPN/SASEクライアントのトンネル方式を確認する。DNSクエリと認証トラフィックがトンネル外へ出る例外がないか、スプリットトンネル設定を一覧化する。
- ReliaQuestは常時接続のフルトンネルVPNを最有効の対策として挙げています。
- 暗号化DNS（DoH/DoT）を利用している場合、平文フォールバックを許す日和見モードになっていないかを確認する。
- WPADをグループポリシー等で無効化する。
- サインインログで、出張者のデバイスコードフロー利用と、不審な地理的位置からのトークン利用を検索できるクエリを用意しておく。
- 出張規程・情報セキュリティ教育に「ホテル・会議場Wi-Fiでは認証画面のURLを確認する」「不審時はモバイル回線へ切り替える」を明記する。
対応方針の比較表
| 対策 | 防げるもの | 副作用・運用負荷 | 着手の速さ |
|---|---|---|---|
| デバイスコードフローのブロック（条件付きアクセス） | デバイスコード悪用によるトークン窃取 | 正当用途の洗い出しが必要。設定のみで完結 | 即日（レポート専用モードから） |
| フルトンネルVPN/SASE常時接続 | DNSポイズニング全般・偽ページ誘導 | キャプティブポータルとの相性設計、帯域コスト | 数週間〜（設計変更を伴う） |
| 厳格モードの暗号化DNS | ゲートウェイでのDNS偽装 | 対応可否が環境依存。フォールバック無効化の検証が必要 | 数週間 |
| WPAD無効化 | 悪性プロキシ経由のトラフィック窃取 | 中央管理環境ではほぼなし | 即日〜数日 |
| ホテルWi-Fi利用禁止・モバイルルーター／テザリングの徹底 | 侵害されたゲートウェイへの接続そのもの | 回線・機器の配備コスト。海外や電波の弱い会場で例外が発生。禁止の技術的な強制が難しく規程頼みになりやすい | 数日〜（機器配備・規程改定） |
| ユーザー教育（URL・証明書確認） | 偽ドメインへの入力 | 効果は補助的。単独では不十分 | 即日 |
着手順は「デバイスコードフローのブロック → WPAD無効化 → トンネル方式の棚卸し → 厳格DoH」でしょう。前の2つは設定変更だけで完結します。フルトンネル化は効果が最も広い一方で設計を伴うため、前の2つを先んじて行うべきです。
ホテルWi-Fiの利用禁止とモバイルルーター・テザリングの徹底は、侵害されたゲートウェイにそもそも接続しないという点で最も根本的な回避策です。ただし禁止を技術的に強制する手段は限られ、海外出張や電波の弱い会場など、ホテルWi-Fiに頼らざるを得ない場面は必ず残ります。運用ルールとして採用しつつ、ルールが破られたときにも耐えられるフルトンネルや認証フロー制限と併用する、という位置づけが現実的です。
見直し時のチェックリスト
- 条件付きアクセスにデバイスコードフローをブロックする（または監査する）ポリシーが存在するか
- ブレークグラス（緊急アクセス）アカウントがポリシー除外に含まれ、除外リストを定期監査しているか
- VPN/SASEのスプリットトンネル例外にDNS・認証エンドポイントが含まれていないか
- キャプティブポータル検出時のVPNクライアント挙動を仕様確認したか
- WPADが無効化されているか（管理外端末・BYODを含めて）
- サインインログでデバイスコードフロー利用を抽出するクエリ・アラートがあるか
- 出張時のWi-Fi利用手順（モバイル回線優先・テザリング許可の基準）が規程化されているか
経営層・監査部門への説明ポイント
経営層への説明は「社員のミスに起因しない攻撃」という一点から始めるのが有効です。従業員がフィッシングを見抜く訓練をどれだけ積んでも、この攻撃は防げません。宿泊先のネットワーク機器が侵害されている以上、会社側の技術統制だけが防御線です。責任の所在が従業員教育ではなく設定と設計にある、という整理は稟議の通し方を変えます。
監査対応では、出張・リモートアクセスに関するリスク評価に「宿泊施設・会議場のネットワークインフラ侵害」を明記し、対応統制としてフルトンネル方針・認証フロー制限・WPAD無効化を紐づけておくと、事後の説明が一貫します。費用面では、既にEntra ID P1相当以上で条件付きアクセスを利用できる環境では追加製品導入なしで着手できる点を先に示すといいでしょう。【要確認：条件付きアクセスはEntra ID P1以上のライセンスが前提のため「追加投資ゼロ」断定の可否を確認】
実務担当者が次に取るべき対応ステップ
- 【今週】条件付きアクセスでデバイスコードフローのブロックポリシーをレポート専用モードで作成し、既存利用を観測する。
- 【今週】WPADの利用実態を確認し、不要ならグループポリシーで無効化する。
- 【2週間以内】VPN/SASEのスプリットトンネル例外を一覧化し、DNS・認証トラフィックの経路を特定する。
- 【1か月以内】レポート専用モードの観測結果をもとにデバイスコードフローブロックを本番有効化し、正当用途のみ例外登録する。
- 【1か月以内】出張者向けのWi-Fi利用手順（モバイル回線優先）を規程・教育資料へ反映する。
- 【四半期内】フルトンネル常時接続への移行計画を策定し、キャプティブポータル対応の検証を行う。
まとめ
ゼロトラストの原則は「ネットワークを信頼しない」でした。ところが実際の端末には、ホテルのゲートウェイが返すDNS応答を信じ、ネットワークが配るプロキシ設定を受け入れる既定値が残っています。
今回の攻撃が突いたのはその隙間です。まずEntra管理センターを開き、デバイスコードフローの監査ポリシーを作成してください。所要時間は30分です。その結果を見てから、トンネル設計の棚卸しに進んでください。
この記事が誰かの役に立てば嬉しいです。
FAQ
Q1. ホテルWi-FiのDNSポイズニング攻撃とは何ですか？
ホテルや会議場のWi-Fiゲートウェイ機器を侵害し、DNS応答を改ざんして宿泊客を偽のMicrosoft 365ログインページへ誘導する攻撃です。2026年6月以降の活動をReliaQuestが2026年7月に報告しました。フィッシングメールを使わない点が特徴です。
Q2. MFAを有効にしていれば防げますか？
防げないケースがあります。デバイスコードフローの悪用では、ユーザーが本物のMicrosoftページで攻撃者の生成したコードを承認してしまうため、MFAを満たした正規トークンが攻撃者に発行されます。Entra ID条件付きアクセスでデバイスコードフロー自体をブロックする対策が必要です。
Q3. VPNを使っていれば安全ですか？
フルトンネル構成で常時接続されている場合のみ有効です。スプリットトンネルでDNSや認証トラフィックがトンネル外へ出る構成、およびキャプティブポータル認証中のVPN未接続時間帯では防御になりません。
Q4. 端末のDNSを8.8.8.8などのパブリックDNSにしていれば防げますか？
防げません。平文のDNSクエリは侵害されたゲートウェイを通過する時点で偽装されるため、リゾルバーの指定先は関係ありません。厳格モードの暗号化DNS（DoH/DoT）かフルトンネルVPNが必要です。
Q5. デバイスコードフローをブロックすると業務に影響しますか？
会議室デバイスや一部のCLIツールなど、正当にデバイスコードフローを使う場面があると影響します。Microsoftはレポート専用モードで既存利用を監査してから、正当用途のみ例外化して全面ブロックに近づける手順を推奨しています。
Q6. Google WorkspaceやOktaを使っている場合は無関係ですか？
無関係ではありません。今回観測されたのはMicrosoft 365を装う偽ページですが、ゲートウェイのDNS改ざんという手口自体はどのIdP・SaaSにも転用できます。フルトンネル化・WPAD無効化・厳格DoHは利用サービスを問わず有効です。
Q7. 出張者向けに今すぐ伝えられる対策はありますか？
「宿泊先や会議場のWi-Fiより会社支給のモバイル回線・テザリングを優先する」「認証画面ではURLを確認し、少しでも違和感があれば入力せず回線を切り替える」の2点です。ただしユーザー教育は補助であり、主対策はテナントと端末の設定側にあります。
