Windows Event Log service

The Windows Event Log service (also called EventLog) is a core system service.

Its job is to collect, store, and manage Windows events from the OS, applications, and security auditing. It acts like a centralized logging hub, every application or system component can report events to it.

The service itself runs inside svchost.exe which hosts multiple Windows services in a single process. Because it’s always running, events are logged in real-time.

Event Viewer

Windows Event Viewer is a built-in Microsoft Management Console (MMC) snap-in that lets you view, filter, and analyze event logs generated by Windows and installed applications.

Windows stores its event logs in two main file formats depending on the OS version:

.evt

stands for event, it’s a binary file used by older versions of Windows.

Stored in:

C:\Windows\System32\config\

or C:\Windows\System32\winevt\Logs\ on some versions.

Structure of .evt

Binary files have these key components:

1. File Header Contains metadata: file size, version, sequence numbers.

2. Event Records Each event is a binary structure including:

   • Record Number
   • Timestamp
   • Event ID
   • Event Type / Level
   • Source / Provider
   • User SID (Security Identifier)
   • Message String (description)

3. Footer / Checksum Ensures integrity of the log.

.evtx

combining evt(event) + x for XML, signaling the new XML-based format.

Stored in:

C:\Windows\System32\winevt\Logs\

XML-based, supports structured fields, easier parsing, forwardable, and secure.

Structure of .evtx

.evtx is highly structured, supporting both human-readable and machine-readable queries.

1. File Header

   • Version info, header size, file flags.
   • Contains checksum and sequence number for integrity.

2. File Chunks

   • .evtx divides logs into 64 KB chunks.

   • Each chunk has:

     • Chunk Header - metadata, sequence number, offset.
     • Event Records - structured XML data.
     • Chunk Footer / Checksum - for integrity verification.

3. Event Records

   • XML format under <Event> tag.
   • Main sections:

<Event>
<System>
    <Provider Name="Service Control Manager"/>
    <EventID>7036</EventID>
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x8080000000000000</Keywords>
    <TimeCreated SystemTime="2026-03-07T12:00:00.000Z"/>
    <EventRecordID>12345</EventRecordID>
    <Channel>System</Channel>
    <Computer>HOSTNAME</Computer>
</System>
<EventData>
    <Data>Service started successfully</Data>
</EventData>
</Event>

• Fully queryable using XPath (XML Path Language) or PowerShell (Get-WinEvent).

4. File Footer

   • Integrity checksum and sequence numbers.

Event Types in EVT and EVTX

Both .evt and .evtx store the same event types, just represented differently internally. Main types (Level/Severity):

.evtx supports more structured event categorization

Log Channels

Event Viewer organizes logs into two main groups:

A. Windows Logs

These are the three (plus a couple more) we discussed:

These are core, built-in logs that every Windows system has.

Application

Used by software applications to record operational events.

Security

This is the most important log for cybersecurity.

only generated if Windows auditing is enabled via Group Policy.

System

Generated by the Windows operating system and drivers.

This tells analysts that a system service started.

Setup

Forwarded Events

This log is used in centralized logging setups. In large organizations, administrators configure:

Windows Event Forwarding (WEF)

Event Log Fields

Each entry in the Windows Event Log is an Event and contains the following primary components:

Log Name

The channel where the event is stored.

Source

The component that generated the event.

Event ID

This is the unique identifier for the event type.

Task Category

Describes the type of operation. This often contains a value or name that can help us understand the purpose or use of the event.

Level

The severity of the event (Information, Warning, Error, Critical, or Verbose).

Keywords

Keywords are flags used for filtering.

User

The user account that was logged on when the event occurred.

OpCode

Indicates what operation occurred. This field can identify the specific operation that the event reports.

Rarely used by analysts but helpful in debugging.

Logged (Timestamp)

The date and time when the event was logged.

Computer

The name of the computer where the event occurred.

B. Applications and Services Logs

These are component-specific logs: Each Windows component or service can define its own logging channel.

For example:

In Event Viewer it looks like a directory path, but it’s not a folder on disk. It’s a logical log channel name used by Windows Event Log.

• Provider: Microsoft-Windows-PowerShell the component that produces events (PowerShell in this case).
• Channel: Operational → the specific log channel for that provider.

