Log Analysis for Cybersecurity: Reading What Matters

Why Is Log Analysis the #1 SOC Analyst Skill?

Log analysis is the process of collecting, parsing, and interpreting records generated by operating systems, applications, network devices, and security tools to detect threats, investigate incidents, and maintain situational awareness. NIST SP 800-92 (Guide to Computer Security Log Management) defines it as the foundation of effective security monitoring, and the SANS Institute consistently ranks log analysis as the single most important technical skill for entry-level SOC analysts.

Every security tool you will use — SIEMs, EDR platforms, firewalls, intrusion detection systems — ultimately produces logs. If you cannot read and interpret those logs, you cannot do the job. A SIEM alert is just a summary. The logs underneath the alert are where the truth lives. Understanding what happened, when it happened, and what to do about it always comes back to reading the logs.

According to the Verizon 2024 Data Breach Investigations Report, log analysis was a factor in detecting 67% of confirmed breaches where detection occurred internally rather than through third-party notification. Organisations with mature log management programmes detected breaches an average of 100 days faster than those without (IBM Cost of a Data Breach Report 2024).

Log analysis sounded incredibly dry to me at first — reading lines of text all day? But once I started actually looking at logs in my home lab, it clicked. Every log entry tells a story. A failed login at 3 a.m., a process spawning from an unusual directory, a DNS query to a suspicious domain — these are the breadcrumbs that reveal what attackers are doing. Coming from real estate and aged care in Sydney, I never imagined I would find raw text data this fascinating. But it is basically detective work, and that appeals to a part of my brain that spreadsheets and property listings never reached.

Certification objective: CompTIA Security+ SY0-701 covers log data sources (Domain 4.4) and security monitoring (Domain 4.1). CompTIA CySA+ CS0-003 tests log analysis extensively across threat detection and incident response domains.

What Are the Main Types of Security Logs?

Not all logs are created equal. Understanding what each log source tells you — and what it does not — is essential for effective analysis.

Log Sources in a Typical Enterprise

From endpoints to SIEM — how log data flows through an organisation

SIEM Platform

Splunk, Sentinel, Elastic — aggregates, correlates, and alerts on all log sources

Cloud Services

AWS CloudTrail, Azure AD, Google Workspace — identity and infrastructure logs

Applications

Web servers, databases, email gateways — access and error logs

Servers

Windows Event Logs, Linux syslog — authentication, process execution, services

Network Devices

Firewalls, proxies, DNS, IDS/IPS — traffic flow and connection data

Endpoints

Workstations, laptops, mobile — EDR telemetry, local event logs

Idle

Windows Event Logs

Windows Event Logs are the most common log source you will encounter in a SOC. They record authentication events, process execution, service installations, and policy changes across every Windows system in the organisation.

Where to find them: Event Viewer (eventvwr.msc) or via PowerShell (Get-WinEvent). In a SOC, these are forwarded to your SIEM.

Key log channels:

Channel	What It Records	SOC Relevance
Security	Logins, logoffs, account changes, privilege use	Primary source for authentication analysis
System	Service starts/stops, driver loads, system errors	Detects persistence mechanisms and system tampering
Application	Application crashes, errors, warnings	Identifies malware behaviour and application abuse
PowerShell/Operational	PowerShell command execution (if enabled)	Critical for detecting fileless attacks and living-off-the-land techniques
Sysmon/Operational	Process creation, network connections, file changes (requires Sysmon)	Gold standard for endpoint visibility — install this in your home lab

Critical Windows Event IDs Every SOC Analyst Must Know

These are the Event IDs you will query daily. Memorise the top ten — you will use them in every investigation.

Event ID	Description	Why It Matters
4624	Successful logon	Confirms access — check the logon type, source IP, and account name
4625	Failed logon	Brute-force detection — multiple 4625s followed by a 4624 is a red flag
4720	User account created	New account creation outside change management could indicate persistence
4732	Member added to security group	Privilege escalation — attacker adding themselves to the Administrators group
4688	New process created	Process execution tracking — look for unusual parent-child relationships
7045	Service installed	New service installation is a common persistence technique (MITRE ATT&CK T1543.003)
4648	Logon using explicit credentials	Pass-the-hash or credential reuse — someone logged on as a different user
4672	Special privileges assigned to new logon	Admin logon — tracks when elevated privileges are used
1102	Audit log cleared	An attacker covering their tracks — this should always trigger an alert
4697	Service installed (detailed)	More detailed version of 7045 — captures the service file path

