はじめに: WSL2が新たな隠れ蓑に
Windows Subsystem for Linux (WSL) は、Windows上での開発者の作業体験を大きく変革しました。しかし、その最新版であるWSL2は、仮想マシン (VM) モデルを採用しているため、攻撃者にとって強力な隠れ場所となっています。Hyper-V内で半隔離されたLinux環境を提供し、多くの場合、従来のエンドポイントセキュリティツール (EDR) によってほとんど監視されません。
WSL2が攻撃者に狙われる理由
レッドチームや実際の攻撃者は、監視の厳重なWindowsセッションから、検知されにくいLinuxエンクレーブへ移行するためにWSL2を利用しています。これにより、ツールを実行したり、ペイロードを配置したり、データや認証情報を窃取したりする際に、検知のリスクを最小限に抑えることができます。多くの開発者ワークステーションでは、WSLディストリビューション内に、保護されていないSSHキー、トークン、シェル設定ファイルや環境変数内の認証情報など、貴重な「お宝」が詰まっていることが少なくありません。
WindowsからWSLにアクセスする一般的な方法は、wsl.exeを直接呼び出すことですが、これは不審なコマンドラインとして検知される可能性のある痕跡を残します。Microsoftが提供するWslApi.dllを介したWslLaunch APIも、内部的にはwsl.exeを起動するため、同様のプロセス痕跡を残します。
よりステルスな攻撃手法
よりステルスで柔軟な操作を実現するため、研究者たちはWSL2のComponent Object Model (COM) インターフェースに着目しました。wslservice.idlファイルには、wsl.exeを起動せずにCOM経由でLinuxプロセスを開始できるCreateLxProcessのような低レベル機能が記述されています。これにより、「特徴的なwsl.exe子プロセス」を伴わずに実行することが可能になります。
COMインターフェースの課題と解決策
しかし、WSL2のCOMインターフェースは、CLSIDの再利用、引数の変更、vtableレイアウトのシフトなど、時間の経過とともにアグレッシブな変更が加えられており、不安定な状態でした。このため、古いWSLバージョンでクライアントビルドがマーシャリングの不一致によりクラッシュすることが頻繁に発生しました。
研究者たちはこの問題を解決するため、James ForshawのOleView.Netなどのツールを使用して、WslServiceProxyStub.dllからIDL定義を動的に再構築しました。内部のProxyFileList構造を解析することで、バージョンに正確なIDLを生成し、単一のBeacon Object File (BOF) 内で複数のインターフェースバリアントを実装しました。
実行時には、この「究極のWSL BOF」がレジストリ (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\MSI) からWSLバージョンを読み取り、対応するインターフェース実装を選択します。このCobalt Strike BOFは、明示的にwsl.exeを起動することなく、複数のWSL2バージョンにわたってCOM経由でWSL2インスタンスを列挙し、コマンドを実行できます。
防御側への教訓
防御側にとって、メッセージは明確です。WSL2を広く利用しているWindows環境は、ホストに密接に統合された、監視が不十分な実行環境を露出させています。セキュリティチームは、WSL2を攻撃対象領域の一部として扱う必要があります。これには以下の対策が含まれます。
wsl.exeの使用状況を監視する。- WSLファイルシステムを検査する。
- WSLサービスを標的とした不審なCOMアクティビティを監視する。
攻撃者はすでにWSL2をステルスな隠れ場所として利用しており、防御側はこれに早急に対応する必要があります。