Overview

Disable or Modify Security Tools (T1562.001) describes attacker actions taken to impair, stop, or tamper with defensive software — including antivirus engines, EDR agents, host-based firewalls, logging pipelines, and SIEM forwarders — so that subsequent malicious activity goes undetected. Attackers may kill processes, alter service configurations, modify registry keys, tamper with policy settings, or uninstall security products entirely to blind the defenders watching the environment.

This technique is a near-universal component of serious intrusions: if an attacker can silence your sensors before executing the main payload, every downstream detection capability fails. Detecting T1562.001 early — ideally before the primary objective is reached — gives defenders a critical window to interrupt the kill chain while the attacker is still in a preparation phase.

Attacker Perspective

Attackers disable or modify security tools as a prerequisite step to ensure that credential dumping, ransomware execution, data exfiltration, or lateral movement will not trigger an alert or be blocked by a defensive agent.

• AV/EDR Process Kill: Using taskkill /F /IM MsMpEng.exe or net stop WinDefend to terminate Windows Defender or third-party EDR agent processes (e.g., CrowdStrike Falcon sensor CSFalconService, SentinelOne SentinelAgent.exe) before dropping a ransomware payload.
• Registry Tampering: Disabling Windows Defender real-time protection via Set-MpPreference -DisableRealtimeMonitoring $true or directly writing HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware = 1 to suppress the engine without killing its process.
• Log and Audit Manipulation: Running auditpol /set /category:* /success:disable /failure:disable to clear Windows audit policy, or stopping Syslog/Winlogbeat forwarder services (net stop winlogbeat) to create a logging gap before executing lateral movement.
• Firewall Rule Modification: Adding permissive rules or disabling the host firewall entirely via netsh advfirewall set allprofiles state off or Set-NetFirewallProfile -All -Enabled False to allow C2 callbacks on non-standard ports that would otherwise be blocked.

This technique is uniquely attractive because it is a force multiplier — a single successful tamper action can invalidate an entire detection stack, giving the attacker free rein for all subsequent activity.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Process Creation (Event ID 4688): Enable via GPO Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation. Also enable command-line logging: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled = 1. Without command-line capture, you see the process but not the arguments.
• Sysmon Event ID 1 (Process Create), ID 12/13 (Registry Create/Set), ID 7 (Image Load), ID 3 (Network Connect): Deploy Sysmon with a community-vetted config (e.g., SwiftOnSecurity or Olaf Hartong’s modular config). Sysmon provides richer process metadata (hashes, parent GUIDs) than native Event ID 4688 alone.
• Windows System Event Log — Service Control Manager (Event ID 7036, 7040, 7045): Event ID 7036 records service state changes (started/stopped); 7040 records start type changes (e.g., automatic → disabled); 7045 records new service installation. No additional audit policy is required — these log by default.
• Windows Security Event Log — Audit Policy Changes (Event ID 4719): Enable via Advanced Audit Policy → Policy Change → Audit Audit Policy Change. This fires any time auditpol or Group Policy modifies the audit configuration — a direct signal for log tampering.
• Windows Security Event Log — Registry Object Access (Event ID 4657) and Registry Value Modification: Requires enabling object access auditing on specific registry keys (HKLM\SOFTWARE\Policies\Microsoft\Windows Defender, HKLM\SYSTEM\CurrentControlSet\Services\) and setting a SACL on those keys via Group Policy Preferences or directly in regedit. Sysmon Event ID 12/13 is often easier to operationalize for this purpose.
• PowerShell Script Block Logging (Event ID 4104): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging = 1. Also enable Module Logging (EnableModuleLogging = 1) to catch cmdlet-level activity even when obfuscation is used. These log to Microsoft-Windows-PowerShell/Operational.
• Windows Defender/EDR Tamper Protection Logs: Windows Defender logs tamper attempts to the Microsoft-Windows-Windows Defender/Operational channel (Event IDs 5001, 5007, 5010, 5012). Event ID 5001 = real-time protection disabled; 5007 = configuration changed; 5010/5012 = on-access/behavior monitoring disabled. Forward these to your SIEM.
• Linux Auditd: Add rules to /etc/audit/rules.d/security-tools.rules: -w /usr/bin/auditctl -p x -k audit_tamper, -w /etc/audit/audit.rules -p wa -k audit_tamper, -w /etc/clamav/ -p wa -k av_tamper, and -a always,exit -F arch=b64 -S kill -k process_kill. Use auditd + audisp-syslog or Filebeat to forward to your SIEM.
• macOS Endpoint Security Framework / Unified Log: Use an EDR that consumes the Apple Endpoint Security Framework, or enable OpenBSM auditing for process execution and file writes. Monitor /Library/LaunchDaemons/ and /Library/LaunchAgents/ for modifications to security tool plist files.
• SIEM Forwarder Health Telemetry: Many SIEMs expose an internal data gap or heartbeat — monitor for hosts that stop sending events for more than 5–10 minutes. In Splunk this is a tstats gap query; in Sentinel this is the Heartbeat table; in Elastic use Fleet agent status. A sudden log gap from a previously active host is itself an indicator of forwarder tampering.

