メモリの暗闇を照らす：EDRは「何を」見てインジェクションを断罪するのか
多くのエンジニアが、セキュリティ製品を「魔法の箱」と錯覚している。しかし、EDR（Endpoint Detection and Response）がメモリインジェクションという「プロセスの深淵」をいかにして暴いているのか、その裏側のロジックを理解している者は驚くほど少ない。
今日は、AESやRSAといった鍵の数学的堅牢さの話から少し離れ、OSのカーネル境界線上で繰り広げられる「生存競争」の最前線について語ろう。
1. 暗号論的アプローチとメモリの乖離
まず前提として、我々が守るべきデータがAES-GCMやECDHでどれほど強固に守られていようとも、「その鍵がメモリ上に展開された瞬間」、あるいは「復号されたペイロードがプロセス空間にロードされた瞬間」、ゲームは振り出しに戻る。
攻撃者は、ディスク上に悪意あるバイナリを置くという旧態依然とした手法を捨てた。今や、信頼されたプロセス（explorer.exeやsvchost.exe）のメモリ空間を乗っ取り、そこで悪意あるコードを直接実行する「ファイルレス・インジェクション」が主流だ。
2. プロセスインジェクションの「手口」と検知の物理的制約
攻撃者は、WindowsのAPIである VirtualAllocEx でメモリを確保し、WriteProcessMemory でシェルコードを書き込み、CreateRemoteThread で実行をトリガーする。これらは極めて標準的なAPIであり、これらを単にフックするだけでは、正規のデバッガや監視ツールと区別がつかない「ノイズ」の山に埋もれることになる。
EDRが真に検知すべきは、APIの呼び出しそのものではなく、「呼び出し元（Caller）と呼び出し先（Callee）の文脈の異常性」だ。
検知パターン：APIフックとスタックトレースの分析
例えば、ntdll.dll の NtMapViewOfSection へのフックを考えてみよう。EDRは以下のパラメーターを泥臭く監視している。
- 戻りアドレス（Return Address）の検証: APIが呼び出された際のスタックトレースを辿り、その呼び出し元が「正当なモジュール（
kernel32.dllなど）」内にあるかを確認する。もし戻りアドレスがメモリ内の「不明な（Anonymous）」セグメントを指していれば、それはインジェクションの明白な兆候だ。
// 概念実証: EDR内部でフックされたAPIのスタックウォークを行う擬似コード
void CheckCallStack(PVOID returnAddress) {
MEMORY_BASIC_INFORMATION mbi;
VirtualQuery(returnAddress, &mbi, sizeof(mbi));
// もし戻り先がディスク上のファイルにマッピングされていないメモリ領域であればフラグを立てる
if (mbi.Type != MEM_IMAGE) {
ReportSecurityAlert("Detect: Suspicious API call from unbacked memory");
}
}3. DLLサイドローディングと「信頼」の悪用
DLLサイドローディングは、アプリケーションがDLLを検索する際の優先順位の甘さを突く。これは暗号化された通信プロトコルそのものの欠陥ではなく、「OSのロードシーケンスという仕様の欠陥」を突いたものだ。
防御の要諦は、実行時のプロセスの「振る舞い」をベースライン化することにある。具体的には、EDRは以下の挙動を相関分析する。
1. 異常な親プロセス: 正規の署名済みバイナリが、本来ロードしないはずのDLLを読み込んでいるか。
2. メモリ保護属性の変更: PAGE_EXECUTE_READWRITE（RWX）という、最も危険なメモリ権限が、本来のプロセス実行中に突如として付与されていないか。
4. 次世代への備え：耐量子とガードレイル
今、我々が真剣に議論すべきは、将来的な耐量子暗号（PQC）への移行だけではない。LLM時代においては、プロンプトインジェクションに対する「ガードレイル」の設計が、かつてのメモリ保護と同様の重要性を持つ。
メモリインジェクションが「プロセス空間の汚染」であるならば、プロンプトインジェクションは「コンテキスト空間の汚染」だ。これらに対する防御は、共通して「入力の妥当性検証（Validation）」ではなく「実行時の文脈（Context）の分離」にある。
- サンドボックスの再定義: プロセスをOSの権限で分けるだけでなく、AIの推論プロセスを完全に分離された「信頼できないメモリ空間（Untrusted Memory Space）」で処理し、出力のサニタイズをハードウェアレベルで強制する設計が、今後求められるだろう。
最後に：泥臭い現場の知見
読者諸氏に伝えたいのは、どんなに高度なAI検知モデルを導入しようとも、最後は「なぜそのプロセスが、そのタイミングで、そのメモリ領域を操作する必要があるのか？」という、泥臭いまでのアーキテクチャの理解に帰結するということだ。
技術は常に攻撃者と防御者のいたちごっこだが、その根底にある「OSがメモリをどう管理しているか」という事実は揺るがない。教科書を閉じて、WinDbg でプロセスを覗き、スタックを追い、パケットの生データを見る。その執念こそが、最高峰のセキュリティを担保する唯一の道である。
次のインシデントハンドリングで、君がその「異常なスタック」を見抜くことを期待している。
コメント