Windows event log cleared via wevtutil or a PowerShell log cmdlet

Siemphony@siemphonymediumT1685.005unverified

AN1472 names three mechanisms — wevtutil, PowerShell, and direct deletion of .evtx files — and this rule covers the first two on the Sysmon process- creation leg, since both are new-process events that put the verb on `CommandLine`. The wevtutil arm requires the binary itself (`Image` ending `\wevtutil.exe`) together with its clear-log verb (`cl` or `clear-log`) on the command line, so a `wevtutil` invocation for any other subcommand — `qe`, `epl`, `gli` — does not match. The PowerShell arm matches `Remove-EventLog`/`Clear-EventLog` by name on `CommandLine` regardless of binary, since both are cmdlets rather than external tools. The brief's Security 1102 leg ("The audit log was cleared") is not used here even though it is the more reliable of the three: 1102 fires only when the Security channel specifically is cleared, so it is silent for `wevtutil cl system` or `wevtutil cl application`, and MITRE's own technique description and `TargetLogName` knob are explicit that all three logs are in scope — a Security-only signal would silently miss two thirds of the technique's stated behaviour. Sysmon EventID 23 (file deletion of the raw .evtx files under `winevt\Logs`) is likewise not used: it is a separate logsource from process creation and a Sigma rule carries one, so the direct-deletion mechanism AN1472 names is out of scope for this rule and would need its own. This rule needs Sysmon installed and EventID 1 enabled; it needs no Windows audit policy change, unlike the Security 4688 alternative this brief does not offer. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0532, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where ((FolderPath endswith "\\wevtutil.exe" and (ProcessCommandLine contains " cl " or ProcessCommandLine contains " clear-log ")) or (ProcessCommandLine contains "Remove-EventLog" or ProcessCommandLine contains "Clear-EventLog"))

Splunk · SPL

Run this as a search.

index=* ((Image="*\\wevtutil.exe" AND (CommandLine="* cl *" OR CommandLine="* clear-log *")) OR (CommandLine="*Remove-EventLog*" OR CommandLine="*Clear-EventLog*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.executable) LIKE "*\\\\wevtutil.exe" AND (TO_LOWER(process.command_line) LIKE "* cl *" OR TO_LOWER(process.command_line) LIKE "* clear-log *")) OR (TO_LOWER(process.command_line) LIKE "*remove-eventlog*" OR TO_LOWER(process.command_line) LIKE "*clear-eventlog*"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)\\wevtutil\.exe$</field>    <field name="CommandLine" type="pcre2">(?i)( cl | clear-log )</field>    <description>Windows event log cleared via wevtutil or a PowerShell log cmdlet (1/2)</description>    <mitre>      <id>T1685.005</id>    </mitre>  </rule>   <rule id="100001" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="CommandLine" type="pcre2">(?i)(Remove-EventLog|Clear-EventLog)</field>    <description>Windows event log cleared via wevtutil or a PowerShell log cmdlet (2/2)</description>    <mitre>      <id>T1685.005</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: medium
Category: defense_evasion_clear_logs
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 79c8a29d-1275-42ba-bbe1-64febdcf0cbb

ATT&CKT1685.005

T1685.005Clear Windows Event Logs

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessondefense evasion clear logs

defense evasion clear logsAI draft — unreviewed

01 · What this rule detects

An attempt to clear a Windows event log via wevtutil cl/clear-log or the PowerShell Remove-EventLog/Clear-EventLog cmdlets — an anti-forensic move to remove the record of prior activity from System, Application, or another channel.

02 · Telemetry you need

Sysmon EventID 1 (process creation), category: process_creation, product: windows. No audit-policy change is required — this needs Sysmon installed with EventID 1 enabled, not the Security 4688/audit-process-creation path AN1472's brief also offers.

03 · How the logic works

Two arms, ORed. The wevtutil arm requires both Image ending \wevtutil.exe and the command line containing the clear-log verb ( cl or clear-log ), so wevtutil qe or gli for any other subcommand doesn't match. The PowerShell arm matches Remove-EventLog/Clear-EventLog on CommandLine by cmdlet name alone, regardless of binary, since these are cmdlets rather than external tools — note this only sees the cmdlet when it's literally on the process command line, so a powershell.exe -File script.ps1 invocation calling the cmdlet from inside the script file leaves CommandLine showing only the launch line. AN1472 names a third mechanism, direct deletion of the raw .evtx files, and a Security 1102 leg; neither is used here. 1102 fires only for the Security channel specifically, so it would silently miss wevtutil cl system or application — two-thirds of what MITRE's TargetLogName knob says is in scope. Direct .evtx deletion (Sysmon EventID 23) is a separate logsource from process creation, so it's out of scope for this rule and would need its own.

04 · Common false positives

The pipeline's own read is that scheduled log-rotation and disk-hygiene scripts — archive-then-clear via wevtutil to hold a channel within a size budget — are the pattern most likely to recur fleet-wide, and this is the rule's loudest false positive. Golden-image and sysprep workflows that clear System, Application, and Security before capturing a deployable template are another common source. Helpdesk scripts that clear the Application log before reproducing an issue for a vendor case, and atomic-test validation runs, round out the list.

05 · Detection maturity

tier_1: Unverified, lowest DeBMM tier. This rule has never fired against a real log line; the medium/low level calibration and the rotation-script false-positive rate both need real data before it moves past scaffold status.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

level: medium sits close to the line given how strong that rotation-script false positive reads. It's defensible — wevtutil-driven rotation is less universal across a fleet than something like an EDR-wide exclusion push, and the PowerShell arm is a fairly precise cmdlet-name match — but if fleet telemetry later shows rotation scripts dominate matches, drop it to low. Correlate against a change-management record of scheduled rotation jobs and golden-image build pipelines before alerting; both are legitimate, scheduled, and will otherwise generate the bulk of hits.

Declared by the author

Log-rotation and disk-hygiene scripts, run by IT operations on a schedule, that archive a channel to a backup .evtx and then clear it with wevtutil to keep the live log within a size budget — this is the pattern most likely to recur across a fleet.
Golden-image and sysprep preparation workflows that clear System, Application, and Security before capturing a deployable template, so no history from the build process ships in the image.
Helpdesk or support scripts that clear the Application log with Clear-EventLog to reduce noise before reproducing a reported issue for a vendor case.
Detection-engineering and atomic-test validation runs that invoke wevtutil cl or Remove-EventLog to demonstrate or self-test this analytic rather than to conceal anything.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1685.005, evaluated against their process_creation events.

Share this rule

/u/siemphony/79c8a29d-1275-42ba-bbe1-64febdcf0cbb

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

2 threads

@nadia-brandt
22 Aug 2026
Small note on the PowerShell arm: Clear-EventLog and Remove-EventLog are Windows PowerShell 5.1 cmdlets and were dropped in PowerShell Core. On a pwsh-only host that arm can only fire on someone typing a cmdlet that does not exist there. Not an argument for removing it — 5.1 is on every Windows box and is where the technique actually lands — just do not read its silence on your pwsh fleet as coverage.
@owen-mackay
20 Aug 2026
The reasoning for skipping Security 1102 is sound and I agree with it as a scoping decision, but in practice we run both and they are not redundant. This rule sees intent — someone invoked the verb. 1102 is written by the Event Log service itself, so it survives an attacker who has already killed Sysmon, and it is frequently the only thing left. Intent and effect, and on a bad day you only get one of them.

Windows event log cleared via wevtutil or a PowerShell log cmdlet

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it

2 threads