Microsoft Defenderで「Defend Not」などの無効化ツールを防ぐ方法とTamper Protection・MDEの実践対策

「Defend Not」のような“Microsoft Defender 無効化ツール”が話題になるたびに、「Defender だけで本当に守れるのか？」「企業向け MDE と家庭向け Defender で何が違うのか？」と不安になる方は多いと思います。本記事では、Windows Security Center API を悪用して Defender を無効化しようとするツールを想定しつつ、Tamper Protection（改ざん防止）と Microsoft Defender for Endpoint（MDE）を軸に、具体的な防御策と運用ポイントを詳しく解説します。

Microsoft Defender は「Defend Not」を防げるのか？Tamper Protection と MDE で徹底検証

「Defend Not」問題の整理 ― 何が気になるのか

ここでいう「Defend Not」は、Windows Security Center API や Defender 用のレジストリ／サービスを操作して、Microsoft Defender を停止・弱体化させることを狙った攻撃ツールの総称として扱います（特定ツールの逆アセンブル解説ではありません）。

多くの管理者・利用者が気にしているポイントは、次の 3 つです。

Microsoft Defender 単体（オンプレ／ローカルの Defender Antivirus）で、こうした無効化ツールを防げるのか。
企業向けの Microsoft Defender for Endpoint（MDE）と、家庭向け・個人 PC の標準 Defender で、どの程度差があるのか。
現場でいますぐ実施できる、具体的な設定・運用のベストプラクティスは何か。

結論から言えば、「最新の Windows ＋ Tamper Protection（改ざん防止）を有効化していれば、『Defend Not』タイプの“Defender 無効化攻撃”に対して、個人向け Defender でも十分に強い防御が可能」です。その上で、企業環境では MDE の EDR・高度なハンティング・自動修復機能を組み合わせることで、検知・調査・封じ込めのレベルを一段引き上げられます。

「Defend Not」の想定動作とリスク

Windows Security Center API を悪用するとは

Windows には、セキュリティ製品の状態（アンチウイルスの有効／無効など）を管理するための Windows Security Center API が用意されています。通常は、正規のセキュリティ製品が自分の状態を OS に通知する目的で利用しますが、管理者権限を得た攻撃ツールがこの API や関連サービスに不正アクセスすると、次のようなことを試みます。

リアルタイム保護のオフ、クラウド提供保護の無効化、サンプル送信の停止など、Defender の重要設定をまとめて無効化する。
Windows Defender サービス（WinDefend、MsMpEng.exe など）を停止したり、スタートアップ種別を変更して再起動後も起動しないようにする。
ポリシー用レジストリキー（例：HKLM\SOFTWARE\Policies\Microsoft\Windows Defender 配下）を不正に書き換えて、Defender が起動しにくくなる状態を作る。

古い Windows や Tamper Protection が無効な環境では、こうした“Defender 無効化攻撃”が成功しやすく、その後にランサムウェアや情報窃取マルウェアを投入される典型的な流れになります。

典型的な無効化手口の例

「Defend Not」タイプのツールがよく狙うポイントを整理すると、次のようになります。

PowerShell の Set-MpPreference コマンドを悪用し、リアルタイム保護やクラウド保護を無効化。
DisableAntiSpyware やその他の Defender ポリシー用キーをレジストリに書き込み、Defender 起動を抑止（※現行バージョンでは非推奨・保護対象）。
サービスコントロール（SC.exe / PowerShell）で WinDefend サービスの停止・スタートアップ種別変更を試行。
Windows Security アプリ自体の起動を妨害し、ユーザーが状態を確認できないようにする（ただし、アプリを止めても Defender エンジン自体は別プロセスとして動き続ける仕様）。

こうした操作がすべて成功してしまうと、Defender の防御力は大きく低下します。そこで鍵を握るのが、次章で解説する「Tamper Protection（改ざん防止）」です。

結論を先に：Defend Not 対策の全体像

詳細な仕組みに入る前に、ざっくりとした答えを整理しておきます。

