Detection rules › Elastic

Sensitive Audit Policy Sub-Category Disabled

Author
Elastic
Source
upstream

Identifies attempts to disable auditing for some security sensitive audit policy sub-categories. This is often done by attackers in an attempt to evade detection and forensics on a system.

MITRE ATT&CK coverage

TacticTechniques
Defense EvasionT1070 Indicator Removal, T1070.001 Indicator Removal: Clear Windows Event Logs, T1562 Impair Defenses, T1562.002 Impair Defenses: Disable Windows Event Logging, T1562.006 Impair Defenses: Indicator Blocking

Event coverage

ProviderEvent IDTitle
Security-Auditing4719System audit policy was changed.

Stages and Predicates

Stage 1: esql:from

Stage 2: esql:where

winlog.event_data.AuditPolicyChangesDescription:("Success Added" or "Success removed") and winlog.event_data.SubCategory:("Audit Policy Change" or "Logon" or "Other System Events" or "Process Creation" or "Security Group Management" or "User Account Management")

Stage 3: esql:eval

Stage 4: esql:inline

Stage 5: esql:where

not <macro:> and winlog.event_data.AuditPolicyChangesDescription:"Success removed"

Stage 6: esql:where

<macro:>

Stage 7: esql:keep

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

FieldKindValues
winlog.event_data.AuditPolicyChangesDescriptioneq
  • Success removed
winlog.event_data.AuditPolicyChangesDescriptionin
  • Success Added
  • Success removed
winlog.event_data.SubCategoryin
  • Audit Policy Change
  • Logon
  • Other System Events
  • Process Creation
  • Security Group Management
  • User Account Management

Neighbors

Stricter alternatives (narrower than this rule)

The rules below may be useful if you find the current rule is too noisy / lacks specificity.