Event Viewer and Windows logging

Overview

Windows logs to the Event Log (Security/System/Application), read via Event Viewer or Get-WinEvent. Key IDs: 4624/4625 logon success/fail, 4672 admin logon, 4688 process creation, 7045 service installed, 1102 log cleared.

Why it matters

Defenders detect attacks and reconstruct incidents from these event IDs and logon types; testers must know their actions are recorded and that tampering (1102) is high-signal and out of scope. It's the Windows counterpart to /var/log analysis.

Core concepts

Security/System/Application logs. Security is the audit log. Key IDs. 4624/4625 logon, 4672 admin, 4688 process, 7045 service install, 1102 cleared. Logon types. 3 network/SMB, 10 RDP, 2 interactive. Integrity. Clearing logs is itself logged.

Lesson

Windows records activity in the Event Log, browsed via Event Viewer (eventvwr) or queried with PowerShell (Get-WinEvent).

The main logs

• Security — authentication and audit events (the defender's primary log).
• System — service and driver events.
• Application — app-level events.

Event IDs worth knowing

• 4624 successful logon · 4625 failed logon — bursts of 4625 = brute force/spray.
• 4672 special privileges assigned (admin logon).
• 4688 process creation — what ran.
• 7045 a service was installed — a classic attacker-persistence signal.

The logon type in 4624 matters: type 3 = network (SMB), type 10 = RemoteInteractive (RDP), type 2 = interactive. Defenders triage by these.

Both sides

• Blue team / SOC: build detections and incident timelines from these IDs.
• Pentesters/red team: know your actions generate these events (a new service → 7045, a logon → 4624), and that clearing logs is itself a logged, high-signal event (1102) and usually out of scope.

Summary

The Windows Event Log captures authentication, process, and service activity by event ID and logon type — the basis of Windows detection and forensics, and a record testers respect rather than tamper with.