The noisiest Windows Security Event IDs, and how to filter them without going blind.

Four rules before you drop anything

1. Fix the cause, not the symptom. Most Security-log noise comes from an audit subcategory or SACL that is wider than anyone needs. Narrowing it at source also saves CPU and disk on the host.
2. Narrow, don't amputate. Filter on the fields that make an event boring: a known process, a read-only access mask, a loopback address. Dropping a whole Event ID throws away the rare instance that matters.
3. Check your detections first. Search your SIEM content for each Event ID before you touch it.
4. Make every drop countable. If you cannot say how many events each rule removed, an attacker's activity and your own filter look the same: nothing.

Measure before you drop

Rank Event IDs by bytes as well as count: 4662 with many property GUIDs and 4688 with long command lines cost more than their counts suggest. In Splunk, over a representative day:

index=wineventlog earliest=-24h
| eval bytes=len(_raw)
| stats count sum(bytes) as bytes by EventCode
| sort - bytes

On a single host, before any SIEM is involved (a sample, not a rate):

Get-WinEvent -LogName Security -MaxEvents 100000 |
  Group-Object -Property Id |
  Sort-Object -Property Count -Descending |
  Select-Object -First 15 -Property Count, Name

Then check which audit subcategories are on with auditpol /get /category:*, and measure per server role: domain controllers, file servers and workstations have different top tens. To turn the numbers into money, use the savings calculator.

Where to filter, and the limits of Windows XPath

There are three places to cut volume, from cheapest to most flexible:

1. Audit policy and SACLs. The event is never generated. Set Advanced Audit Policy through Group Policy, because domain policy overwrites local auditpol changes.
2. The event query. An XPath query on the subscription or collector means the event is written locally but never read or forwarded. This is how Windows Event Forwarding and Get-WinEvent -FilterXml filter.
3. A pipeline filter on the agent or collector. Conditions on any field, including regular expressions, before the SIEM's meter runs.

Windows supports only a subset of XPath 1.0. Microsoft lists the operators and, or, =, !=, <, <=, >, >= and parentheses, and only the band(), timediff() and position functions, so there is no contains(), starts-with() or regular expression. A compound expression of more than 20 expressions must be written as a structured QueryList. The <Suppress> snippets below go inside a <Query> alongside its <Select>, and match exact values only; anything fuzzier belongs in a pipeline filter. Test every query against real events first:

$q = @'
<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=5156)] and EventData[Data[@Name='DestAddress']='127.0.0.1']]</Select>
  </Query>
</QueryList>
'@
Get-WinEvent -FilterXml ([xml]$q) -MaxEvents 20

4662: an operation was performed on an object

What it records. An operation on an Active Directory object, logged on domain controllers, with the subject, the object class (ObjectType, a schema GUID), the AccessMask and a Properties list of GUIDs. It is produced by Audit Directory Service Access, only where the object's SACL matches.

Why it is noisy. Broad inherited SACLs meet constant directory reads from Entra Connect, backup and monitoring service accounts, and every Read Property (0x10) produces an event.

What you lose if you drop it. A lot. DCSync shows up as 4662 with Control Access (0x100) and the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All rights GUIDs in Properties. Writes to AdminSDHolder, Group Policy containers and the domain object are also here.

Safer reduction. Trim the SACLs to the objects and rights you alert on, then suppress pure reads and keep writes, control access and deletes. If you use 4662 reads to spot reconnaissance, drop only reads by named service accounts.

<Suppress Path="Security">
  *[System[(EventID=4662)] and EventData[Data[@Name='AccessMask']='0x10']]
</Suppress>

4663 and 4656: file, registry and kernel object access

What they record. 4656 is a handle request (success or failure); 4663 is an access right actually used (success only). Both carry ObjectType, ObjectName, AccessMask and ProcessName, and come from Audit File System, Registry, Kernel Object and Removable Storage where a SACL matches.

Why they are noisy. SACLs auditing "Everyone: Read" on whole volumes or hives, global object access auditing, and antivirus, backup and search indexers reading everything. Microsoft says kernel object auditing has little to no security relevance unless you know exactly what you need.

