Windows Event IDs worth monitoring: a field reference

Before you start

This page assumes events are already flowing — if not, the Windows Event Logs guide sets up the windowseventlog receiver and an OTTL transform that promotes event.id, event.provider, and the per-event data fields to searchable attributes. Everything below filters on those attributes. The guide's config reads the Application channel; add the other two the same way:

receivers:
  windowseventlog/security:
    channel: Security
    start_at: end
  windowseventlog/system:
    channel: System
    start_at: end

Each table marks an ID with one of three tiers: alert wire a rule, review look when it fires but don't page, context keep searchable for investigations.

Security channel

The Security log answers "who did what to which account from where". It needs the Collector to run with privileges that can read it (LocalSystem as a service, or an elevated shell), and logon auditing enabled — both are on by default on servers. Each ID links to Microsoft's full field-by-field reference.

Event ID	Source	Tier	What it means	What to do with it
`4625`	Security-Auditing	alert	Failed logon. The classic brute-force signal.	Alert on a spike per host. Status says why: 0xC000006A wrong password, 0xC0000064 unknown user, 0xC0000234 locked out. LogonType says how (see properties below).
`4740`	Security-Auditing	alert	Account locked out after repeated failures.	Alert on any. TargetUserName is the locked account; CallerComputerName is where the bad attempts came from.
`1102`	Eventlog	alert	The audit log was cleared.	Alert on any, always. Admins rarely clear the Security log; attackers covering tracks do. SubjectUserName says who.
`4720`	Security-Auditing	review	A user account was created.	Review each one on servers. SubjectUserName created TargetUserName — unexpected pairs are the finding.
`4722` / `4725` / `4726`	Security-Auditing	review	Account enabled / disabled / deleted.	Review on servers; correlate with change tickets. Deletion after suspicious activity is evidence destruction.
`4728` / `4732` / `4756`	Security-Auditing	alert	Member added to a security-enabled group.	Alert when the group is privileged (Administrators, Domain Admins). MemberName joined TargetUserName (the group).
`4724`	Security-Auditing	review	Password reset attempted by another account.	Normal from helpdesk staff; suspicious from anyone else. Compare SubjectUserName vs TargetUserName.
`4648`	Security-Auditing	review	Logon with explicit credentials (runas).	A lateral-movement staple. Watch for service accounts doing this, or bursts across many hosts.
`4624`	Security-Auditing	context	Successful logon.	Too common to alert on alone — but LogonType 10 (RDP) from unexpected source IpAddress is worth a rule.
`4672`	Security-Auditing	context	Admin-level privileges assigned at logon.	Baseline who logs on with admin rights; a new name in the list is the signal.

System channel

The System log is where services, reboots, and dying hardware announce themselves. This is the channel for availability alerting.

Event ID	Source	Tier	What it means	What to do with it
`7034`	Service Control Manager	alert	A service terminated unexpectedly.	Alert when repeated — 3+ in 10 minutes for the same service is a crash loop. The service name arrives in the flattened event data.
`7045`	Service Control Manager	alert	A new service was installed.	Alert on servers: legitimate installs are rare and attackers love services for persistence. Check ServiceName and ImagePath — anything running from temp or user folders is bad.
`7031`	Service Control Manager	review	Service crashed; recovery action scheduled.	The self-healing sibling of 7034. Fine once; a pattern means the recovery is masking a real fault.
`7040`	Service Control Manager	review	Service start type was changed.	Watch for security tooling (Defender, EDR, backup agents) being set to disabled.
`6008`	EventLog	alert	The previous shutdown was unexpected.	Alert on any: the box lost power or hard-crashed. Pairs with Kernel-Power 41 from the same boot.
`41`	Kernel-Power	alert	Rebooted without a clean shutdown.	Power loss, bugcheck, or a hang forcing the reset button. If BugcheckCode in the event data is non-zero, it crashed.
`1001`	BugCheck	alert	Blue screen — bugcheck details and dump path.	Alert on any. The bugcheck code and parameters here are what you take to the vendor or driver hunt.
`1074`	User32	context	Who or what initiated a shutdown/restart.	The answer to "why did this server reboot at 03:00" — process, user, and stated reason are all in the event.
`7 / 51 / 153`	disk	alert	Bad block / paging I/O error / I/O retried.	Early disk-failure signals, usually weeks before SMART gives up. Any recurrence on the same device: plan replacement now.
`129`	storahci	review	Storage controller reset after timeout.	Repeated resets mean a failing disk, cable, or controller — often precedes the disk 153s.
`6005 / 6006`	EventLog	context	Event log service started / stopped.	Reliable boot and clean-shutdown markers; useful for uptime reconstruction, not alerting.

