セキュリティオペレーションの品質向上のヒント

~ Detection & Incident Response ~
第2回 DLL Notification Injection (防御目線)

By Trellix · July 22, 2025

(目次)

• 1. はじめに
• 2. 概要
  
• 3. ブルーチームの対応
  
  • 3.1 PoC検体の解析とIoC
  • 3.2 インシデントレスポンス
• 4. 検知ルール例
• 5. まとめ
• 6. Trellix Professional Servicesでの支援内容

1. はじめに

「セキュリティオペレーションの品質向上のヒント」シリーズの第２回目として、第１回目でご紹介した「DLL Notification Injection」を防御者目線で解説します。

防御者において要となるスキルの一つが「分析力」です。なぜなら、分析結果の良し悪しが、インシデント対応の初期調査や事後対応の成否に直結するためです。分析力を強化することは、高度な攻撃への対応力を向上するだけではなく、自組織のSOCやCSIRTのスキル醸成、セキュリティ製品の導入効果を最大限に引き出すことにも繋がります。

「セキュリティオペレーションの品質向上のヒント」はシリーズものとして、随時当社ブログサイトにてご紹介していきます。
攻撃目線：レッドチームがよく用いるテクニックやツールだけでなく、これから注目すべき新しいテクニック等をピックアップし、技術的概念、侵害時の影響、検証時の再現方法等をご紹介します。
防御目線：ブルーチームが行うインシデント対応 (Threat Hunting、ファストフォレンジックを含む) に役立つ情報として、プロセスの動きやイベントログ等の調査方法、利用したツール等をご紹介します。

2. 概要

「DLL Notification Injection」を使用したPoC検体の解析から検知ポイントを考察しています。複数の検知ポイントを分析し、攻撃の全体像を把握することで、効果的なインシデントレスポンスが可能となります。「DLL Notification Injection」の技術的詳細は、第１回目の記事をご覧ください。

3. ブルーチームの対応

3.1 PoC検体の解析とIoC

検体（.LNKファイル）を検証環境で実行し、解析した内容を抜粋してご紹介します。
なお、今回利用した検証環境はWindows 10 Pro 22H2です。

プロセスの確認

.LNKファイルを実行した場合のプロセスツリーを”Process Monitor”で表示すると、Explorerの子プロセス以下にpowershell及びrundll32を確認できます。
rundll32は、MicrosoftのWindows標準プログラムで、任意のDLL（Dynamic Link Library）等を実行することが可能なため、悪用事例が多数報告されています。

通信の確認

Process Monitorで、Operationにconnectを含むものでフィルターすると、Explorerプロセスから見慣れないIPアドレス及びポート宛の通信を確認できます。

ファイルの確認

Process Monitorで、rundll32の引数を確認すると、一般的なWindows環境では見慣れないファイル名”cyzfc.dat”というファイルを確認できます。

この.datファイルを取得し”pestudio”で表示すると、MS-DOS実行可能形式（MZ）で64bitのDLLであることが分かります。

更に、この.datファイルを”ghidra”で開きます。難読化されていない場合、文字列や逆アセンブルを確認することで処理概要の把握やブレイクポイントとする関数を探すことができます。

ghidraのSymbol Table及びSymbol Referencesで、プロセスインジェクションの１つの可能性として考えられるWindows API（OpenProcess→VirtualAllocEx→WriteProcessMemoryの流れ）を検索すると、それぞれの関数が近いアドレス値に存在すること(180001314～180001408)が確認できます。

また、上記APIの流れに続けて、代表的なプロセスインジェクションで見られるCreateRemoteThreadやNtCreateThreadExやZwCreateThreadExといったAPIは見つからず、単純なプロセスインジェクションとは異なる様子が伺えます。但し、動的に特定のAPI関数を呼び出すことも可能なため、逆アセンブルによる静的解析のみで結論づけることはできません。