What you lose. Writes, deletes and permission or owner changes on sensitive data (WriteData 0x2, AppendData 0x4, DELETE 0x10000, WRITE_DAC 0x40000, WRITE_OWNER 0x80000): your ransomware, tampering and data-staging signals.

Safer reduction. Audit write-class rights on the folders and keys that matter, suppress reads by processes you have confirmed as benign (by exact path), and keep only failed 4656 events, which Microsoft recommends watching:

<Suppress Path="Security">
  *[System[(EventID=4663)] and EventData[Data[@Name='AccessMask']='0x1'
    and Data[@Name='ProcessName']='C:\Program Files\ExampleBackup\agent.exe']]
</Suppress>
<Suppress Path="Security">
  *[System[(EventID=4656) and band(Keywords,9007199254740992)]]
</Suppress>

9007199254740992 is 0x20000000000000, the Audit Success keyword.

4658 and 4690: handle manipulation

What they record. 4658 is a handle being closed; 4690 is an attempt to duplicate one. Neither names the object, so they only make sense correlated on handle ID. Both come from Audit Handle Manipulation, which Microsoft rates high-volume.

What you lose. Very little. Microsoft says these events typically have "little to no security relevance" and does not recommend enabling the subcategory on domain controllers, servers or workstations.

Safer reduction. This is the honest case for removing a whole ID. Disable Audit Handle Manipulation; until that rolls out, suppress both:

<Suppress Path="Security">*[System[(EventID=4658 or EventID=4690)]]</Suppress>

4688: a new process has been created

What it records. Every process start, with NewProcessName, ParentProcessName (Windows 10 and Server 2016 onwards), subjects, TokenElevationType and, if the "Include command line in process creation events" policy is on, CommandLine. It comes from Audit Process Creation.

Why it is noisy. Agents and scheduled tasks start the same short-lived processes thousands of times a day, and long command lines make each event large.

What you lose. Without EDR or Sysmon in the SIEM, this is one of the highest-value events on a Windows host: living-off-the-land binaries, odd parent and child pairs, encoded PowerShell, elevated tokens. Never drop 4688 by image name alone.

Safer reduction. Suppress verified parent and child pairs by full path, and aggregate patterns you want counted rather than dropped (one event per parent, child and host per minute):

<Suppress Path="Security">
  *[System[(EventID=4688)] and EventData[
    Data[@Name='ParentProcessName']='C:\Program Files\ExampleAgent\collector.exe'
    and Data[@Name='NewProcessName']='C:\Windows\System32\conhost.exe']]
</Suppress>

5156 and 5158: the Windows Filtering Platform

What they record. 5156 is a permitted connection, with Application (a \device\harddiskvolumeN\… path), Direction, addresses, ports and Protocol; 5158 is a permitted bind to a local port. Both come from Audit Filtering Platform Connection, which also produces the failures 5157 and 5159.

Why they are noisy. One event per allowed connection, on every host, and very high volumes on domain controllers, DNS and file servers. Microsoft recommends auditing Failure but not Success by default, except where you must watch connections to untrusted addresses on high-value machines.

What you lose. 5156 is crude network telemetry; Sysmon Event ID 3, firewall or flow logs are usually better. 5158 adds almost nothing.

Safer reduction. Follow Microsoft's baseline in Group Policy, or locally:

auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:enable

Where you keep Success, drop 5158 and loopback 5156:

<Suppress Path="Security">*[System[(EventID=5158)]]</Suppress>
<Suppress Path="Security">
  *[System[(EventID=5156)] and EventData[Data[@Name='DestAddress']='127.0.0.1'
    or Data[@Name='DestAddress']='::1']]
</Suppress>

4624 and 4634: network logons and logoffs

What they record. A successful logon (Audit Logon) and a logoff (Audit Logoff), each with a LogonType. Type 3 (network) dominates on domain controllers and file servers: every SMB session and machine-account connection produces one.

What you lose. 4624 is core evidence for lateral movement and credential misuse, so keep it for user accounts. Network logoffs (4634 type 3) are rarely used in detections.

Safer reduction. Drop type 3 logoffs:

<Suppress Path="Security">
  *[System[(EventID=4634)] and EventData[Data[@Name='LogonType']='3']]
</Suppress>

