ホテルの公衆Wi-Fiゲートウェイが侵害されDNSポイズニングでMicrosoft 365アカウントを標的に

セキュリティニュース

投稿日時: 更新日時:

ホテルの公衆Wi-Fiゲートウェイが侵害されDNSポイズニングでMicrosoft 365アカウントを標的に

セキュリティ企業ReliaQuestは2026年7月23日、ホテルや会議施設などで利用される公衆Wi-Fiのゲートウェイが侵害され、接続した出張者のMicrosoft 365アカウントを狙う攻撃キャンペーンを確認したと公表しました。攻撃者は偽のアクセスポイントを設置するのではなく、施設が運用する正規のキャプティブポータル機器を乗っ取り、DNS応答を改変して利用者を攻撃者のインフラへ誘導していました。活動は少なくとも2026年6月から続いており、米国の複数都市に加え、インドとサウジアラビアでも侵害されたゲートウェイが確認されています。

サマリー

  • ホテルや会議施設の正規Wi-Fiゲートウェイが侵害され、利用者の通信が攻撃者のインフラへ誘導されました
  • 攻撃者はゲートウェイのDNS設定を操作し、Microsoft 365を装うページや認証フローへ接続させていました
  • 活動は少なくとも2026年6月から継続し、米国、インド、サウジアラビアで侵害された機器が確認されています
  • 金融、専門サービス、法律、医療、エネルギー、小売など、複数業種の組織から対象ゲートウェイへの通信が観測されています
  • 一部の事例ではWPADの悪用とMicrosoftのデバイスコード認証フローの悪用も確認されました
  • ReliaQuestはAPT28と手口が類似すると評価していますが、同グループによる攻撃とは断定していません
  • 企業端末では常時接続型のフルトンネルVPN、WPADの無効化、デバイスコードフローの制限が重要です
項目 内容
一次ソースの公表日 2026年7月23日
調査機関 ReliaQuest Threat Research
活動開始時期 少なくとも2026年6月
主な標的 ホテル、会議施設などの公衆Wi-Fiを利用する企業の出張者
侵害対象 キャプティブポータルを提供するWi-Fiゲートウェイ
確認地域 米国の複数都市、インド、サウジアラビア
関連業種 金融、専門サービス、法律、医療、エネルギー、小売
主な攻撃手法 ゲートウェイ侵害、DNSポイズニング、Microsoft 365偽装、AiTM
副次的な手法 WPAD悪用、デバイスコード認証フローの悪用
初期侵入の推定 公開されたSSH、SNMP、Web管理画面と、脆弱または使い回された管理者認証情報の組み合わせ
初期侵入の確度 ReliaQuestは低から中程度の確度と評価
APT28との関係 FrostArmadaと手口が重複するが、直接的な帰属は行われていない
日本での被害 一次ソースでは確認されていない
主要な対策 常時接続・フルトンネルVPN、厳格な暗号化DNS、WPAD無効化、デバイスコードフロー制限

ホテルや会議施設の正規Wi-Fi機器を侵害

今回の攻撃は、攻撃者がホテル名と同じSSIDの偽アクセスポイントを設置する、いわゆる悪魔の双子型の攻撃とは異なります。

ReliaQuestが確認したのは、ホテルや会議施設が実際に運用しているWi-Fiゲートウェイやキャプティブポータル機器そのものが侵害される手口です。利用者は正規の施設Wi-Fiへ接続しているため、ネットワーク名だけを確認しても攻撃を見分けられません。

キャプティブポータル機器は、利用規約への同意や部屋番号の入力など、公衆Wi-Fiへ接続する際の認証画面を提供するとともに、接続端末のDNSや通信経路を管理します。1台のゲートウェイが侵害されると、その日に同じネットワークへ接続した多数の利用者が影響を受ける可能性があります。

ReliaQuestは、ホテル以外にも、空港、コワーキングスペース、大学、医療施設、イベント会場など、キャプティブポータルを運用する環境には同様の攻撃面が存在すると指摘しています。

初期侵入は公開管理画面と弱い認証情報の悪用か

ReliaQuestは、攻撃者がどのようにWi-Fiゲートウェイの管理権限を取得したかを確定していません。

調査では機器内部への可視性が限られていたため、初期侵入については低から中程度の確度での評価となっています。想定されているのは、インターネットへ公開されたSSH、SNMP、Web管理コンソールと、脆弱または複数環境で使い回された管理者認証情報を組み合わせる手口です。

侵害されたゲートウェイのメーカー名、製品名、ファームウェアのバージョン、悪用されたCVEは公表されていません。そのため、特定のWi-Fi製品に存在する脆弱性を狙ったキャンペーンとは現時点で断定できません。

ホテルや施設の運営者は、管理画面をインターネットへ直接公開していないか、初期パスワードや共有アカウントが残っていないか、保守事業者の認証情報が使い回されていないかを確認する必要があります。

