EDRChokerによるEDRエージェントの通信帯域の制限

報告の内容

Zero Salariumの作者は、この手法がWindowsファイアウォールやWFP（Windows Filtering Platform）を使うEDRの接続遮断の方法とは異なると説明した⁠［1］。既存の方法の例に挙げたEDRSilencerは、WFPのFwpmFilterAdd0で送信を制限するツールで、EDRのログにpacket-block・packet-dropなどの痕跡を残す⁠［1］。

記事によると、ポリシーベースQoSは、特定のアプリケーション・ポート・プロトコルの送信帯域に絶対的な上限を設定できる⁠［1］。一般的なTLSハンドシェイクの総データ量は平均3〜6KBで、構成によっては10KBを超える⁠［1］。証明書の交換だけで2〜5秒を超えると、アプリケーションかリモートのWebサーバーは接続を切り、Connection Timed Outを返す⁠［1］。

作者は、パケットを遮断・破棄する代わりに帯域を毎秒1KB未満に絞れば、EDRエージェントがサーバーへ送信するたびにタイムアウトさせられると説明した⁠［1］。QoSパケットスケジューラ（pacer.sys）はNDISの軽量フィルタドライバで、WFPより下の層で動く⁠［1］。既存のEDR遮断ツールは、通常WFPの層までしか届かないとした⁠［1］。

EDRChokerの動作

作者の説明では、ツールの導入モードは遮断するEDRのプロセス名を書いた入力ファイルで動き、削除モードは引数なしで実行すると作ったポリシーを消す⁠［1］。ポリシーはプロセスごとに作られ、名前はプロセス名とランダムなGUIDを組み合わせたもの〔注2〕になる⁠［1］。記事は、これらのルールはWindowsの再起動後も残ると書いた〔注1〕⁠［1］。

作者は、QoSポリシーを作った後、Elasticのクライアントはサーバーとの接続を失い、サーバーはそのクライアントを制御できなくなったと説明した⁠［1］。EDRがQoSポリシーを能動的に確かめなければ、ルールに従って遮断されるとも書いた⁠［1］。ツールはGitHubのリポジトリ（TwoSevenOneT/EDRChoker）で公開され、記事は検証環境で試すための入手先として案内した⁠［1］。

Defender for Endpointでの再現

Linden Securityの記事によると、調査のきっかけはURLhausにあった標本だった⁠［2］。標本は、360 Total Securityの通信を担うwdswfsafe.exeを対象に、New-NetQosPolicyで帯域を毎秒10ビットに絞る⁠［2］。同名のポリシーがあれば消して作り直す処理と、ランダムなポリシー名も持っていた⁠［2］。標本を調べていた週末に、EDRChokerのPoCが出たと記事は書いた⁠［2］。

Linden Securityは、QoSポリシーで帯域を絞られたセキュリティ製品は、プロセスが動いたままクラウドに届かなくなり、改ざん防止の警告も出ないと説明した⁠［2］。MsMpEng.exeを絞った場合は、MAPSのクラウド照会だけに影響し、SOCに届くEDRのテレメトリには影響しなかった⁠［2］。

Linden Securityによると、コンパイル済みのEDRChokerは、DefenderにTrojan:MSIL/EDRChoker.DA!MTBとして検出される⁠［2］。同じ処理を数行のPowerShellで書いたものは、まだ検出されていなかった⁠［2］。New-NetQosPolicyの実行は端末のローカルには記録されるが、帯域を絞られたセンサーはその記録をクラウドに送れない⁠［2］。試験で記録がクラウドに届いたのは、ポリシーを消してバッファが流れた後だった⁠［2］。

PowerShellのScript Block Loggingは変数を展開せずに記録し、帯域の値と対象のパスは変数名の文字列のまま残ると記事は説明した⁠［2］。Linden Securityは、Defender for EndpointでPowerShell版を確実に検知する方法は執筆の段階では無いと書いた⁠［2］。

目次へ

根拠と範囲

