攻撃者がWSL2を悪用し、Windowsシステム上で検知されずに活動

Windows Subsystem for Linux（WSL）は、Windows上の開発者体験を大きく変革しました。しかし同時に、攻撃者にとって強力な隠れ場所を静かに生み出してしまいました。

WSL2では、Microsoftは軽量な変換方式から、完全な仮想マシン（VM）モデルへ移行しました。このアーキテクチャ変更により、Hyper‑V内で動作する半分隔離されたLinux環境が提供され、従来のエンドポイントセキュリティツールでは監視されにくくなっています。

レッドチームや現実の攻撃者にとって、これは贈り物です。WSL2を備えたWindowsホストは、実質的に第2のOSを内包しており、プロセスの実行、ファイルへのアクセス、内部ネットワークへの到達が可能で、しかもEDRからの可視性がほとんど、あるいは全くないこともあります。

実際、オペレーターはこれを利用して、厳しく監視されているWindowsセッションからWSL2へピボットし、その隔離領域から自由に活動してきました。すなわち、ツールの実行、ペイロードのステージング、データや認証情報の収集を、検知リスクを最小限に抑えながら行えるのです。

多くの開発者ワークステーションでは、WSLディストリビューションに有用な戦利品が詰まっています。保護されていないSSH鍵、トークン、シェル設定ファイルや環境変数に含まれる認証情報、そして本番サービスにアクセスするスクリプトなどです。

攻撃者がWindows側でコード実行を得ると、WSL2はアクセスを深め、検知の痕跡を減らすための自然な次の一手になります。

WindowsのインプラントからWSLへ到達する最も分かりやすい方法は、Beacon Object File （BOF）などでCreateProcessをラップし、wsl.exeを直接呼び出すことです。

WSL2が攻撃者にとって魅力的な理由

これにより、オペレーターはC2エージェントから、選択したWSLディストリビューション内でコマンドを起動できます。この「怪しいWSLコマンド」方式は機能し、これまでほとんど検知されていませんが、不快なアーティファクトを残します。すなわち、ランダムなプロセスからwsl.exeを起動する不審なコマンドラインであり、検知が追いつけば防御側が容易に着目できるものです。

MicrosoftはWslApi.dllのWslLaunchを通じて、より“それらしく見える”APIを公開しており、WSL内での直接的なプログラム実行を提供しているように見えます。

しかし、そのDLLを逆コンパイルすると、WslLaunchはコマンド文字列を整形し、裏側でCreateProcessを介してwsl.exeを起動していることが分かります。

言い換えると、「公式」APIも、レッドチームがすでに行っていたのと同じことをしており、同じプロセスアーティファクトを残します。

このパターンに静的検知があまり存在しない可能性があるのは、多くの正当なアプリケーションがすでに同様の挙動をしているためだと説明できます。

よりステルス性が高く柔軟な方法を得るために、研究者はWSLサービスを支えるWSL2のComponent Object Model（COM）インターフェースに着目しました。

MicrosoftはWSLをオープンソース化しており、wslservice.idlファイルにはCreateLxProcessのような低レベル機能を公開するインターフェースが記載されています。これにより、wsl.exeを生成する代わりに、COM経由でLinuxプロセスを開始できます。

理論上は、BOFがCOMを直接利用してWSLインスタンスを列挙し、wsl.exeの子プロセスという分かりやすい痕跡を残さずにコマンドを実行できるはずです。

しかし実際には、COMレイヤーは厄介でした。WSL2のCOMインターフェースは、同じCLSIDを再利用しながら、時間とともに大きく変更されてきました。

引数が追加・削除され、関数が挿入・削除され、バージョン間でvtableレイアウトも変化しています。

現実世界での悪用

現行のIDLから作ったクライアントは最新のWSLビルドに対してしか動作せず、古いシステムではマーシャリングの不一致でクラッシュし、さらには誤ったメソッドを呼び出してしまうことさえありました。

これを解決するため、研究者はJames ForshawのOleView.Netを用い、各WSLリリースに同梱されるプロキシスタブDLL（WslServiceProxyStub.dll）からIDL定義を動的に再構築しました。

内部のProxyFileList構造を解析することで、バージョンに正確なIDLと、それに基づくヘッダーを生成し、インターフェースがどのように進化したかを整理し、単一のBOF内に複数のインターフェース派生を実装しました。

実行時に、BOFはレジストリ（HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\MSI）からWSLのバージョンを読み取り、対応するインターフェース実装を選択します。

その結果が「the one WSL BOF」です。これは、Cobalt StrikeのBOFで、wsl.exeを明示的に起動することなく、複数のWSL2バージョンにわたってCOM経由でWSL2インスタンスを列挙し、その内部でコマンドを実行できます。

コードは醜く条件分岐だらけで、将来のWSLリリースで再び互換性が壊れる可能性もありますが、WSL2をレッドチームにとって第一級のピボット機構へと変えます。

防御側にとっての教訓は明白です。WSL2を広く利用しているWindows環境は、ホストと密接に統合されながら監視が不十分な実行環境を露出させています。

セキュリティチームは、wsl.exeの利用監視、WSLファイルシステムの検査、WSLサービスを狙う不審なCOMアクティビティの監視などを含め、WSL2を攻撃対象領域の一部として扱い始めるべきです。

攻撃者はすでにWSL2をステルスな隠れ家として扱っています。防御側も追いつく必要があります。