Linux Logs (syslog and auth.log)

Linux systems use syslog for general system logging and /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) for authentication events.

Key Linux log files:

Log File	What It Records	SOC Relevance
`/var/log/auth.log`	SSH logins, sudo usage, authentication failures	Primary authentication log — equivalent to Windows Security log
`/var/log/syslog`	General system messages, service activity	Broad system health and behaviour
`/var/log/kern.log`	Kernel messages	Hardware issues, potential rootkit activity
`/var/log/cron.log`	Cron job execution	Persistence mechanisms — attackers schedule tasks via cron
`/var/log/apache2/access.log`	Web server requests	Web attack detection (SQL injection, path traversal, brute-force)

Firewall and Network Logs

Firewalls log every connection they allow or deny. This gives you visibility into what is entering and leaving your network.

Key fields in firewall logs:

Timestamp — when the connection occurred
Source IP and port — where the traffic came from
Destination IP and port — where it was going
Action — allowed, denied, or dropped
Protocol — TCP, UDP, ICMP
Bytes transferred — useful for detecting data exfiltration

DNS logs are particularly valuable because virtually all network activity involves DNS. Malware needs to resolve command-and-control (C2) domains, and DNS logs capture every query. Unusual query patterns — high-frequency queries to random-looking domains, TXT record requests to unknown domains — are strong indicators of compromise.

Proxy Logs

Web proxies log all HTTP/HTTPS traffic leaving the network. They capture URLs, user agents, response codes, and bytes transferred. Proxy logs are essential for:

Detecting connections to known malicious domains
Identifying data exfiltration via HTTP POST requests
Tracking user web activity during an investigation
Spotting unusual download patterns (e.g., executables from uncommon sources)

How Do You Read Windows Event Logs?

Let us walk through a practical example of reading Windows Event Logs — the skill you will use most often.

Using PowerShell to Query Event Logs

# Find the 20 most recent failed logon attempts (Event ID 4625)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 |
  Format-Table TimeCreated, @{N='Account';E={$_.Properties[5].Value}},
  @{N='SourceIP';E={$_.Properties[19].Value}} -AutoSize

# Check for new user accounts created in the last 24 hours (Event ID 4720)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720;
  StartTime=(Get-Date).AddDays(-1)} |
  Format-Table TimeCreated, @{N='NewAccount';E={$_.Properties[0].Value}},
  @{N='CreatedBy';E={$_.Properties[4].Value}}

# Find new services installed (Event ID 7045) — potential persistence
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} -MaxEvents 10 |
  Format-Table TimeCreated, @{N='ServiceName';E={$_.Properties[0].Value}},
  @{N='ServicePath';E={$_.Properties[1].Value}}

# Look for audit log clearing (Event ID 1102) — anti-forensics
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} -ErrorAction SilentlyContinue

Reading Linux auth.log

# Find failed SSH login attempts
grep "Failed password" /var/log/auth.log | tail -20

# Count failed logins per source IP — identifies brute-force sources
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

# Check sudo usage — who escalated privileges?
grep "sudo:" /var/log/auth.log | grep -v "pam_unix" | tail -20

# Find successful SSH logins
grep "Accepted" /var/log/auth.log | tail -20

# Look for new cron jobs — potential persistence
grep -i "cron" /var/log/syslog | grep -i "install\|replace\|edit" | tail -10

Legal and ethical warning: Only analyse logs on systems you own or have explicit written authorisation to access. Unauthorised access to computer systems is a criminal offence under the Criminal Code Act 1995 (Australia), the Computer Fraud and Abuse Act (US), and similar legislation in other jurisdictions. In your home lab, practise freely.

How Do SIEMs Make Log Analysis Scalable?

In a real SOC, you are not manually opening Event Viewer or SSH-ing into individual servers. A SIEM (Security Information and Event Management) platform collects logs from every source across the organisation, normalises them into a common format, and lets you search, correlate, and alert on them from a single interface.

Basic Splunk SPL Queries

Splunk uses Search Processing Language (SPL). Here are queries you would use daily as a Tier 1 analyst.

# Find failed Windows logon attempts in the last 24 hours
index=main sourcetype=WinEventLog EventCode=4625
| stats count by Account_Name, Source_Network_Address
| sort -count

# Detect brute-force: more than 10 failed logins from one IP in 15 minutes
index=main sourcetype=WinEventLog EventCode=4625
| bin _time span=15m
| stats count by Source_Network_Address, _time
| where count > 10

