Overview

Disable Windows Event Logging (T1562.002) covers attacker actions that stop, corrupt, or suppress the Windows event logging pipeline — most commonly by tampering with the Windows Event Log service, clearing individual channels, modifying audit policy settings, or patching the in-memory logging subsystem. The goal is to create blind spots: actions taken while logging is suppressed will not appear in SIEM, making detection and forensic reconstruction dramatically harder.

Every security team must detect this technique because logging is the foundation of every other detection. An attacker who successfully disables logging before moving laterally, dumping credentials, or deploying ransomware can operate with near-impunity — your SIEM becomes useless for that window. Detecting the act of disabling logging itself is therefore one of the highest-value detections you can build.

Attacker Perspective

Attackers target the Windows logging subsystem early in the intrusion lifecycle to remove evidence of subsequent actions before those actions are taken.

• Service stop via sc.exe or net.exe: Directly stopping the Windows Event Log service using sc stop eventlog or net stop eventlog — the bluntest instrument, immediately halts all event recording and is trivially scriptable.
• Audit policy manipulation via auditpol.exe: Using auditpol /set /subcategory:"Logon" /success:disable /failure:disable to surgically remove specific audit categories without touching the service, making the absence harder to notice than a full service stop.
• PowerShell ETW patching (e.g., scriptblock logging bypass): Reflectively patching the EtwEventWrite function in the current process memory — used by tools like Invoke-Obfuscation variants and manual red-team techniques — to suppress PowerShell Script Block logging (Event ID 4104) for just that process without touching anything system-wide.
• wevtutil.exe log clearing: Using wevtutil cl Security or wevtutil cl System to wipe existing log contents, erasing prior evidence even if logging later resumes; sometimes paired with a brief service stop to suppress the 1102 “audit log was cleared” event itself.

This technique is highly attractive because it is low-cost, often requires only local administrator rights, and buys attackers deniability and time against detection pipelines that assume log continuity.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Audit Policy Change: Enable via GPO Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Policy Change → Audit Policy Change. Generates Event ID 4719 (system audit policy was changed) and Event ID 4907 (auditing settings on object changed). Without this, auditpol manipulation is invisible.
• Windows Security Event Log — Log Clear Events: Enabled by default. Event ID 1102 (Security log cleared, logged by the Security log itself) and Event ID 104 in the System log (any other log cleared via wevtutil or the UI). These require no special configuration but must be forwarded to your SIEM in real time.
• Windows System Event Log — Event Log Service State: Event ID 7035 (service control manager sent start/stop) and Event ID 7036 (service entered stopped/running state) for the EventLog service. Enable forwarding of the System channel to your SIEM or Windows Event Forwarding (WEF) collector.
• Sysmon Event ID 1 — Process Creation: Deploy Sysmon with a configuration that captures full command lines. Required to detect auditpol.exe, wevtutil.exe, sc.exe, net.exe, and reg.exe invocations with logging-related arguments. Install Sysmon with the SwiftOnSecurity or Olaf Hartong base config and forward to your SIEM.
• Sysmon Event ID 13 — Registry Value Set: Needed to detect direct registry manipulation of audit policy keys. Key paths to monitor: HKLM\SYSTEM\CurrentControlSet\Services\EventLog (service tampering) and HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging (disabling script block logging). Enable Sysmon registry monitoring for these paths in your Sysmon config.
• Windows PowerShell Operational Log — Event ID 4104 (Script Block Logging): Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging or registry key HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. This captures PowerShell-based ETW patching attempts — ironically, they often log themselves before the patch takes effect.
• Windows Event Forwarding (WEF) or a SIEM agent: All of the above channels must be forwarded off-host in real time. If the Event Log service is stopped before forwarding occurs, you lose those events — so minimising forwarding latency is itself a defensive control.

Key Indicators

