Collecting Windows event logs
Which Windows channels are read, how events reach the platform, what Sysmon adds and whether you need it, and the event IDs that carry most of the value.
Windows writes a great deal down. Most of it is noise, a small slice of it is the clearest record you will ever get of an attacker moving through your network, and the difference between the two is a question of which channels you read and which event IDs you keep. This article covers what the platform reads, how it gets there, and what you have to install to make it useful.
How Windows events actually reach the platform
There is one reader, one parser and one normalisation path for Windows events. What varies is who runs the reader, and this is the part where we have to be careful, because the answer is narrower than the codebase's own comments imply.
- The built-in collector — on-premises Windows only
- The platform's background worker can read the local machine's channels itself. It is a proper collector, with per-source scheduling, exponential back-off with jitter, panic isolation so a fault cannot take the worker down, and a durable position per channel. It exists for the small number of deployments where the worker runs on a Windows host inside your own estate. It is switched on by naming the organisation it collects for in the worker's environment, and that is also its ceiling: one organisation per worker process, one machine — the one the worker is running on.
- Pushing the events yourself — the route that works everywhere
- If you already run Windows Event Forwarding, a Winlogbeat-style shipper, or a scheduled script, you can post the events to the HTTP Event Collector with a token whose parser is
windows_eventlogfor JSON-rendered events orwindows_evtxfor records in the native shape. This works on any deployment, scales to as many machines as you have, and is the honest recommendation today. See Send events with the HTTP Event Collector.
On a non-Windows host the built-in collector is not merely inactive, it refuses to be configured: it reports itself as unavailable and validation fails with wineventlog: only supported on Windows, so a Linux worker never schedules it. That is deliberate. A collector that silently reported zero events on the wrong operating system would look exactly like a Windows machine with no activity.
The rest of this article — the channels, the event IDs, the Sysmon question — applies to both routes, because the value of Windows telemetry is decided by what the machine is configured to write down, not by which of these carries it.
Which channels are read
Five channels by default. Each is read independently, with its own position, so one unreadable channel does not stop the others.
| Channel | What it gives you |
|---|---|
Security | The core audit log: logons, logon failures, privilege use, account and group changes, process creation if you have enabled it, and the audit-policy events that reveal tampering. The most valuable single channel. |
System | Service installation and failure, driver loading, unexpected shutdowns. Where persistence installed as a service tends to show up. |
Microsoft-Windows-Sysmon/Operational | Present only if you install Sysmon. Process creation with full command lines and hashes, network connections, image loads, registry changes. |
Microsoft-Windows-PowerShell/Operational | PowerShell execution. With script block logging enabled, the actual script text — which is where obfuscated one-liners become readable. |
Microsoft-Windows-Windows Defender/Operational | Detections, quarantine actions, and — importantly — real-time protection being switched off. |
A channel that cannot be opened is logged and skipped rather than treated as fatal. Sysmon is usually absent, and Security is unreadable without sufficient privilege, so failing the whole collection because one of five channels is missing would mean most machines collected nothing at all.
The event IDs that matter most
The Security channel is filtered server-side, on the Windows machine, by an XPath query naming the specific event IDs of interest. Filtering there rather than after transfer is the difference between shipping a few hundred useful events and shipping a gigabyte of successful file-handle audits.
| Group | Event IDs | Why these |
|---|---|---|
| Authentication | 4624 4625 4634 4647 4648 4768 4769 4770 4771 4776 4778 4779 | Logon and logoff, failed logon, Kerberos ticket requests and failures, NTLM validation, and session reconnect. 4625 in volume is a password-guessing attempt; 4648 — a logon using explicitly supplied credentials — is one of the cleaner signals of credential theft in use. |
| Privilege and account change | 4672 4720 4722 4723 4724 4725 4726 4738 4740 4767 4781 4728 4729 4732 4733 4756 4757 | Special privileges assigned at logon, account created, enabled, disabled and deleted, password set by another user, account locked out and unlocked, account renamed, and additions to global, local and universal groups. This group is how an attacker creating themselves an administrator becomes visible. |
| Process | 4688 4689 | Process created and process exited. 4688 is the highest-value event in Windows for detection work and it is off by default — see below. |
| Network filtering | 5152 5156 5157 | Windows Filtering Platform blocked and permitted connections. Useful for confirming outbound activity from a machine when you have no network sensor. |
| Logging and policy tampering | 1102 4719 4907 | Audit log cleared, audit policy changed, auditing settings on an object changed. An attacker who clears the log leaves exactly one event behind, and it is 1102. |
Turn on 4688 — it is the cheapest improvement available
Process creation auditing is not enabled by default on Windows. Without it, 4688 never occurs, and a large part of what any detection product can tell you about a machine is simply not being written down. Enabling it is a Group Policy change under audit policy, and the companion setting that includes the process command line is a second, separate policy — the one that matters most, because a command line is where the malicious part of an otherwise ordinary process lives.
Be aware of the trade: command lines occasionally contain passwords typed by scripts or administrators, and once they are in your audit log they are in your audit log. That is a real consideration and not a reason to leave it off, but it is your decision to make knowingly.
What Sysmon adds, and whether you need it
Sysmon is a free Microsoft tool that installs as a driver and writes a far richer event stream than the built-in audit log. The platform reads its channel when it is present.
It is not required. Nothing here depends on it; the channel is simply skipped if the channel does not exist. What it adds is depth: process creation with the parent process and file hashes, outbound network connections attributed to the process that made them, DLL loads, and registry modification. If you are trying to answer what did this process actually do, Sysmon is the difference between a guess and an answer.
The honest counter-argument: Sysmon needs a configuration file, and an unconfigured Sysmon produces an enormous volume of events with a poor signal ratio. If you are not prepared to maintain a configuration, and you are running the Qorionix endpoint sensor, the sensor already reports process activity and reconstructs process trees — you would be paying the volume cost twice for a modest gain. If you are not running the sensor, Sysmon plus event ID 4688 is the best Windows visibility available at no licence cost.
How the collector keeps its place
Each channel's position is stored as the channel's own record identifier, not as a timestamp. This is worth a sentence of explanation because the reasoning generalises: a record identifier increases monotonically within a channel and survives a reboot, whereas a wall-clock position double-reads events across a clock correction and skips events across a clock jump forward. Neither failure announces itself.
On its first run the collector reads back one hour by default rather than the entire history of the machine, and it reads at most two thousand records per channel per cycle, polling every sixty seconds. A machine with a large backlog therefore catches up over several cycles instead of flooding the pipeline in one.
wineventlog: only supported on Windows
windows event log puller: missing <field>
siem ingest: puller not scheduled — invalid configuration
siem ingest: no sources configured; ingest worker not startedWhat to read next
- Send events with the HTTP Event Collector — if you already run a Windows log shipper and want to point it here.
- How your logs are normalised — what a
4624becomes once it is stored. - The detection library — which rules would read these events, and the current gap.
- Connecting your first log source — the per-source status table.