Log Analysis Basics for SOC Analysts: What to Check First

Log analysis is one of the core skills used in a Security Operations Centre. Effective log analysis for SOC analyst work means turning raw events into a clear timeline: what happened, when it happened, which systems were involved and whether action is required.

This guide focuses on the first checks a junior SOC analyst should perform. It covers important log fields, source selection, useful commands, event correlation and a worked SSH investigation.

What is log analysis in a SOC?

Log analysis is the process of reviewing machine-generated records to identify security events, operational problems and suspicious behaviour. A SOC analyst uses logs to validate alerts, reconstruct activity and decide whether an event is benign, suspicious or confirmed malicious.

Logs are produced by operating systems, applications, firewalls, identity platforms, cloud services and security tools. A SIEM collects and searches these records, but the analyst must still understand what each event means; this relationship is explained further in how security teams detect threats from logs.

A simple diagram in words looks like this:

User or attacker
      |
      v
Endpoint, server, firewall or cloud service
      |
      v
Local event or audit log
      |
      v
Log collector or SIEM
      |
      v
Detection rule creates an alert
      |
      v
SOC analyst validates, scopes and responds

An alert is not automatically an incident. It is a signal that requires investigation using the underlying logs and relevant context.

What should a SOC analyst look for first?

Start with the timestamp, source, destination, user, action and result. These fields establish the basic facts before you interpret severity or assume malicious intent.

Use the following order during initial triage:

1. Verify the timestamp

Confirm the event time, time zone and clock accuracy. A five-minute clock difference between a firewall and server can place related events in the wrong order.

Prefer Coordinated Universal Time (UTC) during investigations. If a source uses local time, record the offset before building the timeline.

2. Identify the real source and destination

A source IP may represent a workstation, VPN address, proxy, NAT gateway or load balancer rather than the original user. Check fields such as source.ip, client.ip, x-forwarded-for and the firewall translation address.

Similarly, determine whether the destination is the public address, translated private address or final application server. NAT information is especially important when correlating firewall and server logs.

3. Check the action and outcome

Separate attempted activity from successful activity. Fifty failed logins may show password guessing, but one successful login after those failures changes the risk significantly.

Common outcome values include success, failure, allowed, denied, accepted, blocked and dropped. Do not treat a firewall deny as proof that a host was compromised.

4. Establish the normal baseline

Ask whether the user, host, protocol and time are normal for the environment. An administrator using SSH may be expected, while the same account logging in from an unknown external address at an unusual time may need escalation.

A baseline should come from asset records, identity information and previous activity. It should not be based only on an analyst's assumption.

Which log sources should be checked first?

Check the source that generated the alert, then move outward to identity, endpoint, network and application logs. The best order depends on the event type, but using multiple independent sources helps confirm what actually happened.

Important sources include:

• Windows Security logs: logons, account changes, privilege use and process creation when auditing is enabled.
• Linux authentication logs: SSH attempts, sudo use and PAM authentication results.
• Firewall logs: source, destination, ports, policy, NAT details and allow or deny action.
• DNS logs: domains requested by internal hosts.
• Proxy logs: URLs, response codes, users and transferred bytes.
• Cloud audit logs: control-plane actions such as configuration and identity changes.
• Application logs: sessions, errors, API activity and business-level actions.

Firewall analysts should understand how policy order, NAT and logging settings affect recorded events. The practical guide to FortiGate policies, NAT and logging provides useful background.

What is a practical SOC log analysis workflow?

A reliable workflow is validate, normalise, scope, correlate, assess and document. Following the same sequence reduces missed evidence and prevents analysts from jumping to conclusions based on one log line.

Step 1: Validate the alert

Open the original event rather than relying only on the alert title. Confirm that the rule matched real data and that important fields were parsed correctly.

Questions to ask include:

• Does the raw event support the alert description?
• Is the source still sending current logs?
• Did a parser place values in the wrong fields?
• Is the detection based on one event or a sequence?

Step 2: Normalise the timeline

Convert timestamps to a common time zone and note collection delays. Search several minutes before and after the alert because the first detected event may not be the start of the activity.

Step 3: Scope the event

Search for the same IP address, hostname, account, file hash, domain or process across other log sources. Determine whether one asset or several assets are affected.

Step 4: Correlate related events

Correlation connects separate records into one sequence. For example, a VPN login, a Windows logon and an endpoint process event may represent one user session.

Diagram in words:

VPN login from external IP
          |
          v
Internal address assigned to user
          |
          v
Windows logon on finance workstation
          |
          v
PowerShell process starts
          |
          v
Outbound DNS and HTTPS connections

Each event alone may have a benign explanation. Together, they provide stronger evidence and a useful investigation timeline.

Step 5: Assess impact and confidence

Determine what succeeded, which account privileges were available and whether sensitive assets were reached. Assign severity according to organisational procedures, not simply according to the number of events.

Step 6: Preserve and document evidence

Record the query, time range, time zone, affected assets and important raw events. Preserve exported evidence without modifying the source file.

On Linux, a SHA-256 hash can help verify that an exported file has not changed:

sha256sum case-1042-auth.log > case-1042-auth.log.sha256
sha256sum -c case-1042-auth.log.sha256

Which commands help with basic log analysis?

Linux and Windows provide native tools for first-level investigation. These commands are useful for small datasets and validation, although production environments commonly use a SIEM for wider searches.

Linux authentication logs

