Sentinel + AMA で二重にクライアント PC を監視してみる — EDR 回避攻撃の対策？

本記事で紹介する攻撃シナリオは、すべて自身の検証環境において正規の OS API・PowerShell コマンドを用いて疑似的に再現したものです。実マルウェア検体は使用していません。

本記事は GitHub Copilot の支援を受けて執筆しています。

はじめに

EDR (Endpoint Detection and Response) は、エンドポイントセキュリティの中核として広く展開されています。Microsoft Defender for Endpoint (以降 MDE) を運用している組織も多いはずです。

一方で、攻撃者にとって EDR は 真っ先に無力化したい標的 でもあります。近年は「EDR Killer」「EDR Silencer」と総称される、EDR センサーやその通信を停止・遮断する手法が広く使われるようになり、Trend Micro のレポートでは Black Basta / LockBit 系が EDRSilencer を実利用した と報告されています。

もし MDE が静かに無力化されたら、その端末で何が起きているかを誰がどう知るのか?

本記事では、この問いに対する一つの補助的なアイデアとして、「クライアント PC にも Azure Monitor Agent (以降 AMA) を入れて、Sentinel に Windows イベントログを直接流す」 という構成を提案します。AMA は MDE Sense とは別プロセス・別経路で動作するため、MDE が黙らされた状況でも OS が出すイベントログを Sentinel に届けてくれる可能性があります。

絶対防御ではありません。AMA も OS 上のプロセスである以上、攻撃者が SYSTEM 権限を握れば同じように止められ得ます。それでも「MDE 一本足ではなく、もう一つの目をクライアントに置いておく」という選択肢の価値を、2 つの簡易検証を通じて示してみます。

一般的な構成と本記事の提案

AMA は通常、サーバーの監視用 として使われることが多いエージェントです。Sentinel と組み合わせる場合も、対象は IaaS VM や AD ドメインコントローラーなどに限られがちです。

クライアント PC のセキュリティ監視は MDE に任せ、AMA は入れない、という構成が一般的でしょう。

本記事の提案は、高リスクなクライアント PC にも AMA を導入し、MDE と独立した二系統目のテレメトリ経路を持つ という構成です。

ポイントは AMA が MDE Sense とは別プロセス・別認証経路 (Microsoft Entra デバイストークン → Monitoring Configuration Service) で動く ことです。MDE Sense がプロセス停止や通信遮断で黙らされても、AMA 自身に同じ攻撃が及ばなければ、Sentinel への送信は継続します。

OS が生成する Windows イベントログ (System / Security / Microsoft-Windows-Windows Defender/Operational 等) はカーネル側で書き込まれるため、AMA はそれを拾って送り続けます。仮に攻撃者が事後にローカルのログを消去したとしても、それまでに AMA がクラウド側へ送り出したログは Sentinel に残ります — これがエージェントから外部にテレメトリを逃がしておくアーキテクチャの大きな価値です。

検証してみたこと

提案を裏付けるため、Windows 11 24H2 のクライアント (Tamper Protection 有効、AMA / MDE 両方稼働中) で、性質の異なる 2 つの EDR 回避シナリオを試しました。

ケース 1: MDE / Defender プロセス自体を無効化するタイプ

EDR を止めたい攻撃者がまず考えるのは、MDE センサー (Sense) や Defender AV (WinDefend / MsMpEng) そのものを停止したり、リアルタイム保護を無効化したりという正面からのアプローチです。実際の攻撃では PowerShell に限らず、ネイティブ API 直叩き、sc.exe / taskkill 系の OS 標準コマンド、サードパーティ製 EDR Killer 等、さまざまな経路が使われます。

検証では代表的な手段として以下を試しました (今回は PowerShell から Set-MpPreference / Stop-Service / sc.exe create 等で疑似実行)。

• リアルタイム保護の無効化 (Set-MpPreference -DisableRealtimeMonitoring $true)
• Defender AV / MDE センサーサービスの停止 (Stop-Service WinDefend / Sense -Force)
• BYOVD の足がかりとなるカーネルモードドライバーサービスの新規登録 (sc.exe create ... type= kernel)

