Skip to content
T1685.001

Disable or Modify Tools — Disable Windows Event Logging

Defense Impairment Last updated:

Adversaries may disable Windows event logging to limit data that can be leveraged for detections and audits. This includes stopping the EventLog service, modifying audit policies with auditpol.exe, altering registry keys that control event log autologger sessions, or using wevtutil to disable specific logs. Adversaries may also target application-specific logging such as IIS logs using appcmd.exe.

What is T1685.001 Disable Windows Event Logging?

Disable Windows Event Logging (T1685.001) is a sub-technique of Disable or Modify Tools (T1685) in the MITRE ATT&CK framework. It maps to the Defense Impairment tactic — the adversary is trying to break security mechanisms, pipelines, and tooling so defenders can’t see or trust what’s happening.

This page provides production-ready detection logic for Disable Windows Event Logging, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Windows Registry: Windows Registry Key Modification, Microsoft Defender for Endpoint. The queries below are rated critical severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Defense Impairment
Technique
T1685 Disable or Modify Tools
Sub-technique
T1685.001 Disable or Modify Windows Event Log
Canonical reference
https://attack.mitre.org/techniques/T1685/001/
Microsoft Sentinel / Defender
kusto
let EventLogTampering = dynamic(["sc stop EventLog", "sc config EventLog start=disabled", "net stop EventLog", "Stop-Service EventLog", "Set-Service -Name EventLog -Status Stopped", "wevtutil sl", "wevtutil cl", "auditpol /clear", "auditpol /set", "auditpol /remove /allusers"]);
let RegistryPaths = dynamic(["Control\\WMI\\Autologger\\EventLog-Security", "Control\\WMI\\Autologger\\EventLog-System", "Control\\WMI\\Autologger\\EventLog-Application", "Services\\EventLog"]);
union DeviceProcessEvents, DeviceRegistryEvents
| where Timestamp > ago(24h)
| where (ProcessCommandLine has_any (EventLogTampering))
   or (ActionType == "RegistryValueSet" and RegistryKey has_any (RegistryPaths) and RegistryValueName in ("Start", "Enabled", "EnableProperty"))
| extend TamperType = case(
    ProcessCommandLine has "sc stop EventLog" or ProcessCommandLine has "net stop EventLog" or ProcessCommandLine has "Stop-Service EventLog", "EventLog Service Stop",
    ProcessCommandLine has "sc config EventLog", "EventLog Service Disable",
    ProcessCommandLine has "wevtutil cl", "Event Log Clear",
    ProcessCommandLine has "wevtutil sl", "Event Log Settings Modified",
    ProcessCommandLine has "auditpol /clear" or ProcessCommandLine has "auditpol /remove", "Audit Policy Clear",
    ProcessCommandLine has "auditpol /set", "Audit Policy Modified",
    ActionType == "RegistryValueSet", "Autologger Registry Modified",
    "Unknown")
| project Timestamp, DeviceName, AccountName, TamperType, ProcessCommandLine, RegistryKey, RegistryValueName, RegistryValueData, InitiatingProcessFileName
| sort by Timestamp desc

Detects Windows event logging impairment through service manipulation, log clearing, audit policy modification, and autologger registry tampering. Covers EventLog service stopping/disabling, wevtutil log clearing/settings changes, auditpol policy clearing, and direct registry modifications to WMI Autologger keys that control Security/System/Application log generation.

critical severity high confidence

Data Sources

Process: Process Creation Command: Command Execution Windows Registry: Windows Registry Key Modification Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents DeviceRegistryEvents

False Positives

  • IT administrators clearing event logs during troubleshooting or after resolving known issues with full change control documentation
  • Log rotation scripts that archive and clear old event logs on a scheduled basis
  • SIEM agents or log forwarders that modify event log settings during initial deployment or reconfiguration

Sigma rule & cross-platform mapping

The detection logic for Disable Windows Event Logging (T1685.001) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1 Clear Security Event Log with wevtutil

    Expected signal: Security Event ID 1102 (audit log cleared) as the final event. Sysmon Event ID 1 with Image=wevtutil.exe and CommandLine='wevtutil cl Security'.

  2. Test 2 Clear All Audit Policies with auditpol

    Expected signal: Security Event ID 4719 (system audit policy changed). Sysmon Event ID 1 with Image=auditpol.exe.

  3. Test 3 Disable EventLog Service via Registry

    Expected signal: Sysmon Event ID 13: Registry value set for HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Start with value 4 (disabled). Sysmon Event ID 1: reg.exe process creation.


Response Playbook

Triage

  1. Determine which event log or audit category was targeted — Security, System, Application, or a specific provider log?
  2. Check if Event ID 1102 was generated — this confirms the Security log was actually cleared. Note the SubjectUserName and SubjectDomainName.
  3. For auditpol changes (Event ID 4719) — compare the new audit policy with the organization's baseline to determine exactly what was weakened
  4. Identify the user context — was this a domain admin, local admin, or service account? Validate against change management records.
  5. Check for temporal correlation — was the logging impairment preceded by suspicious authentication, followed by lateral movement or data exfiltration?

