Skip to content
T1685.001 Google Chronicle · YARA-L

Detect Disable Windows Event Logging in Google Chronicle

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.

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/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule t1562_002_disable_windows_event_logging {
  meta:
    author = "Argus Detection Engineering"
    description = "Detects attempts to disable or tamper with Windows event logging via sc.exe, net.exe, wevtutil.exe, auditpol.exe, or PowerShell Stop-Service/Set-Service commands"
    mitre_attack_tactic = "Defense Evasion"
    mitre_attack_technique = "T1562.002"
    mitre_attack_url = "https://attack.mitre.org/techniques/T1685/001/"
    severity = "HIGH"
    confidence = "HIGH"
    rule_version = "1.0"

  events:
    $e.metadata.event_type = "PROCESS_LAUNCH"
    $e.principal.hostname = $hostname
    re.regex(
      $e.target.process.command_line,
      `(?i)(sc\s+(stop|config)\s+eventlog|net\s+stop\s+eventlog|(stop-service|set-service).{0,40}eventlog|wevtutil\s+(cl|sl)\b|auditpol\s+/(clear|set|remove))`
    )

  condition:
    $e
}

rule t1562_002_audit_log_cleared {
  meta:
    author = "Argus Detection Engineering"
    description = "Detects Windows Security audit log cleared (EID 1102) or audit policy changed (EID 4719) — indicators of T1562.002 post-tampering evidence destruction"
    mitre_attack_tactic = "Defense Evasion"
    mitre_attack_technique = "T1562.002"
    severity = "CRITICAL"
    confidence = "HIGH"

  events:
    $e.metadata.event_type = "USER_RESOURCE_ACCESS"
    $e.principal.hostname = $hostname
    $e.metadata.product_event_type in ("1102", "4719")

  condition:
    $e
}
high severity high confidence

Two Chronicle YARA-L 2.0 rules for T1562.002: the first matches process launch events where the command line contains EventLog service tampering patterns (sc.exe, net.exe, wevtutil, auditpol, PowerShell); the second detects the resulting artifacts — Windows Security log cleared (EID 1102) or audit policy changed (EID 4719).

Data Sources

Google Chronicle UDM with Windows Event Log ingestionChronicle Forwarder with Sysmon feedWindows Security Event Log via Chronicle

Required Tables

UDM events (PROCESS_LAUNCH)UDM events (USER_RESOURCE_ACCESS)

False Positives & Tuning

  • System administrators running auditpol.exe during quarterly audit policy reviews or after Active Directory Group Policy changes
  • Automated penetration testing tooling in authorized red team engagements that clears logs as part of post-exploitation cleanup simulation
  • Windows Server backup agents using wevtutil sl to reconfigure log size limits or retention policies during maintenance

Other platforms for T1685.001

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

Last updated: 2026-04-20 Research depth: deep
References (4)

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

Tactic Hub

TA0112 Defense Impairment ATT&CK Matrix

Parent Technique

T1685 Disable or Modify Tools

Related Sub-techniques

T1685.002 Disable or Modify Cloud Logs T1685.003 Spoof Security Alerting T1685.004 Disable or Modify Linux Audit System T1685.005 Clear Windows Event Logs T1685.006 Clear Linux or Mac System Logs T1685.007 Impair Autonomous Defenses

Related Techniques

T1562 Impair Defenses T1562.006 Indicator Blocking T1112 Modify Registry T1059.001 PowerShell

Same Tactic: Defense Impairment

Popular Detections