Machine accounts (names ending in $) are the bulk of type 3 4624 on a DC, but XPath cannot test a suffix. Use a pipeline filter, or aggregate them to one event per account and source address per minute, with a count.

5145: a network share object was checked

What it records. Every file or folder access over a share, with ShareName (as \\*\SHARE), RelativeTargetName, IpAddress and AccessMask. It comes from Audit Detailed File Share, and because shares have no SACLs, enabling it audits everything shared.

Why it is noisy. Microsoft rates it high on file servers, and on domain controllers "because of SYSVOL network access required by Group Policy"; on DCs it recommends auditing Failure only.

What you lose. IPC$ named pipes such as svcctl, atsvc and samr, and writes to ADMIN$ or C$: classic signs of remote service creation, PsExec-style tooling and enumeration.

Safer reduction. Drop read-only SYSVOL traffic (Group Policy processing) and keep the rest. 0x120089 is the generic read mask:

<Suppress Path="Security">
  *[System[(EventID=5145)] and EventData[Data[@Name='ShareName']='\\*\SYSVOL'
    and Data[@Name='AccessMask']='0x120089']]
</Suppress>

4703: a user right was adjusted

What it records. Token privileges being enabled or disabled, with the process and privilege lists, on Windows 10 and Server 2016 onwards. It comes from Audit Authorization Policy Change. Microsoft's example of the noise is Configuration Manager's recurring WMI queries, logged as svchost.exe.

What you lose. Microsoft's suggested fix is to disable Success for the subcategory, but that also removes 4704, 4705 and 4670, which are far more valuable. Filter instead, and write down that you are trading away SYSTEM-context svchost privilege changes:

<Suppress Path="Security">
  *[System[(EventID=4703)] and EventData[Data[@Name='SubjectUserSid']='S-1-5-18'
    and Data[@Name='ProcessName']='C:\Windows\System32\svchost.exe']]
</Suppress>

Summary table

Doing it in DPLens

DPLens is a UK-built, self-hosted log collection and security data pipeline agent for Windows. It applies the same layers on the host, and its console shows each source's rate, a stage-by-stage funnel and every loss by cause.

At the source. A Windows Event Log source can include or exclude Event IDs, providers and severity, or take your own XPath query, so excluded events are never collected. The whole-ID drops from this guide fit in one query:

*[System[(EventID!=4658 and EventID!=4690 and EventID!=5158)]]

In the pipeline. A filter keeps or drops events by any combination of conditions on any field: equals, not equals, contains, pattern match, greater or less than, in a list, and network range. That covers what XPath cannot, such as the machine-account suffix. One filter rule can drop, for example:

• Event ID 4662 where AccessMask is 0x10 (Read Property only);
• Event ID 4634 where LogonType is 3 and TargetUserName ends in $.

Field names follow the event's EventData names; check names and values on Live stream before relying on a rule. To collapse repeats instead, aggregate them: one event per group and time window, with a count. Set filters in the agent console on one machine, or once in DPLens Manager for the whole fleet.

Counted, not silent. Every event a rule removes is counted against that rule on the Overview funnel and the Pipeline page, so "are we filtering that?" has a numeric answer. For the cost case, see SIEM cost reduction; for channels, Sysmon and PowerShell logs, see Windows Event Log collection.

Sources

Event descriptions, subcategories, field names and volume ratings are from Microsoft's security auditing reference:

• 4662(S, F): An operation was performed on an object
• 4663(S): An attempt was made to access an object
• 4656(S, F): A handle to an object was requested
• 4658(S): The handle to an object was closed
• Audit Handle Manipulation
• 4688(S): A new process has been created
• 5156(S): The Windows Filtering Platform has permitted a connection
• 5158(S): The Windows Filtering Platform has permitted a bind to a local port
• Audit Filtering Platform Connection
• 4624(S): An account was successfully logged on
• 4634(S): An account was logged off
• 5145(S, F): A network share object was checked to see whether client can be granted desired access
• Audit Detailed File Share
• 4703(S): A user right was adjusted
• Audit Authorization Policy Change
• DS-Replication-Get-Changes-All extended right
• Consuming Events (Windows Event Log): XPath 1.0 limitations