LOLBins – MSBuild を活用した攻撃手法の分析

概要

最近、サイバー攻撃者はシステムに標準搭載された正規バイナリ (LOLBins、Living Off the Land Binaries) を悪用し、セキュリティ製品の検知を回避する攻撃を継続的に試みている。この攻撃手法は、別途の悪意のある実行ファイルを配布することなく、OS が信頼するツールをそのまま使用するという点で、従来のシグネチャベースの検知を効果的に回避する。
その中でも MSBuild.exe は、Microsoft が署名した Windows 標準の開発ツールであり、XML ベースのプロジェクトファイルを通じて C# コードをビルドおよび実行できる。攻撃者はこの特性を悪用し、悪意あるコードをディスク上に明示的に残すことなく任意のコードを実行し、侵入後の段階で密かに追加動作を行う。
本稿では、MSBuild を活用した攻撃手法の動作原理と実際の攻撃事例を検証し、対応策を提示する。

攻撃者が MSBuild を好む理由

MSBuild はもともと開発環境を支援するための正規ツールだが、攻撃者の観点からは以下の理由により、LOLBins 攻撃に非常に適している。
第一に、プロジェクトファイル内にインライン形式で C# コードを挿入して実行できる。これにより攻撃者は、別途コンパイルされた悪意のある実行ファイルなしでも悪意のある動作を実行できる。つまり、柔軟なペイロード構成とファイルレス (fileless) 攻撃が可能となる。
第二に、多様な機能拡張性を持つ。ファイルのロード、ネットワーク通信、バイナリのビルドおよび実行など、攻撃に必要な主要機能をすべて内包しており、さまざまな目的での悪用が可能である。
第三に、MSBuild は Microsoft のデジタル署名が適用された正規バイナリである。MSBuild.exe は信頼されたシステムコンポーネントとして認識されるため、単純な実行有無だけでは悪用の判断が難しい。つまり、コード署名検証を回避する効果が得られる。

MSBuild を利用した検知回避攻撃手法

2025年1月、Michał Walkowski のブログにて、MSBuild を活用した Windows 11 Defender の検知回避手法が紹介された。これを受け、当該手法が実際の環境でも同様に機能するか、そして実際にセキュリティソリューションの検知を回避できるかを直接検証した。
Windows に標準搭載された MSBuild.exe を悪用するために必要なのは、プロジェクトファイルと C# ソースファイルの2つだけである。そこに攻撃者の意図に応じて難読化されたペイロードやシェルコードを追加し、攻撃をさらに高度化することも可能だ。
攻撃者が用意した main.csproj には、main.cs をコンパイルして main.exe を生成し実行する設定が含まれており、main.cs は攻撃者 PC との TCP リバースシェルを接続するシェルコードをロード後に実行するよう構成されている。

プロジェクトファイルである main.csproj ファイルを引数として MSBuild を実行すると、攻撃者サーバーへリバースシェルが接続される。

ここで特に注目すべき点は、MSBuild.exe を利用してリバースシェルを接続する過程において、被害者 PC の Windows 11 Defender のリアルタイム監視が有効な状態であるにもかかわらず、遮断や警告が一切発生しなかったという点である。攻撃者はこの方法により Windows Defender やエンドポイントセキュリティ製品の検知を回避し、リバースシェル接続のような悪意のある動作をそのまま実行できる。

実際の攻撃事例 : MSBuild ダウンローダーと DLL サイドローディング

2026年2月、Lab52 のブログにて MSBuild.exe を活用した攻撃キャンペーンが公開された。先述した直接ビルドして実行する方式とは異なり、この事例では MSBuild.exe が外部 C2 サーバーから悪意のあるペイロードを取得するダウンローダーの役割を果たしていた。
攻撃はフィッシングメールから始まる。

攻撃者は会議の招待状や業務関連文書に偽装した圧縮ファイルをメールに添付して送付し、圧縮ファイル内には正規署名が含まれた実行ファイルとプロジェクトファイルが同梱されていた。特に実行ファイルは、Microsoft 署名が適用された MSBuild.exe のファイル名を文書ファイルのように見せかけることで、ユーザーの警戒心を最小限に抑えていた。

