Microsoft Defender for Endpoint WSLプラグインとは？影響範囲と展開時の注意点

WSLを開発端末で使っている組織では、Windows側だけをMicrosoft Defenderで保護していても、WSL2内のLinuxプロセスや通信が十分に見えていない可能性があります。結論から言うと、Microsoft Defender for Endpoint plug-in for Windows Subsystem for Linux（WSL）は、WSL2上で動くLinux環境のイベントをMicrosoft Defender for Endpointから可視化するためのプラグインです。

管理者が最初に確認すべきことは、対象端末がMicrosoft Defender for Endpoint Plan 2にオンボード済みか、WSLがWSL2かつバージョン2.0.7.0以上か、そしてプラグイン導入後にhealthcheck.exeで正常性を確認できるかです。加えて、このプラグインはWSL内のイベント可視化を強化するものであり、WSL論理デバイスに対してマルウェア対策、脅威と脆弱性の管理、応答コマンドなどの機能がすべて使えるわけではありません。ここを誤解すると、導入後の運用設計で抜けが出ます。(Microsoft Learn)

Microsoft Defenderのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント

Microsoft Defender for Endpoint plug-in for WSLの主な役割は、WSL2という分離されたLinux環境を、Microsoft Defender for Endpointの監視対象として見えるようにすることです。WSL2は仮想化技術で分離されたLinux環境として動作するため、Windowsホストだけを見ていても、WSL内のプロセス、ファイル操作、ネットワーク活動を十分に追えない場面があります。プラグインはこの隔たりを埋め、Microsoft Defenderポータル上でWSLインスタンスをLinuxデバイスとして扱えるようにします。(Microsoft Learn)

ただし、これは「WSL内に通常のLinux版Defenderをそのまま入れる」という話ではありません。Windowsホストにプラグインを導入し、ホストがオンボードされているDefender for EndpointテナントへWSL側も自動的に関連付けられる仕組みです。公式情報では、WslServiceが実行中の場合、インストール時に停止されることも明記されています。開発者が作業中の端末へ一斉展開する場合は、WSLセッションの中断を前提に展開時間を決める必要があります。(Microsoft Learn)

対象になる環境と対象外になる環境

導入対象は、Microsoft Defender for Endpoint Plan 2を利用し、WindowsクライアントデバイスがDefender for Endpointにオンボード済みの環境です。OSはWindows 10 バージョン2004以降、かつビルド19044以降、または対応するWSLバージョンを実行できるWindows 11が前提です。WSLについては、WSLバージョン2.0.7.0以上で、少なくとも1つのアクティブなディストリビューションが必要です。(Microsoft Learn)

確認項目	判断基準	対応の目安
Defenderライセンス	Microsoft Defender for Endpoint Plan 2	対象ライセンスがない端末は展開対象から除外
Windowsホスト	Defender for Endpointへオンボード済み	先にWindowsホスト側のオンボーディングを完了
WSLバージョン	2.0.7.0以上	wsl --updateで更新
WSL種別	WSL2	WSL1は変換または無効化を検討
CPU	x64環境	ARM64端末は対象外
Windows形態	通常のWindows 10/11クライアント	マルチセッション版は対象外

注意したいのは、ARM64プロセッサ搭載端末とWindows 10/11のマルチセッション版がサポート対象外である点です。また、カスタムカーネルやカスタムカーネルコマンドラインを使っている場合、プラグインは実行自体をブロックしませんが、WSL内の可視性は保証されません。開発者が独自カーネルを使う機械学習、低レイヤー検証、特殊なネットワーク検証環境では、セキュリティ標準と開発要件を事前にすり合わせる必要があります。(Microsoft Learn)

今回のポイントは「導入」だけでなく「更新」と「運用」まで見ること

