The Windows Event Logging Architecture
Windows Server records structured events into logs such as Application, System, Security, and, on domain controllers, Directory Service, DNS Server, and File Replication Service (or DFS Replication), each viewable through Event Viewer or queried with Get-WinEvent. Every event carries a numeric Event ID, a source, a level (Information, Warning, Error, Critical), and a timestamp, and these IDs are documented well enough that specific numbers — like 4625 for a failed logon — are recognized industry-wide as signals for particular conditions.
Cricket analogy: Structured event logs with consistent IDs are like Hawk-Eye's ball-tracking data feed, where every delivery is tagged with precise metadata (speed, line, length) that analysts across broadcasters can interpret identically.
Critical Security Event IDs to Monitor
Event ID 4625 (failed logon) and 4624 (successful logon) form the baseline for detecting brute-force or credential-stuffing attacks, especially when correlated by source IP and account name across a short time window. On domain controllers specifically, 4768 and 4769 track Kerberos TGT and service ticket requests, 4740 flags account lockouts, and 4720/4726 record account creation and deletion — a spike in 4720 events outside a normal onboarding window is a classic indicator of an attacker establishing persistence.
Cricket analogy: Correlating repeated 4625 events from the same source is like a match referee noticing the same bowler repeatedly overstepping the crease within minutes — one no-ball is an accident, a pattern is a signal worth flagging.
# Query the Security log for failed logon attempts (Event ID 4625) in the last 24 hours
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625
StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated, @{n='Account';e={$_.Properties[5].Value}}, @{n='SourceIP';e={$_.Properties[19].Value}}
# Find recent account lockouts (Event ID 4740)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4740; StartTime=(Get-Date).AddHours(-8) } |
Select-Object TimeCreated, @{n='LockedAccount';e={$_.Properties[0].Value}}, @{n='SourceHost';e={$_.Properties[1].Value}}Directory Service and Replication Health Events
The Directory Service log surfaces replication and database-level problems, such as Event ID 1988 for lingering objects or 2042 warning that a DC hasn't replicated within the tombstone lifetime, both of which demand immediate investigation since ignoring them risks the same corruption issues discussed in AD disaster recovery planning. These log-based signals are typically paired with command-line diagnostics — dcdiag and repadmin /replsummary — because a single event ID rarely tells the whole story without correlating it against current replication topology.
Cricket analogy: A 2042 replication-lag warning is like a scoreboard operator being warned their feed hasn't synced with the central system in over an hour — left unresolved, their displayed score diverges from official reality.
Do not rely solely on Event Viewer's GUI for ongoing monitoring at scale — it does not alert proactively. Forward critical events to a SIEM (e.g., via Windows Event Forwarding or an agent) and build alert rules for high-signal IDs like 4625, 4740, 4720, and 1988 so incidents are caught in near real time rather than discovered during a manual review.
Increase the default Security log size (often too small at 20MB in older baselines) via Group Policy, since a log that wraps too quickly under high logon volume can silently overwrite the very evidence needed to investigate an incident.
- Every Windows event has a structured Event ID, source, level, and timestamp, viewable in Event Viewer or via Get-WinEvent.
- 4624/4625 track successful/failed logons; correlating 4625 by source IP and account detects brute-force attempts.
- 4768/4769 track Kerberos TGT and service ticket issuance; 4740 flags lockouts; 4720/4726 flag account creation/deletion.
- A spike in 4720 outside normal onboarding hours is a classic indicator of attacker persistence.
- The Directory Service log surfaces replication problems like 1988 (lingering objects) and 2042 (replication lag past tombstone lifetime).
- Event IDs should be correlated with dcdiag and repadmin /replsummary output rather than read in isolation.
- Forward high-signal event IDs to a SIEM for real-time alerting rather than relying on manual Event Viewer review.
Practice what you learned
1. Which Event ID indicates a failed logon attempt in the Windows Security log?
2. A sudden spike in Event ID 4720 outside the normal onboarding schedule most likely indicates what?
3. Which Directory Service event ID specifically flags lingering objects?
4. Why should critical events be forwarded to a SIEM rather than relying only on Event Viewer?
5. Which cmdlet is used to query specific Event IDs from a log programmatically?
Was this page helpful?
You May Also Like
Backup and Disaster Recovery for AD
Understand how to protect Active Directory with system state backups, the AD Recycle Bin, and a tested forest recovery plan.
PowerShell for AD Administration
Learn how to manage users, groups, and organizational units in Active Directory using the ActiveDirectory PowerShell module, bulk pipelines, and remoting.
Windows Server & AD Interview Questions
A curated set of commonly asked Windows Server and Active Directory interview questions with clear, technically grounded answers.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics