DLLサイドローディング

従来の脆弱性悪用とは異なり、DLLサイドローディングはソフトウェアのバグではなく、Windowsのアーキテクチャ上の仕様を逆手に取ったものである^[3]。攻撃者がDLLを読み込むときの性質を利用し、悪意のあるDLLを「サイド（横）」に置くことで実行させるため、この名前がある^[2]。攻撃者が実行環境を完全に制御（パッケージ化）して送り込むため、成功率が極めて高い。そのため、パッチ適用による根本的な解決が難しく、永遠のゼロデイ脆弱性として存在する。例えば、2014年版のGUP.exeや古いMsMpEng.exeにサイドローディングの脆弱性が見つかったとしても、それらのバイナリは正規のデジタル署名を持っており、Windowsによって信頼され続ける。ベンダーが最新版で修正したとしても、攻撃者は古い脆弱なバージョンを持ち込むことで、いつでも攻撃を成功させることができる^[3]。このため、単なるパッチ適用だけでは防ぎきれない、構造的な課題となっている。

また検知が難しいのも特徴的である。DLLサイドローディングは、シグネチャ検知を回避するように設計されている。そのため、検知にはプロセスの親子関係、ロードされるモジュールの署名状態、およびファイルパスの異常性に着目したビヘイビア（ふるまい）検知のアプローチが必要となる。さらに、正規のアプリケーションが実行されているように見えるのも検知を難しくしている要因である。Windowsユーティリティなどの汎用的なアプリケーションだけでなく、特定の業務アプリケーションや、監視の目が届きにくいプロプライエタリな管理ツールのコンポーネントが悪用される事例が増加している^[6]。

サイドローディングのメカニズムは、広範囲に配布される正規ソフトウェアのアップデート機能などに悪意のあるライブラリを混入させる手段としても利用される。正規の更新プロセスの中でサイドローディングが行われる場合、検知は極めて困難になる。これは、ソフトウェアの依存関係（BOM: Bill of Materials）の管理と、サプライチェーン全体のセキュリティ検証の重要性を改めて浮き彫りにしている^[6]。

このような性質から、APT攻撃グループやランサムウェア攻撃者にとって有効な攻撃手段であり続けている^[4]。特に、日本の組織を標的とする攻撃キャンペーン（LODEINFO、MirrorFaceなど）においても主要な侵入・潜伏技術として悪用が確認されている^[5]。

Summarize Fact Check

DLLサイドローディングの本質を理解するためには、WindowsのPortable Executable（PE）ローダーの動作原理、Dynamic Link Libraryシステム、およびマニフェストファイルによる依存関係解決の仕組みを理解する必要がある。

DLLは、複数のプログラムが同時に使用できるコードとデータを含む共有ライブラリである。このモジュールアーキテクチャは、メモリ効率の向上、ディスク使用量の削減、およびコードの再利用性を促進するために設計された^[7]。アプリケーションが実行される際、依存するDLLをメモリにロードする方法には主に以下の2つが存在する。

• ロードタイムリンク: アプリケーションのビルド時に必要なDLLと関数がインポートアドレステーブル（IAT）に記述され、OSのローダーがプロセス起動時に自動的にDLLを検索してロードする。
• ランタイムリンク: アプリケーション実行中に、LoadLibraryやLoadLibraryExなどのAPIを使用して、必要なタイミングで動的にDLLをロードする^[7]。

このどちらの方式であっても、プログラムがDLLを呼び出す際に『C:\Windows\System32\example.dll』のようなフルパス（絶対パス）を指定せず、単にファイル名だけで読み込みを要求するケースが一般的である。この点が、サイドローディングを含むハイジャック攻撃の根本的な原因となる。

アプリケーションがDLLをロードする際、フルパスが指定されていない場合、Windowsローダーは定義された検索順序に従ってファイルを探す。この挙動がサイドローディング攻撃の悪用ポイントとなる。

現代のWindowsシステムにおいて「Safe DLL Search Mode（安全なDLL検索モード）」が有効になっている場合、標準的な検索順序は以下の通りである^[8]。