• Event ID 1102 / 104 — Log cleared: Source: Security or System log. Field EventID = 1102 in Security, or EventID = 104 in System. Field SubjectUserName identifies who cleared it. Any occurrence outside an authorised maintenance window is suspicious.
• Event ID 4719 — Audit policy changed to disable: Source: Security log. Field EventID = 4719. Check AuditPolicyChanges field for the string %%8448 (success removed) or %%8450 (failure removed). Subcategories of highest concern: Logon, Process Creation, Account Logon.
• auditpol.exe with disable arguments: Source: Sysmon Event ID 1. Field Image ends with auditpol.exe. Field CommandLine contains /success:disable or /failure:disable. Example: auditpol /set /subcategory:"Logon" /success:disable.
• wevtutil.exe clear-log invocation: Source: Sysmon Event ID 1. Field Image ends with wevtutil.exe. Field CommandLine contains cl or clear-log followed by a log name such as Security, System, or Microsoft-Windows-PowerShell/Operational.
• EventLog service stopped via sc.exe or net.exe: Source: Sysmon Event ID 1. Field Image ends with sc.exe or net.exe. Field CommandLine matches pattern stop eventlog or stop "Windows Event Log". Correlate with System log Event ID 7036 where param1 = Windows Event Log and param2 = stopped.
• Registry modification disabling script block logging: Source: Sysmon Event ID 13. Field TargetObject contains PowerShell\ScriptBlockLogging. Field Details (the value written) equals 0. This indicates an attempt to turn off PowerShell logging via registry.
• PowerShell ETW patching keywords in script blocks: Source: PowerShell Operational log Event ID 4104. Field ScriptBlockText contains strings like EtwEventWrite, PatchEtw, AmsiScanBuffer combined with [System.Runtime.InteropServices.Marshal] or VirtualProtect — hallmarks of in-memory ETW patch techniques.
• Suspicious parent process for logging-related tools: Source: Sysmon Event ID 1. ParentImage is cmd.exe, powershell.exe, or wscript.exe as parent of wevtutil.exe or auditpol.exe — legitimate admin tools rarely spawn from script interpreters.

Detection Logic

Rule 1: Any Security or System Log Cleared
IF EventID IN (1102, 104) THEN alert HIGH

This catches the most obvious form of log tampering — explicit clearing of Windows event log channels. Volume should be very low; most environments see zero of these per week outside scheduled maintenance. High-fidelity rule with almost no false positives outside authorised admin activity.

Rule 2: Audit Policy Disabled via auditpol.exe
IF EventID = 1 (Sysmon Process Create) AND Image ENDSWITH "auditpol.exe" AND CommandLine CONTAINS "/success:disable" OR CommandLine CONTAINS "/failure:disable" AND NOT ParentImage IN [known_admin_tools] THEN alert HIGH

Catches surgical disabling of specific audit subcategories. Legitimate auditpol usage does exist in hardened build scripts, so tune with a known-good parent process or account allowlist. Expected volume is very low in a mature environment.

Rule 3: Windows Event Log Service Stopped
IF (EventID = 7036 AND param1 = "Windows Event Log" AND param2 = "stopped") OR (EventID = 1 AND Image ENDSWITH "sc.exe" AND CommandLine CONTAINS "stop" AND CommandLine CONTAINS "eventlog") THEN alert CRITICAL

A stopped Event Log service is immediately actionable — this almost never happens legitimately outside OS patching. Correlate both the service state event and the process creation event to handle cases where one source is missing. Expect near-zero volume.

Rule 4: PowerShell ETW Patch Attempt via Script Block
IF EventID = 4104 AND ScriptBlockText CONTAINS "EtwEventWrite" AND ScriptBlockText CONTAINS ANY ("VirtualProtect", "Marshal", "WriteProcessMemory") THEN alert HIGH

Targets in-process ETW patching used by offensive PowerShell tools. This is a narrower, high-precision rule. False positive rate is extremely low — legitimate code does not reflectively patch ETW. May miss obfuscated variants; pair with a broader AMSI anomaly detection layer.