続けてghidraで逆アセンブルコードを確認します。
OpenProcessの部分に着目し、引数dwProcessIdに指定されるプロセスIDが何かを遡って見ることで、どのプロセスがターゲットとされているかを探します。

起動しているプロセスを順にチェックしていくループ処理で、特定の文字列に一致したプロセスを探していることが分かります。

もう少し遡って見ると、「explorer.exe」という文字列を指定していることが分かり、explorerプロセスを操作しようとしている様子が見えます。

ここからは.datファイルを”x64dbg”で開き動的解析を行います。x64dbgでOpenProcessにブレイクポイントをセットすると、先ほど逆アセンブルコードで確認したとおり、explorerプロセスへアクセスしていることが確認できます。以下の例ではexplorerプロセスのプロセスIDは3076(0xC04)です。

続けて、デバッグを進めるとVirtualAllocExでメモリ領域を確保後、WriteProcessMemoryでシェルコードを書き込む様子が確認できます(アドレスポインター0xB70435からサイズ0x1FE)。シェルコード内には、通信先のIP・port情報やシェルコードが通信機能のために悪用することの多いws2_32といったDLL名情報が含まれています。

次に、x64dbgでデバッグを進めながら、explorerプロセスを”API Monitor”で監視します。API MonitorでLdrLoadDLLをCaptureすると、ws2_32.dllがロードされていることとシェルコードが書き込まれたメモリ領域内(0xb7053f)を参照していることが分かります。そしてこのタイミングでexplorerプロセスから不審通信が発生します。

シェルコードがメモリに書き込まれてから、コードが実行され不審通信が発生するまでの間をもう少し詳しく見ていくと、DLL Notification機能で利用されるリスト(LdrpDllNotificationList)のheadアドレス値を改ざんする処理があり、この点が今回使用されている「DLL Notification Injection」がスレッドレスと呼ばれる所以でした。LdrpDllNotificationListの改ざんについての詳細は第１回目をご覧ください。

3.2 インシデントレスポンス

インシデントレスポンスで最も重要なフェーズは検知から封じ込めです。効果的な封じ込めのためには、一つ一つの個別の検知をいかに結び付け、影響範囲を正しく把握できるかが重要になります。初期調査の分析が浅い場合、影響範囲を見誤り封じ込めに失敗し、攻撃者による侵害が深刻なものとなる可能性が高くなります。 単発では些細な検知に見えるかもしれませんが、一連の攻撃の部分である可能性を踏まえ分析を進めることが大切です。

以下に主な検知ポイントと留意点をまとめます。

検知ポイント①

.LNKファイル実行時のプロセスツリーから、powershellやrundll32等の攻撃者に悪用されやすいプロセスの実行を検知します。EDRによる検知が主となります。
rundll32以外にも悪用される標準プログラムは多数あり、多くはLOLBAS（Living Off the Land Binaries And Scripts）のページで確認できます。
標準プログラムのため過検知となり易く、プロセスの親子関係や引数となるファイルやパラメータに不審点がないかを相関させてアラート化することを検討します。

検知ポイント②

マルウェアが生成する中間ファイル(今回はcyzfc.dat)を検知します。アンチウイルスソフトウェアによる検知が主となります。
特定の端末のみで検知があった場合は、ファイルハッシュ、ファイル名、含まれる文字列やファイルサイズ等をYARA等で展開し感染範囲を確認・監視することが大切です。

検知ポイント③

「DLL Notification Injection」に特有のWindows API (LdrRegisterDllNotification、LdrUnregisterDllNotification)がファイル検体に含まれていることを検知します。不審ファイル解析を行うSandboxによる検知が主となります。
特徴的な関数の利用は、難読化や動的にリンクしている可能性が高く、検知が難しい部分でもあるため、動的解析による検知が可能なSandboxが重要となります。

検知ポイント④