このタイプは「ちゃんと構成された MDE」がほぼ防いでくれる

結論から言うと、この種の正攻法な攻撃に対しては、AMA を持ち出すまでもなく Defender AV + MDE + Tamper Protection を正しく構成しておけば、検出・ブロックが期待できます。今回の検証でも以下が観測されました。

• PowerShell スクリプト経路は Defender AMSI が Trojan:Win32/MpTamperSrvDisableAV.L 等として丸ごとブロック (Defender Operational EventID 1116 / 1117)
• リアルタイム保護を無効化するレジストリ書き込みは Tamper Protection が EventID 5013 で拒否
• サービス停止試行も Tamper Protection によって拒否される

これらは AMA があっても無くても、まず MDE 側で止まる・記録される話です。AMA は「同じものが二経路で見える」という冗長性の意味は持ちますが、ここがメインの価値ではないと言い切ってしまって良いと思います。

補足として、sc.exe create ... type= kernel のようなカーネルモードドライバーサービスの新規登録自体は AMSI / Tamper Protection ではブロックされず通ります。ただしこれも MDE 側では DeviceProcessEvents に sc.exe のコマンドライン全文が、AMA 側でも System EventID 7045 が、それぞれ独立に記録されており、同じ事象が両方から見える という構図です。AMA 単独でしか見えない要素はほとんどなく、ケース 1 における AMA の意味は冗長性に留まると整理しておくのが正直なところです。

ケース 2: WFP-based EDR Silencer

ケース 1 のような「プロセスを止める」アプローチが MDE / Tamper Protection に堅く防がれると、攻撃者は別の経路を探ります。EDRSilencer (netero1010) や FireBlock (MdSec NightHawk) 等のツールに代表される、「プロセスは生かしたままアウトバウンド通信だけを WFP (Windows Filtering Platform) でブロックする」 手法がその代表例です。

試したこと (実ツールは使わず、New-NetFirewallRule で同等の効果を再現):

• MsSense.exe / MsMpEng.exe / SenseIR.exe のアウトバウンド通信をブロックするファイアウォールルールを作成
• WFP 監査 (auditpol の Filtering Platform Connection / Packet Drop / Policy Change) を有効化
• DCR に Security チャネルの WFP 関連 EventID (5152 / 5157 等) を追加

観測されたこと:

• Tamper Protection はファイアウォールルールの作成を保護対象としていない ため、警告なくルール作成成功
• ルール作成直後から MDE プロセスのアウトバウンドが連続的にドロップされ、MDE クラウドへのテレメトリは完全停止
• にもかかわらず、MDE ポータル上の DeviceInfo は OnboardingStatus=Onboarded / SensorHealthState=Active のまま (Inactive 判定までに約 6 時間)

つまり、MDE 側の見た目は健全なまま、実態はテレメトリゼロの "silent compromise" が成立してしまいました。これが EDR Silencer の本当に怖いところです。

このとき AMA 経由で Sentinel Event テーブルに届いたログ:

EventID	チャネル	意味	観測件数 (約 13 分間)
5152	Security	WFP によるパケットドロップ	mssense.exe / msmpeng.exe / senseir.exe で計 365 件
5157	Security	WFP による接続ブロック	同上 357 件

特に SenseIR は何度もリトライするため大量のドロップイベントが出ます。MDE 自身が "黙らされた" ちょうどそのタイミングで、AMA だけが攻撃の存在を Sentinel に届け続けていた という状況になります。

silent compromise を検知するシンプルな KQL

ケース 2 のシグネチャを使えば、「MDE プロセスのアウトバウンドが WFP でブロックされている」という事実そのものを検知できます。最小構成はこれだけです。

// AMA 経由で MDE プロセスの outbound block を検知 (5152: パケットドロップ / 5157: 接続ブロック)
Event
| where TimeGenerated > ago(30m)
| where EventLog == "Security" and EventID in (5152, 5157)
| extend AppName = extract(@"(mssense|msmpeng|senseir|sensecncproxy)\.exe", 0, tolower(RenderedDescription))
| where isnotempty(AppName)
| summarize BlockCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by Computer, AppName, EventID
| order by BlockCount desc

