Windows event logs worth forwarding, and the ones that waste money

Log collection has a cost that scales with volume and a value that does not. Collecting everything produces a bill that grows every year and a data set nobody can search quickly. Collecting nothing means that during an incident you are reconstructing events from memory.

The useful middle is narrow and specific: collect the events that answer the questions an investigation actually asks, and leave the rest on the device.

The questions an investigation asks

Work backwards from these. Almost every incident investigation needs to answer some subset:

• Who signed in, from where, and when?
• Who obtained administrative rights, and how?
• What accounts and group memberships changed?
• What ran, and what started it?
• What persisted — services, scheduled tasks, run keys?
• What was accessed?
• Did anyone try to cover their tracks?

Each maps to a small number of events. That mapping is your collection list.

The events worth collecting

Authentication and session

4624 — an account was successfully logged on. The single most valuable security event Windows produces. The logon type matters enormously: type 2 is interactive, type 3 is network, type 10 is remote interactive. A type 10 logon by an administrative account onto a workstation is exactly the pattern the tiering model in administrative tiering exists to prevent.

4625 — an account failed to log on. Individually noisy, collectively essential: password spray is a pattern across many accounts with few attempts each, which is invisible in any single event.

4648 — a logon was attempted using explicit credentials. This is a lateral movement indicator, showing an account being used from a session belonging to someone else.

4672 — special privileges assigned to a new logon. Effectively “an administrative session started”. High value, moderate volume.

4634 and 4647 — logoff. Useful for establishing session duration. Lower priority if volume is a concern.

Directory and account changes

4720 — a user account was created. 4722, 4725, 4726 — account enabled, disabled, deleted. 4728, 4732, 4756 — a member was added to a security-enabled global, local and universal group respectively. These three are how privilege escalation appears in the log, and they are essential. 4738 — a user account was changed. 4740 — an account was locked out. 4767 — an account was unlocked.

Group membership changes to privileged groups deserve their own alert, not merely collection.

Kerberos, on domain controllers

4768 — a ticket-granting ticket was requested. 4769 — a service ticket was requested. 4771 — Kerberos pre-authentication failed.

These are high volume on a busy domain controller, and they are the events that reveal Kerberos-specific attacks. If budget forces a choice, 4771 and 4768 carry more investigative weight per event than 4769.

Execution and persistence

4688 — a new process has been created. This is the highest-value event for understanding what happened on a machine, and the highest volume. Enable command line auditing with it, because a process name without its arguments answers much less than people expect.

Be deliberate here. 4688 with command lines across an entire estate is frequently the single largest contributor to an ingestion bill. Options: collect it from servers and privileged workstations only, or rely on Defender for Endpoint’s own process telemetry, which covers the same ground without duplicating it into your log platform.

7045 — a service was installed on the system. Low volume, high value. Installing a service is a standard persistence and lateral movement technique.

4697 — a service was installed, from the security log where the relevant audit policy is enabled.

4698, 4699, 4702 — a scheduled task was created, deleted or updated. Same reasoning: low volume, a known persistence technique.

Tampering

1102 — the audit log was cleared. This should never happen in normal operation. Alert on it immediately, every time, without exception.

4719 — system audit policy was changed. An attacker reducing what is logged before doing something. Rare and high signal.

104 — a log file was cleared, from the System log.

Policy and credential protection

4713, 4716, 4739 — domain policy and trust changes. Rare, and they matter.

Changes to the credential protection settings discussed in protecting LSASS are also worth capturing, because disabling those protections is a preparatory step.

What is usually not worth forwarding

Being explicit about this is what keeps the bill sensible:

• Verbose informational events from every service. Application and System logs in full are enormous and mostly operational rather than investigative.
• 4689 — process termination. Rarely used in investigation, high volume.
• Successful file and registry access auditing across the board. Object access auditing is valuable narrowly — on a specific sensitive share or registry key — and ruinous when enabled broadly. This is the single most common cause of an unexpected ingestion bill.
• Print, DNS debug and similar operational logs, unless you have a specific reason.
• Everything from low-value endpoints, where endpoint detection and response already covers the ground.

Implementation

Confirm the audit policy actually generates the events. This is the step that gets skipped, and it means collections quietly produce nothing. Many of the events above require advanced audit policy configuration that is not on by default — process creation, command line auditing, and several of the directory categories.

# What is the effective audit policy on this machine?
auditpol /get /category:*

Configure audit policy through Group Policy or Intune, consistently, and verify on a sample of machines rather than trusting the policy console.

Choose a collection mechanism. Windows Event Forwarding to a collector, an agent writing to your SIEM, or the Azure Monitor Agent with data collection rules. The last of these lets you filter at the source with an XPath query, which is the mechanism that actually controls cost — filtering after ingestion does not save anything.

Filter at the source. Specify the event IDs you want rather than forwarding whole channels and discarding later.

Tier your collection. Domain controllers and Tier 0 systems justify verbose collection. Ordinary workstations justify much less. One policy for everything is how estates end up paying for workstation noise and still missing domain controller detail.

Validation

• Generate each event deliberately — sign in, fail a sign-in, add an account to a group, create a scheduled task — and confirm it arrives in your platform, with the fields you need. This is the only real test.
• Confirm the arrival latency. An alert that fires two hours later has a different operational value from one that fires in two minutes, and you need to know which you have.
• Check coverage: which machines are actually reporting? The gap is usually a group of servers nobody enrolled.
• Confirm your retention meets whatever obligation you have, and know the cost of extending it.

Operations

Review ingestion by source and event ID monthly. The largest contributor is rarely what anyone expects, and the exercise usually finds one misconfigured source producing most of the volume.

Revisit the list after each incident. The most valuable input to this design is the investigation where you wished you had something and did not.

Use cheaper tiers where they fit. Log platforms increasingly offer lower-cost tiers for high-volume data that is searched rarely rather than alerted on. Verbose process creation data is a natural candidate.

Do not collect what you will never look at. Data that is neither alerted on nor searched during investigations is pure cost, and the honest test is whether anyone has queried it in the past year.

Verification and limits

The event IDs and their meanings, the requirement for advanced audit policy configuration to generate several of them, command line auditing for process creation, and source-side filtering in collection mechanisms were checked against current Microsoft documentation on 20 September 2026. The collection priorities, the exclusions and the tiering advice are my own judgement, and the right list for any organisation depends on its threat model and budget.

Nothing here was deployed for this article. auditpol /get is read-only. Enabling audit policy — particularly object access or process creation with command lines — can increase log volume and ingestion cost substantially: enable on a sample first, measure the volume, and confirm each event is actually generated in your estate before building detections on it.

References

• Advanced security audit policy settings
• Audit Process Creation and command line auditing
• Use Windows Event Forwarding to help with intrusion detection
• Collect Windows events with Azure Monitor Agent