What Are Event Logs? Types, Fields, and Sources

A Windows host is compromised and the first place a responder opens is the Security event log. The story is usually there. A burst of 4625 failed logons from one account, then a 4624 success. A 4688 process creation showing powershell.exe spawned by winword.exe. A 4720 creating a new local account minutes later. And, if the attacker was tidy, a 1102 where the audit log itself was cleared. None of these events explains itself. Each is one line the operating system wrote when something happened, in the order it happened. Reading them in sequence is the investigation.

An event log is a chronological record of events a system generates as it runs: a service starting, a user logging on, a driver failing, a permission changing. Operating systems write them, applications write them, network devices and cloud services write them. The format and field names differ across sources, but the shape is the same: a timestamp, a source, a severity, an identifier, and a description of what occurred. This guide covers what an event log is, the types and sources that produce them, the fields inside each entry, how logs get populated and managed, and what defenders actually do with event logs once they reach a SIEM. It is written for the people who read these files for a living: SOC analysts triaging alerts, threat hunters building baselines, and DFIR responders reconstructing an intrusion.

What is an event log?

An event log is a file or stream in which a system appends one record per event, in the order the events occur, describing what happened and when. The unit is the event, not the request and not the session. An event is any noteworthy occurrence the system decides to record: a logon, a service crash, a configuration change, a blocked connection, an application error. Each entry is written at the moment the event happens, so the log is a time-ordered history of the system's behavior.

That property is what makes event logs the backbone of both operations and security. An administrator reads them to find why a service died. A defender reads them to find what an attacker did. The same 7045 service-installation event that tells an admin a new service appeared tells a hunter that an attacker may have installed a persistence mechanism. The log does not judge intent. It records the occurrence and leaves the reading to you.

Event logs differ from the other log families a defender works with. An access log records requests to a resource, one line per request, including the ones that failed. An event log is broader: it records the full range of things a system does, not only inbound requests. An audit log is narrower and is often a subset of the event log, focused specifically on security-relevant changes. On Windows the Security channel is effectively the audit log, carried inside the same Event Log subsystem as everything else. The categories overlap in practice, which is why naming alone never tells you what a file contains. The fields do.

Types and sources of event logs

Event logs come from every layer of the stack. A real investigation pulls from several at once, because no single source sees the whole picture. The major sources fall into four groups.

Operating system logs

The operating system is the richest event source on any host.

Windows records events through the Windows Event Log service into named channels. The classic channels are Application, Security, System, Setup, and Forwarded Events. The Security channel holds audit events such as logons (4624), failed logons (4625), process creation (4688), account creation (4720), and the cleared-audit-log event (1102). The System channel records OS and driver events such as service installation (7045). Beyond these, Windows keeps hundreds of application and service-specific channels under Applications and Services Logs, including the PowerShell operational log and, where deployed, Sysmon. Modern Windows stores these as binary .evtx files under %SystemRoot%\System32\winevt\Logs. Each event carries a numeric Event ID, a source, and a level, which is what lets you query for one behavior across thousands of entries.

Linux has no single event-log service. Historically the system logging daemon (syslogd, then rsyslog) wrote plain-text files under /var/log, with the catch-all on Debian and Ubuntu being /var/log/syslog and on Red Hat-family systems /var/log/messages. Authentication events land in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (Red Hat). On systemd-based distributions the journal (journald) collects logs into a structured binary store you read with journalctl. Many systems run both: the journal plus forwarded rsyslog text files.

Application and database logs

Applications write their own event logs to record what they did internally and when something went wrong. Database engines log access requests, internal errors, and administrative actions; Microsoft SQL Server, for example, writes to its ERRORLOG file. Web servers split their output, with Apache and Nginx writing an access.log for requests and an error.log for server-side faults. Line-of-business applications write to their own files or, on Windows, into a dedicated Event Log channel. These logs are where you confirm that a specific action inside an application actually occurred, which the OS log alone cannot tell you.

Network device logs

