[Rule Tuning] Sensitive Audit Policy Sub-Category Disabled (0ef5d3eb-67ef-43ab-93b7-305cfa5a21f6)

[tradebot-elastic]

Rule Tuning Analysis

Rule ID: 0ef5d3eb-67ef-43ab-93b7-305cfa5a21f6
Rule Name: Sensitive Audit Policy Sub-Category Disabled
Rule Type: query

---

Classification

Metric	Value
Category	NOISY_PERFORMANT
Priority	MEDIUM
Tuning Score	47.09
Version Status	✅ Established (24 release cycles)

---

Alert Telemetry

Metric	Value
Total Alerts (3d)	44,909
Unique Clusters	87
Cluster Coverage	3.1%
Daily Average	14970
Days Active	3
Coefficient of Variation	0.65 (MODERATE)

---

Analysis Flags

• 🔴 Noisy on Latest Version: ✅ Yes
• 🔴 Widespread False Positive: ❌ No
• ⚠️ Version Regression: ❌ No
• ⚠️ Stale and Noisy: ❌ No
• ⚠️ Low Version / High Volume: ❌ No
• ℹ️ Low Activity: ❌ No

---

Recommendation

Action: Modify the KQL to suppress the common SYSTEM+computer-account pattern when only Success auditing is removed, while still alerting on Success+Failure removal and on non-computer/non-SYSTEM actors.

Rationale: This rule is extremely noisy in a small subset of environments and the sampled alerts consistently show audit sub-category changes being performed under Local System (S-1-5-18) by the computer account (e.g., HAL-D38B6F4$, MH-DC-03$). This pattern is commonly associated with automated policy enforcement (e.g., GPO / baseline tooling) rather than hands-on attacker activity. The best way to reduce volume while preserving detection value is to (1) focus on higher-fidelity cases (e.g., Success+Failure removed), and (2) suppress the very common automated pattern where only Success is removed under SYSTEM/computer-account context.

Query Modifications

High false-positive volume from automated SYSTEM/computer-account audit policy enforcement when only Success auditing is removed. (Impact: accuracy)

Current:

event.code : "4719" and host.os.type : "windows" and
  winlog.event_data.AuditPolicyChangesDescription : "Success removed" and
  winlog.event_data.SubCategory : ("Logon" or "Audit Policy Change" or "Process Creation" or "Audit Other System Events" or "Audit Security Group Management" or "Audit User Account Management")

Modify →

event.code : "4719" and host.os.type : "windows" and
  winlog.event_data.AuditPolicyChangesDescription : "Success removed" and
  winlog.event_data.SubCategory : ("Logon" or "Audit Policy Change" or "Process Creation" or "Audit Other System Events" or "Audit Security Group Management" or "Audit User Account Management") and
  /* suppress common automated 'success-only' removal by SYSTEM/computer account */
  not (
    winlog.event_data.SubjectUserSid : "S-1-5-18" and
    winlog.event_data.SubjectUserName : "*$" and
    not winlog.event_data.AuditPolicyChangesDescription : "Failure removed"
  )

Grounded in samples: all events are SYSTEM (S-1-5-18) and computer accounts (username endswith $). Events 1 and 5 show success-only removal; excluding this specific automation pattern cuts common benign churn while keeping alerts for (a) non-SYSTEM/non-machine actors, and (b) more severe Success+Failure removal (seen in Events 2-4).

Query can scan unnecessary Windows/security-like data in mixed indices; add provider/dataset to reduce search space. (Impact: performance)

Current:

event.code : "4719" and host.os.type : "windows" and ...

Modify →

event.code : "4719" and host.os.type : "windows" and
event.provider : "Microsoft-Windows-Security-Auditing" and
event.dataset : "system.security" and
winlog.channel : "Security" and
winlog.event_data.AuditPolicyChangesDescription : "Success removed" and
winlog.event_data.SubCategory : ("Logon" or "Audit Policy Change" or "Process Creation" or "Audit Other System Events" or "Audit Security Group Management" or "Audit User Account Management")

In the samples, the triggering events consistently come from the Security channel, system.security dataset, and Microsoft-Windows-Security-Auditing provider. Adding these filters early typically reduces the amount of data scanned in broad index patterns (winlogbeat-, forwarded, logs-system.security).

Exception Recommendations

Add exception: winlog.event_data.SubjectUserSid is "S-1-5-18" (Confidence: HIGH)

Evidence: All provided samples show SubjectUserSid=S-1-5-18 (Local System) with SubjectLogonId=0x3e7, indicating automated/system context (Events 1-5). Use this only in combination with the machine-account + success-only conditions to avoid broadly suppressing true attacker activity running as SYSTEM.

Modify →

and winlog.event_data.SubjectUserSid is "S-1-5-18"

Add exception: winlog.event_data.SubjectUserName wildcard "*$" (Confidence: HIGH)

Evidence: Samples show SubjectUserName as the computer account (e.g., HAL-D38B6F4$, MH-DC-04$, MH-DC-03$, HPR-APP66$) (Events 1-5). This is a strong indicator of policy application by the machine rather than a named admin user. Apply with AND alongside SubjectUserSid=S-1-5-18 and the success-only condition to reduce noise without fully disabling the detection for real user-driven tampering.

Modify →

and winlog.event_data.SubjectUserName wildcard "*$"

Add exception: winlog.event_data.AuditPolicyChangesDescription is "Success removed" (Confidence: MEDIUM)

Evidence: Some noisy samples contain only "Success removed" (Event 1 and Event 5 show AuditPolicyChangesDescription=["Success removed"]). If your environment intentionally disables Success auditing via automated policy, combining this with SYSTEM+computer-account suppression will significantly reduce volume. Do NOT apply this exception by itself (it would blind the rule).

Modify →

and winlog.event_data.AuditPolicyChangesDescription is "Success removed"

Field-Level Recommendations

Field	Value	Alert %	Cluster %	Confidence	Type
winlog.event_data.SubjectUserSid	S-1-5-18	0.0%	100.0%	HIGH	EXCEPTION
winlog.event_data.SubjectUserName	*$	0.0%	100.0%	HIGH	EXCEPTION
winlog.event_data.AuditPolicyChangesDescription	Success removed	0.0%	100.0%	MEDIUM	EXCEPTION

---

This issue was generated by the GenAI Tradecraft Rule Tuning Advisor.
Analysis timestamp: 2026-02-20T06:22:55.607810