環境	Defend Not への耐性	必須の前提	追加の推奨対策
個人 PC（Windows 10/11, Defender のみ）	Tamper Protection を ON・OS/Defender を最新にしていれば、Defender 無効化の多くはブロック可能	標準の Windows Update、Tamper Protection ON	標準ユーザー運用、Smart App Control、有効な UAC 設定
企業 PC（MDE 未導入、Defender のみ）	個人 PC と同等だが、運用規模が大きい分、「誰かが Tamper Protection を切ってしまう」リスクに注意	グループポリシー／セキュリティベースラインでの一括設定	ログの集中収集、EDR 製品導入の検討
企業 PC（MDE 導入）	Tamper Protection＋EDR による行動検知で、“Defender 無効化” 自体がインシデントとして検知・調査・自動修復可能	MDE onboarding、ポリシー／ロール設定	高度なハンティング、EDR アラートの運用プロセス整備

ポイントは、「Tamper Protection を ON にしておく」ことが、個人・企業を問わず 最重要の土台 になるという点です。ここを押さえるだけで、「Defend Not」タイプの攻撃ツールが触れる設定の多くが OS レベルでガードされます。

最重要：改ざん防止（Tamper Protection）を有効にする

Tamper Protection が守ってくれるもの

Tamper Protection は、「Defender の重要設定を、ローカル管理者やマルウェアから守るため」の仕組みです。Windows 10 バージョン 1903 以降および Windows 11 では、コンシューマ向けには既定で有効、企業向けではポータルや Intune などで一括制御できるようになっています。

Tamper Protection が有効な場合、次のような操作は、たとえローカル管理者権限を持つユーザーであっても制限されます。

リアルタイム保護、クラウド提供保護、自動サンプル送信など、Defender のコア設定の変更。
DisableAntiSpyware をはじめとする Defender 関連レジストリキーの書き換えや削除。
一部の PowerShell コマンドレット（Set-MpPreference など）を用いた無効化／低減化の試行。
ポリシーに反する構成変更（たとえば GPO から無効化を試みても、Tamper Protection 有効時は無視される）。

内部的には、Tamper Protection はカーネルモードドライバー（WdFilter.sys）等を使って Defender の設定・レジストリ領域を監視し、不正な変更をブロック／ロールバックしています。　そのため、「Defend Not」タイプのツールがレジストリやサービス設定を書き換えようとしても、Tamper Protection が有効な限り、多くの場合は失敗します。

Windows 11 / 10 個人 PC での有効化手順

個人 PC で Tamper Protection を確認・有効化する手順は次の通りです（Windows 10 / 11 共通）。

スタート ボタン → 設定を開く。
プライバシーとセキュリティ → Windows セキュリティ をクリック。
Windows セキュリティを開く ボタンを押し、ウイルスと脅威の防止 を選択。
ウイルスと脅威の防止の設定 の項目にある 設定の管理 をクリック。
下の方にある 改ざん防止 をオンに切り替える。

もし「この設定は組織によって管理されています」「Tamper Protection は組織によって管理されています」と表示されていてローカルから変更できない場合は、企業や学校のポリシー制御が有効です。その場合、勝手に無効化するのではなく、管理者（情報システム部門など）に確認しましょう。

企業環境：ポータルから一括設定する

MDE を利用している企業では、Microsoft Defender ポータルから Tamper Protection を一括管理できます。代表的な手順は次の通りです。

Microsoft Defender ポータルにサインインする。
設定（Settings） → エンドポイント（Endpoints） を開く。
一般（General） → 高度な機能（Advanced features） を選択。
一覧の中から Tamper protection を探し、オンに切り替えて保存する。

Intune や Configuration Manager を併用している場合は、同様にポリシーとして Tamper Protection を有効にできるため、「一部の端末だけ Tamper Protection が OFF だった」という穴が生まれないようにする ことが重要です。

Tamper Protection の有無による違い