さらに「MDE 側の生テレメトリが届かなくなっている」事実とつき合わせれば、silent compromise の確度がぐっと上がります。MDE ポータルの DeviceInfo.SensorHealthState は判定が遅く (Inactive 化まで約 6 時間)、また数十分単位で更新されるとも限らないため、DeviceEvents 等のイベント系テーブルへの最終到達タイムスタンプを「Heartbeat 代わり」にした方が反応が速く実態にも即します。

// MDE テレメトリ途絶 (DeviceEvents の最終到達) × AMA 経由の WFP block の相関
let stale = 15m;
let mdeStale =
    DeviceEvents
    | where Timestamp > ago(6h)
    | summarize MdeLastEvent = max(Timestamp) by DeviceName
    | where MdeLastEvent < ago(stale)
    | extend deviceKey = tolower(tostring(split(DeviceName, ".")[0]));
let wfpBlocks =
    Event
    | where TimeGenerated > ago(1h)
    | where EventLog == "Security" and EventID in (5152, 5157)
    | where tolower(RenderedDescription) matches regex @"(mssense|msmpeng|senseir|sensecncproxy)\.exe"
    | extend deviceKey = tolower(tostring(split(Computer, ".")[0]))
    | summarize BlockCount = count(), LastBlock = max(TimeGenerated) by deviceKey;
wfpBlocks
| join kind=inner mdeStale on deviceKey
| project deviceKey, BlockCount, LastBlock, MdeLastEvent,
          SilentCompromise = iif(LastBlock > MdeLastEvent, "YES", "Suspected")

5152/5157 で MDE プロセス名にマッチする時点で正常運用ではほぼ起こらない事象なので、実用上は最初のクエリだけでも十分にアラート価値があります。テレメトリ途絶とのクロス相関は、誤検知を抑えたい場合や状況証拠を強めたい場合に追加する位置づけです。

DeviceEvents の更新間隔は端末のアクティビティ次第で、平常時でも 15 分ほど無音になることはあり得ます。本記事の stale = 15m はあくまで一例で、実環境では運用ベースラインを取って閾値を決めてください。DeviceProcessEvents や DeviceNetworkEvents を OR で束ねて「最後にどこかで MDE テレメトリが流れたか」を見る形にすると、より反応が安定する場合もあります。

2 つのケースから見えること

観点	ケース 1 (プロセス無効化系)	ケース 2 (WFP-based EDR Silencer)
攻撃の主要部分の到達	AMSI / Tamper Protection で阻まれた	Firewall ルールで成功 (silent compromise 成立)
MDE 単独で見える?	大部分は見える / ブロック済み	見えない (MDE ポータル上は健全表示)
AMA を入れる主な意味	冗長性 (同じ事象が二経路で見える) に留まる	MDE が黙らされた状況で 唯一残る監視経路

ケース 1 は MDE と Tamper Protection をきちんと構成していれば、攻撃の主要部分は MDE 側でブロックされ、DeviceProcessEvents 等にも痕跡が残ります。AMA を入れる意義はあくまで「もう一経路でも同じものが見える」という冗長性で、ここを目当てにクライアントへ AMA を展開するほどの強い動機にはなりにくいと思います。

ケース 2 は話が変わります。MDE 側の表示は健全なまま、AMA だけが攻撃の痕跡を Sentinel に届けています。AMA が入っていなければ、攻撃者がいつ侵入を完了させても誰も気づけない 状況になり得ます。クライアントに AMA を二系統目として入れる本質的な動機は、こちらにあると考えています。

クライアント PC への AMA 展開という選択肢

ここまでの結果を踏まえて、「高リスクなクライアント PC には MDE に加えて AMA も入れておく」という選択肢は、検討する価値があるか考えていただければと思います。

対象として想像しやすいのは、特権ユーザーが使う管理端末、PAW (Privileged Access Workstation)、開発者端末、外部公開された業務端末などです。すべてのクライアントに展開する必要はありませんが、「ここがやられたら本当にまずい」 という端末から優先的に検討する価値はありそうです。