Microsoft Defender for Endpoint plug-in for WSLは、入れて終わりのプラグインではありません。Microsoftのサポート情報では、このプラグインは新機能をサポートするために年に複数回更新が必要とされています。また、同じKB番号5037621で定期的にリリースされ、記事側が最新のプラグインバージョンで更新されると説明されています。(マイクロソフトサポート)

更新管理で特に重要なのは、プラグインのバージョンです。公式ドキュメントでは、1.24.522.2より前のバージョンは自動更新をサポートしないとされています。1.24.522.2以降はWindows Update経由の更新がサポートされますが、WSUS、SCCM、Microsoft Update Catalogを使う更新は、パッケージ安定性の観点からProductionリングのみがサポート対象です。(Microsoft Learn)

状況	管理者が取るべき対応
新規導入	Microsoft Defenderポータルのオンボーディング画面からMSIを取得し、検証端末で先行導入
既存プラグインが1.24.522.2未満	自動更新に頼らず、更新計画を立てて明示的に更新
Windows Update運用	リングごとの配布タイミングを確認し、検証リングから展開
WSUS／SCCM運用	Productionリング前提で配布設計を確認
バージョン確認	healthcheck.exeでプラグイン、WSL、Defenderのバージョンを確認

サポート情報では、バージョン1.24.605.1以降、今後のプラグイン更新をWindows Updateで手動介入なしに適用できるようになると説明されています。更新の自動化が進む一方で、セキュリティ運用チームは「どの端末に、どのバージョンが入っているか」を可視化しておく必要があります。(マイクロソフトサポート)

展開前に実施すべきチェックリスト

プラグイン展開前には、端末単位で最低限の状態確認を行います。特にWSLは開発者が個別に導入・設定していることが多いため、資産管理ツールの情報だけでは実態を把握しきれません。

wsl --version
wsl -l -v

wsl --versionでWSL本体のバージョンを確認し、wsl -l -vで各ディストリビューションがWSL2として動いているかを見ます。WSLバージョンが古い場合は、次のコマンドで更新します。

wsl --update

公式ドキュメントでは、wsl --versionで2.0.7.0より古いバージョンが表示される場合、wsl --update --pre-releaseで最新更新を取得する手順も示されています。ただし、本番端末へpre-releaseを広く適用するかは、組織の更新ポリシーに合わせて判断してください。検証端末で互換性を確認してから展開するのが安全です。(Microsoft Learn)

WSL1を使っているディストリビューションがある場合は、WSL2への移行を検討します。公式ドキュメントでは、WSL2で実行されているLinuxディストリビューションがサポート対象であり、WSL1に関連付けられている場合は問題が発生する可能性があるため、WSL1の無効化が推奨されています。(Microsoft Learn)

wsl --set-version <YourDistroName> 2
wsl --set-default-version 2

開発者のローカル環境では、WSL1前提の古いスクリプトやネットワーク挙動に依存していることがあります。移行前にwsl --exportでディストリビューションをバックアップし、主要な開発フロー、ビルド、Docker連携、プロキシ接続を確認してから移行することをおすすめします。

Intuneで制御すべきWSL設定

企業環境では、WSLを個人任せにせず、Intuneの設定カタログで制御することが重要です。MicrosoftはIntuneなどの管理ツールを使って、WindowsコンポーネントとしてWSLを管理できると説明しています。Intune管理センターで「Windows Subsystem for Linux」を検索すると、WSL関連の設定を追加できます。(Microsoft Learn)

特に確認すべき設定は次のとおりです。

設定	推奨判断	理由
WSL1を許可する	無効化を検討	WSL2のみを利用させ、プラグイン対象を明確にするため
カスタムカーネル構成を許可する	原則無効	プラグインの可視性が保証されない構成を避けるため
カーネルコマンドライン構成を許可する	原則無効	セキュリティ監視の抜け道を減らすため
デバッグシェルを許可する	必要な管理者に限定	調査用途以外での乱用を防ぐため
カスタムネットワーク構成を許可する	開発要件に応じて制御	プロキシ、DNS、接続テストへの影響を抑えるため