DNSポイズニングで通信先を攻撃者のサーバーへ変更

ゲートウェイの管理権限を取得した攻撃者は、接続端末へ渡すDNS応答を改変していました。

DNSは、利用者が入力したドメイン名を接続先のIPアドレスへ変換する仕組みです。公衆Wi-Fiへ接続した端末は、通常、そのネットワークからDHCPで指定されたDNSリゾルバーを利用します。ゲートウェイを管理する攻撃者は、正規ドメインへの問い合わせに対して攻撃者のIPアドレスを返し、通信を不正なインフラへ誘導できます。

ReliaQuestが調査した事例では、正規のMicrosoft 365を装うため、次のドメインが利用されていました。

不正ドメイン 関連IPアドレス
m365-owa[.]com 31.57.243[.]154
owa-ms365[.]com 31.57.243[.]154
ms365-device[.]com 31.57.243[.]154
ms365-live[.]com 104.194.159[.]150

DNSの改変や偽サイトを組み合わせる手口は、DNSへのサイバー攻撃とドメインハイジャックでも解説しています。

ただし、DNS応答を書き換えただけで、正規のMicrosoft HTTPSサイトを警告なしに完全になりすませるわけではありません。通常はTLS証明書の検証によって、正規ドメインと異なるサーバーへの接続が阻止されます。

今回の攻撃では、Microsoftに似せた別ドメイン、キャプティブポータルによる誘導、WPAD、デバイスコード認証などが組み合わされていました。利用者が表示されたURLや認証要求を正規のMicrosoft画面だと信じることが、アカウント侵害につながります。

公開DNSを指定するだけでは防げない

端末のDNSサーバーをGoogle Public DNSなどへ固定していても、DNS通信が暗号化されていなければ十分な対策にはなりません。

通常のDNS問い合わせは平文で送信されます。通信が公衆Wi-Fiのゲートウェイを通過する以上、攻撃者は問い合わせを読み取り、正規のDNSサーバーより先に偽の応答を返すことができます。

ReliaQuestは、有効な対策として、常時接続型のフルトンネルVPNと、平文へのフォールバックを許可しない厳格なDNS over HTTPSまたはDNS over TLSを挙げています。

フルトンネルVPNでは、DNSを含む端末の通信が暗号化されたトンネルへ収容されます。公衆Wi-Fiのゲートウェイは暗号化されたVPN通信を転送するだけとなり、内部のDNS問い合わせを読み取ったり改変したりしにくくなります。

一方、VPNが接続される前に通常の通信を許可する設定や、Microsoft 365だけをVPN経由から除外するスプリットトンネル設定があると、今回の攻撃経路が残る可能性があります。ReliaQuestは、ネットワーク接続時にVPNを自動開始し、トンネル確立前のインターネット通信を遮断する構成を推奨しています。

英国NCSCも、組織管理端末では端末全体を保護するVPNの利用を推奨する一方、公衆Wi-Fiのキャプティブポータルと常時接続VPNの互換性を事前に確認する必要があると説明しています。

WPADを使ったプロキシ設定の乗っ取りも試行

ReliaQuestが観測した事例のおよそ3分の1では、攻撃者がWeb Proxy Auto-Discovery、WPADの悪用も試みていました。

WPADは、Windowsなどの端末がネットワークへ接続した際に、利用すべきプロキシ設定を自動的に取得する仕組みです。WindowsはDHCPのオプション252や、wpadというホスト名へのDNS問い合わせを使ってPACファイルを探します。

今回のように攻撃者がゲートウェイを制御している場合、DHCPとDNSの両方へ不正な情報を返すことができます。悪意のあるPACファイルを端末へ読み込ませることに成功すると、ブラウザだけでなく、Windowsのネットワーク機能を利用する認証コンポーネントや業務アプリの通信も攻撃者のプロキシへ送られる可能性があります。

ReliaQuestは、今回の調査ではWPAD悪用が成功したことまでは確認できなかったとしています。そのため、主要な侵害経路ではなく、攻撃者が機会的に試した副次的な手法とみられます。

WPADを業務で使用していない組織は、グループポリシーなどで自動プロキシ検出を無効化することを検討する必要があります。MicrosoftもWindowsのWPADを無効にする設定方法を公開しています。

デバイスコード認証でMFA済みのアクセスを取得

一部の事例では、DNSポイズニングによる誘導に、Microsoftのデバイスコード認証フローが組み合わされていました。

デバイスコードフローは、キーボードを持たない機器や入力が難しい端末をMicrosoftアカウントへ接続するための正規機能です。利用者は別の端末でMicrosoftの認証画面を開き、表示されたコードを入力してアクセスを承認します。

攻撃者は、自分が開始した認証セッションを被害者に承認させることで、有効なOAuthトークンを取得できます。被害者は正規のMicrosoft認証画面でMFAを完了しているため、攻撃者側にはMFAを満たしたセッションが発行されます。