Tuning Guidance

• Patch Tuesday / Windows Update cycles: The Event Log service may briefly stop or restart during OS updates. Exclude events where ParentImage = TiWorker.exe or TrustedInstaller.exe, or suppress alerts during your defined maintenance windows using a time-based filter.
• SIEM/EDR agent installation scripts: Some agent installers (CrowdStrike, Defender for Endpoint, Splunk UF) briefly modify audit policy or restart log-related services during deployment. Build an allowlist of user IN [deployment_service_accounts] combined with ParentImage IN [msiexec.exe, setup.exe] for these events.
• Authorised log management tooling: Log rotation or archival scripts using wevtutil.exe may legitimately clear older channels. Exclude Image = wevtutil.exe where ParentImage = task scheduler service and the task name matches your known archival scheduled task. Document this allowlist and review it quarterly.
• Domain Group Policy application of audit settings: When GPO pushes a new audit policy baseline, Event ID 4719 fires on every affected host simultaneously. Suppress 4719 alerts where SubjectUserName = SYSTEM and the change matches your documented baseline subcategory list — a mass simultaneous 4719 from SYSTEM across all hosts is GPO rollout, not an attack. A single host or a non-SYSTEM account is the indicator.
• Legitimate security tooling using ETW internally: Some EDR sensors and monitoring agents use ETW APIs internally and may generate 4104 script blocks referencing ETW-adjacent functions. Build an allowlist of ScriptBlockText hashes or path-based exclusions for your known security tools after baselining them in a test environment.

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 your SIEM using the specific EventID, host, and timestamp from the alert. Confirm the event was forwarded from the host and is not a SIEM parsing artefact — check the _raw or equivalent field to see the original XML.
2. Identify the affected host and user — flag if privileged. Extract the ComputerName, SubjectUserName, and SubjectUserSid from the event. Cross-reference the account against your identity system to determine if it is a standard user, local administrator, domain administrator, or service account — escalate immediately if privileged.
3. Pull the full command-line and parent process chain. Using Sysmon Event ID 1 from that host, retrieve the full CommandLine, Image, ParentImage, ParentCommandLine, and ProcessGuid for the triggering process. Trace the process chain upward two to three levels using ParentProcessGuid correlations to identify whether this was spawned by a script, a remote shell, or an interactive session.
4. Determine the timeline of logging suppression and what happened during the gap. Identify the exact timestamp when logging was disabled or cleared. Then query Sysmon, EDR telemetry, or Windows Event Forwarding for any events from that host in the window immediately before and after — look for process creations, network connections, or file writes that would only occur during an active intrusion.
5. Check for network connections and files written to disk during and after the event. Query Sysmon Event ID 3 (Network Connect) and Event ID 11 (File Create) for the same host and timeframe. Look for outbound connections to unusual IPs or domains, and for new executables or scripts written to %TEMP%, C:\ProgramData, or C:\Windows\Temp — common staging locations for attacker tools.
6. Look for lateral movement indicators from this host. Query your SIEM for Security Event ID 4624 (logon type 3 or 10) and Sysmon network events showing SMB (port 445), RDP (port 3389), or WinRM (port 5985/5986) connections originating from this host to other internal systems in the 30 minutes surrounding the logging suppression event. Cross-check destination hosts for the same logging-disable indicators.
7. Escalation decision — separate confirmed incident from benign. If the triggering account is non-privileged, the parent process is a script interpreter or remote shell, and there are concurrent suspicious process or network events — escalate to incident response immediately. If the account is a known deployment service account, the parent is an authorised toolset, and the change matches a documented baseline, document as a false positive and improve your tuning exclusions.

Response Playbook

Containment