# Find successful logon after multiple failures (potential compromise)
index=main sourcetype=WinEventLog (EventCode=4625 OR EventCode=4624)
| transaction Account_Name maxspan=30m
| search EventCode=4625 EventCode=4624
| table _time, Account_Name, Source_Network_Address, EventCode

# New services installed across all Windows endpoints
index=main sourcetype=WinEventLog EventCode=7045
| table _time, host, ServiceName, ServiceFileName
| sort -_time

# DNS queries to suspicious TLDs
index=dns
| search query="*.xyz" OR query="*.top" OR query="*.buzz"
| stats count by query, src_ip
| sort -count

Basic KQL Queries (Microsoft Sentinel)

If your target SOC runs Microsoft Sentinel, you will use Kusto Query Language (KQL).

// Failed logons in the last 24 hours
SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(24h)
| summarize FailCount=count() by TargetAccount, IpAddress
| sort by FailCount desc

// New services installed
Event
| where EventID == 7045
| project TimeGenerated, Computer, RenderedDescription
| sort by TimeGenerated desc

What Does the Full Log Analysis Workflow Look Like?

Whether you are investigating a single alert or hunting for threats, the workflow follows the same structure.

Log Analysis Workflow

The structured approach SOC analysts follow for every investigation

Collect

Step 1

Identify relevant log sources

Define time window

Gather raw data from SIEM

Normalise

Step 2

Parse fields (timestamp, source, action)

Standardise formats across sources

Enrich with threat intel data

Correlate

Step 3

Link events across log sources

Build timeline of activity

Identify patterns and anomalies

Investigate

Step 4

Check IOCs against threat intel

Determine scope of activity

Classify: TP / FP / BTP

Document

Step 5

Record findings in ticket

Note evidence and queries used

Escalate or close with rationale

Idle

Applying the Workflow: A Worked Example

Scenario: Your SIEM fires an alert — “Multiple failed logons followed by successful logon” for the account jsmith from IP address 203.0.113.47 at 02:17 UTC.

Collect: Query all events for jsmith and 203.0.113.47 in the last 24 hours. Pull Windows Security logs (4624, 4625), VPN logs, and proxy logs.
Normalise: Line up the timestamps. You see 47 failed logon attempts (4625) from 203.0.113.47 between 01:45 and 02:16, followed by a successful logon (4624) at 02:17. The logon type is 10 (RemoteInteractive — RDP).
Correlate: Check what jsmith did after the successful logon. You find Event ID 4688 (process creation) showing cmd.exe spawning whoami, net user, and net group "domain admins" — classic reconnaissance commands. Event ID 7045 shows a new service installed at 02:23.
Investigate: Look up 203.0.113.47 on AbuseIPDB and VirusTotal — it is flagged as a known brute-force source from Eastern Europe. The commands executed match MITRE ATT&CK T1087 (Account Discovery) and T1543.003 (Create or Modify System Process: Windows Service). This is a confirmed compromise.
Document: Record the full timeline, every query you ran, every IOC you found, your classification (True Positive — confirmed compromise via brute-force), and escalate to Tier 2 / IR team for containment.

What Patterns Indicate a Compromise?

Experienced analysts recognise these patterns because they have seen them repeatedly. As a beginner, memorise these — they will sharpen your instincts.

High-Confidence Indicators

Pattern	What It Looks Like in Logs	MITRE ATT&CK Reference
Brute-force → successful logon	Many 4625 events from one IP, then a 4624 for the same account	T1110 (Brute Force)
New service installed after compromise	7045 event shortly after a suspicious 4624	T1543.003 (Windows Service)
Reconnaissance commands	4688 events showing `whoami`, `net user`, `net group`, `ipconfig`, `nltest`	T1087 (Account Discovery), T1016 (System Network Configuration)
Audit log cleared	1102 event — someone is covering their tracks	T1070.001 (Clear Windows Event Logs)
Unusual parent-child process	`winword.exe` spawning `powershell.exe` or `cmd.exe`	T1059 (Command and Scripting Interpreter)
Lateral movement	Multiple 4624 type 3 (network logon) events from one internal host to many others in a short window	T1021 (Remote Services)
DNS tunnelling	High volume of long, encoded DNS TXT queries to a single domain	T1071.004 (Application Layer Protocol: DNS)
Data exfiltration	Unusual outbound traffic volume in proxy logs, especially to cloud storage or paste sites	T1048 (Exfiltration Over Alternative Protocol)

Common False Positive Patterns

