Registry Parser
← All articles

Detecting T1562.001: defense tampering in the registry

8 min read

Before an attacker runs the loud part of an intrusion, they turn off the things that would catch it. That is what MITRE ATT&CK T1562.001, Impair Defenses: Disable or Modify Tools covers, and on Windows a large share of it lands in the registry. You do not need to disable Defender from a privileged process if you can flip a policy DWORD; you do not need to clear the logs if you can stop the service that writes them. The registry is where the configuration of every defensive control lives, which makes it both the attacker's lever and the defender's single best place to detect the pull. The point of this post is narrow: which keys T1562.001 touches, and what the change looks like when you find it.

The thing that makes registry-based defense tampering tractable to detect is that the legitimate values are nearly constant. A managed estate has a known Defender configuration, a known set of running services, UAC on, the Event Log running. The keys below do not change on a healthy box from one week to the next. That is the whole detection story: baseline them once, treat any deviation as high-signal, and resist the urge to write off a "weird" value as normal noise. There is very little normal noise here.

The registry tamper points

Windows Defender

The first stop for disable Windows Defender registry activity is the policy path: HKLM\SOFTWARE\Policies\Microsoft\Windows Defender. DisableAntiSpyware=1 and DisableAntiVirus=1 are the blunt instruments — they turn the engine off wholesale. DisableRealtimeMonitoring=1 under ...\Windows Defender\Real-Time Protection is the subtler sibling: the product still looks alive but is no longer scanning. None of these should ever be 1 on a protected host. If you manage Defender through Group Policy you will see the policy key populated, but the disable values set to 1 are the tamper signal, not the key's mere presence.

The exclusions are the quieter abuse. HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths, \Extensions, and \Processes each hold a list of values that Defender will not inspect. An attacker who adds C:\Users\Public\ to Paths, or their loader's name to Processes, has carved a blind spot without tripping a single "AV disabled" alert. The detection signal is twofold: any exclusion you did not put there, and specifically any exclusion pointing at a user-writable path (\Users\, \AppData\, \Temp\, \ProgramData\). Legitimate exclusions point at vendor application directories and database files; they do not point at world-writable scratch space.

The Event Log

If they cannot stop you from logging the intrusion, they stop the log. The service definition lives at HKLM\SYSTEM\CurrentControlSet\Services\EventLog. Start=4 (disabled) on that key means the Windows Event Log service will not come up at next boot, and the EVTX channels stop receiving events — this is T1562.002, Disable Windows Event Logging, the close cousin of T1562.001 and frequently part of the same playbook. A Start value of anything other than 2 on EventLog is an emergency. Per-channel tampering lives under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\<channel>, where Enabled=0 silences a specific log (the Security or PowerShell/Operational channels are favourite targets) without the obvious blast radius of stopping the whole service. Walk those Enabled values; they should be 1.

UAC and SmartScreen

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System carries the UAC controls. EnableLUA=0 disables User Account Control outright, which removes the elevation prompt and silently auto-elevates admin-token processes — a meaningful downgrade of the host's posture and a common post-exploitation step. ConsentPromptBehaviorAdmin=0 weakens the prompt without fully killing UAC. SmartScreen sits at HKLM\SOFTWARE\Policies\Microsoft\Windows\System (EnableSmartScreen=0) and ...\Microsoft\Windows Defender\SmartScreen; turning it off removes the reputation check on downloaded and executed binaries. Related, and worth checking in the same pass: SaveZoneInformation=1 under the Attachments policy stops Windows tagging downloaded files with Mark-of-the-Web, defeating the SmartScreen/zone checks downstream (that one is T1553.005). All of these are off-by-default-secure: a 0 where you expect SmartScreen and UAC on is the tell.

Security-tool services

Beyond Defender's own service, attackers disable third-party EDR and AV the same way they disable the Event Log: by editing the service's Start value under HKLM\SYSTEM\CurrentControlSet\Services\<name>. Start=4 on your endpoint agent's service, its driver, or its telemetry service means it will not load at next boot. This is the registry equivalent of sc config <svc> start= disabled, and it is durable across reboots in a way that simply killing the process is not. Build the list of service short-names your security stack registers — the agent, the kernel driver, the updater — and assert Start=2 on every one of them. A flip to 4, or a repointed ImagePath, is the services-hijack pattern applied to defense evasion.