Routers, switches, firewalls, and proxies emit event logs, most often over syslog to a central collector. A firewall logs allowed and denied connections. A router logs configuration changes and interface state. A proxy logs the destinations clients reached. These events are how you see traffic and control-plane changes that never touch an endpoint's own logs, and they are frequently the only record of an attacker moving between network segments.

Cloud service logs

Cloud providers expose event logging as configurable services, and the defaults matter. On AWS, CloudTrail records management and API activity across the account: who called which API, from which IP, when, and whether it succeeded. CloudWatch Logs ingests application and system logs from resources, and AWS Config records changes to resource configuration over time. The equivalents on other platforms (Azure Activity Log and Microsoft Entra sign-in logs, Google Cloud Audit Logs) play the same role. The recurring pitfall is the same one access logs have: if the relevant logging was never enabled, there is no record for the window you need.

Common event log fields

Across operating systems, applications, and network devices, event log entries share a recurring set of fields. Names and order vary by source, but these are the ones an investigation leans on.

The Event ID field carries more weight than its size suggests. Because each event type has a stable identifier, a hunt becomes a query: pull every 4688 where the parent process is winword.exe, every 4720 outside change windows, every 1102 anywhere. The identifier turns a wall of text into a searchable dataset. The severity field does similar work in reverse, letting you strip the routine Information events and surface the Errors and Criticals that point at a fault or an attack.

How event logs are populated and managed

Most event logging is automatic. The operating system and applications generate entries as they run without anyone asking; the Windows Event Log service and the Linux journal are always recording at their configured level. What an administrator controls is not whether events are written but how much, where, and for how long.

