SOP-78: Security Policy Disabled / Defender Config Tampered (Tamper Protection, ASR, MDE Offboarding) Response | CyberHawk Threat Intel

Tamper Protection exists precisely to stop this. If it went OFF outside a documented policy change, do not rationalise it as "an admin tuning Defender" — a stolen admin token disabling Tamper Protection is the single most reliable pre-payload signal you will see. Confirm-then-isolate; do not wait.

Five yes/no questions decide whether this queues or pages the on-call now. Any single YES on Q1–Q3 makes it an immediate-action SEV1.

Pull the change/CAB record BEFORE you query — if you already hold a ticket that names this device, this change, and this time window, the queries below become confirmation, not discovery, and you save 10 minutes.

Tamper Protection is the lock on the Defender settings door. It is normally managed only by Microsoft (MDE cloud) or Intune — a local process turning it off is almost always malicious and is the highest-fidelity signal in this SOP.

• 1First check Incidents & alerts → Alerts and filter for titles containing "Tamper" — MDE raises a built-in alert when a tamper attempt is observed.
• 2Open Advanced hunting and run the AlertInfo/DeviceRegistryEvents KQL below. Set Time range to Last 24 hours.
• 3For any hit, open the Device timeline from the DeviceName link and read the InitiatingProcess chain — was it PowerShell, reg.exe, or an unknown binary?
• 4Confirm the current live state in Assets → Devices → [device] → Overview — check whether Tamper Protection now reads Off.

A tamper alert with an unknown or user-writable initiating process (not MsMpEng.exe / MpCmdRun.exe under SYSTEM, not the Intune management extension) is a confirmed local tamper. Isolate the host before you finish reading the timeline.

Once Tamper Protection is down, the fastest way to blind Defender is a burst of Set-MpPreference flags or Policies-key writes — cloud protection off, sample submission off, real-time off, script/PUA scanning off. Each persists in configuration and each is individually queryable.

• 1Run the DeviceProcessEvents KQL below for PowerShell / MpCmdRun feature-disable command lines.
• 2Run the paired DeviceRegistryEvents query for the Policies\Microsoft\Windows Defender keys — GUI/registry disablement bypasses PowerShell logging.
• 3Note the value data: MAPSReporting=0, SubmitSamplesConsent=0/2, DisableRealtimeMonitoring=1, DisableScriptScanning=1 all indicate a weakened engine.
• 4Correlate the timestamp with I1 — an exclusion/feature disable that immediately follows a Tamper Protection off is a single confirmed chain.

Attack Surface Reduction (ASR) rules are what block the exact behaviours attackers need — Office spawning child processes, credential theft from LSASS, executable content from email. Flipping a rule from Block (1) to Disabled (0) or Audit (2) removes the block while looking like routine tuning. This is A2 and it means a specific payload is about to run unopposed.

• 1Run the KQL below for AttackSurfaceReductionRules_Actions set to Disabled/Audit via PowerShell, plus the ASR\Rules registry path.
• 2Map any rule GUID in the command line back to its rule name (e.g. block Office child-process, block credential stealing from LSASS) to understand what the attacker just un-blocked.
• 3Check whether the change matches the Intune ASR policy baseline in Endpoint security → Attack surface reduction — a divergence from policy indicates local tampering, not a managed rollout.
• 4Immediately hunt the following minutes on the same host for the behaviour the rule would have blocked (Office→cmd/PowerShell, LSASS access).

Keep the ASR rule-GUID→name lookup table pinned in your runbook. "Rule 3B576869… set to 0" means nothing under pressure; "block executable content from email client set to OFF" tells you the delivery vector in one line.

The most complete blinding is offboarding the sensor entirely: setting OnboardingState=0 under the Advanced Threat Protection policy key and stopping the Sense service. The device stops streaming telemetry to Defender XDR — so the very absence of a device's logs is itself the indicator. Watch also for Windows Security Center provider tampering.

• 1Open Reports → Device health → Sensor health and look for devices flipping to "Inactive" or "Sensor communication error" without a decommission record.
• 2Run the KQL below for OnboardingState registry writes to 0 and for sc stop sense / service-config changes on the Sense service.
• 3Because an offboarded host stops reporting, also run a last-seen query across the fleet — a device that was healthy an hour ago and is now silent, with no shutdown event, is a prime suspect.
• 4Check the Windows Security Center provider keys for registration tampering that would hide the degraded state from the user/Action Center.

An offboarded host is invisible to Advanced Hunting from the moment the Sense service stops. Do not assume "no further telemetry = no further activity." Pivot to Sentinel SecurityEvent / Sysmon / network logs for that host, and physically or remotely re-onboard as part of containment.

Before escalating, pull the artifacts a responder needs and make the call. The pivotal question is always the same: does the initiating identity + a change ticket explain this, or does an unexpected process + a risky prior sign-in indict it?

"An admin probably did it" is a hypothesis, not a verdict. Close as FP ONLY when a change record actually names this device, this change, and this window — and the initiating identity matches the platform service. A stolen admin token is the single most common way this alert is wrongly closed.

Do not re-enable settings and walk away. If the config was tampered by an actor, re-arming it without isolating and hunting simply tells the actor you noticed — they will offboard again or pivot. Contain first, restore second.

• 1If the sensor is still onboarded, initiate a Live Response session and collect running processes + a memory image FIRST — isolation cuts the network but Live Response over the MDE channel still works.
• 2Select Actions (⋮) → Isolate device → Full isolation. If the sensor was already offboarded (I4), isolate at the network/NAC layer or physically pull the host instead.
• 3Contain the initiating account: Entra admin center → Users → [user] → Revoke sessions, then Block sign-in. Revoke BEFORE reset so an issued token cannot be reused.
• 4Run I1–I4 across the subnet / device group to confirm whether the same change hit multiple hosts (automated push = ransomware operator).

If a stolen-admin session drove the change, the account — not just the host — is the incident. Isolating one endpoint while the token roams free lets the attacker weaken the next machine. Contain identity and endpoint together.

If cloud protection or sample submission was disabled, treat any file that executed during the blind window as unverified — re-scan and re-submit those samples once cloud protection is back on. A dropper that dodged the cloud verdict is still on disk.

• Tamper Protection is On and policy-enforced; local override blocked
• All ASR rules report Block; cloud protection, MAPS, sample submission and real-time monitoring re-enabled
• MDE sensor re-onboarded and reporting Active in Sensor health
• Attacker-created exclusions, policy overrides and persistence removed
• I1–I4 re-run returns 0 hits; full scan clean
• Root-cause entry point closed and compromised credentials reset
• Timeline reconstructed and documented for the incident record

Tamper Protection off + sensor offboarded on the same host is a telemetry blackout by an actor who intends to act unseen — page IR and CISO in parallel and assume the payload phase is imminent. Do not wait for a second, "louder" alert; you have already been shown the loudest one.