Windowsの防御を担うはずのMicrosoft Defenderそのものに、特権昇格の脆弱性が潜んでいた——しかもそのうち2件は、この記事を書いている時点でまだパッチが提供されていない。Huntress Labsの報告により、3件のゼロデイ脆弱性が実際の攻撃に使われていることが確認された。組織のWindows環境を守る立場のエンジニアや管理者にとって、対応を急ぐべき状況だ。

何が起きているか

今回の発端は、「Chaotic Eclipse」（別名 Nightmare-Eclipse）と名乗るセキュリティ研究者による、PoC（概念実証コード）の意図的な公開だ。MicrosoftのSecurity Response Center（MSRC）との調整プロセスに不満を持ったこの研究者が、4月初旬に3件分のエクスプロイトコードを相次いで公開した。

3件の脆弱性の概要は以下のとおりだ。

BlueHammer（CVE-2026-33825）——修正済み

Microsoft Defenderのローカル特権昇格（LPE）脆弱性。4月の定例セキュリティ更新（Patch Tuesday）で対処済み。ただしHuntress Labsによれば、4月10日時点ですでに実攻撃に使われており、パッチ前から悪用が始まっていた。

RedSun——未修正

Defenderがクラウドタグ付きのマルウェアファイルを検知した際に、「検出した場所にそのファイルを再書き込みする」という奇妙な動作を悪用してシステムファイルを上書きし、SYSTEM権限を奪取する手法だ。Windows 10・Windows 11・Windows Server 2019以降のすべてが対象となる。4月のPatch Tuesdayを適用済みの環境でも影響を受ける点が厄介だ。

UnDefend——未修正

標準ユーザー権限でDefenderの定義ファイル更新を止められる脆弱性。これ単体では致命的ではないが、RedSunと組み合わせることで「検知を封じてから特権昇格」という流れが成立する。SSLVPN経由での侵害事例では、この2件が同一ホストで同時に使われていることが確認されている。

なぜこれが重要か

DefenderはWindowsに標準搭載されており、追加コストなしで有効なセキュリティレイヤーとして機能している。その防御機構の内部ロジックが攻撃の踏み台になるという構造は、見逃せない。

特にRedSunの仕組みが象徴的だ。「マルウェアを検知したらファイルを元の場所に再配置する」という設計が攻撃ベクターになっている。セキュリティ機能の実装ミスが権限昇格の窓口を開いてしまう——これはネットワーク境界ではなく、エンドポイントの内部で起きていることだ。

また、SSLVPN経由での侵害という報告も示唆に富んでいる。ネットワーク境界を突破された後、端末内部での権限昇格に今回のゼロデイが使われている構図は、「VPNさえあれば安全」という旧来の前提がいかに脆いかを改めて示している。

実務への影響と今すぐできる対策

1. April Patch Tuesdayの適用状況を確認する

BlueHammerの修正は4月の更新に含まれている。適用済みであれば1件は封じられている。MicrosoftのMUSE（Microsoft Update Catalog）やIntune/WSUS経由で未適用端末がないか確認しよう。

2. RedSun・UnDefendは「パッチなし」と理解した上で対策を立てる

現時点ではWorkaroundが公式に示されていない。多層防御の考え方で、エンドポイントへの初期侵入そのものを防ぐ層を厚くするしかない。具体的にはMFAの徹底、条件付きアクセスポリシーの強化、EDR/MDRによる異常な権限昇格の検知設定を見直すべきだ。

3. SSLVPNとネットワーク境界への過信を見直す

今回の攻撃ではSSLVPN経由の侵害が起点になっている。「VPN接続 = 信頼済み」とみなす設計は再検討する時期だ。ゼロトラストモデルへの段階的な移行——デバイスコンプライアンスチェック、Just-In-Timeアクセス、最小特権の徹底——が正しい方向性だ。

4. 「今は大丈夫」を根拠にしない

Huntress Labsが観測したのは実際に侵害された環境だ。未修正の脆弱性は「いつか悪用されるかもしれない」ではなく「すでに悪用されている」という事実を出発点にリスク評価をし直してほしい。

筆者の見解

今回の騒動で改めて問われているのは、「脆弱性の責任ある開示」（Coordinated Vulnerability Disclosure）のあり方だ。Microsoftは公式声明でこのプロセスの重要性を述べているが、研究者側が「調整が機能しなかった」と判断してPoC公開に踏み切った背景は軽視できない。

MSRCは世界規模で膨大な報告を処理する組織だ。対応品質にばらつきが出ることは理解できる。ただ、その結果として未修正のゼロデイが実攻撃に使われる状況になっているとすれば、プロセスそのものを見直す理由は十分ある。Microsoftには、セキュリティ研究コミュニティとの関係をもう少し丁寧に扱う余地があるのではないか。開発力も影響力もある会社なのだから、そこで正面から勝負してほしいと思う。

RedSunの仕組みについては、率直に言って「設計として変だ」という研究者の指摘は的を射ている。検知したマルウェアを元の場所に書き戻す動作は、それだけ聞けば奇妙に映る。ただ、その実装判断の背景には何らかの理由があるはずで、修正対応の中でその説明もあってほしいところだ。

セキュリティに興味を持つエンジニアとして付け加えると、今回のような事案が積み重なるほど「境界型防御だけでは足りない」という当たり前の結論が強化される。端末内部での特権昇格を前提に、ゼロトラストアーキテクチャで「侵入後の動きを封じる」設計を日常業務に組み込むことが、現実的かつ持続可能な防御戦略だと考えている。

出典: この記事は Recently leaked Windows zero-days now exploited in attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。