項目	Tamper Protection OFF	Tamper Protection ON
レジストリによる Defender 無効化（DisableAntiSpyware など）	一部環境では成功する可能性あり（非推奨かつ今後さらに制限）	設定変更はブロック・無視される。キー自体も保護対象。
PowerShell からのリアルタイム保護無効化	管理者権限があれば成功しやすい	ポリシーや Tamper Protection に反する変更は失敗または即座にロールバック
誤操作・悪意あるローカル管理者による操作	設定をオフにされたことに気づきにくい	多くの変更がブロックされ、ログにも Tamper Protection によるブロックが記録される

このように、Tamper Protection を ON にするだけで、「Defend Not」が狙う典型的な無効化手口のかなりの部分をつぶすことができます。

Microsoft Defender for Endpoint（MDE）の追加防御力

企業環境では、クライアント／サーバーを Microsoft Defender for Endpoint にオンボードしておくことで、「Defend Not」のような無効化ツールに対してさらに強力な検知・対応が可能になります。

EDR による「Defender 無効化」の行動検知

MDE の EDR（Endpoint Detection and Response）は、マルウェアや攻撃ツールの「挙動」を時系列で記録・分析します。そのため、次のような行動を「Defender 無効化を試みる不審行為」として検知できます。

MpCmdRun.exe や Set-MpPreference を不自然な引数で繰り返し実行（リアルタイム保護 OFF など）。
短時間に複数回、Defender 関連サービスの停止・スタートアップ種別変更を試行。
Defender のレジストリキーに対する連続した書き込み失敗（Tamper Protection によるブロック）と、それに続く怪しいプロセス活動。
Windows Security Center API を利用するプロセスの中に、通常存在しないカスタムツールや C&C 通信中のプロセスが含まれている。

こうしたシグナルは、「Defender が実際に無効化された／されそうになった」瞬間だけでなく、「無効化を試みて失敗したが、その後に別の攻撃手法を試している」といった文脈も含めて分析されます。

また、サードパーティ製アンチウイルスをメインに使う環境向けには、「EDR in block mode」という機能もあります。これは、Defender が“第 2 の防御ライン”として、他ベンダー製 AV が見逃した脅威をブロックするためのモードで、MDE の設定画面から有効化できます。ただし、既に Defender 自身をメイン AV として使っている環境では、通常は EDR in block mode を別途オンにする必要はありません。

高度なハンティングで「怪しい無効化」を追跡する

MDE の「高度なハンティング」機能（Kusto Query Language / KQL）を使うと、「Defend Not」タイプの振る舞いを自分でパターン化して、継続的に監視することができます。例えば、次のようなクエリ例が考えられます。

// Defender の設定変更を試みる PowerShell / MpCmdRun を検出
DeviceProcessEvents
| where Timestamp &gt; ago(7d)
| where FileName in ("powershell.exe", "pwsh.exe", "MpCmdRun.exe")
| where ProcessCommandLine has_any (
    "Set-MpPreference",
    "DisableRealtimeMonitoring",
    "DisableIOAVProtection",
    "DisableBehaviorMonitoring",
    "DisableAntiSpyware"
)
| project Timestamp, DeviceName, AccountName,
          FileName, ProcessCommandLine, InitiatingProcessFileName

// Defender 関連レジストリキーへの書き込み
DeviceRegistryEvents
| where Timestamp &gt; ago(7d)
| where RegistryKey has @"HKLM\SOFTWARE\Policies\Microsoft\Windows Defender"
| where ActionType in ("RegistryValueSet", "RegistryKeyDeleted")
| project Timestamp, DeviceName, AccountName,
          RegistryKey, RegistryValueName, PreviousRegistryValueData,
          RegistryValueData, InitiatingProcessFileName, InitiatingProcessCommandLine

これらのクエリをベースに、社内で実際に使っている運用ツールやスクリプトをホワイトリスト化し、それ以外の不審なコマンドラインだけをアラートにする、といったチューニングを行うことで、「Defender 無効化ツールだけを高精度に拾い上げる」ことも可能です。

自動修復・ポリシー強制で“無効化されっぱなし”を防ぐ

