Windows Security Events That Deserve Your Attention

Windows records a great deal of security activity: accounts are created, passwords are reset, users join groups, sessions begin, and authentication fails. It is tempting to turn every interesting event ID into an alert. That usually creates a queue full of technically correct but operationally useless notifications.

The better question is: when would this event be unusual here? A new account created by the identity-management service during an approved onboarding window is routine. The same event created by an administrator at 2 a.m., followed by a privileged-group change and a remote logon, is a very different story.

A detection cannot recover an event that was never recorded or collected. Confirm the effective advanced audit policy on domain controllers, servers, and workstations, then verify that the resulting Security logs reach the SIEM with the fields you expect.

• Enable the relevant account-management, security-group-management, logon, lockout, and special-logon audit subcategories.
• Collect from endpoints as well as domain controllers. Local accounts and local Administrators-group changes happen on the machine where the change was made.
• Keep stable identity fields such as SIDs and logon IDs. Display names can change, and names alone are awkward correlation keys.
• Measure ingestion delay, parsing failures, and missing hosts. A silent collection gap can look like a quiet environment.
• Test the policy on representative systems before broad rollout; stronger auditing can increase event volume substantially.

This is not a universal “top events” list. It is a manageable foundation for identity-focused monitoring. Add coverage when you can describe the expected behaviour, the suspicious variation, and the investigation that follows.

1. 1

   A short-lived account. Correlate 4720 with 4726 for the same account within a short window. Raise the priority if the account logged on, accessed a sensitive host, or joined a privileged group before deletion.

2. 2

   Brief privileged-group membership. Pair group-add and group-remove events for the same member and group. A five-minute membership can be enough to perform a damaging action, so removal does not make the earlier access harmless.

3. 3

   Account management outside the normal path. Compare the actor in account-management events with the approved administrators or identity-management service accounts. Look for changes made by unexpected identities, from unusual systems, or without a matching request.

4. 4

   Local administrator access. Monitor local account creation and additions to local Administrators groups on workstations and servers. These changes can create a route around central domain controls.

5. 5

   A service account used interactively. Look for service identities using logon type 2 or 10. Scheduled tasks and services normally produce other logon types, so interactive or Remote Desktop use deserves a prompt explanation.

6. 6

   Failed logons with a meaningful pattern. Group 4625 events by source, target account, status, substatus, and logon type. A burst against many usernames suggests something different from one stale password in a scheduled task.

An alert should arrive with enough context to support a first decision. If it only says “Event 4728 occurred,” the analyst still has to discover what changed, who changed it, and whether it mattered.

• Who performed the action, and is that identity allowed to perform it?
• Which account, group, or computer was changed?
• Was the target privileged, dormant, disabled, new, or otherwise high value?
• Where did the activity originate, and is that an approved administrative system?
• Was there a matching change, onboarding, offboarding, or access request?
• What happened immediately before and after—logons, process creation, ticket requests, remote access, or further identity changes?
• Can the analyst explain the behaviour quickly, or does the account need containment while ownership is confirmed?

Not every failed logon is an attack, and not every administrator action is safe. Tune with business context rather than broad exclusions. Suppress a known automation path only when the initiating identity, source host, target scope, and expected schedule all match.

Use thresholds for noisy activity such as failed logons, but keep high-confidence changes—like an unexpected addition to Domain Admins—as single-event alerts. Microsoft’s guidance makes the same distinction: some events are strong enough to investigate once, while others become meaningful only when they exceed an established baseline.