Detection of Failed WMI Event Log Clear Attempts

This detection focuses on identifying instances where an attempt to clear Windows event logs via the Windows Management Instrumentation (WMI) NTEventLogFile ClearEventLog method fails. Such failures are recorded as EventID 5858 within the WMI-Activity operational log. This event is specifically generated when the WMI operation encounters an error, such as access denied due to insufficient privileges or a provider failure. While this event indicates a failed action, it is a strong indicator that an attacker has attempted to impair defenses by removing forensic evidence. Successful event log clearing operations do not generate EventID 5858 and would instead typically correlate with Security event 1102 or System event 104 for successful clearance. Detecting these failed attempts can provide an early warning of adversary activity before successful obfuscation occurs.

Impact

A successful attempt to clear event logs can significantly hamper forensic investigations and incident response efforts by removing crucial evidence of malicious activity, including initial access, privilege escalation, and lateral movement. While this brief focuses on failed attempts, the fact that such an attempt occurred signifies an adversary's intent to impair system defenses. If these attempts were to succeed, organizations could face prolonged undetected breaches, making attribution and recovery exceedingly difficult, potentially leading to significant data exfiltration, system compromise, or financial losses without a clear audit trail.

Recommendation

• Deploy the Sigma rule "Detect Failed Event Log Clear Via WMI NTEventLogFile ClearEventLog" to your SIEM system to identify failed attempts to clear event logs.
• Ensure that WMI-Activity operational logs are enabled, collected, and ingested into your SIEM, as this is the log source for EventID 5858 used by the rule.
• Review alerts generated by this rule to investigate the source process attempting the ClearEventLog method, determine if the activity was legitimate (e.g., misconfigured admin script), and adjust permissions if necessary or escalate as a security incident.