Intuneの推奨設定では、エンタープライズ環境でセキュリティを最大化するために、WSL1、デバッグシェル、カスタムカーネル構成、カーネルコマンドライン構成などを無効化する設定が示されています。開発者向け端末では例外が必要になることもありますが、例外はユーザー単位ではなく、用途・期間・責任者を明確にして管理するべきです。(Microsoft Learn)

インストール手順と検証方法

新規導入では、Microsoft Defenderポータルのオンボーディング画面からWSL2プラグインのMSIを取得します。公式ドキュメントでは、DefenderPlugin-x64-0.24.426.1.msiというインストーラー名が記載されており、Microsoft Defenderポータルの「Settings > Endpoints > Onboarding」からダウンロードできるとされています。実際の配布時は、ポータル上で提供される最新パッケージを確認してください。(Microsoft Learn)

インストール後は、すぐに成功と判断せず、少なくとも5分待ってからhealthcheck.exeを実行します。

cd "%ProgramFiles%\Microsoft Defender for Endpoint plug-in for WSL\tools"
.\healthcheck.exe

確認すべき項目は、プラグインバージョン、WSLバージョン、Defenderアプリバージョン、正常性状態です。公式ドキュメントでは、プラグインバージョン1.24.522.2、WSLバージョン2.0.7.0以上、Defenderアプリバージョン101.24032.0007、Defender Health StatusがHealthyであることが検証目安として示されています。(Microsoft Learn)

展開後に見落としやすいのは、「WSLを起動していない端末」です。プラグインの状態確認やポータル反映には、少なくとも1つのディストリビューションが起動している必要があります。検証時は次のようにWSLを起動してから待機します。

wsl

その後、Microsoft DefenderポータルのデバイスビューでWSL2タグを使ってフィルターします。プラグインが有効なWSLインスタンスは、Windowsホストと同じホスト名を持ちながら、Linuxデバイスとして表示されます。(Microsoft Learn)

プロキシ環境で注意すべき設定

企業ネットワークでは、プラグインの導入よりもプロキシ設定でつまずくことがあります。公式ドキュメントでは、ホスト側のWindows EDRテレメトリプロキシ、WinHTTPプロキシ、ネットワークとインターネットのプロキシ設定を、WSL用プラグインが自動的に採用すると説明されています。(Microsoft Learn)

複数のプロキシ設定がある場合、選択順位は次の順です。

優先順位	プロキシ設定
1	Defender for Endpoint静的プロキシ設定 TelemetryProxyServer
2	netshで構成されたWinHTTPプロキシ
3	ネットワークとインターネットのプロキシ設定

ここで重要なのは、WSL Defenderがサポートするのはhttpプロキシのみである点です。また、DefenderProxyServerレジストリキーはサポートされなくなっています。古い手順書を流用している組織では、展開前にプロキシ設定手順を見直してください。(Microsoft Learn)

接続テストは、プロキシ変更時と1時間ごとのスケジュールで実行されます。WSL起動後に5分待ってhealthcheck.exeを実行し、接続テストがinvalidになる場合は、まず次のコマンドでプロキシ情報を確認します。(Microsoft Learn)

healthCheck --extendedProxy

それでも解決しない場合、公式ドキュメントでは.wslconfigに次の設定を追加する手順が示されています。Windows 11では次の設定です。

[wsl2]
dnsTunneling=true
networkingMode=mirrored

Windows 10では次の設定です。

[wsl2]
dnsProxy=false

.wslconfigの変更後はWSLを再起動します。ネットワーク設定は開発環境の通信にも影響するため、プロキシ必須環境では、開発者のビルド、パッケージ取得、Git操作、コンテナ通信まで確認してから本番展開してください。

SOCと管理者が見るべきMicrosoft Defenderポータル上の変化