Not every unusual log entry is malicious. Learning to recognise benign activity saves time and prevents unnecessary escalation.

Scheduled vulnerability scans — mass connection attempts that look like port scanning
IT admin using remote tools — RDP, PsExec, or PowerShell remoting during business hours from a known admin workstation
Password reset cycles — multiple 4625 events when a user forgets their password and keeps trying
Patch deployment — new services installed across many endpoints simultaneously during a maintenance window
Cloud sync tools — large outbound data transfers to sanctioned cloud services (OneDrive, SharePoint)
Monitoring tools — network probes and health checks that trigger IDS alerts

How Do You Practise Log Analysis in a Home Lab?

You do not need a corporate SOC to build log analysis skills. Here is a practical plan using free tools.

Step 1: Set Up Your Log Sources

Windows VM with Sysmon — install Sysmon with the SwiftOnSecurity configuration. This generates detailed process creation, network connection, and file modification logs that mirror real enterprise telemetry.
Linux VM — any Ubuntu or Debian server. SSH into it, create users, simulate activity. The auth.log fills up naturally.
Splunk Free — install on a Linux VM. It processes up to 500 MB of logs per day, which is more than enough for learning.

Step 2: Generate Realistic Log Data

Atomic Red Team — run safe, controlled attack simulations that generate the exact log entries you would see in a real compromise. Each test maps to a MITRE ATT&CK technique.
DVWA (Damn Vulnerable Web Application) — generates web server logs showing SQL injection, XSS, and brute-force attempts.
Simulate brute-force attempts — use Hydra against your own lab SSH server and then investigate the auth.log entries.
BOTS (Boss of the SOC) dataset — Splunk’s free competition dataset with realistic enterprise logs and investigation scenarios.

Step 3: Practise Investigation Workflows

For each exercise, follow the five-step workflow (Collect, Normalise, Correlate, Investigate, Document). Write up your findings as if you were submitting a ticket in a real SOC. This builds both the technical skill and the documentation habit that hiring managers look for.

Exercise	What You Learn	Time Investment
Investigate a brute-force attack in Splunk	SPL queries, Event ID 4625/4624 correlation	1-2 hours
Trace a simulated malware execution via Sysmon logs	Process trees, parent-child relationships, persistence	2-3 hours
Analyse a PCAP file for C2 traffic in Wireshark	DNS queries, HTTP beacons, traffic patterns	1-2 hours
Complete a TryHackMe log analysis room	Guided practice with real scenarios	1-2 hours per room
Run an Atomic Red Team test and find it in Splunk	Attack simulation → detection → investigation	2-3 hours

Recommended Training Platforms

Platform	Relevant Content	Cost
TryHackMe	Windows Event Logs, Splunk, Sysmon, SOC Level 1	$14/month
LetsDefend	SOC simulator with log-based alert triage	Free tier available
Splunk Education	Splunk Fundamentals 1 and 2	Free
Blue Team Labs Online	Log analysis and investigation challenges	Free tier available
CyberDefenders	Real-world forensic challenges with log data	Free

The study tracker includes log analysis practice milestones — building from basic Windows Event Logs to SIEM queries over several weeks.

Career Roadmap & Study TrackerAvailable Now

Step-by-step roadmap with study tracker worksheets and certification decision framework.

Get the Guide → $27

Summary and Key Takeaways

Log analysis is the bedrock skill of cybersecurity defence. Every investigation, every alert triage, every incident response engagement starts with reading logs.

Logs tell the story of what happened. SIEM alerts are summaries — the raw logs underneath contain the evidence you need to make accurate classifications.
Windows Event IDs 4624, 4625, 4720, 4688, 7045, and 1102 are the ones you will query most often. Learn them by heart.
Linux auth.log is the equivalent starting point for Linux environments — failed SSH attempts, sudo usage, and authentication events.
Firewall, proxy, and DNS logs provide network-level visibility that endpoint logs alone cannot give you. DNS logs are particularly valuable because nearly all malicious activity involves DNS resolution.
The log analysis workflow is always the same: Collect, Normalise, Correlate, Investigate, Document. Following this structure prevents you from jumping to conclusions or missing evidence.
Pattern recognition develops with practice. Brute-force followed by successful logon, unusual parent-child processes, new services installed after compromise — these patterns repeat across incidents.
You can build real log analysis skills for free using Splunk Free, Sysmon, Atomic Red Team, and TryHackMe. A home lab is the fastest path to job readiness.
SIEM query skills (SPL or KQL) are directly testable in interviews. Practise writing queries, not just reading them.