Key Indicators

• Security tool process termination: In Sysmon Event ID 1 or Windows Event ID 4688, look for process_name = taskkill.exe with command_line containing known security product process names: MsMpEng.exe, CSFalconService.exe, SentinelAgent.exe, cb.exe, bdagent.exe, mcshield.exe, avgnt.exe. Also watch for process_name = sc.exe with arguments stop or delete targeting those service names.
• PowerShell AV/EDR tamper commands: In PowerShell Event ID 4104, look for ScriptBlockText containing Set-MpPreference combined with any of: -DisableRealtimeMonitoring, -DisableBehaviorMonitoring, -DisableIOAVProtection, -DisableScriptScanning, -ExclusionPath, -ExclusionExtension. Adding exclusions is frequently used to carve out a path for payload execution without full AV disable.
• Auditpol tampering: In Event ID 4688 or Sysmon Event ID 1, look for process_name = auditpol.exe with command_line containing /success:disable or /failure:disable. Correlate with Event ID 4719 showing subcategory audit policy changes.
• Windows Firewall disabled: In Event ID 4688/Sysmon Event ID 1, look for process_name = netsh.exe with command_line matching advfirewall set * state off. Alternatively, look for PowerShell Event ID 4104 with Set-NetFirewallProfile and -Enabled False. Windows Firewall state changes also generate Event ID 2003 in the Microsoft-Windows-Windows Firewall With Advanced Security/Firewall log.
• Registry modifications to Defender policy keys: In Sysmon Event ID 13 (RegistryValueSet), look for TargetObject containing HKLM\SOFTWARE\Policies\Microsoft\Windows Defender with Details showing values like DisableAntiSpyware = 1 or DisableAntiVirus = 1. Parent process being anything other than a known management tool (SCCM, Intune MDM agent) is suspicious.
• Security service start-type changed to disabled: In System Event Log Event ID 7040, look for param1 (service name) matching known security services (WinDefend, Sense, MBAMService, CylanceSvc) and param3 = disabled (start type changed to disabled).
• Suspicious parent-child process relationship: In Sysmon Event ID 1, look for parent_image = cmd.exe or powershell.exe spawning sc.exe, taskkill.exe, or reg.exe where parent_user is not a known admin service account. Especially suspicious if parent_image is an Office application, browser, or script interpreter.
• Log forwarder service stopped: In System Event Log Event ID 7036, look for param1 matching forwarder service names: Winlogbeat, SplunkForwarder, AzureMonitorAgent, MMA (Microsoft Monitoring Agent), elastic-agent, fluentd — combined with param2 = stopped.
• Tamper protection alert from Defender: In the Microsoft-Windows-Windows Defender/Operational log, Event ID 5001 (real-time protection disabled) or Event ID 5007 (configuration change) with New Value showing a permissive configuration should be treated as a high-priority indicator regardless of the process that triggered it.

Detection Logic