On Ubuntu systems using traditional text logs, SSH authentication events are commonly written to /var/log/auth.log:

sudo grep -F "Failed password" /var/log/auth.log
sudo grep -F "Accepted password" /var/log/auth.log
sudo grep -F "sudo:" /var/log/auth.log

Search current and rotated files together:

sudo zgrep -h "Failed password" /var/log/auth.log*

Count repeated SSH failures by source IP:

sudo zgrep -h "Failed password" /var/log/auth.log* |
awk '{print $(NF-3)}' |
sort |
uniq -c |
sort -nr

The first column is the count and the second is the extracted IP address. Always inspect sample raw lines because log formats can vary and may change the correct awk field.

For systems using the systemd journal:

sudo journalctl -u ssh --since "2026-10-22 09:00:00" \
  --until "2026-10-22 10:00:00" --utc

The SSH unit may be named ssh.service or sshd.service, depending on the distribution. Check available units with:

systemctl list-units --type=service | grep -E 'ssh|sshd'

Windows Security logs

PowerShell can retrieve recent failed logons, represented by Windows Security Event ID 4625:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4625
    StartTime=(Get-Date).AddHours(-2)
} | Select-Object TimeCreated, Id, MachineName, Message

Useful Windows event IDs include:

Event IDs require context. For example, service accounts can generate frequent 4624 events as part of normal system operation.

JSON security events

If events are exported as newline-delimited JSON, jq can select and format relevant fields:

jq -r 'select(.event.action == "login-failed") |
[.["@timestamp"], .source.ip, .user.name] | @tsv' events.json

This command filters failed-login events and prints the timestamp, source IP and username as tab-separated values.

How do you investigate repeated SSH failures followed by success?

First determine whether the successful login came from the same source as the failures and whether the account performed further actions. A success after repeated failures may indicate a compromised password, but it can also result from a legitimate user correcting a saved credential.

Consider these example events:

Oct 22 09:11:02 app01 sshd[4182]: Failed password for backupadmin from 198.51.100.24 port 51120 ssh2
Oct 22 09:11:07 app01 sshd[4185]: Failed password for backupadmin from 198.51.100.24 port 51128 ssh2
Oct 22 09:14:31 app01 sshd[4231]: Accepted password for backupadmin from 198.51.100.24 port 51302 ssh2
Oct 22 09:16:04 app01 sudo: backupadmin : COMMAND=/usr/bin/cat /etc/shadow

A practical investigation would be:

1. Confirm the timestamps and server time zone.
2. Count failures from 198.51.100.24 and identify all targeted accounts.
3. Confirm whether the successful login used the same IP and account.
4. Check whether the source belongs to an approved VPN, office or administrator.
5. Review sudo, shell history, process audit and file-access records after login.
6. Search firewall, VPN and identity logs for the same source and username.
7. Check whether the account accessed other servers.
8. Escalate according to the response procedure if the login is unauthorised or cannot be explained.

The sudo command shown is highly sensitive because it attempts to read password-hash data. However, the log line alone does not confirm that the command succeeded; permissions, command output and supporting audit logs must be checked.

How can analysts reduce false positives?

False positives are reduced by validating asset roles, approved behaviour and event outcomes. Suppression should be narrow and evidence-based so that a known benign pattern is excluded without hiding similar malicious activity.

Before closing an alert, ask:

• Is the source an approved vulnerability scanner?
• Is the account a service account with expected scheduled activity?
• Did a maintenance window explain the configuration change?
• Was the connection blocked, or did it complete?
• Has the asset owner confirmed the activity?
• Does historical data show the same pattern?

Document the evidence supporting closure. Avoid broad exclusions such as ignoring every event from an administrator subnet.

What should you do when logs are missing or inconsistent?

Check source generation, forwarding, parsing, retention and time synchronisation in that order. Missing events do not prove that an action did not happen; they may indicate a visibility problem.

Useful time checks include:

timedatectl status
chronyc tracking

On Windows, check time-service status with:

w32tm /query /status

Never silently treat a logging gap as a clean result. Record the limitation in the case notes and escalate the telemetry issue when required.

How can beginners practise SOC log analysis safely?

Build a small isolated lab with one Linux server, one Windows machine and a log collection platform. Generate known events, record the exact time and verify how each action appears locally and in the collector.

A useful practice sequence is:

1. Attempt an SSH login with an incorrect password from a lab client.
2. Log in successfully with an authorised test account.
3. Run an approved sudo command.
4. Review the Linux authentication events.
5. Search by username, source IP and time range.
6. Write a short timeline and explain why each event occurred.

Do not expose the lab SSH service directly to the internet. Use private addressing and systems you are authorised to test.

Hands-on investigation, SIEM searching and incident documentation are important parts of structured Cybersecurity and SOC training. The goal is not only to find events, but to explain their meaning and make a defensible escalation decision.

Quick summary

• Start with time, source, destination, identity, action and result.
• Read the raw event before trusting an alert description.
• Separate failed attempts from successful activity.
• Correlate identity, endpoint, network and application logs.
• Use a common time zone when building a timeline.
• Validate normal behaviour before closing an alert.
• Document missing data and preserve relevant evidence.

Reviewed by Network Rhinos cybersecurity trainers.

To practise log triage, SIEM searches and investigation workflows in guided labs, view the Cybersecurity and SOC course and enquire about current batch details.

Related reading: Kali Linux Tools Overview for Ethical Hacking Students