Individual results vary. Career timelines, salary outcomes, and job availability depend on your location, experience, market conditions, and effort. The information on this page is educational, not a guarantee of employment outcomes.

SOC Analyst Playbook to see how log analysis fits into the daily SOC workflow
Alert Triage for prioritising the alerts that log analysis generates
Incident Response for what happens when your log investigation confirms a compromise
Home Lab Setup to build the practice environment described on this page

Frequently Asked Questions

What is log analysis in cybersecurity?

Log analysis is the process of collecting, parsing, and interpreting records generated by operating systems, applications, network devices, and security tools to detect threats, investigate incidents, and maintain security. It is defined as a foundational security practice by NIST SP 800-92 and is the core technical skill for SOC analysts.

What are the most important Windows Event IDs for security?

The most critical Windows Event IDs for SOC analysts are: 4624 (successful logon), 4625 (failed logon), 4720 (user account created), 4688 (process created), 7045 (service installed), 4732 (user added to security group), 4648 (logon with explicit credentials), 4672 (admin logon), and 1102 (audit log cleared). These cover authentication, process execution, persistence, privilege escalation, and anti-forensics.

What is a SIEM and why is it important for log analysis?

A SIEM (Security Information and Event Management) platform collects logs from every source across an organisation — endpoints, firewalls, servers, cloud services, and applications — normalises them into a common format, correlates events across sources, and generates alerts when suspicious patterns are detected. Without a SIEM, analysts would need to manually check logs on individual systems, which is impossible at enterprise scale.

How do I learn Splunk for free?

Splunk offers a free tier (Splunk Free) that processes up to 500 MB of logs per day — plenty for a home lab. Install it on a Linux VM, forward Windows Event Logs and Sysmon data to it, and practise writing SPL queries. Splunk Education provides free Fundamentals 1 training. TryHackMe has multiple Splunk-focused rooms in the SOC Level 1 path. The BOTS (Boss of the SOC) dataset provides realistic investigation scenarios.

What does a brute-force attack look like in logs?

A brute-force attack appears as a high volume of failed logon events (Windows Event ID 4625) from a single source IP address targeting one or more accounts in a short time window. If the attack succeeds, you will see a successful logon event (4624) following the failures. In Linux auth.log, you see repeated 'Failed password' entries from the same IP. SIEM correlation rules can automatically detect this pattern.

What is the difference between Windows Event Log and Sysmon?

Windows Event Logs are built into Windows and record authentication, system events, and application activity. Sysmon (System Monitor) is a free Microsoft Sysinternals tool that provides much more detailed endpoint telemetry — process creation with full command lines, network connections per process, file creation timestamps, and registry modifications. Sysmon is considered the gold standard for endpoint visibility and is widely used in enterprise SOCs.

How do attackers try to avoid log detection?

Common anti-forensic techniques include clearing Windows event logs (Event ID 1102), disabling logging services, timestomping (modifying file timestamps), using living-off-the-land binaries (LOLBins) that blend with legitimate system tools, and tunnelling command-and-control traffic through DNS or HTTPS to evade network logging. This is why defence-in-depth logging — collecting from multiple sources — is essential. An attacker may clear endpoint logs but cannot easily erase firewall or SIEM copies.

Can I practise log analysis without a corporate SOC?

Yes. Set up a home lab with Splunk Free, a Windows VM running Sysmon, and a Linux VM. Use Atomic Red Team to generate realistic attack telemetry, then investigate the logs as if you were in a SOC. TryHackMe SOC Level 1, LetsDefend, Blue Team Labs Online, and CyberDefenders all provide structured log analysis exercises at free or low cost. Document your investigations in a portfolio to show hiring managers.

More resources

NIST SP 800-92 — Guide to Computer Security Log Management

The authoritative NIST guide covering log generation, transmission, storage, analysis, and disposal for security purposes.

Visit SANS Log Management Cheat Sheet

Quick reference for log sources, critical Event IDs, and log analysis techniques used in security operations.

Visit MITRE ATT&CK — Data Sources

Maps log data sources to adversary techniques — shows exactly which logs detect which attack behaviours.

Visit Splunk Free Download

Splunk Free tier for home lab practice — process up to 500 MB of logs per day at no cost.

Visit

Sources: NIST SP 800-92, NIST SP 800-61, SANS Institute, MITRE ATT&CK, Verizon DBIR 2024, IBM Cost of a Data Breach 2024. Last verified: March 2026.