MDE では、Defender の設定がポリシーと異なる状態になった場合に、自動的に修復する機能も利用できます。また、Tamper Protection が有効な状態では、「トラブルシューティングモード」を使って一時的に Tamper Protection を緩め、作業完了後に元のポリシーへ自動で戻す、といった運用も可能です。

これにより、「現場対応のために一時的に Defender を弱めたが、そのまま戻し忘れていた」といった人的ミスによるリスクを大幅に減らせます。

クラウド連携なしの個人利用でも守れるのか？

前提：最新の Windows / Defender を使うことが大前提

個人利用で MDE を契約していない場合でも、「Tamper Protection ON ＋ OS／Defender を最新」にしておけば、「Defend Not」タイプのツールに対する耐性はかなり高くなります。

Windows 10 1903 以降では、DisableAntiSpyware キーによる Defender 無効化は非推奨となり、多くのケースで無視されます。
Defender が完全に無効化されていると、セキュリティインテリジェンスやエンジン・プラットフォームの更新が行えず、最新の脅威に対応できません。
クラウド提供保護をオンにしておくことで、新しい無効化ツールそのものをマルウェアとして検知・ブロックできる可能性も高まります。

したがって、ホームユーザーであっても、Windows Update を停止しない／Defender の更新をブロックするような“チューニングツール”は使わない ことが何より重要です。

ホームユーザー視点の 3 つのシナリオ

個人利用者の現実的なシナリオをイメージすると、Defender の守り方も見えてきます。

標準ユーザーでログオンし、UAC を有効のまま使っているケース
この場合、「Defend Not」タイプのツールは管理者権限を必要とするため、実行時に UAC の昇格ダイアログが表示されます。ここで「許可しない」を選べば、そもそも Defender 無効化の試みまで到達しません。Tamper Protection は“最後の砦”として働くイメージです。
常に管理者アカウントでログオンしているケース
正直に言うと、ここが最も危険です。攻撃ツールが管理者権限で実行されるため、Tamper Protection や OS 自体の防御機構が頼みの綱になります。Tamper Protection が OFF だと、「Defend Not」タイプのツールが Defender を弱体化できる可能性が大きく上がります。
古い Windows（または長期間アップデートしていない）を使用しているケース
DisableAntiSpyware など古い手法がまだ有効である可能性があり、無効化ツールにとって“おいしいターゲット”になります。OS を最新バージョンに更新するか、サポートの続くバージョンへ移行することが不可欠です。

対策としては、「標準ユーザーでの日常利用」「UAC は原則デフォルト以上」「Tamper Protection ON」「Windows Update 自動更新」の 4 点セットを守るだけで、Defender 無効化ツールへの耐性は大きく向上します。

「Defend Not」タイプの攻撃の前提条件と限界

「Defend Not」に代表される Defender 無効化ツールは強力に見えますが、実際にはいくつかの前提条件や限界があります。それらを理解しておくと、対策の優先度付けがしやすくなります。

攻撃ステップ	攻撃側の前提条件	目的	Defender / MDE 側の対抗策
無効化ツールのダウンロード・実行	ユーザーがファイルを実行する／マクロを有効化する	端末上で攻撃コードを走らせる	Defender によるマルウェア検知、SmartScreen、Smart App Control、アプリケーション制御
管理者権限の取得	管理者アカウントでのログオン、もしくは UAC 昇格の承認	Defender の設定・サービスにアクセスできるようにする	標準ユーザー運用、強い UAC 設定、LAPS 等によるローカル管理者パスワード管理
Defender 設定の変更・サービス停止	OS の防御機構が緩い、Tamper Protection が OFF	リアルタイム保護などを無効化し、後続攻撃を検知されにくくする	Tamper Protection、MDE による挙動検知、ログ監視（Event ID 5001, 5007, 5013 など）
後続のランサムウェア／情報窃取	ネットワーク到達性、横展開可能な環境	暗号化・窃取・持続化	Defender の振る舞い検知、ASR ルール、EDR による横展開検知、自動隔離