1. アプリケーションがロードされたディレクトリ - 攻撃において最も重要な場所である。正規のアプリケーションと同じフォルダ（横＝サイド）にDLLを置くだけで、システムディレクトリ（2番目以降）にある正規DLLよりも優先して読み込まれてしまう。これが「サイドローディング」が成立する最大の理由である。
2. システムディレクトリ - 通常は C:\Windows\System32。正規のDLLが存在する場所。
3. 16ビットシステムディレクトリ - レガシー互換性のためのディレクトリ。
4. Windowsディレクトリ - 通常は C:\Windows。
5. カレントディレクトリ - Safe DLL Search Mode有効時は順位が下がるが、無効時は2番目に検索されるリスクがある。
6. PATH環境変数に記載されたディレクトリ - ユーザーまたはシステムが設定したパス。

攻撃者は、正規のシステムDLL（例: userenv.dll, version.dll, mpclient.dll）と同じ名前の悪意のあるDLLを作成し、それを標的となる正規アプリケーションと同じディレクトリに配置する^[1]。Windowsローダーの仕様上、アプリケーションがロードされたディレクトリはシステムディレクトリ（System32）よりも優先順位が高いため、正規のアプリケーションはSystem32内の本物のDLLではなく、攻撃者が配置した偽のDLLを誤ってロードしてしまう。これにより、信頼されたプロセスのメモリ空間内で攻撃者のコードが実行されることになる^[1]。

本来、Windowsには『マニフェスト』という仕組みがあり、特定のバージョンのDLLを強制的に読み込ませることで、勝手なDLLの置き換え（DLL Hellやサイドローディング）を防ぐ機能が存在する^[3]。しかし、このマニフェストの設定が不十分なアプリケーションを標的である場合、攻撃者は、この防御をすり抜けることができる。

マニフェストは、アプリケーションが依存するDLLの正確なバージョンや構成を記述したファイルであり、アプリケーションに埋め込まれるか、外部XMLファイル（.manifest）として存在し、使用すべきDLLのバージョンや場所を指定する^[9]。このとき、 マニフェストがライブラリのファイル名のみを指定し、フルパスや署名情報を含まない場合、それは「弱い参照」と見なされる^[10]。攻撃者はこの弱い参照を悪用する。System32に正規のDLLが存在していても、マニフェストがシステムバージョンへのバインディングを強制していない場合、ローカルディレクトリのDLLが優先される^[4]。このように、マニフェストが存在していても、フルパスや署名情報を含まない設定がある場合、悪意のあるDLLをロードさせることができる。

開発者は「DLLリダイレクション」という機能を使用して、アプリケーションごとのDLL構成を強制することができる。例えば、Editor.exeというアプリケーションに対してEditor.exe.localというファイルまたはフォルダを作成することで、OSに対して、System32よりも特定のローカルディレクトリを探すことを指示することが可能である（ただし、Windows XP以降ではマニフェストの使用が推奨されている）^[11]。

攻撃の文脈では、正規のアプリケーションにマニフェストが存在しない、あるいはマニフェスト設定が不十分な場合、攻撃者は特権的な配置を行わずに任意のDLLをロードさせることが可能になる。特に、XML構造において<file>要素や<dependency>要素で絶対パス指定やハッシュ検証が行われていないケースが狙われる^[9]。

実行フローの詳細は以下の通りである。

• 起動: 被害者がフィッシングメールの添付ファイルやUSBメモリ内のショートカットをクリックし、正規の実行ファイルを起動する^[1]。
• ロード: 正規の実行ファイルは、自身のディレクトリにある偽のDLL（hex.dll）を、正規のライブラリと誤認してロードする。
• 復号と展開: ロードされた悪意のあるDLLは、初期化処理（DllMainなど）の中で、同じディレクトリにある暗号化されたペイロードファイル（adobeupdate.dat）を読み込み、メモリ上で復号する。
• 実行: 復号されたマルウェアが、正規プロセスのメモリ空間内で実行される。この際、ファイルシステム上に実行形式（.exe）のマルウェアが作成されることはない^[4]。

