ホテルのWi-Fiが「本物のまま」乗っ取られる時代──ロシア対外情報庁系ハッカーの新しい狩り場
出張先のホテルでノートPCを開いて、部屋番号と苗字を入れてWi-Fiに繋ぐ。あの画面、キャプティブポータルって言うんやけど、あれ自体が攻撃者に握られとったらどうする？
Microsoft Threat Intelligenceが公開した報告が、まさにその話や。ロシア対外情報庁（SVR）と結びつけられとる攻撃グループが、ホテルや会議施設の公衆Wi-Fiを狩り場にして、Microsoft 365の認証情報とマルウェアを配っとった。
ワイがこのニュースで背筋が寒くなったのは、攻撃の技術やない。日本で公的に案内されとる「公衆Wi-Fiの安全な使い方」が、この攻撃に対してほぼ全部空振りすることや。
順に解剖していくで。
何が起きたのか
MicrosoftはこのキャンペーンをCaptiveCrunchと名付けた。
実行主体はStorm-2945。ロシアの対外情報庁と結びつけられた脅威アクターMidnight Blizzardのサブクラスタや。Midnight Blizzardは、Cozy Bear、APT29、Nobeliumという別名でも知られとる</cite>。名前を聞いたことある人も多いはずや。国家支援型の、いちばん上のランクの相手やねん。
Microsoftは、キャンペーンが少なくとも5月上旬から活動しとると見とる。ただしこの攻撃グループは、2月からデバイスコードフィッシングとOAuthコードフィッシングを走らせとった。つまり先に認証情報を狙う手口を回しとって、5月にネットワーク機器そのものの侵害へエスカレートしたという流れや。
攻撃の入口は「ログイン画面が出るWi-Fi」
<cite index="59-1">狙われとるのは、キャプティブポータルを使うホスピタリティ系のネットワークや。ゲストWi-Fiに繋いだときに出てくる、ログインや利用規約の同意を求めるあの画面やな。基盤となる機器が侵害されると、攻撃者はDNSとHTTPのトラフィックを操作して、利用者を自分たちの管理下のインフラへ静かに誘導できる</cite>。
The Hacker Newsが伝えとるReliaQuestの調査結果が、この構造をいちばん端的に説明しとる。<cite index="61-1">調査対象となった侵害ネットワークでは、キャプティブポータルのゲートウェイが、接続端末に割り当てられるDNSリゾルバも兼ねとった</cite>。
これが何を意味するか。名前解決の入口を握られたら、その端末が「どのサイトに繋がるか」を全部決められる。 URLは正しく打っとるのに、着地点だけがすり替わる。
3つの誘導先
DNSとHTTPを操作された利用者は、3つのルートに振り分けられた。
Microsoft 365のサインインポータルを装ったフィッシングページ
Microsoft Entra IDの認証フローを悪用したデバイスコードフィッシングページ
偽のブラウザ／OSアップデート画面（ClickFix手法でマルウェアを実行させる）
3番目については、<cite index="56-1">一部のClickFix着地ページで、APKファイルを配布してAndroid端末も標的にしとる形跡が見つかっとる</cite>。PCだけの話やない。
2種類のマルウェア：CornFlakeとChocoShell
CornFlakeはGo言語で書かれたWindows向けRAT（遠隔操作型トロイの木馬）や。機能一覧を並べると露骨や。
キーロギング
クリップボード監視
スクリーンショット取得
音声監視
映像監視
ブラウザ認証情報の窃取
ファイル持ち出し
USBドライブ監視
セキュリティ製品の設置状況の調査
リモートシェル
マイクとカメラが入っとる。 出張先のホテルの部屋でこれが動くという意味を、ちょっと想像してみてほしい。
<cite index="60-1">CornFlakeは偽の進捗ウィンドウを表示しながら自分をインストールし、「Cloud Sync Service」という表示名でWindowsサービスとして登録される。さらに、防御側が取り除いた永続化の仕組みを復元するウォッチドッグ機能まで持っとる</cite>。消しても戻ってくる設計や。
もう一方のChocoShellは、完全にメモリ上で動くPowerShell製の情報窃取ツールや。<cite index="58-1">狙いはブラウザのセッションクッキー、保存パスワード、Microsoft 365のシングルサインオントークン、Wi-Fi認証情報の大量窃取</cite>。
技術的にえげつないのがここ。<cite index="53-1">複数の防御回避技術を使い、ユーザーアカウント制御（UAC）のバイパスを試み、AMSI保護を無効化し、Chromeのリモートデバッグインターフェースを悪用して、実行中のブラウザセッションから復号済みのクッキーを直接抜き取る</cite>。
Microsoftの整理が分かりやすい。CornFlakeが端末に長く居座る足場を作り、ChocoShellが最も運用価値の高い認証情報を抜いてクラウド環境へのアクセスを渡す。 役割分担が明確や。
AIが開発を手伝った形跡
ここは今回のニュースで見逃されがちやが、重要な点や。
Microsoftの研究者は、ChocoShellのソースコードに詳細な開発者コメントが含まれとることを指摘し、AI支援による開発が相当程度あったことを示唆しとる。
Help Net Securityも、この作戦全体にAI支援の兆候があると報じとる。
国家支援型の攻撃グループがAIをコード生成に使っとる、という話が推測やなく観測として報告される段階に来とるわけや。
C2パネルには認証がかかってへん
最後にひとつ、皮肉な話を。
FruitStoneは、Storm-2945のオペレーターがCaptiveCrunchのインフラ全体を管理するために使っとるWeb版C2パネルや。HTMLとJavaScriptのシングルページアプリケーションとして実装されとって、全機能が認証なしで露出しとる。侵害端末の管理、新しいペイロードの作成と配備、収集データ（スクリーンショット、キーストローク、ブラウザ認証情報）の閲覧が、ここから一元的にできる。
このパネルは「CloudSync Console」というブランドで、フッターには「Acuity Systems, Inc. — Cloud Infrastructure Portal v3.2.1」と表示される。防御側やホスティング事業者にURLを見つけられた場合に、正規のエンタープライズ向けクラウド管理ソフトに見えるよう偽装されとる。
盗んだ被害者のスクリーンショットやキーストロークが、認証なしのWebページに置かれとったということでもある。国家支援型でも運用の粗さはある、という話やな。
なぜ重要なのか──「気をつけよう」が効かん理由
ここからがワイの本題や。
① 「偽のアクセスポイントに注意」という指導が無効化された
日本で公的に案内されとる公衆Wi-Fiの注意点は、だいたいこの2つに集約される。
<cite index="76-1">ポイント1：接続するアクセスポイントをよく確認する。ポイント2：正しいURLでHTTPS通信しているか確認する</cite>
これは総務省のガイドラインに沿った、まっとうな指導や。従来の脅威、つまり「攻撃者が偽のアクセスポイントを立てる」タイプの攻撃には、ちゃんと効く。
でも今回の攻撃には効かん。理由を並べる。
アクセスポイントは本物。ホテルが正規に運用しとるSSIDや
キャプティブポータルの画面も本物。ホテルの機器が出しとる
暗号化の有無も関係ない。侵害されとるのは無線区間やなくゲートウェイや
HTTPSも部分的にしか助けにならん。DNSを握られとると、そもそも接続先が変わる
「怪しいフリーWi-Fiには繋ぐな」という指導は、繋ぎ先が正規のホテルWi-Fiやった時点で発動せえへん。
ワイが言いたいのはこういうことや。信頼の判断基準が「ネットワークの見た目」に置かれとる限り、機器側を取られた瞬間に全部崩れる。
② 侵害されとるのが「1軒のホテル」やない可能性
Microsoftの報告でいちばん不穏なのがこの部分や。
<cite index="52-1">キャプティブポータルネットワークの初期侵害経路の調査は継続中やが、複数の影響を受けたネットワークで使われとる機器や管理システムに注目すべき共通点が観測された。この類似性は、活動が個々の施設の孤立した侵害に留まらず、キャプティブポータルのエコシステムの一部における共有サービスへのアクセスを反映しとる可能性を示唆する</cite>。
日本語に噛み砕くとこうや。「A社のホテルが侵害された」やなくて、「複数のホテルにキャプティブポータルの仕組みを提供しとる裏側の共有基盤が侵害されとるかもしれん」。
これはサプライチェーン攻撃の構造そのものや。宿泊者から見れば「泊まった宿がやられとった」やが、実態は宿もまた被害者で、真の侵害点はもっと上流にある可能性がある。
そしてこの構造の帰結は残酷や。利用者側が「どのホテルなら安全か」を判別する手段が、原理的に存在せえへん。
③ MFAを入れとっても、この経路は塞がらん
日本の情シス界隈でよく聞く「MFAを入れたから大丈夫」が、今回いちばん危ういポイントや。
デバイスコードフィッシングという手口を説明する。NTTセキュリティ・ジャパンの解説がいちばん的確やった。<cite index="66-1">この手口が悪用されやすい理由は2つ。ユーザーがそのフローに慣れておらず騙しやすいこと。そして、ユーザーが操作する認証・認可の画面がMicrosoft公式のものであり、攻撃者のインフラを経由せえへんため、画面の真正性だけを見とるユーザーには気づかれにくいこと</cite>。
攻撃者のサイトで認証するんやない。本物のMicrosoftの画面で認証する。 その結果発行されたトークンが攻撃者の手元に渡る。
せやからこうなる。<cite index="69-1">フィッシング耐性MFA（パスキー、FIDO2セキュリティキー、証明書ベース認証など）は、AiTM攻撃に対しては最も効果的な防御のひとつやが、デバイスコードフィッシングは直接には防げん。あの手口では、認証方式が何であれ、ユーザーが発行されたトークンそのものを攻撃者に渡してまうからや</cite>。
パスキーを配ったから安心、では終わらん。 対策のレイヤーが違う。<cite index="65-1">最も効果的な対策は、条件付きアクセスポリシーでデバイスコードフロー自体をブロックすることで、Microsoftも公式ドキュメントでブロックを推奨しとる</cite>。
ここは日本企業でほとんど手が付いてへん領域やとワイは見とる。理由は単純で、Entra IDの条件付きアクセスにはP1以上のライセンスが要るからや。<cite index="67-1">条件付きアクセスにはEntra ID P1またはP2ライセンスが必要になる</cite>。
つまりライセンスをケチっとる組織ほど、この攻撃に対して構造的に無防備という、身も蓋もない話になる。
④ 攻撃側のAI活用が「観測」の段階に来た
ChocoShellのコードに残っとった詳細な開発者コメントからAI支援が示唆された、という部分。
これ、単に「攻撃者もAI使うんやな」で流したらあかん。意味を分解するとこうや。
国家支援型グループは元々、高度なコードを書く能力を持っとる
そこにAIが加わって上がるのは能力の上限やなく、開発の速度と量
つまりキャンペーンの回転数が上がる
同じグループが2月にデバイスコードフィッシングを回して、5月にネットワーク機器侵害へ移行しとる。この移行速度自体が、AI支援の実効的な効果を示しとるとも読める。防御側にとっての意味は、「新しい手口が来る間隔が短くなる」ということや。
日本への影響
日本語圏でこのニュースを扱っとる媒体は、記事執筆時点で限られとる。せやけど日本の状況を考えると、他人事どころやない。
日本は「泊まる側」と「泊める側」の両方や
ホテルWi-Fiが狩り場になるという話は、日本にとって二重に効いてくる。
泊まる側：海外出張する日本のビジネスパーソン。狙われとるのは<cite index="55-1">まさにビジネス旅行者</cite>や。M365を使っとる日本企業は膨大やから、条件はぴったり当てはまる。
泊める側：日本のホテル・会議施設。インバウンドで海外からの宿泊客が多いということは、日本の施設が攻撃対象の候補にもなるということや。しかも国際会議やカンファレンスの会場は、標的の密度が高い。
日本のホテルWi-Fiがこのキャンペーンで侵害されたという報告は、現時点では確認できてへん。ここは推測で埋めるべきやない部分やから、はっきり「未確認」と書いとく。 ただし、構造的に対象外である理由も存在せえへん。
総務省の枠組みとのズレ
総務省は<cite index="70-1">公衆Wi-Fiの提供者向けに、安全なWi-Fi提供のためのセキュリティ対策の手引きを作成しとる</cite>。<cite index="73-1">利用者意識調査と提供者実態調査も毎年実施されとる</cite>。枠組み自体はある。
問題は、その枠組みが想定しとる脅威モデルや。従来の公衆Wi-Fiのリスクは、<cite index="72-1">盗聴、なりすまし、悪意のあるアクセスポイントやサイトへの接続</cite>として整理されてきた。
今回の攻撃は、この3つのどれとも微妙にズレる。 盗聴やない（能動的な書き換えや）。なりすましやない（本物のAPや）。悪意のあるAPやない（正規のAPが乗っ取られとる）。
既存の枠組みで「対策済み」にチェックが入っとっても、この攻撃は素通りする。脅威モデルの更新が要る段階に来とるとワイは考えとる。
日本企業の弱点を3つ挙げる
元システムエンジニアとして肌で感じることを書く。
出張時のネットワーク運用ルールが「VPN繋いでね」で止まっとる — VPNは通信を守るが、偽アップデート画面を掴まされて自分で実行するタイプの攻撃は止められん
条件付きアクセスの設定が手付かず — ライセンスがあっても、デバイスコードフローのブロックまで設定しとる組織は多くない
「ホテルのWi-Fiは信用しない」が現場で守られへん — テザリングのデータ量を経費で認めてへん会社が実際に多い。ルールとコスト負担が噛み合ってへんと、現場は必ずホテルWi-Fiを使う
3番目が地味やけどいちばん効いとると思う。セキュリティルールが経費精算の都合で破られるという、極めて日本的な失敗パターンや。
AI利用者への影響
ChatGPT、Claude、Gemini、Copilotを日常的に使っとる人向けに、この攻撃が何を意味するかを書く。
盗まれると困るものが増えとる
ChocoShellが狙うのはブラウザのセッションクッキーと保存パスワードや。ここで考えてほしい。あなたのブラウザに、どのAIサービスのログインセッションが残っとる？
ChatGPTの会話履歴
Claudeのプロジェクト、アップロードした社内資料
各種AI APIのキー（ブラウザに保存しとる場合）
AIツールと連携させとるクラウドストレージ
セッションクッキーを盗まれると、パスワードもMFAも通さずにログイン状態を再現される。 AIサービスに業務資料を突っ込んどる人ほど、被害の中身が濃くなる。
「偽アップデート画面」への耐性を上げる
ClickFixという手法は、要するに「画面の指示通りにユーザー自身にコマンドを実行させる」やり方や。ブラウザやOSのアップデートを装う。
覚えといてほしい原則を1つだけ。
OSもブラウザも、Wi-Fiに繋いだ直後にアップデートを要求してこん。 更新は設定画面か、OS/ブラウザ自身の通知から始まる。Webページから始まる更新は、全部偽物や。
そしてMicrosoftの推奨も同じ方向を向いとる。<cite index="52-1">ホテルやカンファレンスのWi-Fiは信頼できんものとして扱い、実務的に可能なら携帯回線か管理された接続を使い、キャプティブポータル経由で提供されるソフトウェア更新やツールは避けること</cite>。
出張時の実務ルール
ホテルのWi-Fiに繋ぐ前に、まずテザリングで足りるか考える
繋ぐなら、その端末でM365やクラウドの認証をやり直さん（既存セッションを使う。新規ログインを求められたら疑う）
デバイスコードの入力を求められたら、原則として拒否する。自分から要求してへんコードを入れる場面は、通常の業務ではまず無い
帰国後、出張中に使った端末のブラウザセッションを一度切る
投資家への影響（観察的文脈として）
※ここからは投資助言やない。ワイが構造として何を見とるかの共有や。判断は各自で。
「認証基盤」と「ネットワーク機器」の間の空白地帯
今回の事案が浮かび上がらせとるのは、既存のセキュリティ製品カテゴリの隙間や。
エンドポイント側（EDR）は端末を守るが、ネットワーク機器の侵害は見えん
ID側（Entra ID、MFA）は認証を守るが、トークンを自分で渡す攻撃は止まらん
ネットワーク側（VPN）は通信を守るが、ユーザー自身が実行するマルウェアは通す
3つとも入れとっても抜ける経路がある、という構造や。ここを埋めるカテゴリ、具体的には条件付きアクセスの高度化、トークン保護、ゼロトラストネットワークアクセスあたりが、需要側の圧力を受ける領域やと見とる。
ホスピタリティ業界の設備投資という補助線
もうひとつの角度。侵害されとるのがキャプティブポータル機器やとすると、更新需要はホテル・会議施設側に発生する。
ホスピタリティ業界のネットワーク機器は、更新サイクルが長く、管理も外部委託されとることが多い。今回のように「共有基盤の侵害の可能性」が指摘されると、業界横断での機器・管理体制の見直しが発生しうる。
ただしこれは実際に起きるかどうか分からん話や。過去の類似事案でも、注意喚起の後に大規模な設備更新が起きたケースと、そのまま流れたケースの両方がある。 ここは「起きるはず」やなく「観察対象」として置いとくのが誠実やと思う。
Microsoftというプレイヤーの二面性
今回の報告主体はMicrosoftや。同時に、被害の対象もMicrosoft 365とEntra IDや。
この構図をどう読むかは分かれる。「自社製品への攻撃を自社で検出・公表しとる」という誠実さの表れとも読めるし、「対策として自社の上位ライセンス（Entra ID P1/P2の条件付きアクセス）が必要になる」という商業的な帰結を伴う報告とも読める。
ワイの立場は、両方本当やろ、というものや。脅威は実在するし、対策に上位ライセンスが要るのも事実。この2つは矛盾せえへんし、どちらか一方だけを見るのは読み方として雑や。
教育現場への影響
情報教育に関わる人向けに、いちばん更新が必要な部分を書く。
「フリーWi-Fiは危険」の教え方が古い
学校で教えられとる公衆Wi-Fiの注意点は、だいたい以下や。
提供元が不明なWi-Fiに繋がない
鍵マークのないWi-Fiに繋がない
公衆Wi-Fiで個人情報を入力しない
このうち今回の攻撃に効くのは3番目だけや。 1番目と2番目は、正規のホテルWi-Fiが侵害されとる状況では発動せえへん。
更新すべき教材観
「安全なネットワーク」という概念自体を疑わせる — ネットワークの信頼性やなく、そこで何をするかでリスクを判断する考え方に移す
「Webページから始まる更新は全部偽物」を具体的なルールとして教える — 抽象的な「怪しいものに注意」より、判定可能なルールの方が実効性がある
セッションとトークンの概念を扱う — 「パスワードを守る」だけでは足りん時代に入っとる。中高生でも、ログイン状態そのものが盗まれうることは理解できるはずや
保護者向けに一行で
修学旅行や旅行先のホテルWi-Fiでお子さんがスマホを使うこと自体は、止めんでええ。ただ「Wi-Fiに繋いだ直後に出てくるアップデート画面は絶対に押さん」だけは伝えといてほしい。 今回の攻撃の実行トリガーが、まさにそこやから。
ワイ自身の主張への、いちばん強い反論
ここまで「従来の指導が効かん」と散々書いたが、この記事への最強の反論を自分で書いとく。
反論①「結局、最後は本人がマルウェアを実行しとるやろ」
その通りや。 ClickFixで偽アップデート画面が出ても、ユーザーが押さなければ感染せえへん。DNSを乗っ取られてフィッシングページに飛ばされても、認証情報を入力せんかったら盗まれん。
「ネットワーク機器が侵害された」という前半のインパクトが強いだけで、最終的な発火点は昔から変わらん「ユーザーの操作」や。 ワイが書いた「気をつけようが効かん」は、正確には「気をつけるポイントがズレとる」であって、注意喚起自体が無意味なわけやない。
反論②「ホテルWi-Fiは使うな、で終わる話やないか」
これも一理ある。Microsoftの推奨自体が「信頼できんものとして扱え、携帯回線を使え」やから、結論としては極めてシンプルや。長々と構造分析するより「テザリング使え」の一行の方が実用的やという批判は成立する。
ワイの反論への反論としては、それでも人はホテルWi-Fiを使う、というのがある。データ量の問題、海外ローミングの費用、会社の経費規定。「使うな」で解決するなら、そもそも公衆Wi-Fiの注意喚起は20年前に役目を終えとる。
反論③「日本での被害は確認されとらん」
これも事実や。Microsoftの報告で日本の施設が挙げられとるわけやない。ワイは記事内で「日本で被害が出た」とは一言も書いてへんし、書くべきでもない。
「構造的に対象外である理由がない」という書き方も、慎重に見えて実は何も言うてへんという批判は正当や。可能性の指摘は、事実の報告やない。
それでもワイが「見るべき」と考える理由
反論を全部認めたうえで、今回の事案に固有の要素を1つだけ挙げる。
「利用者側に判別手段が存在せえへん」という状態が、はっきり可視化されたこと。
従来の公衆Wi-Fiの注意喚起は、「利用者が見分けられる」ことを前提に組まれとった。SSIDを確認する、鍵マークを見る、HTTPSを確認する——全部「見分ける」ための技法や。
今回の攻撃は、その前提を壊しとる。正規のAP、正規のポータル画面、正規の設備。見分けられん相手に対して「見分けろ」と指導し続けるのは、対策やなく責任転嫁になってまう。
せやから対策の設計も変わる必要がある。**「安全なネットワークを選ぶ」やなく「どのネットワークでも安全なように振る舞う」**へ。デバイスコードフローのブロックも、Webページ起点の更新を拒否するルールも、全部この方向の話や。
まとめ：今日やること
長い話をしたが、やることは地味や。
個人としてすぐやる
出張・旅行時は、まずテザリングで足りるか検討する癖をつける
Webページから始まるアップデートは、いかなる場合も実行せんとルール化する
自分から要求してへんデバイスコードの入力を求められたら、その場では入れん
ブラウザに保存しとるパスワードを、パスワードマネージャに移す
組織としてやる
Entra IDの条件付きアクセスで、デバイスコードフローの利用状況を確認する
出張時のネットワーク利用ルールを、経費規定とセットで見直す（テザリング代を認めてへんなら、そこが穴になる）
海外出張者の端末で、出張前後にセッションの棚卸しをする運用を作る
考え方として持って帰ってほしいこと
ネットワークの見た目で安全性を判断するのは、もう成立せえへん
MFAは万能やない。トークンを自分で渡す攻撃には別のレイヤーの対策が要る
「見分けろ」やなく「見分けられん前提で振る舞う」
参考にした一次情報
Microsoft Security Blog「CaptiveCrunch: Midnight Blizzard targets travelers worldwide」（2026年7月31日）
Help Net Security（2026年8月4日）
ReliaQuest調査（2026年7月23日公開）
総務省「無線LAN（Wi-Fi）の安全な利用（セキュリティ確保）について」
NTTセキュリティ・ジャパン、トレンドマイクロによるデバイスコードフィッシング解説
この記事は海外の一次情報をもとに、日本の読者向けに独自の構造分析を加えて再構成したものです。翻訳記事ではありません。
投資に関する記述は筆者の観察であり、特定銘柄の売買を推奨するものではありません。