Policy lockdowns

The last category degrades the analyst's tooling rather than the security product's. HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableTaskMgr=1 greys out Task Manager; DisableRegistryTools=1 (same path) blocks regedit; DisableCMD blocks the command prompt. These ship in the per-user NTUSER.DAT. They are crude, sometimes used by commodity malware to frustrate a user trying to investigate their own infected machine, and trivially baseline-able: on a normal user profile these values do not exist. Their mere presence with value 1 is the signal.

Why these are high-signal

The reason to weight these keys heavily is that almost none of them have a benign reason to change on a given host after build time. Compare this to, say, a Run key, where new entries appear legitimately every time software installs. Defender is not supposed to get disabled. The Event Log service is not supposed to stop. UAC does not turn itself off. A user does not normally acquire a DisableRegistryTools policy. The false-positive rate on "this value deviated from the secure default" is low enough that you can afford to alert on the deviation itself rather than waiting for a second corroborating signal. The only honest caveat is the managed-policy case: in a hardened estate some of these are set by GPO. The answer is the same as everywhere else in DFIR — know your baseline. A value set by your own GPO is not the finding; a value set on a host that your GPO does not target is.

How to hunt them

Acquire the offline hives — SOFTWARE and SYSTEM for the machine-wide keys, every NTUSER.DAT for the per-user policy lockdowns — and run a fixed checklist:

  1. Defender policy and exclusions. Dump DisableAntiSpyware, DisableAntiVirus, DisableRealtimeMonitoring, and every value under Exclusions\Paths|Extensions|Processes. Flag any disable value of 1 and any exclusion in a user-writable path.
  2. EventLog service. Read SYSTEM\CurrentControlSet\Services\EventLog\Start. Anything but 2 is a finding. Then walk WINEVT\Channels\*\Enabled.
  3. UAC/SmartScreen. Read EnableLUA, ConsentPromptBehaviorAdmin, EnableSmartScreen, and the attachment SaveZoneInformation. Compare against secure defaults.
  4. Security services. For each service in your security stack, assert Start=2 and an expected ImagePath.
  5. Policy lockdowns. Per NTUSER.DAT, check DisableTaskMgr, DisableRegistryTools, DisableCMD.
  6. Timestamp pivot. Every one of these keys carries a LastWrite. Sort by it. A cluster of these values written inside your suspected intrusion window, against keys otherwise untouched since OS install, is your timeline anchor. Then diff against a VSS snapshot — a disabled value present in the live hive but absent two days ago is the incident, with the window narrowed for you.

Resolve CurrentControlSet correctly when you read the SYSTEM-hive keys; on a hive captured offline the symlink may not point where it does on a live box, and a service Start value differing between ControlSet001 and ControlSet002 is itself worth a look.

Investigate it in your browser

You do not have to walk all of this by eye. This site's automated Findings engine already flags several T1562.001 patterns directly: a Defender exclusion sitting in a user-writable path, DisableAntiSpyware/DisableAntiVirus=1 ("Windows Defender disabled via policy"), the EventLog service set to Start=4, UAC-bypass shell hijacks, and the Mark-of-the-Web suppression value — each tagged with its ATT&CK technique so you can pivot straight from the finding to the matrix. Load the hive, read the Findings tab for the high-signal hits, then use them as leads into the tree to confirm the surrounding values by hand. You can analyze a SOFTWARE hive in your browser with nothing installed — the parsing and the rule evaluation run client-side, so the hive never leaves the machine, which matters when you are working evidence.

Related techniques

For the broader map of how attacker behaviour lands in the registry, see MITRE ATT&CK and the registry. T1562.001 rarely travels alone: the defense tampering is the setup, and the payoff is usually persistence or execution elsewhere. The services-as-persistence deep-dive covers the same Services\<name> keys from the persistence angle — the Start value an attacker flips to 4 to kill your EDR is the same one they flip to 2 to launch their own service. And because much of T1562.001 is just writing a specific value to a specific key, it sits squarely inside T1112, Modify Registry; the techniques overlap by design. Hunt the values, baseline the defaults, and treat any deviation as the high-signal lead it almost always is.

The authoritative reference is MITRE ATT&CK T1562.001.