Together:

Microsoft-Windows-PowerShell/Operational

This tells Windows: Store events generated by the PowerShell provider in the Operational channel.

since the actual .evtx files are stored in:

C:\Windows\System32\winevt\Logs\

For PowerShell Operational:

Microsoft-Windows-PowerShell%4Operational.evtx

How to access it

In Event Viewer open Applications and Services Logs → Microsoft → Windows → PowerShell → Operational

In PowerShell

Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational"

Event Levels (Severity)

Windows Event Logs are structured entries that record system, application, and security-related activities. Each entry is called an Event, and each event provides detailed information that helps administrators and analysts understand what occurred on the system.

Every event has a Level, which indicates severity. These apply across Application, System, Setup, and many custom logs.

In the (Security log), you may instead notice “Audit Success” or “Audit Failure.” These are not new severity levels. They are Keywords attached to the event.

Microsoft did this to make security auditing more intuitive: rather than just Information, you see whether an action (like a logon attempt) succeeded or failed. For example:

The Level field is still Information. The Keywords field shows Audit Success.

Logon ID

Every login session in Windows receives a unique Logon ID.
Windows assigns this ID to all actions performed during that login session.

Example:

4624  Successful login
4672  Admin privileges assigned
4688  Process started
4634  Logoff

If all these events share the same Logon ID, they belong to the same user session.

Logon ID 0x3E7

Logon ID 0x3E7 represents the Local System account.

User: SYSTEM
Domain: NT AUTHORITY

This account is used by:

• Windows services
• OS components
• system-level processes

It has very high privileges on the machine. Seeing actions under this account often means:

• a system process performed the action
• a service executed it
• or malware gained SYSTEM privileges

Logon Failure Status Codes

Windows assigns status/sub-status codes for failed logon attempts. These codes indicate why a logon failed and are crucial for analyzing brute-force attacks, misconfigurations, or policy violations.

Logon Type

Numerical codes in Windows security logs that define how a user or service accessed a system:

Example:

Logon Type: 5
User: SYSTEM

This means a service created a logon session.

Event IDs

Every event in Windows Event Logs has a unique identifier called an Event ID. This ID corresponds to a specific type of system or security activity.

Common Event ID Ranges and Categories

Here’s a breakdown of widely used ranges:

Here’s a compact list of commonly used Event IDs:

System / Service Events

• 1074 → System shutdown/restart
• 6005 → Event Log started (system boot)
• 6006 → Event Log stopped (shutdown)
• 6013 → System uptime
• 7040 → Service startup type changed

Security / Audit Events

• 1102 → Audit log cleared
• 1116 → Malware detected
• 1118 → Malware remediation started
• 1119 → Malware remediation succeeded
• 1120 → Malware remediation failed

User / Account Activity

• 4624 → Successful login
• 4625 → Failed login
• 4647 → User logoff
• 4672 → Special privileges assigned (admin)
• 4720 → User account created
• 4726 → User account deleted
• 4722 → Account enabled
• 4725 → Account disabled

Policy / Audit Changes

• 4663 → Object accessed (files/folders)
• 4670 → Permissions changed on object
• 4719 → Audit policy changed
• 4902 → Per-user audit policy changed
• 4907 → SACL changed

Process / System Integrity

• 4688 → Process created
• 4689 → Process terminated
• 4697 → Service installed

SACL Change (Audit Policy Change) 4907

ACL (Access Control List)

Think of an ACL as a rulebook attached to a file, folder, or object that tells Windows:

1. Who can do what (DACL)
2. Which actions should be logged (SACL)

Windows uses these two main types of ACLs:

DACL (Discretionary Access Control List)

Controls permissions (who can read/write/execute). controls access, not logging.

SACL (System Access Control List)

Controls auditing/logging, not permissions. controls what gets recorded in the Security Event Log, so administrators can track sensitive actions.

Event ID 4907 SACL Changed

4907 happens when someone changes the SACL (the audit rules) of an object.

Example: You tell Windows: Start logging every time someone deletes this file.

When you make that change, Windows logs Event ID 4907.

So Event 4907 is literally someone changed what gets logged for this file/folder event.