ユーザーが警戒なく当該実行ファイルをクリックすると、攻撃は直ちに次の段階へと移行する。MSBuild のデフォルト動作の特性上、実行ファイルと同一パスに存在するプロジェクトファイル (.csproj) が自動的に検索され、別途コマンドライン引数なしにロードされる。この過程はユーザーが認識しにくいレベルで自然に行われ、結果として攻撃者が意図したプロジェクトファイルが MSBuild によって実行される。
問題のプロジェクトファイル内部にはインライン形式の C# スクリプトが含まれている。当該スクリプトは外部の攻撃者サーバーと通信し、追加ファイルをダウンロードする役割を担う。このときダウンロードされるファイルは一時フォルダーのようにユーザーが頻繁にアクセスしないパスに保存され、ファイル名もランダムな文字列を使用することで手動分析をさらに困難にしている。

[コード 1] C# インラインスクリプト

ダウンロード完了後、MSBuild はその中の最初の実行ファイルを自動的に実行する。この実行ファイルもまた正規署名が含まれたプログラムに偽装されているため、実行だけでは悪意のある動作と判断しにくい。しかし攻撃者は、この正規実行ファイルが動作する過程で同一ディレクトリに存在する DLL を一緒にロードするという点を悪用した。同時にダウンロードされた悪意のある DLL がこのタイミングでメモリにロードされ、攻撃者は最終的にマルウェアの実行に成功する。
一連の攻撃フローにおいて、MSBuild.exe、正規署名された実行ファイル、そしてユーザーによる直接実行行為が組み合わさった構造は、セキュリティソリューションとユーザーの双方にとって正常な動作に見えざるを得ない。その結果、攻撃者は追加ペイロードの実行や後続の侵入行為を比較的自由に行える足がかりを確保することになる。
この事例は、MSBuild のような正規開発ツールが攻撃者にとっていかに効果的な LOLBins ツールとして活用されうるかを示している。単に「正規ファイルかどうか」だけでは攻撃を識別することが難しく、プロセス間の関係、実行コンテキスト、ファイルの生成およびロードの流れを総合的に分析しなければ検知が非常に困難であることを示唆している。

攻撃への対応策

MSBuild ベースの攻撃は単一の IoC だけでは検知が難しいため、動作とコンテキストを中心とした多層検知戦略が必要である。
まず、プロセス動作ベースのモニタリングが重要である。Outlook、Web ブラウザ、ダウンロードパスなど非開発環境で MSBuild.exe が実行される場合や、MSBuild.exe が PowerShell・cmd.exe のような子プロセスを生成する動作は、疑わしい対象として分類すべきである。
また、プロジェクトファイルの実行行為に対する可視性の確保が必要である。一般ユーザー環境で .csproj または .xml ファイルが実行されるケースは極めてまれであり、特に解凍直後または %Temp% パスから実行される場合は攻撃シナリオとの高い関連性を持つ。
ネットワーク面では、MSBuild.exe の外部通信の有無、短時間内における多数ファイルのダウンロード、乱数ベースのファイル名生成などの動作を合わせて分析すべきである。さらに、正規署名された実行ファイルが不正な DLL をロードする DLL サイドローディングのパターンも主要な検知ポイントとなる。

まとめ

MSBuild は Windows 環境において信頼された正規バイナリだが、攻撃者にとっては強力な LOLBins ツールとして悪用される可能性がある。インラインスクリプトの実行、プロジェクトの自動ロード、DLL サイドローディングといった機能は、攻撃者の隠ぺい性を大きく高める。

したがって、「正規プロセスは安全である」という認識から脱却し、プロセス間の関係、実行コンテキスト、ネットワーク動作などビヘイビアベースの検知戦略を強化する必要がある。MSBuild を含む LOLBins 攻撃は今後もさまざまな形で変化する可能性が高いため、継続的な脅威ハンティングによる先手を打ったセキュリティ対策とポリシー的な統制が求められる。