Event ID 4719: system audit policy was changed
Event 4719 means an audit setting changed: a category of events is now logged, or no longer logged. Most of the time it is Group Policy applying your settings. But switching off logon or process auditing is also a classic step for an attacker who wants to stay unseen – often together with clearing the log (1102).
- What it is: a change to the audit policy – which subcategory, and whether Success / Failure was added or removed.
- Often normal: Group Policy writes it (as the computer account) when it applies changed settings.
- Suspicious: Success or Failure removed for Logon, Process Creation, Account Management, Audit Policy Change – by a user account, outside a planned change.
- Check the result:
auditpol /get /category:*.
1. The fields
- Subject (
SubjectUserName): who changed it. The computer account (NAME$) or SYSTEM means Group Policy or a local tool. - Subcategory and Subcategory GUID (
SubcategoryGuid): which audit setting. The GUID is the same on every Windows language. - Changes (
AuditPolicyChanges):%%8449Success added,%%8448Success removed,%%8451Failure added,%%8450Failure removed.
2. PowerShell: what was switched off
function Get-EventFields($e) { $d = [ordered]@{}; ([xml]$e.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }; [pscustomobject]$d }
$codes = @{ '%%8448' = 'Success removed'; '%%8449' = 'Success added'; '%%8450' = 'Failure removed'; '%%8451' = 'Failure added' }
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4719; StartTime=(Get-Date).AddDays(-30)} -ErrorAction SilentlyContinue |
ForEach-Object { $f = Get-EventFields $_
[pscustomobject]@{ Time = $_.TimeCreated; By = $f.SubjectUserName; Subcategory = $f.SubcategoryGuid
Change = (($f.AuditPolicyChanges -split ',\s*') | ForEach-Object { $codes[$_.Trim()] }) -join ', ' } } |
Format-Table -AutoSize
Look up a GUID with auditpol /list /subcategory:* /v.
3. Normal or attack?
- Normal: by the computer account after a Group Policy change your team made; during software installation of a monitoring tool; at the time of a planned hardening.
- Suspicious: by a user account; removed for Logon, Credential Validation, Process Creation, User Account Management or Audit Policy Change; at the same time as other attack signs (new accounts, cleared logs, new services).
Set it right again (auditpol /set ... or gpupdate /force) and find out who had administrator rights at that time.
4. Let Coinetic watch it for you
Coinetic keeps the network side of a Server or PC in shape, so attackers rarely get as far as this:
- A security check with plain explanations: open ports, risky settings and firewall rules nobody needs any more – each with a severity and a fix you can undo.
- Firewall change watch: if something switches the firewall off or opens a port to everyone, Coinetic alerts you and names the program.
- Logging kept on: Coinetic keeps the audit settings and the Security log size it needs, and reports audit settings that flood the log.
- Ask AI (Pro + AI): “Which finding of the security check should I fix first, and why?”
Download Coinetic, install, done: it starts protecting at once. 30 days free with all features, no payment details. From $20 per computer per year.
More guides: all Coinetic guides.
Frequently asked
Why do I get 4719 after every gpupdate?
Only when a setting actually changes. If you see the same change again and again, two policies are fighting over the setting - for example a domain GPO and a local tool.
Can an attacker change auditing without a 4719?
Changing the audit policy through the normal ways writes a 4719. Attackers with full control can do much more, which is why logs should also be forwarded to another system.
Which audit settings should never be off?
At least Logon, Credential Validation, User Account Management, Security Group Management and Audit Policy Change. Microsoft's Security Baselines list the full recommendation.