Configuration decides the value of the log. The key parameters are the severity threshold (how verbose: record everything, or only warnings and above), the destination (a local file, the journal, or forwarded to a central collector), retention (how long entries are kept before rotation or overwrite, set by size or age), and the timezone and clock source (UTC versus local time, and whether the host's clock is synced, which determines whether your timeline is trustworthy). On Windows, audit policy decides which Security events are even generated; process-creation auditing that produces 4688, for instance, is off by default and must be enabled.

These choices are exactly where investigations succeed or fail. A log retained for seven days is useless for an intrusion discovered after thirty. A host with the wrong clock corrupts every correlation it touches. Logs that live only on the endpoint are gone the moment an attacker wipes them, which is why forwarding events off the host to a central store is a control in its own right, not just a convenience.

What defenders do with event logs

Event logs earn their keep across the SOC and DFIR workflow. Most of that work happens after the logs are centralized, because a single host's logs are only a fragment of the story.

Detection. Event patterns are signal. A run of 4625 failures followed by a 4624 success is a brute-force that worked. A 4688 showing Office spawning a script interpreter is a classic phishing-to-execution chain. A 7045 installing an unfamiliar service is possible persistence. A 1102 clearing the Security log is an attacker covering tracks, and the clearing event is itself the evidence. Detection rules encode these patterns so the system flags them instead of waiting for an analyst to scroll.

Forensics and incident response. After a confirmed compromise, event logs are how you reconstruct it. You take a known account, host, or process and pull every event tied to it, which rebuilds the sequence: the initial logon, the processes spawned, the accounts created, the services installed, the lateral movement to the next host. Because logs are time-ordered and carry the actor's identity, the timeline assembles from the entries themselves. This is the core of incident response once an alert is confirmed.

Baselining and threat hunting. Before you can spot the anomaly you have to know normal. Event logs over time establish the baseline: which services run, which accounts log on from where and at what hours, which processes spawn which children. A hunt is then a search for deviation: a service that appeared on one host and nowhere else, an admin logon at 3 a.m., a parent-child process pair that never occurs in a healthy fleet.

Feeding the SIEM. Individually, these logs are scattered files and journals on thousands of hosts in incompatible formats. Collected, parsed, normalized into a common schema, and indexed in a SIEM, they become queryable at scale and correlatable across sources. The 4624 that means nothing alone becomes an alert when the SIEM ties it to a firewall-denied burst and a CloudTrail API call from the same identity minutes apart. Turning raw events into answers is the work of log analysis, and event logs are among its highest-value inputs.

Reading event logs in practice

Put the pieces together on a real sequence. Imagine these four Windows Security events from one host, in order:

4625 failed logon, account jsmith, fifteen times in two minutes from a remote workstation. Then 4624 logon success, same account, same source. Then 4688 process creation: cmd.exe spawned by explorer.exe, then powershell.exe spawned by cmd.exe with an encoded command line. Then 4720, a new local account svc_backup, created by jsmith.

Read in sequence, the entries tell a single story: a password guessed (4625 burst then 4624 success), an interactive session opened, a script interpreter launched by hand, and a new account stood up for persistence (4720). No one event proves an intrusion. The sequence does. That is the defining trait of event logs: the value is not in any single line but in the ordered set, and the only failure mode that matters is the event that was never recorded because logging was off or the retention window had already closed.

Frequently Asked Questions

What is an event log?

An event log is a chronological record of events a system generates as it runs, with one entry per event in the order the events occurred. Each entry typically captures a timestamp, the source that generated it, a severity level, an event identifier, and a description of what happened. Operating systems, applications, network devices, and cloud services all produce event logs.

What is the difference between an event log and an audit log?

An event log records the full range of things a system does, including operational events such as services starting, drivers failing, and applications erroring. An audit log is narrower and focuses on security-relevant events such as logons, permission changes, and account modifications, and it is often a subset of the event log. On Windows, the Security channel functions as the audit log inside the broader Windows Event Log subsystem.

What are the Windows event log channels?

The classic Windows Event Log channels are Application, Security, System, Setup, and Forwarded Events. The Security channel holds audit events such as logons and account changes, the System channel records OS and driver events, and the Application channel records events from installed software. Modern Windows also keeps many service-specific channels under Applications and Services Logs, including the PowerShell operational log and Sysmon where it is deployed.

What fields does an event log entry contain?

The recurring fields are the timestamp, a severity or level, the event source, an event ID or code, the username or account when present, the host or IP involved, and a human-readable description. Names and order vary by source, but these fields are what let a defender filter by severity, query by event ID, and pivot on an account or host across many logs.

Where are event logs stored?

On modern Windows, events are stored as binary .evtx files under %SystemRoot%\System32\winevt\Logs. On Linux, traditional syslog text files live under /var/log (for example /var/log/syslog or /var/log/messages, and /var/log/auth.log or /var/log/secure for authentication), while systemd systems keep a structured journal read with journalctl. Cloud event logs such as AWS CloudTrail are delivered to storage you configure.

How do attackers show up in event logs?

Common patterns include bursts of failed-logon events (4625 on Windows) followed by a success (4624), suspicious process-creation events (4688) such as Office applications spawning script interpreters, new service installations (7045), unexpected account creation (4720), and the clearing of the Security audit log itself (1102), which attackers do to cover tracks but which is logged as an event in its own right.

Are event logs enabled by default?

Basic event logging runs by default on both Windows and Linux, but the security-relevant detail often does not. On Windows, several high-value audit categories, including process-creation auditing that produces 4688, are disabled until audit policy turns them on. Retention windows and forwarding also have to be configured. If the right policy was not set or the events were never forwarded off the host, the record you need during an incident may not exist.

The bottom line

An event log is a time-ordered record of what a system did, one entry per event, spanning operations and security alike. Windows writes them to named channels as .evtx files, Linux splits them across syslog text files and the systemd journal, applications and network devices write their own, and cloud services write them when you enable the feature. The fields are consistent enough to read anywhere: timestamp, severity, source, event ID, account, and description.

For a defender the value is in the sequence. A single 4624 is nothing; the same event after a burst of 4625 failures, followed by 4688 script execution and a 4720 account creation, is an intrusion in plain text. Centralizing these events into a SIEM is what turns scattered host logs into a correlatable timeline. The only failure mode that matters is the event that was never recorded, so confirm the right logging and retention are on before you need them.