Rule 1 (Broad — High Sensitivity): Security Tool Process or Service Stopped
IF (process_name IN ["taskkill.exe","sc.exe","net.exe","net1.exe"] AND command_line MATCHES ["MsMpEng","WinDefend","CSFalconService","SentinelAgent","cb.exe","bdagent","CylanceSvc","MBAMService","Winlogbeat","SplunkForwarder","elastic-agent"]) OR (event_id = 7036 AND param1 IN ["WinDefend","Sense","MBAMService","CylanceSvc","SplunkForwarder","Winlogbeat"] AND param2 = "stopped") THEN alert(severity=HIGH)

This rule catches the most common and direct method of disabling security tools — process or service termination. It will produce moderate alert volume in environments with active patching or legitimate admin activity; use the tuning guidance below to suppress known-good paths. Expected volume: 5–20 alerts/day in a mid-size environment before tuning.

Rule 2 (Targeted — PowerShell AV Tampering): Set-MpPreference Abuse
IF event_id = 4104 AND script_block_text MATCHES ["Set-MpPreference"] AND script_block_text MATCHES ["-DisableRealtimeMonitoring","-DisableBehaviorMonitoring","-DisableIOAVProtection","-ExclusionPath","-ExclusionExtension","-DisableScriptScanning"] AND NOT (user IN [known_admin_accounts] AND parent_process IN ["sccm.exe","ccmexec.exe","intune_management_extension.exe"]) THEN alert(severity=HIGH)

PowerShell-based AV configuration changes are a strong signal because legitimate management tools use APIs or GPO rather than cmdlets executed interactively. This rule has low false positive volume after the management platform exclusion is in place. Expected volume: 1–5 alerts/day before tuning, near-zero after.

Rule 3 (Targeted — Audit Policy Disabled): Auditpol Tamper
IF (process_name = "auditpol.exe" AND command_line MATCHES ["/success:disable","/failure:disable"]) OR (event_id = 4719 AND subcategory_guid != "" AND setting_value IN ["No Auditing"]) THEN alert(severity=CRITICAL)

Legitimate audit policy changes are rare and almost always performed via GPO from a domain controller, not interactively on an endpoint. This rule should produce near-zero false positives and should be treated as a critical, high-urgency alert requiring immediate investigation. Expected volume: fewer than 1 alert/day in most environments.

Rule 4 (Precision — Log Telemetry Gap): Host Goes Silent
IF host was sending events (event_count > 0 in previous 60 minutes) AND event_count = 0 for current 10-minute window AND host NOT IN [known_maintenance_window_list] AND host NOT IN [recently_rebooted_hosts] THEN alert(severity=MEDIUM, host=affected_host)

This rule catches the scenario where an attacker kills or tampers with the log forwarder itself, creating a blind spot that none of the other rules can fire into. It is best implemented using your SIEM’s native heartbeat or data gap monitoring capability (e.g., Sentinel Heartbeat table, Splunk tstats gap detection). False positive sources include planned reboots, patching windows, and network outages — correlate with change management records.

Tuning Guidance

• Endpoint management platforms (SCCM/MECM, Intune, Tanium, BigFix): These tools legitimately stop and restart security services during patch cycles. Identify the specific service accounts and parent process names used by your management platform (e.g., ccmexec.exe, intune_management_extension.exe) and add exclusions as: AND NOT (parent_process IN ["ccmexec.exe","intune_management_extension.exe"] AND user IN ["SYSTEM",""]). Do NOT exclude the entire SYSTEM account — scope it to the known management process name.
• Security product self-updates: AV engines and EDR agents stop and restart their own services during definition or version updates. Capture the hashes or signed binary paths of your specific vendor’s update processes and exclude them: AND NOT (process_name = "MpCmdRun.exe" AND process_hash IN [known_good_hashes]). Use hash-based exclusions rather than name-based ones to prevent masquerading.
• Planned maintenance windows: Build a dynamic exclusion list in your SIEM fed from your change management system (ServiceNow, Jira, etc.). During approved maintenance windows, suppress Rule 1 and Rule 4 alerts for the specific hosts listed in the change ticket. Do not suppress Rules 2 and 3 — no legitimate change process requires interactive PowerShell AV tampering or audit disablement.
• Security team and red team activity: Your own security team may run tools like Invoke-AtomicRedTeam that exercise these techniques in testing. Maintain a list of authorized testing source hosts and a testing schedule, and add a time-bounded exclusion: AND NOT (host IN [pentest_hosts] AND timestamp BETWEEN [test_start, test_end]). Require the red team to notify SOC before each test to avoid wasted investigations.
• Virtual desktop and ephemeral infrastructure: Non-persistent VDI hosts that reset daily may trigger the telemetry gap rule repeatedly as they shut down on schedule. Add an exclusion for hosts in the VDI OU or subnet: AND NOT (host IN [vdi_subnet] AND hour_of_day BETWEEN [18,07]) to suppress after-hours shutdown gaps.

