Windows Audit Policy Sub-Category Disabled

Attackers may disable auditing on a system in order to evade detection and forensic analysis. This is often done after initial compromise, to prevent security tools from logging their actions. This rule identifies attempts to disable auditing for specific security-sensitive audit policy sub-categories, providing defenders with insight into potential malicious activity. The rule leverages Windows Security Event Logs and specifically focuses on Event ID 4719, which indicates changes to the audit policy. It aggregates policy changes within 5-minute windows to identify removals of audit policies that are not re-enabled within the same timeframe, reducing false positives from temporary or legitimate policy changes. This detection logic is implemented using ES|QL in Elastic Stack version 9.3.0 and later.

Attack Chain

1. Initial Access: The attacker gains initial access to the system through various means (e.g., phishing, exploitation of vulnerabilities).
2. Privilege Escalation: The attacker escalates their privileges to gain administrative or system-level access.
3. Discovery: The attacker performs reconnaissance to identify the current audit policy settings and determine which sub-categories are enabled.
4. Defense Evasion: The attacker executes commands or scripts to disable specific audit policy sub-categories, such as Logon, Audit Policy Change, Process Creation, Other System Events, Security Group Management, and User Account Management, using tools like auditpol.exe or modifying Group Policy Objects.
5. Activity Execution: With auditing disabled, the attacker performs malicious activities without generating relevant security logs.
6. Persistence: The attacker establishes persistence mechanisms to maintain access to the system, such as creating scheduled tasks or modifying registry keys.
7. Lateral Movement: The attacker moves laterally to other systems on the network, potentially disabling auditing on those systems as well.
8. Objective Completion: The attacker achieves their objective, which could include data theft, system disruption, or ransomware deployment.

Impact

Successful disabling of audit policies can severely impair an organization’s ability to detect and respond to security incidents. Without proper logging, malicious activities can go unnoticed, leading to prolonged compromises and increased damage. Disabling auditing can impact incident response efforts, making it difficult to determine the scope and impact of an attack. The risk score associated with this activity is 47, indicating a significant potential impact on security posture.

Recommendation

• Enable Audit Policy Change auditing to generate the necessary events for this rule as described in the setup instructions.
• Deploy the provided Sigma rule to your SIEM to detect attempts to disable sensitive audit policy sub-categories. Tune the rule as necessary based on your environment and baseline activity.
• Investigate any alerts generated by the Sigma rule to determine the legitimacy of the audit policy changes and identify potential malicious activity.
• Review the references to understand the significance of Event ID 4719 and its implications for security monitoring.
• Consider enabling Sysmon process creation logging with command line auditing to detect the use of tools such as auditpol.exe to modify audit policies.