悪性コードが挿入される標的プロセス（今回はexplorer）の異常を検知します。Windowsセキュリティイベントによる検知が主となります。
攻撃者によって操作されるプロセスはクラッシュする可能性があり、検知時刻付近のプロセスやアクセスを確認することで、インシデントの早期発見に繋がる可能性が高まります。
今回の検証では悪性コードが実行されC2通信が出た後、通信できない状況が一定時間続くとexplorerプロセスが再起動することを確認しています。

検知ポイント⑤

C2通信を検知します。プロキシやIPSによる検知が主となります。
あらかじめ出口を絞るなど、検知しやすいネットワークアーキテクチャにしておくことも重要です。
今回はPoC検体のため、通信先がプライベートIPアドレス(172.16.0.0/12)及び特徴的なポート(1234)と気づきやすいですが、実際のマルウェアの場合、C2通信先として正規サービスや利用者の多いパブリッククラウド環境が悪用される傾向があり、通信先のみで不審か否かの判断が難しくなってきています。また、マルウェアによっては複数の通信先を保持している可能性があり、環境や条件によって通信先が異なる可能性もあるため、マルウェアを検知した際は検体解析を行い、挙動を確認することが重要です。

4. 検知ルール例

不審なDLL等を実行するプロセスを検知するsigmaルール案（XXXの部分を自組織の正規パターンに置き換え）

「DLL Notification Injection」を使用したマルウェアを検知するYARAルール案

explorerプロセスのクラッシュを検知するsigmaルール案

5. まとめ

今回のブログでは、第１回目で作成したPoC検体の解析及び抽出したIoCを使用した検知ポイントの内容をブルーチーム視点でご紹介しました。「DLL Notification Injection」は、Windowsの正規の仕組みを悪用しているため、それ自体を検知することは困難なケースが多いと考えられます。実際、「DLL Notification Injection」という攻撃手法を知らずに検体解析をした場合、表面上は突然悪性コードがロードされたように見えます。最新の脅威情報を継続的に把握していく必要性を感じていただけた方も多いでのはないでしょうか。また、インシデントレスポンスにおいては、短時間である程度の精度をもって広く封じ込めをしていくことが基本となるため、攻撃の全体像を想定した上で、複数の検知ポイントを迅速かつ複合的に見て判断していけるかがキーとなります。

[Appendix]
今回取り上げた「DLL Notification Injection」について、5つの指標案を用いて攻撃手法を評価しました。スコアが高いほど、攻撃手法として脅威が高いという評価です。この評価方法(Attack Scoring System)については別途ブログでご紹介しておりますので是非ご覧ください。

なお、本記事はセキュリティ攻撃手法の分析プロセスの解説を目的としたものであり、紹介しているツールはあくまで分析の一例で、当社が特定のツールを推奨する意図はありません。また、実際の検証作業には様々な危険が伴うため、ご利用にあたっては、各ツールのライセンスおよび利用規約を遵守し、読者ご自身の責任において安全な環境で行ってください。

6. Trellix Professional Servicesでの支援内容

Trellix Professional Services（以下、Trellix PS）では、セキュリティオペレーションの品質向上のために、SOC及びCSIRT支援を行うことが可能です。

CSIRT及びSOC支援の期待する効果

• お客様の環境を理解した上での助言によるナレッジ強化
• ログ分析力の向上
• インシデント対応力の向上
• マルウェア解析による検知強化
• Threat Huntingの導入

この他にも様々なサービスをTrellix PSでは提供しています。

• 技術的監査支援（脆弱性診断、ペネトレーションテスト、レッドチーム演習
• サイバーセキュリティ体制構築支援
• SOCの高度化・自動化支援
• CSIRT支援（インシデント対応含む）
• セキュリティ教育支援

これらサービスはお客様事情に合わせ柔軟にカスタマイズしてご提供が可能です。セキュリティに関する課題を是非Trellixへお気軽にご相談ください。
https://www.trellix.com/services/advanced-cyber-threat-services/