Event 4719: System audit policy was changed.
Quick Answer
Event 4719 logs changes to the system's audit policy, recording when security event logging settings are modified. Attackers modify audit policies to disable logging and evade detection. This event is critical for detecting attempts to blind security monitoring systems.
Technical Details
Event ID: 4719
Windows Security- Policy Change
Event Description
System audit policy was changed.
Key Log Fields
SubjectUserName- Account that changed audit policySubjectDomainName- Domain of the accountSubjectLogonId- Logon ID for correlationCategoryId- Audit category that was modifiedSubcategoryId- Audit subcategory that was modifiedSubcategoryGuid- GUID of the subcategoryAuditPolicyChanges- Changes made to audit policy (Success/Failure enabled/disabled)
MITRE ATT&CK® Mapping (3)
Adversaries may maliciously modify components of a victim environment in order to hinder or disable defensive mechanisms. This not only involves impairing preventative defenses, such as firewalls and anti-virus, but also detection capabilities that defenders can use to audit activity and identify malicious behavior. This may also span both native defenses as well as supplemental capabilities installed by users and administrators. Adversaries may also impair routine operations that contribute to defensive hygiene, such as blocking users from logging out, preventing a system from shutting down, or disabling or modifying the update process. Adversaries could also target event aggregation and analysis mechanisms, or otherwise disrupt these procedures by altering other system components. These restrictions can further enable malicious operations as well as the continued propagation of incidents.(Citation: Google Cloud Mandiant UNC3886 2024)(Citation: Emotet shutdown)
Adversaries may disable Windows event logging to limit data that can be leveraged for detections and audits. Windows event logs record user and system activity such as login attempts, process creation, and much more.(Citation: Windows Log Events) This data is used by security tools and analysts to generate detections. The EventLog service maintains event logs from various system components and applications.(Citation: EventLog_Core_Technologies) By default, the service automatically starts when a system powers on. An audit policy, maintained by the Local Security Policy (secpol.msc), defines which system events the EventLog service logs. Security audit policy settings can be changed by running secpol.msc, then navigating to <code>Security Settings\Local Policies\Audit Policy</code> for basic audit policy settings or <code>Security Settings\Advanced Audit Policy Configuration</code> for advanced audit policy settings.(Citation: Audit_Policy_Microsoft)(Citation: Advanced_sec_audit_policy_settings) <code>auditpol.exe</code> may also be used to set audit policies.(Citation: auditpol) Adversaries may target system-wide logging or just that of a particular application. For example, the Windows EventLog service may be disabled using the <code>Set-Service -Name EventLog -Status Stopped</code> or <code>sc config eventlog start=disabled</code> commands (followed by manually stopping the service using <code>Stop-Service -Name EventLog</code>).(Citation: Disable_Win_Event_Logging)(Citation: disable_win_evt_logging) Additionally, the service may be disabled by modifying the “Start” value in <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog</code> then restarting the system for the change to take effect.(Citation: disable_win_evt_logging) There are several ways to disable the EventLog service via registry key modification. First, without Administrator privileges, adversaries may modify the "Start" value in the key <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-Security</code>, then reboot the system to disable the Security EventLog.(Citation: winser19_file_overwrite_bug_twitter) Second, with Administrator privilege, adversaries may modify the same values in <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-System</code> and <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-Application</code> to disable the entire EventLog.(Citation: disable_win_evt_logging) Additionally, adversaries may use <code>auditpol</code> and its sub-commands in a command prompt to disable auditing or clear the audit policy. To enable or disable a specified setting or audit category, adversaries may use the <code>/success</code> or <code>/failure</code> parameters. For example, <code>auditpol /set /category:”Account Logon” /success:disable /failure:disable</code> turns off auditing for the Account Logon category.(Citation: auditpol.exe_STRONTIC)(Citation: T1562.002_redcanaryco) To clear the audit policy, adversaries may run the following lines: <code>auditpol /clear /y</code> or <code>auditpol /remove /allusers</code>.(Citation: T1562.002_redcanaryco) By disabling Windows event logging, adversaries can operate while leaving less evidence of a compromise behind.
An adversary may attempt to block indicators or events typically captured by sensors from being gathered and analyzed. This could include maliciously redirecting(Citation: Microsoft Lamin Sept 2017) or even disabling host-based sensors, such as Event Tracing for Windows (ETW)(Citation: Microsoft About Event Tracing 2018), by tampering settings that control the collection and flow of event telemetry.(Citation: Medium Event Tracing Tampering 2018) These settings may be stored on the system in configuration files and/or in the Registry as well as being accessible via administrative utilities such as [PowerShell](https://attack.mitre.org/techniques/T1059/001) or [Windows Management Instrumentation](https://attack.mitre.org/techniques/T1047). For example, adversaries may modify the `File` value in <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security</code> to hide their malicious actions in a new or different .evtx log file. This action does not require a system reboot and takes effect immediately.(Citation: disable_win_evt_logging) ETW interruption can be achieved multiple ways, however most directly by defining conditions using the [PowerShell](https://attack.mitre.org/techniques/T1059/001) <code>Set-EtwTraceProvider</code> cmdlet or by interfacing directly with the Registry to make alterations. In the case of network-based reporting of indicators, an adversary may block traffic associated with reporting to prevent central analysis. This may be accomplished by many means, such as stopping a local process responsible for forwarding telemetry and/or creating a host-based firewall rule to block traffic to specific hosts responsible for aggregating events, such as security information and event management (SIEM) products. In Linux environments, adversaries may disable or reconfigure log processing tools such as syslog or nxlog to inhibit detection and monitoring capabilities to facilitate follow on behaviors (Citation: LemonDuck).
Event Comparison
Event 4719 logs audit policy changes. Event 1102 logs when the Security event log itself is cleared, which is another evasion technique. Both should be monitored together.
What This Event Means
Event 4719 is generated whenever the audit policy configuration is modified on a Windows system, capturing what audit category was changed, what the new setting is, and which account made the modification. This event is particularly significant because threat actors who gain administrative access frequently attempt to disable or reduce security logging to hide their activities from security operations teams. By modifying audit policies, attackers can prevent the generation of critical security events that would otherwise reveal their presence, making their actions invisible to traditional log monitoring solutions. The event records changes across all audit categories including logon/logoff, object access, privilege use, account management, and process tracking. Legitimate audit policy changes should be extremely rare in production environments and typically only occur during initial security hardening, compliance audits, or major infrastructure changes. Any unexpected modification to audit policies, especially changes that reduce or disable logging of security-critical events, should trigger immediate investigation and alert escalation. The most concerning scenario is when attackers disable audit logging for the specific activities they're about to perform, such as disabling process tracking before running malicious executables or disabling logon auditing before conducting lateral movement. Security teams should implement strict change control around audit policy modifications and consider using read-only domain controllers or secure log forwarding that continues capturing events even if local audit policy is compromised.
Security Implications
- Disabling logon/logoff auditing allows attackers to move laterally without generating authentication logs
- Turning off object access auditing hides file access and data exfiltration activities
- Disabling process tracking prevents detection of malware execution and suspicious process creation
- Audit policy changes during active intrusions indicate advanced attackers attempting to evade detection
- Changes made via Group Policy require domain admin access, indicating high-level compromise
Detection Strategies
Implement real-time alerting for any audit policy changes, as these should be extraordinarily rare in stable environments. Create detection rules that immediately notify security teams when auditing for logon events, object access, or process tracking is disabled or reduced. Monitor for audit policy changes that occur outside designated maintenance windows and without corresponding change tickets. Correlate 4719 events with the modifying account's recent activity to determine if the account may be compromised. Track patterns where audit policy is changed, malicious activity occurs, then audit policy is restored to cover tracks. Ensure audit policy logs are forwarded immediately to a centralized SIEM that attackers cannot easily access or modify. Consider implementing Windows Event Forwarding or Sysmon as compensating controls that may continue logging even if native audit policy is disabled. Pre-configured alert rules for popular SIEM platforms will be included in future documentation updates.
Note: Comprehensive SIEM detection queries for Splunk SPL, Microsoft KQL, and Elastic Query DSL will be added in future updates.
Real-World Attack Examples
APT groups including APT28 and APT29 disable specific audit categories before conducting espionage activities in compromised networks
Ransomware operators often disable security event logging before deploying encryption to avoid rapid detection and response
Insider threats frequently modify audit policies to hide data theft and unauthorized system access