What Windows Event IDs Should You Actually Monitor

Introduction

I had a conversation with a customer recently: "We want better visibility into our Windows endpoints for security monitoring, but we don't know where to start." Honestly, that's a fair place to be stuck. Windows can generate a huge number of security events, and if you try to collect everything on day one, you'll drown in noise (and ingestion costs) before you find anything useful.

So for this project, instead of trying to do everything at once, the team I worked with picked a small, high-value set of Windows Security events and started there — authentication, privileged access, process execution, registry changes, object access, and security group changes. Nothing fancy, just the events that actually tell you something when you're looking for trouble.

Objective

Collect meaningful Windows Security events from endpoints, centralize the data in Azure Data Explorer (ADX) or SIEM tool, and give security analysts a practical foundation for investigations, threat hunting, dashboards, and future detection logic.

In short, we wanted to:

• Collect meaningful security events from Windows endpoints
• Centralize the data somewhere analysts can actually query it
• Set up a foundation for future threat detection and hunting
• Start narrow, and expand once we had evidence it was worth expanding

The high-level flow:

Nothing groundbreaking here , it's the same shape most endpoint telemetry pipelines take:

Windows Endpoints  →  Security Event Logs  →  Collection Agent  →  Azure Data Explorer/SIEM  →  Investigation & Threat Hunting

Walking through it step by step:

1. Something happens on a workstation or server — a user logs in, a process runs, a registry key changes.
2. If the relevant audit policy is turned on, Windows logs an event for it.
3. A monitoring agent installed on the endpoint picks up the events we care about.
4. The agent ships those records off to ADX for ingestion.
5. Analysts query and correlate the data in ADX when they're investigating something or hunting proactively.

Simple pipeline. The value comes from which events you choose to collect and how well you understand what each one is telling you.

The starting event list

This isn't meant to be a complete security monitoring baseline , think of it as a sensible first cut. Every one of these needs to be read in context, using its detailed fields and whatever else was happening around it.

Event ID	Event	Security value
4624	Successful logon	Who accessed a device, logon type, source information, and authentication context.
4657	Registry value modified	Changes that may relate to configuration, persistence, or tampering.
4663	Attempt to access an object	Access to audited files, folders, registry keys, or other objects.
4672	Special privileges assigned to a new logon	Logons receiving sensitive administrative privileges.
4688	A new process was created	Process execution, including PowerShell, command shells, scripts, installers, and applications.
4730	Security-enabled global group deleted	Deletion of a global security group. More commonly relevant on domain controllers than ordinary endpoints.
4731	Security-enabled local group created	Creation of a local security group.
4732	Member added to a security-enabled local group	Membership additions, including additions to local Administrators.
4733	Member removed from a security-enabled local group	Membership removals from local security groups.
4734	Security-enabled local group deleted	Deletion of a local security group.
4735	Security-enabled local group changed	Changes to local security group properties or attributes.

A few of these with a closer look, so let's dig in.

4624 — Successful Logon

This one fires whenever a logon session gets created on a system. Don't just look at "someone logged in" — check the logon type, target account, source address, workstation, and authentication package. That's where the actual signal lives.

Things I'd want to know when reviewing this:

• Is that an unexpected RDP or network logon?
• Is a privileged account showing up on a device it has no business touching?
• Is one account logging into an unusual number of systems in a short window?

4672 — Special Privileges Assigned

This flags logons that receive sensitive privileges. It pairs nicely with 4624, but don't treat it as automatically suspicious — plenty of legitimate admin and service accounts trigger this every day. Context is everything.

Worth checking:

• An administrative logon that doesn't fit the usual pattern
• A service account suddenly getting privileges on a device it's never touched before

4688 — New Process Created

This is your window into process execution. If you want command-line details, you'll need the right audit setting enabled — and you should think through the privacy and data-volume implications before you turn that on everywhere.

Processes worth keeping an eye on:

• powershell.exe
• cmd.exe
• wscript.exe / cscript.exe
• rundll32.exe
• mshta.exe

4657 — Registry Value Modified

Useful for catching configuration changes or persistence attempts, but only if registry auditing is actually configured on the keys you care about.

Look out for:

• Startup and autorun locations
• Security configuration changes
• Application persistence that shouldn't be there

