T1685.005: Clear Windows Event Logs
Adversaries may clear Windows Event Logs to hide the activity of an intrusion. Windows Event Logs are a record of a computer's alerts and notifications. There are three system-defined sources of events: System, Application, and Security, with five event types: Error, Warning, Information, Success Audit, and Failure Audit.
With administrator privileges, the event logs can be cleared with the following utility commands:
* `wevtutil cl system` * `wevtutil cl application` * `wevtutil cl security`
These logs may also be cleared through other mechanisms, such as the event viewer GUI or PowerShell. For example, adversaries may use the PowerShell command `Remove-EventLog -LogName Security` to delete the Security EventLog and after reboot, disable future logging. Note: events may still be generated and logged in the .evtx file between the time the command is run and the reboot.Citationdisable_win_evt_logging
Adversaries may also attempt to clear logs by directly deleting the stored log files within `C:\Windows\System32\winevt\logs\`.
Security context for executives and security teams
Clearing Windows Event Logs is a visibility-denial behavior: it does not create the initial compromise, but it can remove the evidence leaders and responders need to understand scope, preserve audit trails, and make containment decisions. Because it requires administrator-level capability and targets System, Application, and Security logs, it is especially material during ransomware, espionage, insider, or hands-on-keyboard investigations where proof of activity and timeline reconstruction matter.
Executive priority
Treat this as an incident-readiness and evidence-preservation priority for Windows environments. The key business question is whether endpoint logs survive local administrator tampering long enough to support investigation, legal/audit needs, and continuity decisions. Budget and control discussions should prioritize off-host log retention, least-privilege administration, and validated SOC alerting for log-clearing behavior. ATT&CK relationships show this behavior is used across multiple campaigns, groups, and software entries, so it should be covered as a baseline Windows defense-impairment scenario rather than a niche detection.
Technical view
For SOC, detection engineering, and IR teams, validate coverage for Windows log clearing through built-in utilities, PowerShell, Event Viewer, and direct manipulation of stored .evtx files under C:\Windows\System32\winevt\logs\. The technique is a sub-technique of Disable or Modify Tools under defense-impairment, so detections should not only look for a single command or UI action; they should correlate log-clear activity with administrator context, suspicious process execution, PowerShell activity, direct log-file deletion, reboot timing, and gaps between endpoint and centralized log stores. The related DET0532 detection strategy indicates a behavioral-chain approach is relevant. Official ATT&CK detection text is not provided, so local engineering must define and test the specific analytics.
Likely telemetry
- Windows System, Application, and Security Event Logs from endpoints and servers
- Centralized or remote log storage showing forwarded Windows events before local clearing
- Process execution and command-line telemetry for Windows utilities associated with log management, including wevtutil
- PowerShell execution telemetry for log-management commands such as Remove-EventLog
- File activity telemetry for .evtx files in C:\Windows\System32\winevt\logs\
Detection direction
- Validate whether local log clearing is still visible in centrally collected logs; if the first alert depends only on the local host after clearing, coverage is fragile.
- Tune detections around behavioral chains: admin context plus log-clear utility use, PowerShell log removal, Event Viewer-driven clearing, or direct .evtx deletion.
- Baseline legitimate administrative maintenance so SOC triage can distinguish approved log rotation or troubleshooting from unexpected clearing on servers, workstations, domain-connected systems, or sensitive Windows assets.
- Alert on loss or interruption of expected Windows log forwarding, especially when paired with recent privileged activity or security-tool impairment behavior.
- Test coverage against the ATT&CK-described mechanisms without assuming one command covers the technique; the official object names multiple mechanisms and provides no official detection logic.
Mitigation priorities
- Prioritize M1029 Remote Data Storage: forward critical Windows logs to secure off-host storage so local clearing does not erase investigative evidence.
- Apply M1022 Restrict File and Directory Permissions: limit who and what can write to or delete sensitive log files and directories, consistent with least privilege.
- Review administrator rights and operational processes because the official description notes administrator privileges can clear logs.
- Use M1041 Encrypt Sensitive Information where relevant to protect sensitive data at rest and in transit, while recognizing encryption alone does not replace off-host log preservation or privilege control.
- Define retention, access control, and audit requirements for Windows logs as part of incident response and compliance readiness, then test them with tabletop or purple-team validation.
Additional notes and limits
This ATT&CK object is Windows-specific and focused on defense impairment through clearing Windows Event Logs. Relationship context maps it to a behavioral-chain detection strategy, three mitigations, a revoked legacy technique reference, and numerous groups, campaigns, and software entries. Those relationships support prioritizing this behavior, but they do not prove current activity against any specific organization.
MITRE provides no official detection section for this object. The supplied data does not include specific event IDs, SIEM queries, product coverage, exploit details, or environment-specific prevalence. Local validation is required to determine whether Windows events, process telemetry, PowerShell activity, file activity, and remote log retention are actually collected and retained.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Clear Windows Event Logs
Adversaries may clear Windows Event Logs to hide the activity of an intrusion. Windows Event Logs are a record of a computer's alerts and notifications. There are three system-defined sources of events: System, Application, and Security, with five event types: Error, Warning, Information, Success Audit, and Failure Audit.
With administrator privileges, the event logs can be cleared with the following utility commands:
* `wevtutil cl system` * `wevtutil cl application` * `wevtutil cl security`
These logs may also be cleared through other mechanisms, such as the event viewer GUI or PowerShell. For example, adversaries may use the PowerShell command `Remove-EventLog -LogName Security` to delete the Security EventLog and after reboot, disable future logging. Note: events may still be generated and logged in the .evtx file between the time the command is run and the reboot.Citationdisable_win_evt_logging
Adversaries may also attempt to clear logs by directly deleting the stored log files within `C:\Windows\System32\winevt\logs\`.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.