Zero Salariumの作者がEDRChokerを試したのは、自身の検証環境のElastic Defendだった⁠［1］。手法の実行には管理者権限が必要だと、Linden SecurityとiPurple Teamの記事は書いた⁠［2、3］。

Linden Securityは、手法そのものはEDRChokerで既に公開されていて新しい攻撃面ではないと断り、記事には誤りが含まれうると書き添えた⁠［2］。iPurple Teamは、手法はEDRのルールそのものを損なわず、CrowdStrikeなど一部のEDRはルールを端末に置いていると注記した⁠［3］。

The Hacker Newsは6月11日の記事で、同じ研究者が2026年1月にも、EDRの起動を妨げる別のツールEDRStartupHinderを示していたと報じた⁠［4］。

目次へ

関係者の対応

Zero Salariumの作者が挙げた対策は、端末のポリシーベースQoSの定期的な監査と、PowerShellの監査ログとWindowsのイベントログによるポリシーの作成と帯域制限の適用の追跡である⁠［1］。作者は、攻撃者が端末の管理者権限を得る前の事象の監視を最も重要な対策とした⁠［1］。

Linden Securityは対策として、センサーのクラウド経路に頼らないログ（PowerShell Module LoggingのEvent ID 4103、SysmonとWindows Event Forwardingなど）をSIEMに送ることを挙げた⁠［2］。確実な検知ができるまでは、QoSポリシーの操作をそれ自体疑わしいものとして探索するとした⁠［2］。攻撃者は既定の列挙では見えず再起動で消えるActiveStoreを使えるため、調査では両方の保存先のポリシーの列挙を推奨した⁠［2］。

iPurple Teamの6月17日の記事では、New-NetQosPolicyの実行はPowerShellのEvent ID 4104に記録される⁠［3］。バイナリのCIMコマンドレットなので、Event ID 4103は生成されない⁠［3］。PowerShellとWMIのどちらで実行しても、NetQosCimプロバイダの開始を示すWMIのEvent ID 5857が共通して出る⁠［3］。記事はこのイベントをQoSポリシーの悪用の指標に使うよう勧めた⁠［3］。

同じ記事は、EDRエージェントは健全に見え続けうるとして、EDRのクエリに頼らない検知の設計をSOCに推奨した⁠［3］。ActiveStoreのポリシーはレジストリに書かれないため、レジストリの監視は確実な検知にならず、永続的なポリシーの検知を補う用途に使えるとも書いた⁠［3］。

iPurple Teamによると、別の研究者がファイルを残さないWMIの対策EDRUnChokerを公開した⁠［3］。EDRUnChokerは5秒ごとにActiveStoreとGPOのQoSポリシーを列挙し、不審なポリシーを消そうとする⁠［3］。不審と判定する条件は、既知のEDRのプロセス名と、1Mbps以下の帯域の2つである⁠［3］。

目次へ

未公表の事項

• 実際の攻撃でのEDRChokerの使用
• Linden Securityが見たURLhausの標本の件数と配布の規模
• MicrosoftとElasticなどEDRの開発元の見解と対策
• Zero SalariumとLinden Securityの試験の条件（試行の回数、製品とOSの版）
• 再起動後もポリシーが残るとした説明とコード解析の食い違いへの作者の説明

注

• 〔注1〕iPurple Teamのコード解析では、EDRChokerはWMIでOwnerを1にしてポリシーを作り、これはメモリ上にあって永続しないActiveStoreへの作成と同等だった⁠［3］。
• 〔注2〕iPurple Teamのコード解析では、ポリシー名は8文字のランダムな文字列だった⁠［3］。

出典

更新記録

• 2026年6月9日：公開した。
• 2026年6月11日：The Hacker Newsの6月11日の記事（出典4）を加え、根拠と範囲の節を改めた。
• 2026年6月17日：iPurple Teamの6月17日の記事（出典3）を加え、根拠と範囲・関係者の対応・注の節を改めた。

目次へ