When the Alert Fires: Investigation Steps

1. Verify the alert is real — confirm the raw event exists in the source log. Pull the raw event from the originating log source (e.g., query Sysmon Event ID 1 or Windows Event ID 4688 directly from the host’s forwarded logs in your SIEM) and confirm the event fields match what the detection rule fired on. Do not begin escalation based solely on the alert — confirm the underlying data to rule out SIEM parsing errors or false correlation.
2. Identify the affected host and user — flag if privileged. Note the hostname, domain, user, and logon_type from the event. Cross-reference the user account against your identity provider (Active Directory, Okta, Azure AD) to determine if it is a domain admin, service account, or standard user — privileged accounts executing these commands without a change ticket is an immediate escalation trigger.
3. Pull the full command-line and parent process chain. Use Sysmon Event ID 1 correlation on ProcessGuid and ParentProcessGuid to trace the full ancestry of the suspicious process — go at least three levels up (grandparent, parent, child). An unexpected chain such as winword.exe → powershell.exe → taskkill.exe or svchost.exe → cmd.exe → sc.exe is a strong indicator of exploitation or malware execution rather than legitimate administration.
4. Check for network connections and files written to disk around the same timeframe. Query Sysmon Event ID 3 (NetworkConnect) for any outbound connections from the affected host within ±15 minutes of the tamper event, and look for Sysmon Event ID 11 (FileCreate) or Event ID 15 (FileCreateStreamHash) for payloads dropped to disk. Unusual outbound connections on ports 443, 4444, 8080, or 1337 to non-corporate IPs immediately after a security tool disable are a strong C2 indicator.
5. Determine whether the security tool was actually impaired and for how long. Check your EDR console or the Microsoft-Windows-Windows Defender/Operational log (Event IDs 5001, 5007) to confirm whether the tool was actually disabled, or whether tamper protection prevented the change. Calculate the gap window — from the time of the tamper attempt to when the tool resumed — and check for any other malicious activity that occurred during that blind period by querying all event sources for that host and time range.
6. Search for lateral movement originating from this host. Query Windows Security Event Log for Event ID 4648 (explicit credential use), 4624 with logon_type = 3 (network logons), and Sysmon Event ID 3 for SMB (port 445) or WinRM (port 5985/5986) connections from the affected host to other internal hosts. Check your EDR for remote process execution events. Any authentication to other hosts that occurred after the tamper event should be treated as potentially compromised.
7. Make the escalation decision — what separates a confirmed incident from a benign event. Escalate to a confirmed incident (P1/P2) if any two or more of the following are true: the security tool was confirmed disabled (not just an attempt); a payload was dropped to disk; outbound C2 network connections were observed; lateral movement evidence exists; or the user has no corresponding change ticket. Classify as a tuning candidate (not an incident) only if the process parent is an approved management tool, the user has a matching change ticket, and the tool was never actually impaired.

Response Playbook

Containment