サイドローディングの最大の利点は、既存のセキュリティ制御を回避できる点にある。「MicrosoftやAdobeによって署名されたバイナリ」の実行を許可する設定になっている場合、ホストプロセスは正規の署名を持っているため、実行が許可されてしまう^[1]。また、 外部へのネットワーク通信や不審なAPIコールが、信頼されたプロセス（例: Outlook.exeやTeams.exe、MsMpEng.exe）から発生しているように見えるため、ファイアウォールのルールをすり抜けたり、SOCアナリストの調査において誤検知と判断されたりする可能性が高い^[12]。

• DLL検索順序ハイジャック - 被害者のシステムに既にインストールされているアプリケーションを標的とする。アプリケーションがDLLをロードする際のカレントディレクトリやPATH環境変数の検索順序を悪用し、上位のディレクトリに悪意のあるDLLを配置して読み込ませる^[6]。既存の環境に依存するため、成功するかどうかは被害者の環境設定やアプリケーションのインストール状況に左右される。
• ファントムDLLハイジャック - アプリケーションがロードしようとするものの、システム上には存在しない（欠落している）DLLを標的とする。古い依存関係や、特定の条件下でのみ使用されるDLLがこれに該当する^[6]。攻撃者は「存在しないはずのファイル」を正規の場所に配置することで、アプリケーションに読み込ませる。

DLLサイドローディングは、国家が支援するAPT攻撃グループから金銭目的のサイバー犯罪グループまで、幅広い攻撃者に採用されている。

JPCERT/CCおよびトレンドマイクロの分析によると、日本の組織を標的とする攻撃グループMirrorFaceは、独自のマルウェア「LODEINFO」や「NOOPDOOR」の展開にDLLサイドローディングを多用している^[5]。MirrorFaceは、正規のアプリケーションをWindowsのタスクスケジューラに登録して実行させ、サイドローディングによって悪意のあるDLL（NOOPLDR）を読み込ませる。ペイロードの復号には感染端末固有の情報（MachineIdやComputerName）を使用するため、サンドボックス環境や解析環境ではペイロードが動作しないという高度な解析妨害機能を備えている^[5]。

ロシア対外情報庁に関連するとされるAPT29は、極めて高い隠蔽性を維持するためにサイドローディングを利用する。Adobe Acrobatのコンポーネントなどの正規バイナリと共に、トロイの木馬化されたDLLを展開し、バックドア「WellMess」や「ToneShell」を実行する。署名付きバイナリを悪用することで、企業の厳格なセキュリティ監視網の中に紛れ込む環境寄生型戦術の高度な例である^[13]。

中国に関連するこのグループは、特に東南アジアや欧州の外交・政府機関を標的とし、「PlugX」RATの配布にサイドローディングを定常的に使用している。感染したUSBドライブを使用し、不可視化されたフォルダ内に「正規EXE + 悪性DLL + 暗号化データ」のセットを配置し、ユーザーには無害なLNKファイルをクリックさせることで感染を広げる。AdobeHelp.exeやSamsungのRunHelp.exeなど、広く普及しているソフトウェアの古いバージョンが悪用される^[1]。

東アジアのハイテク企業を標的とするBlackTechは、セキュリティ対策ソフト自体のコンポーネントを悪用することで知られている。トレンドマイクロやマカフィーなどのセキュリティ製品に含まれる署名付きバイナリを悪用し、悪意のあるDLLをロードさせる。セキュリティ製品のプロセスは高い権限で動作し、かつ監視対象から除外されていることが多いため、これを悪用することで強力な権限昇格と検知回避を実現している^[6]。

2021年、攻撃者は、Kaseyaのエージェントを通じて、Windows Defenderの正規実行ファイルである古いバージョンのMsMpEng.exeを被害者のシステムにドロップし、同じフォルダに悪意のあるmpsvc.dllを配置した。MsMpEng.exeが実行されると、システムは自動的にこの偽のDLLをロードし、REvilランサムウェアが復号・実行された。マイクロソフト自身が署名したセキュリティソフトのバイナリが悪用されたことで、多くの振る舞い検知システムが迂回された^[1]。

主要なRaaS（Ransomware-as-a-Service）であるLockBitも、VMwareやCitrixの正規コマンドラインツールを悪用して暗号化プロセスを隠蔽する手法を採用している。これにより、EDRが暗号化の動作を正規の管理操作と誤認する可能性を高めている^[14]。