Application channel

The Application log is where your workloads crash. Less standardized than the other two — every vendor logs differently — but a handful of provider/ID pairs are universal.

Event ID	Source	Tier	What it means	What to do with it
`1000`	Application Error	alert	A process crashed.	Alert grouped by the faulting application name in the event data; the faulting module narrows it to the DLL.
`1002`	Application Hang	review	A process stopped responding.	Same fields as 1000. A hang followed by 1000 for the same app is a hang that was killed.
`1026`	.NET Runtime	review	Unhandled .NET exception.	Fires just before the matching 1000 and carries the exception type and stack — the more useful of the pair for .NET services.
`1001`	Windows Error Reporting	context	Crash report bucket for a preceding crash.	Mostly duplicate signal next to 1000; useful for the WER bucket ID when escalating to Microsoft.
`11707 / 11708`	MsiInstaller	context	MSI install succeeded / failed.	Handy audit trail of what got installed when — correlate with 7045 on servers.

Properties to filter on

Windows puts the interesting detail in per-event data fields, which the transform flattens into log attributes. These recur across the IDs above:

Attribute	What it tells you
`event.id / event.provider / event.channel`	Promoted by the transform in our Windows guide — these are your primary filters: every rule on this page starts with an event.id filter.
`TargetUserName`	The account acted upon: the one that failed to log on (4625), got created (4720), or got locked (4740).
`SubjectUserName`	The account that performed the action. Subject ≠ Target on account-management events is what makes them interesting.
`LogonType`	How a logon happened: 2 interactive (console), 3 network (SMB shares), 4 batch, 5 service, 7 unlock, 8 cleartext, 10 RDP, 11 cached. Filtering 4624/4625 by LogonType is the difference between noise and signal.
`IpAddress / WorkstationName`	Where a logon attempt came from. A 4625 spike from one IpAddress is a brute force; from many, a spray.
`Status / SubStatus`	Hex failure code on 4625: 0xC000006A wrong password, 0xC0000064 no such user, 0xC0000234 locked out, 0xC0000071 expired password.
`ServiceName / ImagePath`	On 7045/7034/7040: which service, and which binary it runs. ImagePath outside Program Files or System32 deserves a look.

Full per-event field definitions are in Microsoft's security auditing reference — every linked Event ID above goes to its page; for example the 4625 page documents every Status code.

The alert rules to wire first

Five rules in Telemtra alerts cover the bulk of the value, all on signal type logs with an event.id filter:

Brute force — count of event.id = 4625 per host.name above ~10 in 5 minutes. Add a second any-match rule for 4740 lockouts.
Tampering — any event.id = 1102 (audit log cleared) or 7040 touching security tooling. Treat as page-immediately.
Persistence — any event.id = 7045 on servers; review ServiceName and ImagePath on every firing.
Crash loop — count of event.id = 7034 per host above 3 in 10 minutes; the same shape works for Application 1000 grouped per app.
Hardware — any event.id in 7, 51, 153 from the disk source, plus any 6008 / Kernel-Power 41 for unexpected reboots.

Noise control

Two channels dominate volume: Security 4624 (every logon, including service accounts every few seconds) and System 7036 (every service state change). Keep 4624 — it's the investigation backbone — but don't alert on it raw. 7036 is safe to drop at ingest with Data Shaper rather than editing Collector config on every host. For the metrics side of Windows monitoring, the same hosts can report CPU, disk, and filesystem data — see the host metrics reference for what the hostmetrics receiver emits on Windows. Running a mixed fleet? The Linux log patterns reference is this page's sibling for auth.log, kernel, and systemd messages.

New to Telemtra? The quickstart covers the minimum config for every supported stack, and creating a workspace takes about a minute.

The Windows Event IDsactually worth watching.