この場合、攻撃者は偽ページからパスワードを直接盗んだり、通信を復号したりする必要がありません。利用者が表示された承認内容を確認せず、攻撃者のセッションを正規のログインだと誤認することが問題になります。

デバイスコードを悪用するフィッシングについては、FBIが警告したKali365のデバイスコードフィッシングでも取り上げています。

Microsoft Entra IDを利用する組織は、業務上デバイスコードフローを必要としない利用者に対し、条件付きアクセスポリシーで同フローをブロックできます。会議室端末などで必要な場合は、対象アカウントや端末だけを例外にする構成が必要です。

APT28との手口の重複はあるが帰属は未確定

ReliaQuestは、今回の攻撃手法がロシア軍参謀本部情報総局との関係が指摘されるAPT28、別名Fancy BearやForest Blizzardの活動に類似すると評価しています。

背景にあるのが、2026年4月に英国NCSC、Microsoft、Lumen Technologiesなどが公表したFrostArmadaです。FrostArmadaでは、APT28がMikroTikやTP-LinkなどのSOHOルーターを侵害し、DNS設定を変更してMicrosoftの認証情報やOAuthトークンを窃取していました。

LumenのBlack Lotus Labsによると、FrostArmadaは2025年5月ごろから活動し、2025年12月のピーク時には120か国以上の1万8,000を超えるIPアドレスが攻撃インフラと通信していました。米当局やMicrosoftなどは2026年4月に関連インフラを妨害しています。

今回のホテルWi-Fiを狙う活動も、ゲートウェイの侵害、DNSの改変、AiTMによるMicrosoft 365アカウントの窃取という手順が重なります。

一方、攻撃インフラのドメインやIPアドレスはFrostArmadaと一致せず、コードの再利用や運用上のミスといった直接的な技術証拠も確認されていません。ReliaQuestはAPT28への直接的な帰属を行わず、少なくとも手口が再利用されている可能性があるとの評価にとどめています。

影響を受けた企業数やアカウント数は不明

一次ソースでは、侵害されたWi-Fiゲートウェイの台数、影響を受けたホテル名、接続した利用者数、実際に侵害されたMicrosoft 365アカウント数は公表されていません。

金融、専門サービス、法律、医療、エネルギー、小売の組織から、侵害されたゲートウェイへの通信が観測されたとしていますが、これらの組織ですべて認証情報が窃取されたことを意味するものではありません。

日本国内のホテルや企業が影響を受けたとの情報も、ReliaQuestの報告には記載されていません。

ただし、海外出張者が米国、インド、サウジアラビアのホテルや会議施設で業務端末を接続した場合、日本企業のMicrosoft 365アカウントが標的になる可能性はあります。攻撃は施設の所在地ではなく、接続した利用者の所属組織へ波及します。

情報システム部門への示唆

情報システム部門は、出張用の業務端末に常時接続型のVPNを導入し、フルトンネルでDNSを含む通信を保護してください。VPN確立前の通信を許可しない設定とし、公衆Wi-Fi接続時に利用者が手動でVPNを開始する運用へ依存しないことが重要です。

Microsoft 365への通信をVPN対象外とする設定を採用している場合は、今回の攻撃に対する影響を再評価する必要があります。性能や帯域を理由にスプリットトンネルを利用する場合でも、DNSと認証通信が信頼できないゲートウェイへ露出しない設計が求められます。

Windows端末でWPADを利用していない組織は、自動プロキシ検出を無効化してください。利用している場合は、PACファイルの取得先を承認済みの社内ホストへ限定し、外部ネットワークから提供されたWPAD情報を受け入れない構成を検討します。

Microsoft Entra IDでは、デバイスコード認証フローの利用状況を確認し、不要なユーザーでは条件付きアクセスでブロックしてください。管理者や重要情報へアクセスする利用者には、FIDO2セキュリティキー、Windows Hello for Businessなどのフィッシング耐性を持つMFAを要求することが有効です。

調査では、出張期間中のサインインログを確認し、通常とは異なる国・地域、未知の端末、デバイスコードフロー、見慣れないOAuthアプリ、攻撃者による端末登録がないかを確認します。不審なアクセスが見つかった場合は、パスワード変更だけでなく、セッションとリフレッシュトークンの失効、攻撃者が登録した端末や認証方法の削除が必要です。

従業員には、公衆Wi-Fiへ接続した直後にMicrosoft 365のログイン画面やデバイスコードの承認画面が突然表示された場合、その場で認証を続けないよう周知してください。ホテル名と一致する正規SSIDであっても、ネットワーク機器自体が侵害されている可能性があるためです。

出張先では、携帯電話のテザリングや企業管理のモバイルルーターを優先し、公衆Wi-Fiを使用する場合はVPN接続を必須とする運用が現実的です。

出典