7-Zipのデフォルト設定では、インターネット経由で受信したアーカイブから展開されたファイルからMark of the Web(MotW)が失われてしまいます。その結果、Windows SmartScreenがレピュテーションチェックを一切実行せず、署名されていないペイロードが「WindowsによってPCが保護されました」という警告なしに実行できてしまいます。
インターネット・通信
長らくレッドチームの手法として扱われてきたこの挙動は、現在では正式に認識され複数の7-Zipの脆弱性として追跡されています。これはサードパーティ製アーカイバに依存するWindowsシステムにおいて、SmartScreenのカバレッジに存在し続けている隙間を浮き彫りにしています。
最近実施されたフィッシングに焦点を当てたある侵入テストでは、ShellcodePackランチャーで包んだSliver C2ビーコンを、Microsoft Defender for Endpoint(MDE)を完全に回避できるまで調整しました。書き込み時の静的検知もなければ、実行時の振る舞い検知アラートもなく、C2へのビーコン通信もクリーンに通ってしまいました。
ところが同じペイロードを、メールのリンク、ブラウザでのダウンロード、エクスプローラーでのダブルクリックという現実的なフィッシングの流れで配信したところ、即座にブロックされました。ブロックしたのはMDEではなく、Windows SmartScreenでした。
この違いを生んだのはMotWです。最近のブラウザはダウンロードしたファイルにZoneId=3のZone.Identifier代替データストリーム(ADS)を書き込み、そのファイルがインターネット由来であることを示すフラグを立てます。
SmartScreenはこのフラグを起点として動作し、Microsoftのクラウドに照会してレピュテーションを確認します。署名されておらず、これまで観測されたことのないペイロードは、設計上このチェックに失敗し、Defenderのエンジンが沈黙していても強制的にブロックされます。
重要なのは、SmartScreenとMDEが独立した制御機構であるという点です。Defenderからは見えないペイロードであっても、MotWが付与されており、かつエクスプローラーからシェル経由で実行される場合には、完全に阻止される可能性があります。
逆に、PowerShellから直接呼び出す場合や、MotWが付与されないパスから実行する場合には、SmartScreenを完全に回避できてしまいます。つまり、実行のコンテキストによって、どちらの制御機構が実際に作動するかが決まるのです。
現行のWindows 11ビルドでは、Microsoftは過去に存在したMotWの隙間をいくつか塞いでいます。エクスプローラー標準のZIP処理機能は、パスワード保護されたアーカイブから展開したバイナリにもMotWを伝播するようになりました。またISOのマウント処理も強化され、コンテナの境界を越える際にZone識別子タグが日常的に剥ぎ取られることはなくなりました。
Chromiumベースの最新ブラウザ(Chrome、Edge、Brave)およびFirefoxは、blob:/data: URLの再構築を含め、ダウンロード時にすべてMotWを書き込みます。HTMLスマグリングは依然として主に境界防御を回避する手法であり、エンドポイント上のMotW回避手段ではありません。
Edgeはさらに一歩進んで、SmartScreenをダウンロード処理そのものに組み込んでおり、防御側に実行前の判断ポイントを追加で提供しています。
しかし、サードパーティ製のアーカイブツールは依然として弱点として残っています。7-Zipは長年にわたり、デフォルトではMotWの伝播に一切対応してきませんでした。
7-Zipのデフォルト設定
Attackdの研究者らが明らかにしたところによると、7-ZipはMotWの処理をオプトイン機能(「Zone.Idストリームを伝播する」)としてのみ提供しており、デフォルトでは「いいえ」に設定されています。そのため展開されたファイルはインターネット由来を示すフラグを失い、SmartScreenのレピュテーションチェックを回避してしまいます。
さらに最近では、この問題は単なる設定上の癖から悪用可能な脆弱性へと格上げされました。CVE-2025-0411は、MotWが付与された外側のアーカイブの中に、MotWなしで中身が展開されてしまう内側のアーカイブが含まれるというネストされたアーカイブのシナリオを説明するもので、攻撃者が用意した実行ファイルがSmartScreenの警告なしに実行できてしまいます。
ソフトウェア脆弱性データベース
ネストされたアーカイブに関する問題を修正した24.09以降でも、追加のMotW処理に関するバグが報告されています。
CVE-2026-58052が示すところによれば、26.02までの7-Zipは、細工されたRAR5アーカイブを展開する際にMotWを維持できないことがあり、NTFSストリームの正規化処理を通じてZoneId=3を事実上ZoneId=0で上書きしてしまいます。これによりファイルの内容を偽装しつつ、SmartScreen/MotWの警告を無効化できてしまいます。
実務的な観点で言えば、脆弱なバージョンや設定不備のある7-Zipが動作している環境はどこであっても、アーカイブの展開を通じてSmartScreenを確実に回避できる経路が存在することになります。特に7-Zipが広く導入されている開発者中心の技術系組織では、その傾向が顕著です。
SmartScreenの判定ロジックは単純です。ファイルにMotWが付与されており、シェル経由で起動された場合、SmartScreenはそのファイルが信頼できる発行元によって署名されているか、またそのファイルハッシュがMicrosoftのテレメトリにおいて肯定的なレピュテーションを確立しているかを確認します。
従来、拡張検証(EV)コード署名証明書を使えば、SmartScreenのレピュテーションを即座に獲得できました。EV署名済みのインストーラーであれば、初回ダウンロード時の警告をスキップできていたのです。
しかし、この近道はもはや存在しません。2024年にMicrosoftのTrusted Root Programに加えられた変更により、EV専用のOIDが撤廃されました。現行のドキュメントによれば、EV証明書とOV証明書は、クリーンなダウンロード実績と一貫した署名を通じて、同じ方法でレピュテーションを構築することになっています。
防御側やソフトウェア発行元にとって、これはコード署名が身元保証や長期的な信頼性の確保において依然として不可欠であることを意味しますが、初日からSmartScreenの回避を保証するものではもはやなくなったということでもあります。
攻撃者にとって、正規の証明書を購入することは今なお意味のある障壁であり、CVE-2013-3900(WinVerifyTrustの証明書パディング)のようなエッジケースを悪用するには、さらなる高度な技術と環境固有の回避策が必要になります。
今回紹介した侵入テストは、重要な現実を浮き彫りにしました。SmartScreenは、署名されておらずブラウザ経由で配信されるペイロードに対して有効であり、しばしば過小評価されている制御機構であるということです。したがって、これを「回避された」ではなく「阻止された」と記録するのが正確な評価だと言えます。
EDRの回避だけでは実行が保証されるわけではありません。MotWとSmartScreenは、しばしば最後の防衛線としての役割を果たします。
防御側にとって、取るべき対策は明確です。まず、Edgeおよびそれ以外の環境を含め、実際に使用しているOSとブラウザの組み合わせでSmartScreenの挙動をテストし、自組織の送信ポリシーの下でクラウドレピュテーションチェックがフェイルオープンになるかフェイルクローズになるかを検証すべきです。
次に、サードパーティ製のアーカイバ、特に7-Zipの棚卸しを行い、パッチ済みビルド(ネストされたアーカイブの不具合には24.09以降、RAR5のMotW処理には26.03以降)へ更新するか、Zone.Idストリームを伝播する設定を強制すべきです。
最後に、SmartScreenを広範な制御群の中の一層として位置づけることが重要です。SmartScreenが作動するのは、MotWが付与されたファイルがシェル経由で実行される場合のみであり、社内共有フォルダ、USB、スクリプト経由のパスを通じて配信されるペイロードは、そもそもこの制御機構に一切触れることがありません。
2026年版Agentic SOC購入ガイドをぜひご活用ください――厳選8製品の徹底比較 – 2026年版購入ガイドをダウンロード
翻訳元: https://gbhackers.com/7-zip-default-setting/