4663 — Object Access

Tracks access attempts on anything you've set up auditing for. Be careful with scope here — broad object-access auditing gets loud, fast.

Good candidates to audit:

• Sensitive folders
• Critical configuration files
• Specific registry paths you care about

Security group events, together

The local-group events are especially valuable when you're watching for additions to the local Administrators group , that's usually the one people care about most. Note that 4730 stands apart from the rest of this set: it's about a global group being deleted, which shows up more on domain controllers than on typical endpoints.

• 4730 — Global security group deleted
• 4731 — Local security group created
• 4732 — Member added to local security group
• 4733 — Member removed from local security group
• 4734 — Local security group deleted
• 4735 — Local security group changed

High-value example

Someone gets added to the local Administrators group. Event 4732 gives you the actor, the member, the target group, and the system context — everything you need to start an investigation.

Putting events together: a few investigation scenarios

Single events rarely tell the whole story. Here's how a few of these come together in practice.

Scenario 1 — Privileged interactive activity
4624 (successful logon) → 4672 (special privileges assigned) → 4688 (PowerShell or another process launched)

Ask yourself: does the user, device, source, timing, and command line line up with approved administrative work?

Scenario 2 — Suspicious configuration change
4624 (user logon) → 4688 (process created) → 4657 (registry value modified)

Figure out which process and account touched the registry, and whether that key relates to startup, security settings, or application config.

Scenario 3 — Potential privilege escalation
4732 (member added to local group) → 4624 (subsequent logon) → 4672 (privileged logon)

Was the group membership change actually authorized? And did elevated activity follow right after?

Why start small instead of collecting everything?

It's tempting to just turn every audit category on and figure it out later. Don't. Collecting everything drives up ingestion volume, cost, and noise — and it makes the investigation process harder, not easier. A phased approach lets you prove value, tune what you're collecting, and understand the operational impact before you commit further.

Stage	Suggested scope	Purpose
Phase 1: Foundation	4624, 4657, 4663, 4672, 4688, and 4730-4735	Authentication, privilege, execution, registry, object access, and group changes.
Phase 2: Expand	4625, 4720, 4726, 4740, 4697, and 1102	Failed logons, account lifecycle, lockouts, service installation, and audit-log clearing.
Phase 3: Enrich	PowerShell logs, Sysmon telemetry, Defender signals, and network telemetry	Deeper process, script, endpoint, and network context based on validated use cases.

Questions this data should let you answer in ADX

Once the pipeline is flowing, these are the kinds of questions analysts should be able to run against the data without much friction:

• Which users received special privileges today?
• Which endpoints launched PowerShell, command shells, or script engines?
• Which monitored registry values changed during the investigation window?
• Who got added to a local privileged group?
• Which devices generated unusual privileged logons?
• What ran right after a privileged logon?
• Which accounts touched a monitored sensitive object?

Things worth thinking through before you build this

A few practical points that tend to get skipped and then bite people later:

Audit policy — the right Windows audit subcategories need to be turned on. Object and registry events won't show up unless auditing is configured on those specific targets too.

Data volume — process creation, logon, and object-access events can get big fast. Measure expected ingestion before you roll this out broadly.

Event context — don't just store the event ID. Capture the account, device, logon type, process, command line, target object, group, and activity IDs — that's where the investigative value actually is.

Privacy and governance — command lines, file paths, usernames, and object names can carry sensitive information. Make sure access, retention, and handling controls are actually approved and in place.

Coverage validation — test that every endpoint type is actually producing and forwarding what you expect. Keep an eye on agent health and ingestion gaps — silent failures are the worst kind.

Correlation — one event almost never proves anything on its own. Correlate across time, user, device, logon session, process, and whatever other signals you have.

Final thoughts

You don't need to capture every possible Windows event to build something useful. A focused set of high-value events gives you real visibility into authentication, privileged access, process execution, registry changes, audited object access, and group membership changes — and that's plenty to start hunting and investigating with.

Centralizing that telemetry in something like ADX gives analysts a shared place to dig in and build hunting queries over time. From there, let the event list grow based on real investigation needs, measured data volume, validated detections, and whatever risk priorities matter most to the environment you're working in.