導入のハードルそのものは高くありません。

• Windows クライアント向け AMA インストーラー (AzureMonitorAgentClientSetup.msi) のインストール
• Microsoft Entra テナントスコープの Monitored Object に DCR を関連付け
• DCR では 取得チャネル / EventID を最小限に絞り込む (System / Defender Operational / Security の WFP 関連 EventID 等)
• Sentinel 側で MDE の DeviceEvents 等のテレメトリ最終到達時刻とのクロス相関ルールを作成

データ取り込み量も、EventID を絞れば 1 端末あたり相当限定的に抑えられます。
ただし、後述するとおりクライアント向け AMA は DCR がテナント全体スコープでしか適用できないという大きな制約があります。「特定のクライアントだけに展開」という運用にはそのままでは向かない点に注意が必要です。

注意点と割り切り

冒頭で書いた通り、これは 絶対防御ではありません。むしろ前提として以下を理解しておく必要があります。

• AMA も止められる: AMA も OS 上の一プロセスです。攻撃者が SYSTEM 権限を握り、AzureMonitorAgent サービスを止めたり、AMA プロセスのアウトバウンドを WFP で block したりすれば、同じように黙らされます。MDE が落ちる攻撃なら AMA も落ちるシナリオは普通にあり得ます
• クライアント向け AMA は DCR スコープがテナント全体になる: Windows クライアント OS 向けの AMA インストーラー (AzureMonitorAgentClientSetup.msi) は、DCR を Monitored Object (Microsoft Entra テナントスコープ) に関連付ける方式しかサポートされません。つまり「クライアントインストーラーで AMA を入れたテナント内の全 Windows クライアントに DCR が一律適用される」ことになり、端末単位やグループ単位の細かな出し分けができません。XPath で取得 EventID を最小化してノイズを抑える設計が必須で、ノイジーなチャネルを安易に追加すると対象外であるが AMA 導入済みなクライアント端末からも大量にログが流れ込みます
• DCR の EventID 絞り込みは必須: Security!* を雑に取り込むとログ量が爆発します。WFP 関連 (5152 / 5157 等) のように 必要な EventID だけ XPath で明示して取り込むことが必要です
• WFP 監査の有効化が必要: Filtering Platform 関連の監査はデフォルト OFF です。auditpol で Failure を有効化しないクライアントと 5152/5157 は出ません。Success まで有効化すると正常通信を全件記録するため絶対に避けること
• ライセンス・コスト: Sentinel のデータ取り込み課金がかかります。対象端末数とイベント量を見積もって判断してください

それでも、「MDE が完全に信頼できなくなった瞬間に、もう一つだけ目が残っている」という状態は、ゼロよりはマシです。コストや運用負荷と相談しながら、自組織の高リスク端末に対する一つの選択肢として検討してみる価値はあると思います。

まとめ

• EDR Killer / EDR Silencer 系の手法により、MDE が黙らされる事例は実環境で増えている
• 特に WFP-based EDR Silencer は、MDE ポータル上は健全に見えたままテレメトリだけが止まる "silent compromise" を成立させる
• クライアント PC にも AMA を入れておくと、MDE と独立した別経路で Windows イベントログを Sentinel に届けられ、上記のような silent compromise を検知できる可能性がある
• AMA 自体も止められ得るため絶対防御ではないが、MDE 一本足から二本足にする という補助的アイデア
• 導入は AMA インストール + DCR の最小限スコープ + クロス相関ルールで始められる

EDR を信頼することと、EDR が信頼できなくなった場合の備えを持つことは、どちらか一方ではなく両立できるはずです。本記事の構成が、そのための小さなヒントになれば幸いです。

参考

• Windows クライアント デバイスでの Azure Monitor エージェントの設定 - Azure Monitor | Microsoft Learn
• Data collection rules in Azure Monitor - Microsoft Learn
• Audit Filtering Platform Connection - Microsoft Learn
• netero1010/EDRSilencer (GitHub)
• Trend Micro: EDRSilencer disrupting endpoint security solutions