この表から分かる通り、「Defender 無効化」までの道のりは一見短そうでいて、いくつもの段階を踏む必要があります。こちら側としては、どこか 1 段階でも確実に止められればよい わけで、その最有力候補が Tamper Protection という位置付けになります。

追加ベストプラクティスで防御を固める

管理者権限を最小化する

Defender 無効化ツールの多くは、管理者権限を前提として作られています。したがって、「ユーザーが日常作業を標準ユーザーで行う」だけでも、成功率は大きく下がります。

通常利用用の標準ユーザーアカウントと、管理者作業用アカウントを分ける。
UAC の通知レベルを下げない（既定値またはそれ以上を維持）。
企業では、ローカル管理者アカウントを LAPS などで一元管理し、利用履歴を監査する。

「ローカル管理者権限を広く配布するのが当たり前」という文化を改めることが、Defender 無効化ツールへの最も効果的な対策のひとつです。

アプリケーション制御で未知ツールを止める

Defender 無効化ツールは、基本的にはどこかに保存された実行ファイル（EXE／DLL）やスクリプト（PS1／BAT／VBS など）として動作します。そこで、アプリケーション制御を組み合わせることで、「そもそも怪しいツール自体を実行させない」というアプローチが有効です。

Windows 11 Home / Pro では、Smart App Control をオンにすることで、信頼できないアプリや署名のないソフトの実行を OS レベルでブロック可能。
企業環境 では、Windows Defender Application Control（WDAC）や AppLocker を使い、「署名付き・承認済みアプリのみ実行可能」「ユーザーの書き込み可能フォルダからは EXE を実行不可」といったルールを構成。

これにより、「Defend Not」のような単体ツールだけでなく、将来現れる類似ツールもまとめてブロックすることができます。

ASR ルールやクラウド保護を活用する

Microsoft Defender には、Attack Surface Reduction（ASR）ルールと呼ばれる攻撃面削減機能があります。たとえば、次のようなルールは、「Defender 無効化ツールの前段で実行されがちな Office マクロやスクリプトによる攻撃」を抑止するのに有効です。

Office が子プロセスを起動するのをブロック。
不審なスクリプトの実行を制限。
LSASS や資格情報への不正アクセスをブロック。

さらに、クラウド提供保護を有効にしておけば、Microsoft セキュリティ研究チームが日々収集する新しい攻撃ツールのシグネチャや挙動ルールが即座に反映され、「Defend Not」の派生・亜種の検出にも追随しやすくなります。

ログを集約して「無効化の兆候」をモニタリングする

Defender は、Windows イベントログ（Microsoft-Windows-Windows Defender/Operational など）に詳細な情報を書き込みます。主なイベントの例は次の通りです。

Event ID 1116：マルウェア検出（MALWAREPROTECTION_STATE_MALWARE_DETECTED）。
Event ID 5001：リアルタイム保護が無効化された（MALWAREPROTECTION_RTP_DISABLED）。
Event ID 5007：Defender 設定が変更された（MALWAREPROTECTION_CONFIG_CHANGED）。
Event ID 5013：Tamper Protection による設定変更のブロック（MALWAREPROTECTION_SCAN_CANCELLED）。

これらのイベントを SIEM やログ管理基盤（Syslog, Wazuh, Graylog など）に集約し、次のようなルールでアラートを出すと有効です。

短時間に複数の端末で 5001（リアルタイム保護 OFF）が発生した。
同じ端末で、1116（マルウェア検出）に続いて 5001 や 5007 が発生した。
5013（Tamper Protection によるブロック）が頻発している端末がある。

こうしたイベントは、「Defend Not」タイプの攻撃ツールが試行された痕跡である場合が多く、早期検知とフォレンジックの起点として非常に有用です。

実運用での具体的なチェックリスト

個人・小規模環境向けチェックリスト

Windows 10 / 11 をサポート期限内のバージョンに保ち、Windows Update を止めていないか。
Microsoft Defender の リアルタイム保護 と クラウド提供保護 が ON になっているか。
改ざん防止（Tamper Protection） が ON になっているか。
日常作業を標準ユーザーで行い、UAC を既定値以上に保っているか。
「チューニングツール」や「軽量化ツール」を名乗るソフトが、Defender や Windows Update を勝手に無効化していないか。