Containment

  1. Immediately restore audit policy from GPO baseline: gpupdate /force on affected host
  2. If EventLog service was stopped/disabled: restart it (sc start EventLog, sc config EventLog start=auto)
  3. Preserve any remaining logs and forward to SIEM before they are rotated or overwritten
  4. If clearing occurred on a domain controller: initiate domain-wide audit policy verification across all DCs
  5. Isolate the endpoint if other compromise indicators are present

Evidence Collection

  1. Security Event ID 1102 — the log-clearing event itself, includes the clearing account identity
  2. Security Event ID 4719 — system audit policy was changed, includes old and new policy values
  3. Sysmon Event ID 1 — process creation for auditpol.exe, wevtutil.exe, or sc.exe
  4. System Event ID 7036/7040 — EventLog service state and start type changes
  5. Registry: HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-* — Start and Enabled values
  6. SIEM: preserved copies of forwarded events that may have been cleared from the local log

Escalation Criteria

  • ! Security event log cleared with no corresponding change ticket
  • ! Audit policy silently changed to disable logon, process creation, or privilege use auditing
  • ! Event logging disabled on domain controllers or other critical infrastructure
  • ! Log clearing followed by account creation, lateral movement, or data exfiltration
  • ! Multiple hosts showing simultaneous log clearing (coordinated attack)

Investigation Guide

Forensic Artifacts

  • > Event Log: Security Event ID 1102 — contains SubjectUserName that cleared the log
  • > Event Log: Security Event ID 4719 — contains old and new audit policy settings
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-Security — Start value (0=disabled)
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Services\EventLog — Start value for EventLog service
  • > File System: C:\Windows\System32\winevt\Logs\*.evtx — file timestamps show when logs were last written/cleared
  • > Prefetch: C:\Windows\Prefetch\WEVTUTIL.EXE-*.pf, AUDITPOL.EXE-*.pf — execution timestamps

Tuning Guidance

Event ID 1102 (log cleared) should almost never be suppressed — it is a critical detection. Exceptions should only be made for documented log rotation processes with specific service accounts. For auditpol monitoring, baseline your expected audit policy and alert on any deviation. Consider deploying a canary audit policy setting that should never change. If your environment uses scheduled log clearing, ensure those scripts run under a dedicated service account so you can exclude them precisely.


Hunting Queries

Hunt for accounts that have cleared the Security event log. In most environments, this should be extremely rare. Any account clearing logs on multiple hosts is highly suspicious.

Hunting — KQL
kql
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 1102
| summarize ClearCount=count(), Hosts=make_set(Computer) by SubjectUserName, SubjectDomainName
| sort by ClearCount desc
Hunting — SPL
spl
index=wineventlog sourcetype="WinEventLog:Security" EventCode=1102
| stats count as ClearCount, values(host) as Hosts by SubjectUserName, SubjectDomainName
| sort - ClearCount

Hunt for all auditpol.exe executions. In most environments, auditpol should only be called by GPO processing or during initial setup. Interactive use is suspicious.

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "auditpol.exe"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
| sort by Timestamp desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\auditpol.exe"
| table _time, host, User, CommandLine, ParentImage
| sort - _time

Atomic Red Team Tests

Test 1 Clear Security Event Log with wevtutil
windows

Clears the Windows Security event log. This generates Event ID 1102 as the final entry before the log is wiped. Used by numerous threat actors (APT41, Threat Group-3390, Magic Hound) to cover tracks after exploitation.

Command

powershell
wevtutil cl Security

Expected Telemetry

Security Event ID 1102 (audit log cleared) as the final event. Sysmon Event ID 1 with Image=wevtutil.exe and CommandLine='wevtutil cl Security'.

Expected Detection

KQL: TamperType='Event Log Clear'. SPL: TamperType='Event Log Clear (wevtutil)' and EventCode=1102.

Test 2 Clear All Audit Policies with auditpol
windows

Uses auditpol /clear /y to remove all audit policies, effectively disabling Security event generation. The /y flag suppresses confirmation. This generates Security Event ID 4719.

Command

powershell
auditpol /clear /y

Cleanup

powershell
auditpol /set /category:* /success:enable /failure:enable

Expected Telemetry

Security Event ID 4719 (system audit policy changed). Sysmon Event ID 1 with Image=auditpol.exe.

Expected Detection

KQL: TamperType='Audit Policy Clear'. SPL: TamperType='Audit Policy Cleared' and EventCode=4719.

Test 3 Disable EventLog Service via Registry
windows

Modifies the EventLog service Start registry value to disable the service. This persists across reboots but does not take effect until the next restart, making it a stealthy technique.

Command

powershell
reg add HKLM\SYSTEM\CurrentControlSet\Services\EventLog /v Start /t REG_DWORD /d 4 /f

Cleanup

powershell
reg add HKLM\SYSTEM\CurrentControlSet\Services\EventLog /v Start /t REG_DWORD /d 2 /f

Expected Telemetry

Sysmon Event ID 13: Registry value set for HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Start with value 4 (disabled). Sysmon Event ID 1: reg.exe process creation.

Expected Detection

KQL: TamperType='Autologger Registry Modified'. SPL: Registry event targeting EventLog service Start value.

Related Detections