• Isolate the host from the network immediately, but leave it powered on. Use your EDR console (CrowdStrike Network Containment, SentinelOne Network Quarantine, Defender for Endpoint Isolate Device) to cut network access while preserving volatile memory and running processes for forensic collection. Do not shut the machine down — you will lose active process trees, network connections, and in-memory artifacts.
• Disable the affected user account. In Active Directory, use Disable-ADAccount -Identity <username> or disable the account in the Azure AD / Okta admin portal. If the account is a service account, coordinate with the application owner before disabling to understand downstream impact, but do not skip this step if compromise is confirmed.
• Block identified C2 IPs and domains at the perimeter and DNS layer. Submit suspicious IPs and domains observed in Sysmon Event ID 3 logs to your firewall team for immediate null-route or ACL block. Push the same IOCs to your DNS RPZ (Response Policy Zone) or DNS security layer (Cisco Umbrella, Infoblox) to block resolution across all endpoints, not just the isolated host.
• Kill any active malicious processes on the host. Use your EDR’s live response capability to run tasklist and identify any suspicious processes still running (e.g., RAT, miner, or loader identified during investigation). Terminate them via the EDR console rather than locally to preserve the process tree in EDR telemetry before termination.
• Revoke active sessions and tokens for the compromised user. In Azure AD, use Revoke-AzureADUserAllRefreshToken or the Revoke Sessions option in the portal. In on-premises AD, reset the user’s Kerberos TGT by resetting the password twice (to invalidate existing tickets). If the account accessed any SaaS applications, revoke OAuth tokens from those platforms directly.

Eradication

• Remove identified persistence mechanisms. Use EDR live response or Sysinternals Autoruns (run as admin on the isolated host remotely) to enumerate scheduled tasks, registry Run keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run), WMI subscriptions, and installed services. Delete any entries not present in a known-good baseline. Document each one removed before deletion.
• Search for and delete dropped payloads and attacker tools. Based on Sysmon Event ID 11 findings from the investigation, enumerate files written to disk during the attack window. Use your EDR’s file search or a live response shell to locate and remove payloads, often found in %TEMP%, %APPDATA%, C:\ProgramData\, or C:\Windows\Temp\. Submit samples to your malware analysis sandbox before deleting.
• Reset credentials for all accounts that executed or were exposed to malicious activity. Reset the password for the directly affected user, and any accounts whose credentials were stored on the host (check LSASS dump indicators, cached credentials in browser stores, and service account passwords stored in registry or config files). Force MFA re-registration if the MFA device may have been compromised.
• Check all lateral movement target hosts for backdoors. For every host the compromised account authenticated to during the attack window (identified in investigation step 6), run an EDR sweep for the same IOCs (file hashes, process names, registry keys) found on the primary host. Treat any positive match on a secondary host as a new, separate incident requiring its own containment cycle.
• Rotate any secrets or API keys that may have been exposed. If the compromised host had access to secrets managers (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), cloud service principal credentials, or hardcoded API keys in config files, rotate all of those secrets immediately regardless of whether you have direct evidence they were accessed. Assume they are compromised.

Recovery

• Verify the host is clean before reconnecting to the network — re-image if confidence is low. Run a full EDR scan and review Autoruns output one final time. If the attack involved a sophisticated or fileless implant, or if you cannot account for the full attack timeline, re-image the host from a known-good baseline rather than attempting cleanup. The risk of a missed backdoor outweighs the inconvenience of re-imaging.
• Re-enable the user account only after confirming no persistence remains and credentials are reset. Before re-enabling, confirm the password reset is complete, MFA is re-enrolled on a clean device, and no persistence mechanisms tied to that account remain on any host. Document the re-enablement action in your incident ticket with the approver’s name.
• Confirm that all security tools are fully operational and reporting to the console before releasing the host. Verify in your EDR console and SIEM that the host is sending telemetry, Defender (or your AV) is reporting as active with current definitions, and all tampered registry keys or service configurations have been restored to their expected values. Run Get-MpComputerStatus via PowerShell to validate Defender state.
• Monitor the previously affected host and user account for 72 hours post-remediation. Create a temporary watchlist or detection rule in your SIEM scoped to the specific host and user, alerting on any process execution, network connection, or authentication event that falls outside normal baseline behavior. Assign a named analyst