Microsoftが7月31日に公開した脅威インテリジェンス記事「CaptiveCrunch」を受けて、国内外のメディアに「マイクロソフトが緊急警告、ホテルのWi-Fiは使うな」という見出しが並んだ。Forbes(およびその日本版)もその一つだ。だが原文を読むと、Microsoftはそんなことを一度も書いていない。しかもこの見出しは、報告書の中で最も効く対策を落とし、最も効かない対策だけを残している。実務者にとって危険な要約なので、原文が何を言っているかを整理しておきたい。

Microsoftが実際に書いた2つの文

該当箇所は次の2文である。

When traveling, users should treat hotel, conference, airport, and other guest wireless networks as untrustworthy.

Prefer private connectivity (including mobile hotspots, satellite, and eSIM-based cellular data connections) over public Wi-Fi whenever practical.

「信頼できる前提を捨てろ」「実務上可能な範囲で私設回線を優先しろ」であって、禁止ではない。宛先も"corporate travelers"(企業の出張者)であり、Windowsユーザー一般への緊急警告でもない。MSTICが日常的に出している脅威インテリジェンス記事の一本だ。

攻撃されているのはWi-Fiではなく「キャプティブポータル」

より重要なのは、これが電波の盗聴の話ではないという点である。侵害されているのは、宿泊施設のWi-Fi接続時に出てくるログインページ、すなわちキャプティブポータルのゲートウェイ機器だ。この機器が接続端末に配布されるDNSリゾルバも兼ねていたため、管理権限を取ったロシア系攻撃者グループMidnight Blizzardのサブクラスター「Storm-2945」は、DNS応答を偽造して任意の宛先にユーザーを飛ばせるようになった。

つまり、Wi-Fiにパスワードが掛かっていようが、WPA3で暗号化されていようが、この攻撃には一切関係がない。「暗号化されていない公衆Wi-Fiは危ない」という10年来の啓発モデルとは、脅威の所在が違う。Microsoftは複数施設で機器と管理システムに共通性が見られるとして “similarities suggest that the activity might not be limited to isolated compromises”(個別の侵害に留まらない可能性がある)と述べており、個々のホテルではなくポータル機器やその管理事業者の側が侵害されている可能性を示唆している(調査中で断定はしていない)。

TLSは破られていない — 盗まれ方は3経路

では暗号化されたHTTPS通信からどうやって認証情報を奪うのか。答えは「奪っていない」だ。3つの経路はいずれもユーザー自身に正規の操作をさせる形を取る。

  1. 偽アップデート+ClickFix — Windowsが起動時に行う接続確認(NCSIプローブ)を偽ページに誘導し、「ブラウザやOSを更新せよ」と表示する。ユーザーが自分で実行すると、Go製RATのCornFlake(Webカメラ画像・マイク音声・キーストロークを取得)やPowerShell製インフォスティーラーのChocoShell(ブラウザのセッションCookieを窃取)が入る。
  2. AiTMのサインインページ — Microsoftを模した偽サインイン画面へリダイレクトし、攻撃者インフラを経由させる。
  3. デバイスコードフローの悪用 — 7月16日以降に一部のランディングページへ追加された手口で、これが最も厄介だ。攻撃者側がEntra IDの認証要求を起こし、ユーザーには本物のmicrosoft.comのサインインページで表示コードを入力させる。ユーザーから見て偽サイトの痕跡はどこにもないが、認証されるのは攻撃者のセッションである。

3番目は「URLをよく見て偽サイトを見抜きましょう」という教育では原理的に防げない。ここが今回の報告の核心である。

「Wi-Fiを避ける」では守れない理由

見出しに従って「ホテルのWi-Fiを使わない」「VPNを張る」だけを実行しても、守れる範囲は限定的だ。VPNは経路上の盗聴には効くが、キャプティブポータル通過の通信には効かず、ユーザーが自分の手でマルウェアを実行する経路にも、デバイスコードの詐取にも効かない。実際、Microsoftが挙げている推奨事項の筆頭はネットワークの話ではない。

Only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible.

条件付きアクセスでデバイスコードフローを塞ぐこと。次いでパスキー等のフィッシング耐性MFA、キャプティブポータル経由で提示された更新・証明書・ネットワーク診断ツール・セキュリティユーティリティを一切ダウンロードしない運用、企業管理のトラベルルーターで社内へ暗号化トンネルを張ること、そしてClickFix系(「このコマンドをコピーして貼り付けて実行せよ」)を悪性と認識させる教育が並ぶ。

実務への影響 — 日本のIT管理者・エンジニアが今すぐ確認すべきこと

海外出張のある組織であれば、まず自テナントの条件付きアクセスでデバイスコードフローの利用状況を確認したい。会議室デバイスやサイネージなど正当な用途がある場合を除き、ユーザーサインインでは原則ブロックが推奨されている。この設定は今回のキャンペーンに限らず、Midnight Blizzardが以前から多用してきたデバイスコードフィッシング全般に効く。

検知側では、Microsoftが提示しているハンティングの着眼点が実装しやすい。NCSIによる接続確認から2分以内のファイル生成を疑う、というものだ。IoCとしてms365-device[.]comm365-owa[.]com213.145.86.11231.57.243.154が公開されているので、プロキシやDNSログでの遡及調査もすぐ回せる。

そして出張者への周知は「ホテルのWi-Fiを使うな」ではなく「接続直後にポータルから出てくる更新・証明書の類は何であれ入れるな」「サインイン画面でコードを入力させられたら、自分が始めた認証か必ず確認しろ」の2点に絞るほうが実効性が高い。前者は行動として明確で、後者は今回追加された最新手口をピンポイントで塞ぐ。

報道の見出しは短くなければならないという事情は理解できる。ただ今回のように、原文が「これが最優先だ」と名指しした対策(デバイスコードフローの遮断)が見出しから消え、原文が"whenever practical"と条件付きで述べた項目(Wi-Fiの回避)が断定形の命令になって残ると、読者の対策リソースは間違った方向に配分される。一次情報を読む価値は、こういうところにある。


出典: この記事は CaptiveCrunch: Midnight Blizzard targets travelers worldwide for malware delivery and credential theft(Microsoft Security Blog)の内容をもとに、筆者の見解を加えて独自に執筆したものです。報道例として Forbes JAPAN および Forbes(原文・Zak Doffman) を参照しました。