Windows event log

Windows records activity in event logs, grouped into channels. The Security log holds authentication and audit events, the System log records services and drivers, and many applications and Windows components have their own operational logs, such as Microsoft-Windows-PowerShell/Operational. Each event has an ID that identifies its type, which makes the IDs a shared vocabulary across tools and investigations.

A few IDs every analyst meets early:

• 4624 / 4625 (Security): successful / failed logon. The logon type shows how: 2 interactive, 3 network, 10 Remote Desktop.
• 4688 (Security): a new process was created, with the command line if that option is enabled.
• 4720 (Security): a user account was created.
• 4728 / 4732 (Security): a member was added to a global / local security group.
• 1102 (Security): the audit log was cleared.
• 7045 (System): a new service was installed.
• 4104 (PowerShell Operational): PowerShell script block logging.

Many of these events only appear if the matching audit policy is enabled, which is a common gap.

Example

On a compromised server, the timeline shows event 4624 with logon type 10 from an unfamiliar workstation at 02:13, a 7045 service installation one minute later, and a 1102 audit log clearance at 02:20. Each event alone could be explained; together they describe an attacker logging in, installing a remote access tool and covering their tracks.

Why it matters for a SOC analyst

Windows event logs are the raw material behind many SIEM detections and investigation queries, including Sentinel's SecurityEvent table. Knowing the key IDs lets you read a timeline quickly, write precise queries and recognize when the logs you need were never enabled.