企業・組織向けチェックリスト

すべての端末で Tamper Protection の設定状態を一元把握できているか（ポータル・Intune・GPO など）。
MDE 導入済みであれば、Defender 関連の高度なハンティングクエリを定期的に実行しているか。
Defender のイベントログ（1116, 5001, 5007, 5013 など）が SIEM に取り込まれているか。
ローカル管理者アカウントの配布状況・パスワード管理（LAPS 等）、利用申請フローが整備されているか。
アプリケーション制御（WDAC / AppLocker）や ASR ルールが、業務影響を抑えつつ有効に構成されているか。
トラブルシューティング目的で Defender を弱める際の手順と、終了後に必ず元に戻す運用ルールが明文化されているか。

よくある疑問と誤解

「Windows Security アプリを無効にしたら Defender も止まる？」

いいえ。Windows Security アプリは、Defender を含むセキュリティ状態を表示・設定するためのフロントエンドであり、アプリ自体を停止・無効化しても、Defender エンジン（アンチウイルス）やファイアウォールは別のサービスとして動作し続けます。

むしろ、Windows Security アプリを無効化すると、「Defender が再度有効化されるきっかけを失う」「状態の表示が古いままになる」といった副作用の方が問題になるため、意図的に無効化するのは推奨されません。

「レジストリの DisableAntiSpyware で簡単に無効化できる？」

これは過去の話です。現在の Windows 10 / 11 では、DisableAntiSpyware は非推奨（deprecated）となっており、Tamper Protection が有効な環境では、このキーを使った無効化は基本的に無視されます。

「ネットの古い記事に書いてあったから」といって安易にレジストリを変更すると、OS のサポートポリシーとずれた状態になり、想定外の挙動や将来のアップデート時の不具合を招く可能性があります。

「検証のために本番端末で Tamper Protection を OFF にしていい？」

原則としておすすめしません。どうしても必要な場合は、次のような方針を徹底してください。

できる限り検証用の隔離された環境（ラボ、仮想マシン）で行う。
本番端末で行う場合は、MDE の「トラブルシューティングモード」など、時間制限付きの一時的な緩和機能を利用し、作業が終われば自動的に元のポリシーへ戻るようにする。
誰が・いつ・どの端末で Tamper Protection を変更したかを記録し、レビューするプロセスを持つ。

まとめ：Defender を「最後まで戦う防御役」にする

「Defend Not」のような Defender 無効化ツールは、いかにも強力に聞こえますが、実際には次のようなポイントを押さえるだけで、防御側の優位に立つことができます。

Tamper Protection（改ざん防止）を必ず ON にする。 これだけで多くの無効化手口が封じられます。
OS と Defender を常に最新に保つ。 非推奨となったレジストリによる無効化手法などを OS 側が無視するようになっているため、アップデートを止めないことが重要です。
標準ユーザー運用＋アプリケーション制御で、「そもそも無効化ツールを実行させない」設計にする。
企業環境では MDE の EDR・高度なハンティング・自動修復を活用し、「Defender 無効化の試み」そのものをインシデントとして扱う。
ログの集中管理・監視で、「Defender が弱められた痕跡」をすばやく検知する。

Defender は「無料だから弱い」「サードパーティ製より頼りない」と誤解されがちですが、Tamper Protection や MDE を含むエコシステム全体で見ると、むしろ OS と深く統合された強力なプラットフォームです。「Defend Not」のような無効化ツールに怯えるのではなく、設定と運用を少し見直すだけで、Defender を“最後まで戦い続ける防御役”に育てることができます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Defenderで「Defend Not」などの無効化ツールを防ぐ方法とTamper Protection・MDEの実践対策

Microsoft Defender は「Defend Not」を防げるのか？Tamper Protection と MDE で徹底検証

「Defend Not」問題の整理 ― 何が気になるのか