• Isolate the host from the network immediately — leave it powered on. Use your EDR platform’s network isolation feature (CrowdStrike contain host, Defender for Endpoint isolate device, Carbon Black quarantine) to cut network connectivity while preserving memory and process state for forensics. Do not power off — volatile memory may contain attacker tooling or credentials.
• Disable the affected user account. In Active Directory, disable the account via Disable-ADAccount -Identity [username] or the ADUC console. If the account is a service account, coordinate with the application owner before disabling. Revoke any active Kerberos tickets by resetting the account password twice to invalidate existing TGTs.
• Block identified C2 IPs and domains at the perimeter. If network analysis from step 5 of the investigation identified suspicious outbound connections, push block rules to your firewall and DNS resolver immediately. For DNS sinkholes, redirect the domain to an internal IP and alert on any subsequent resolution attempts.
• Kill any identified malicious processes on the isolated host. Use your EDR to terminate processes identified as malicious during the investigation. Document the PID, process name, hash, and parent before termination — this information is needed for eradication and threat intel.
• Re-enable Windows Event Logging immediately if it was stopped. Use a remote management tool (PSExec, WinRM from a trusted jump host, or EDR remote shell) to restart the Windows Event Log service: sc start eventlog or Start-Service -Name EventLog. Verify Event ID 7036 shows the service as running, and confirm events are flowing to your SIEM.

Eradication

• Remove identified persistence mechanisms. Check for new scheduled tasks (schtasks /query /fo LIST /v), registry run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run and HKLM equivalents), new services (sc query type= all), and startup folder entries. Remove any entries not present in your baseline configuration.
• Search for and delete dropped payloads and attacker tools. Based on Sysmon File Create events from your investigation, enumerate and hash all files written to staging directories (%TEMP%, C:\ProgramData, C:\Windows\Temp). Submit hashes to your threat intel platform and delete confirmed malicious files. Scan the host with your EDR’s on-demand scan after isolation.
• Reset credentials for all accounts that touched the compromised host. Reset passwords for the affected user account and any other accounts observed logging into or executing processes on the host during the incident window. Pay special attention to any accounts used for lateral movement. Notify account owners through a side channel.
• Restore audit policy and logging configuration to baseline. If audit policy was modified, use auditpol /restore /file:baseline.csv to reapply your documented baseline policy. Re-enable Script Block Logging via GPO if it was disabled via registry. Verify all SIEM-forwarded channels are actively shipping events before returning the host to service.
• Check lateral movement target hosts for the same indicators. For each host the compromised system connected to during the investigation, run the same detection queries — look for log clearing events, audit policy changes, and new persistence on those targets. Treat any positive finding as a separate incident workflow.

Recovery

• Verify the host is clean before reconnecting to the network — re-image if confidence is low. Run a full EDR scan on the isolated host and review the findings with a senior analyst. If any uncertainty remains about the scope of access or installed tooling, re-image from a known-good golden image rather than attempting manual cleanup — a clean re-image is faster and more reliable than trying to fully remediate a compromised host.
• Re-enable the user account only after confirming no persistence remains. Before unlocking the account, verify that no backdoor credentials, OAuth tokens, or SSH keys were added to the account during the incident. Require the user to enrol in MFA if not already enforced, and brief them on what happened.
• Monitor the previously affected host and user account for 72 hours post-remediation. Create a temporary high-sensitivity watchlist rule in your SIEM scoped to that host and account. Alert on any recurrence of logging-related commands, new process creation from unusual parents, or outbound connections to previously observed IPs or domains.
• Document the full incident timeline and close with lessons learned. Write up a timeline from first indicator to containment, including the logging gap window and what activity is unaccounted for during that period. Share findings with the wider detection engineering team to update runbooks and SIEM detection rules with any new IOCs or patterns observed.
• Review and harden logging infrastructure against future suppression attempts. Evaluate whether Windows Event Forwarding latency can be reduced to shrink the window between a log-clearing event and SIEM ingestion. Consider enabling Protected Event Logging (encrypts log content in transit) and evaluate whether the EventLog service can be protected via a service ACL change to prevent non-SYSTEM accounts from stopping it.