Audit policy or Windows Event Log channel disabled via CLI tooling

Siemphony@siemphonylowT1685.001unverified

AN0535 spans five log sources — service state, an audit-log-cleared event, two registry categories and process creation — but only one of those lets a single Sigma rule express the *disable* half of the technique's name rather than the *clear* half. This rule matches the two command lines the brief's description names directly: `auditpol /set ... /success:disable /failure:disable`, and `wevtutil sl <channel> /e:false`, the switch that turns a channel off rather than emptying it. `wevtutil cl` (clear) and Security 1102 are deliberately left out — that observable belongs to Indicator Removal: Clear Windows Event Logs (T1070.001), and folding it in here would blur the two techniques the same way casual reading of "disable or modify" already does. A third selector covers the bluntest form of the same behaviour, the EventLog service itself being stopped or reconfigured through `sc.exe`/`net.exe`. The registry-key legs (Sysmon 13/14 on the EventLog and Autologger keys) and the System 7035 service-state leg are not expressed here — each needs its own logsource and its own rule, since lib/sigma has no construct for combining logsources in one detection. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0187, 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 "/e:false") or (FolderPath endswith "\\auditpol.exe" and (ProcessCommandLine contains "/success:disable" or ProcessCommandLine contains "/failure:disable")) or ((FolderPath endswith "\\sc.exe" or FolderPath endswith "\\net.exe" or FolderPath endswith "\\net1.exe") and ProcessCommandLine contains "eventlog"))

Splunk · SPL

Run this as a search.

index=* ((Image="*\\wevtutil.exe" AND CommandLine="*/e:false*") OR (Image="*\\auditpol.exe" AND (CommandLine="*/success:disable*" OR CommandLine="*/failure:disable*")) OR ((Image="*\\sc.exe" OR Image="*\\net.exe" OR Image="*\\net1.exe") AND CommandLine="*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 "*/e:false*") OR (TO_LOWER(process.executable) LIKE "*\\\\auditpol.exe" AND (TO_LOWER(process.command_line) LIKE "*/success:disable*" OR TO_LOWER(process.command_line) LIKE "*/failure:disable*")) OR ((TO_LOWER(process.executable) LIKE "*\\\\sc.exe" OR TO_LOWER(process.executable) LIKE "*\\\\net.exe" OR TO_LOWER(process.executable) LIKE "*\\\\net1.exe") AND TO_LOWER(process.command_line) LIKE "*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. -->  <!-- 3 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="5">    <!-- 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)/e:false</field>    <description>Audit policy or Windows Event Log channel disabled via CLI tooling (1/3)</description>    <mitre>      <id>T1685.001</id>    </mitre>  </rule>   <rule id="100001" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)\\auditpol\.exe$</field>    <field name="CommandLine" type="pcre2">(?i)(/success:disable|/failure:disable)</field>    <description>Audit policy or Windows Event Log channel disabled via CLI tooling (2/3)</description>    <mitre>      <id>T1685.001</id>    </mitre>  </rule>   <rule id="100002" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)(\\sc\.exe$|\\net\.exe$|\\net1\.exe$)</field>    <field name="CommandLine" type="pcre2">(?i)eventlog</field>    <description>Audit policy or Windows Event Log channel disabled via CLI tooling (3/3)</description>    <mitre>      <id>T1685.001</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: low
Category: defense_evasion_clear_logs
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: c74dd0b5-5b58-4b9e-beb6-6862f33d3ad5

ATT&CKT1685.001

T1685.001Disable or Modify Windows Event Log

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

Three command lines that turn Windows event logging off rather than clear it afterward: wevtutil sl <channel> /e:false disabling a channel, auditpol /set ... /success:disable /failure:disable disabling an audit subcategory, and sc.exe/net.exe/net1.exe stopping or reconfiguring the EventLog service itself. AN0535 spans five log sources; this rule authors only the process-creation leg. wevtutil cl (clear) and Security 1102 are deliberately excluded — that observable belongs to T1070.001, Clear Windows Event Logs, and folding it in here would blur the two techniques.

02 · Telemetry you need

category: process_creation, product: windows — Sysmon EventID 1 or Security 4688 with command-line auditing enabled. Without Include command line in process creation events, CommandLine logs empty and every selector below is silently blind. The registry legs (Sysmon 13/14 on the EventLog and Autologger keys) and the System 7035 service-state leg named in AN0535 are not expressed here — each needs its own logsource and its own rule, since lib/sigma cannot combine logsources in one detection.

03 · How the logic works

Three independent selections, condition: 1 of selection*:

selection_wevtutil_disable and selection_auditpol_disable each pair a binary gate with the specific switch the technique description names, so both are reasonably tight. selection_service_stop is the loose one: it has no verb requirement at all, just eventlog anywhere on a sc.exe/net.exe command line. The reviewer flagged that this also matches an unrelated net use \\host\eventlog-share — the substring test can't tell a service-control verb from a share name. The fix (add stop or config to the gate) was not applied in this pass; treat it as the rule's known weak point.

04 · Common false positives

The rule's own falsepositives block names Group Policy re-application as "the highest-volume source by a wide margin on a managed domain" — a scheduled gpupdate replays the site's audit-policy baseline through auditpol, and most real baselines leave several subcategories at success-only or failure-only, so a routine refresh legitimately reissues /success:disable or /failure:disable on the other half of the pair. Also expect: log-retention tooling disabling a noisy diagnostic channel with wevtutil sl ... /e:false as documented policy; imaging and sysprep processes stopping the EventLog service mid-build; and CIS/STIG remediation scripts asserting an intentionally-disabled subcategory, which produces the literal command an adversary would run.

05 · Detection maturity

tier_1: .** UNVERIFIED — derived from DET0187, never executed against a log line. selection_service_stop's missing verb gate is a known, unaddressed finding from review, not a hypothetical concern.
tier_2: requires running this against a domain with a real GPO refresh cadence to confirm the baseline-replay volume the falsepositives block predicts, and tightening the service-stop selector before trusting its matches.

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

Start with selection_service_stop: add a verb term (stop, config) so it can't match a share path that merely contains the word "eventlog." Then suppress the auditpol selectors around your gpupdate schedule, or correlate against the change rather than the raw command — a subcategory flipping to disabled when the baseline says it should be enabled is the real signal, not the disable command in isolation. Exclude known imaging and CIS-remediation service accounts from selection_service_stop by User. level: low already reflects how dominant the GPO false positive is; don't raise it without narrowing the auditpol selector first.

Declared by the author

Group Policy re-application. A scheduled gpupdate cycle replays the site's audit-policy baseline through auditpol on every domain-joined host, and most real baselines leave several subcategories at success-only or failure-only, so the remaining half of each pair is written as a literal /success:disable or /failure:disable on a normal refresh interval. This is the highest-volume source by a wide margin on a managed domain.
Log-retention and disk-space management tooling that disables noisy diagnostic or operational channels (for example a verbose PowerShell or application-compatibility log) with wevtutil sl ... /e:false as part of a documented baseline, rather than the Security or System channel.
Imaging, sysprep and generalization tooling that stops or reconfigures the EventLog service as one step of a multi-step build process, which is disruptive but sanctioned.
Security baseline and compliance tools (CIS/STIG remediation scripts) that assert an intentionally-disabled subcategory explicitly rather than relying on the existing state, producing the same auditpol command an adversary would run.

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.001, evaluated against their process_creation events.

Share this rule

/u/siemphony/c74dd0b5-5b58-4b9e-beb6-6862f33d3ad5

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.

No comments yet. Someone who deploys this will have something to say about it.

Audit policy or Windows Event Log channel disabled via CLI tooling

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it