Windows will happily generate more log data than you can afford to store, and by default it does not record the one field you will most want. Teams routinely discover this mid-investigation: process creation events are present, but without command lines, so the record shows that PowerShell ran and nothing about what it did.
This is a field guide to the events that repay their storage cost, what each actually proves, and the interpretation details that determine whether a record means anything.
Where the useful events live
The classic three channels — Security, System and Application — are only part of the picture. The Security channel carries authentication, authorisation and audit policy results, and is where most detection value sits. System records service and driver activity, which matters because service installation is a common persistence and lateral-movement artefact.
Beyond those, the operational channels carry disproportionate value. Microsoft-Windows-PowerShell/Operational holds script block logging. Microsoft-Windows-TaskScheduler/Operational records task registration. Microsoft-Windows-Sysmon/Operational, if you deploy Sysmon, provides richer process, network and file telemetry than the built-in auditing offers.
Authentication: 4624 and 4625
Event 4624 records a successful logon and 4625 a failure. These are the highest-volume security events in most environments and also the most misread, because the event ID alone tells you almost nothing. The logon type is what carries the meaning.
- Type 2 — Interactive. Someone logged on at the console.
- Type 3 — Network. Access to a shared resource, such as a file share or an administrative share. This is the dominant lateral movement type.
- Type 4 — Batch and Type 5 — Service. Scheduled tasks and service accounts. Ordinarily routine, and therefore useful when they appear where they never have before.
- Type 7 — Unlock. Workstation unlocked.
- Type 8 — NetworkCleartext. Credentials passed in clear text, commonly basic authentication against IIS. Worth reviewing on principle.
- Type 9 — NewCredentials. Explicit alternate credentials, the artefact left by
runas /netonly. Frequently associated with credential abuse. - Type 10 — RemoteInteractive. RDP. Among the most security-relevant logons in any estate.
- Type 11 — CachedInteractive. Logon using cached credentials, with no domain controller consulted.
The practical consequence is that a rule alerting on 4624 is meaningless, whereas a rule alerting on type 10 to a server that has never accepted RDP from that source, or type 9 on a workstation, is specific and defensible.
On failures, the interpretation depends on the pattern. Many 4625s for one account across many hosts suggests password spraying. Many for many accounts against one host suggests brute force. Check the substatus code too: it distinguishes a bad password from a disabled or non-existent account, and a spray against non-existent accounts implies the adversary is guessing at usernames rather than working from a stolen list.
Two companions are worth collecting. Event 4648 records a logon using explicit credentials and often reveals lateral movement where an operator ran a tool as another user. Event 4672 records that special privileges were assigned at logon, which is effectively the “an administrator just logged on” event.
Execution: 4688 and Sysmon Event ID 1
Event 4688 records process creation, and it is the single most valuable detection event on the platform — but only when command-line auditing is enabled. That is a separate policy setting from process auditing itself, and without it the event records the image path and nothing about the arguments.
With command lines captured, 4688 supports the detections that actually catch modern intrusions: process lineage anomalies such as an Office application spawning a script interpreter, encoded PowerShell arguments, and the abuse of signed system binaries.
Sysmon event ID 1 covers the same ground with more context, including the parent command line, image hashes and the originating user, which removes several correlation steps during analysis. If you deploy Sysmon, the events worth prioritising are:
- 1 — process creation.
- 3 — network connection, attributed to the initiating process, which is exactly what you need to spot a signed binary reaching the internet.
- 7 — image loaded, useful for DLL side-loading but high volume, so filter carefully.
- 8 — remote thread created, a strong process-injection signal.
- 11 — file created.
- 13 — registry value set, which covers many persistence mechanisms.
Persistence: 7045, 4698 and friends
Event 7045 in the System log records a service installation. This is a genuinely high-signal event: legitimate service installation happens during software deployment and little else, so an unexpected service on a workstation deserves investigation. It is also the classic artefact of remote execution tooling such as PsExec, which installs a temporary service to run its payload.
Event 4698 records the creation of a scheduled task, one of the most common persistence mechanisms in use. The event includes the task definition, so the command being scheduled is visible in the record. Related events cover task modification and deletion, and the deletion event matters because removing a task after use is a cleanup step.
Registry-based persistence — run keys and similar autostart locations — is best captured through Sysmon event 13 rather than native auditing, which is awkward to scope without generating enormous volume.
Account and group manipulation
These events are low volume and high value, which is the ideal combination. Event 4720 records user account creation. Events 4728, 4732 and 4756 record additions to security-enabled global, local and universal groups respectively — in other words, privilege escalation and persistence through group membership. Event 4738 records account changes, and 4726 deletion.
In a stable environment these fire rarely and always trace back to a change ticket. An addition to Domain Admins outside a change window is one of the few alerts that justifies waking someone.
Anti-forensics: 1102 and 4719
Event 1102 records that the Security audit log was cleared. There is essentially no benign reason for this to happen on a modern estate, and it is a deliberate anti-forensic action. Event 4719 records a change to system audit policy, which is the quieter version of the same intent: rather than clearing evidence after the fact, the adversary stops it being generated.
Both should alert immediately, and both are arguments for forwarding logs off the host. An adversary with administrative rights controls the local log; they do not control what has already been shipped to your collector.
Windows event records are timestamped in UTC and frequently need converting during timeline work.
Lateral movement and share access
Events 5140 and 5145 record access to network shares and to individual objects within them. They are noisy and require care, but they are the events that reveal an adversary enumerating C$ and ADMIN$ across the estate — behaviour that precedes both credential theft and ransomware deployment. Pair them with type 3 logons for a reasonably complete picture of who reached which server.
Making it practical
Three configuration changes deliver most of the value: enable process creation auditing with command lines, enable PowerShell script block logging, and forward logs to a central collector with retention measured in months rather than days. Retention matters because dwell time routinely exceeds the default retention on a busy domain controller, and an investigation cannot examine data that has already rolled off.
Then baseline before alerting. Every event listed here occurs legitimately somewhere in your environment, and the ones that do not are the interesting ones. Collect first, understand what normal looks like, and write rules against the deviations. A detection built on a documented baseline survives contact with production; one built on an assumption gets disabled in a fortnight.
Kerberos events and credential attacks
Domain controllers log the Kerberos exchange, and those records reveal a family of attacks that endpoint telemetry misses entirely. Event 4768 records a ticket-granting ticket request, 4769 a service ticket request, and 4771 a pre-authentication failure.
Their detection value comes from the encryption type and the request pattern. Kerberoasting works by requesting service tickets for accounts with a service principal name and cracking them offline; the artefact is a burst of 4769 events from one account for many distinct services, classically with the weaker RC4 encryption type requested deliberately because it cracks faster. A single account requesting service tickets for dozens of services in quick succession has no ordinary explanation.
AS-REP roasting targets accounts configured without Kerberos pre-authentication, and appears as 4768 events with pre-authentication not required. The durable defence is configuration — strong service account passwords, no unnecessary SPNs, pre-authentication enforced — but the detection is straightforward once the events are collected.
Event 4771 with the right failure code also distinguishes password spraying from ordinary user error at the domain level, which is useful because spraying is deliberately slow enough to stay under account-lockout thresholds.
Getting the logs off the host
Every event discussed here is written to a local file that an administrator can clear, and adversaries who reach administrative privilege routinely do exactly that. Local logs are therefore evidence of convenience, not of record. Forwarding is what makes the telemetry trustworthy.
Windows Event Forwarding provides this natively and without agents, using subscriptions that pull defined event IDs from subscribed hosts to a collector. It is well suited to environments that cannot deploy a commercial agent everywhere, and it scales further than most people expect. Whatever the mechanism, the properties that matter are the same: events leave the host quickly, the collector is in a different trust zone from the endpoints it collects from, and retention there is measured against realistic dwell time rather than disk convenience.
Sizing is the usual objection, and it is manageable if you are selective. Forwarding every event from every host is unaffordable and unnecessary. Forwarding a curated set — authentication, process creation, service and task creation, account and group changes, log clearing, PowerShell script blocks — produces a fraction of the volume and nearly all of the detection value. Start with that set, measure the actual volume, and expand deliberately.
Configuration that must be verified, not assumed
Several of the most valuable settings are off by default or silently ineffective, and every one of them is worth confirming directly on a sample host rather than trusting the group policy console.
- Process creation auditing and, separately, command-line inclusion. The second is a distinct setting; enabling the first alone produces events without arguments.
- PowerShell script block logging, which captures deobfuscated code, and module logging where volume permits.
- Log size and retention. Default Security log sizes on a busy domain controller can roll over within hours, which means the event you need was overwritten before anyone looked.
- Audit policy subcategories. Legacy top-level audit categories and modern subcategory settings can conflict, resulting in policy that appears configured but is not applied.
A five-minute verification — generate a test process with a distinctive command line, then confirm the event arrives at the collector with the arguments intact — is worth more than an hour of reviewing policy documents.
Turning events into detections
Collection is not detection. The step that converts one into the other is deciding, for each event type, whether it is inherently interesting or only interesting in context.
A small number are inherently interesting and can alert directly with minimal tuning: the Security log being cleared, audit policy being modified, an addition to a highly privileged group, or a new domain administrator account. These are rare, deliberate and consequential.
The majority are contextual, and alerting on them raw produces noise that trains analysts to ignore the channel. A successful logon is meaningless until qualified by logon type, source, target and whether that combination has occurred before. A service installation is routine on a server during a deployment window and alarming on a finance workstation at midnight.
The practical pattern is therefore to alert directly on the small inherently-interesting set, and to build the contextual ones as enriched correlations — joining an event to asset criticality, to the account’s normal behaviour, and to whether a change window is open. That work is why baselining is not a preliminary chore but the substance of detection engineering.
Building the timeline
During an investigation these events are read together rather than individually, and the reconstruction usually follows a consistent shape. Authentication events establish which accounts touched which hosts and when. Process creation events establish what was executed on each. Service and task creation establish how access was made durable. Share access and network connections establish movement between systems. Account and group changes establish escalation.
Two practical cautions. Windows records event times in UTC internally but tooling frequently displays local time, and a timeline assembled from mixed representations will sequence events incorrectly — which matters, because sequence is how causation is inferred. And absence of evidence is genuinely ambiguous here: an event may be missing because the activity did not occur, because auditing was not enabled for it, because the log rolled over, or because it was deliberately cleared. Distinguishing those four possibilities is often the difference between a defensible conclusion and a guess.