プラグイン導入後、Microsoft DefenderポータルではWSLインスタンスをWSL2タグで絞り込めます。デバイスページの概要には、そのWSLデバイスがどのWindowsホスト上で動いているかを示すリンクがあり、そこからホスト側の調査や対応へ移れます。タイムラインには、WSLサブシステム内のファイル、プロセス、ネットワークイベントが表示され、必要に応じてアラートやインシデントも生成されます。(Microsoft Learn)

SOC運用では、WindowsホストとWSL論理デバイスを別物として扱いすぎないことが重要です。攻撃者がWindowsホストからWSLへ移動した場合、ポータル上ではLinuxデバイスのイベントとして見える可能性があります。逆に、WSL内のイベントだけを見ていても、元のWindowsホスト上のユーザー、端末、プロセス起点を見落とすことがあります。

Advanced Huntingでは、DeviceInfoテーブルのHostDeviceIdを使うことで、WSLインスタンスとWindowsホストを対応付けられます。(Microsoft Learn)

DeviceInfo
| where OSPlatform == "Linux" and isnotempty(HostDeviceId)
| distinct WSLDeviceId=DeviceId, HostDeviceId

WSL内でcurlやwgetが実行された端末を確認したい場合は、次のようなクエリが使えます。

let wsl_endpoints = DeviceInfo
| where OSPlatform == "Linux" and isnotempty(HostDeviceId)
| distinct DeviceId;
DeviceProcessEvents
| where FileName == "curl" or FileName == "wget"
| where DeviceId in (wsl_endpoints)
| sort by Timestamp desc

このクエリは、開発作業で普通に使われる通信と、不審なダウンロードを切り分ける出発点になります。実務では、利用者、実行パス、コマンドライン、通信先、直前の親プロセスをあわせて確認してください。

カスタムタグを使った運用設計

プラグインは既定でWSLマシンにWSL2タグを付けてオンボードします。組織独自の分類が必要な場合は、レジストリでカスタムタグを設定できます。公式ドキュメントでは、HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging配下にGROUPというREG_SZ値を作成し、値にカスタムタグを指定する手順が示されています。(Microsoft Learn)

Name: GROUP
Type: REG_SZ
Value: Custom tag
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging

設定後は次のコマンドでWSLを再起動します。

wsl --shutdown
wsl

注意点として、設定したカスタムタグには_WSL2が後ろに付きます。たとえば値をDevTeamAにした場合、ポータル上ではDevTeamA_WSL2のように表示されます。タグ設計をするときは、Windowsホスト側のタグとWSL側のタグが混同されない命名規則にしておくと、インシデント調査時に迷いにくくなります。(Microsoft Learn)

開発者への影響と事前に伝えるべきこと

開発者にとって最大の影響は、WSLが「個人のローカル開発環境」から「組織の監視対象」に変わることです。セキュリティ上は望ましい変化ですが、展開の伝え方を間違えると、開発者が勝手に設定を戻したり、別環境へ逃がしたりする原因になります。

展開前に伝えるべきポイントは次の3つです。

開発者へ伝える内容	理由
インストール中にWSLサービスが停止する可能性がある	作業中のビルドやシェルセッションが影響を受けるため
カスタムカーネルや特殊な.wslconfigは制限される可能性がある	可視性が保証されない構成を避けるため
WSL内の不審なプロセスや通信はDefenderで検出・調査対象になる	監視範囲を透明に説明し、不要な不信感を避けるため

特に、.wslconfigでネットワーク、カーネル、systemd関連の設定を変更している開発者は少なくありません。セキュリティ部門が一方的にブロックすると、ビルド環境やコンテナ実行環境が壊れることがあります。Intuneで制御する場合は、標準ポリシー、例外ポリシー、例外期限を分けて設計すると現場運用が安定します。

よくある失敗とトラブルシューティング

プラグイン導入で多い失敗は、インストール成功だけを見て、ポータル反映やイベント取得まで確認しないことです。公式ドキュメントでは、プラグインの初期化に数分、WSL2インスタンスのオンボーディングに最大30分かかる場合があり、短時間だけ動くWSLコンテナーではMicrosoft Defenderポータルに表示されない可能性があると説明されています。(Microsoft Learn)

症状	主な原因	対応
ポータルにWSLデバイスが出ない	起動時間不足、フィルター誤り、権限不足	WSL2タグで絞り込み、権限と反映時間を確認
タイムラインにイベントが出ない	WSLが起動していない、初期化待ち	wslを実行し、5分以上待って再確認
healthcheck.exeでbash起動を求められる	WSLディストリビューション未起動	ターミナルでwslを実行し、5分後に再実行
Waiting for Telemetryと表示される	テレメトリ待機中	5分待って再実行
接続テストがinvalid	プロキシ、DNS、ネットワーク設定の問題	healthCheck --extendedProxyと.wslconfigを確認
ERROR_FILE_NOT_FOUND	プラグインのインストール不備	コントロールパネルからプラグインを修復

WSL起動時にA fatal error was returned by plugin 'DefenderforEndpointPlug-in' Error code: Wsl/Service/CreateInstance/CreateVm/Plugin/ERROR_FILE_NOT_FOUNDのようなエラーが出る場合、公式ドキュメントでは、コントロールパネルの「プログラムと機能」からMicrosoft Defender for Endpoint plug-in for WSLを選び、修復する手順が示されています。(Microsoft Learn)

解決しない場合は、サポートバンドルを取得します。

cd "%ProgramFiles%\Microsoft Defender for Endpoint plug-in for WSL\tools"
.\healthcheck.exe --supportBundle

ネットワーク問題が続く場合は、管理者権限のPowerShellでネットワークログを収集し、wsl --debug-shellからmdatp connectivity testを実行する手順も公式ドキュメントに示されています。運用手順書には、サポートへ渡すログの取得方法まで含めておくと、障害対応が早くなります。(Microsoft Learn)

導入判断の基準

Microsoft Defender for Endpoint plug-in for WSLは、すべてのWindows端末へ無条件に入れるというより、WSL2を使う開発端末や検証端末を中心に優先展開するのが現実的です。特に次の条件に当てはまる環境では、早めに導入計画を立てる価値があります。

優先度	対象環境	理由
高	開発者端末でWSL2を日常利用	コード取得、ビルド、外部通信が多く、攻撃面が広い
高	管理者やSREがWSL2でツールを実行	権限の高い操作とLinuxツールが交差するため
中	研修・検証用端末	一時的なツール導入が多く、可視性が必要
低	WSL未使用の一般事務端末	まずWSL利用有無の把握を優先

導入しない場合でも、WSLを許可しているなら、少なくともWSL1の禁止、カスタムカーネル制御、プロキシ設定、利用端末の棚卸しは進めるべきです。WSLは便利な開発基盤ですが、管理されないLinux環境として放置すると、Windows側のEDR運用だけでは調査しにくい領域になります。

まず取るべき次のアクション

最初にやるべきことは、WSL利用端末の棚卸しです。wsl -l -vや端末管理ツールでWSL2利用端末を把握し、Defender for Endpointへオンボード済みかを確認します。次に、検証端末へMicrosoft Defender for Endpoint plug-in for WSLを導入し、healthcheck.exeで正常性、プロキシ接続、Microsoft Defenderポータル上のWSL2タグ表示、Advanced HuntingでのHostDeviceId確認まで行います。

本番展開では、開発者への事前告知、WSL1からWSL2への移行方針、IntuneでのWSL制御、更新リング、トラブル時のサポートバンドル取得手順をセットで整備してください。プラグインは単なる追加コンポーネントではなく、WSLを組織のエンドポイントセキュリティ運用に組み込むための入口です。