Log Analysis for Incident Response — SIEM Correlation and Pivot to Respond to Attacks

You just received a SIEM alert: an internal host is contacting an unknown IP on a non-standard port. Where do you start? Without a log analysis methodology, the alert remains noise. We, at Meteora Web, have handled such scenarios dozens of times. The difference between an incident managed in hours and a disaster that takes down a business lies in your ability to correlate events and pivot across logs. This guide shows you how, with real commands and an operational approach.

What makes log analysis in Incident Response different from ordinary monitoring?

Ordinary monitoring watches thresholds: too much traffic, too many errors, a service down. It generates alerts but doesn't tell you what happened. Log analysis in IR is detective work: you need to reconstruct a timeline, find the origin, understand lateral movement and exfiltration. You don't care about the average error rate; you care about the single anomalous event and its connections.

Real example: A client had a compromised WordPress e-commerce site. The SIEM flagged an admin login from an unfamiliar Chinese IP. From there we pivoted: we looked for that IP in web server access logs, found a suspicious POST request, then in audit logs we saw a plugin file modification. From system logs we saw an outbound connection to a suspicious domain. All in 15 minutes because we had a method to correlate and pivot.

The difference: Monitoring tells you “there’s a problem”, IR log analysis tells you “here’s exactly what happened, when, and how”.

Action now: When you receive an alert, don't just read it. Ask: “Does this event have a before and after in the logs?”. Note the exact timestamp and start collecting logs from that minute.

How to correlate events across different log sources to identify an attack?

Correlation is the heart of log analysis in IR. A single log isn't enough: you must cross-reference auth logs, web server logs, firewall logs, DNS logs, and system logs. The goal is to find a thread linking seemingly separate events.

Temporal correlation

If the SIEM shows a successful login from an unknown IP at 14:32:15, a file modification at 14:32:45, and an outbound connection at 14:33:10, you already have a suspicious sequence. Time is the first correlation factor.

Entity correlation

Same IP, same username, same process, same host. Here's an example of manual correlation via command line. Start with SSH logs:

# Find all failed login attempts
sudo grep "Failed password" /var/log/auth.log | awk '{print $1,$2,$3,$11}' | sort | uniq -c | sort -nr

This gives you IPs with the most failed attempts. Pick one and check if a successful login occurred:

# Search for successful logins from that IP
sudo grep "Accepted password" /var/log/auth.log | grep "SUSPICIOUS_IP"

If found, take the timestamp and look in web server logs (e.g., nginx) for requests from the same IP:

sudo grep "SUSPICIOUS_IP" /var/log/nginx/access.log | awk '{print $4,$7}'

Then compare with system logs for commands like wget, curl, or sensitive file changes at the same time.

Power tool: use journalctl with specific unit and IP filter:

sudo journalctl -u sshd -g "SUSPICIOUS_IP" --since "2026-04-10 14:30" --until "2026-04-10 14:35"

This manual correlation is fast and works even without a SIEM. We use it often for rapid analysis on Linux servers.

SIEM correlation rules

SIEMs have native correlation rules. For example in Wazuh you can create a rule that fires when a successful login is followed by a suspicious command:

<rule id="100001" level="12">
  <if_sid>5715</if_sid>  <!-- Rule for successful SSH login -->
  <match>wget|curl|nc -e|bash -i</match>
  <description>SSH login followed by suspicious command</description>
  <group>incident_response,</group>
</rule>

This rule looks at the temporal sequence between two different log sources. That's how you turn logs into intelligence.

Action now: Pick a recent alert from your SIEM. Extract the timestamp and IP. Manually correlate across at least three log sources (e.g., auth + web + firewall). Write down the emerging timeline.

What log pivot techniques let you follow the attacker?

Pivoting is the art of moving from one indicator to another to reconstruct the attacker’s path. You start from an IP, move to a user, then a file, then a process, then a new connection. Here are the main techniques.

Pivot from IP to sessions

An IP appears in firewall logs. Query all logs containing that IP to find all sessions:

sudo grep "SUSPICIOUS_IP" /var/log/firewall.log | awk '{print $1,$2,$5,$7}'

If the firewall logs flows, you can see destination ports and protocols. An IP contacting ports 22 and 80 is more suspicious than one only on 443.

Pivot from session to user

From system logs, find the login associated with that IP and get the username:

sudo last | grep "SUSPICIOUS_IP"

Or on systems with auditd:

sudo ausearch -ui username -ts recent

Now you have a user. With that user, look in file change logs (inotify, auditd, File Integrity Monitoring) to see which files were modified.

Pivot from file to process

Suppose the modified file is /var/www/html/wp-content/uploads/malware.php. Search system logs for processes that wrote or executed that file:

sudo ausearch -f /var/www/html/wp-content/uploads/malware.php -i

On Windows, you'd use Get-WinEvent with Event ID 4663 (file access). The result gives you the process (e.g., /usr/bin/php) and exact time.

Pivot from process to connection

If the process is php, check if it initiated network connections in that same minute. Use auditd for connections (syscall connect) or system logs:

sudo ausearch -sc connect -i -ts 04/10/2026 14:30:00 -te 04/10/2026 14:35:00

This closes the loop: from file to outbound connection.

Advanced tool: lnav (Logfile Navigator) lets you browse multiple log files interactively, apply filters, and pivot on fields. We use it for quick analysis on servers without a SIEM.

Action now: Take a past incident log (even simulated). Apply the pivot chain: IP -> session -> user -> file -> process -> connection. Document each step. You'll see the path unfold.

How to build an incident timeline using logs?

A timeline is the backbone of IR communication: it lets you tell the attack story to decision makers. You build it by extracting timestamps from all sources and sorting them.

Collect logs and normalize timestamps

Not all logs have the same timezone. First convert everything to UTC. On Linux, use date:

# Convert a local timestamp to UTC
date -d "2026-04-10 15:30:00 CEST" -u +"%Y-%m-%dT%H:%M:%SZ"

Then extract all events of interest from each log source and put them in one file. Quick extraction example:

sudo grep "2026-04-10" /var/log/auth.log | grep -E "Accepted|Failed|session" >> timeline.txt
sudo grep "2026-04-10" /var/log/syslog | grep -E "malware|wget|curl" >> timeline.txt
sudo grep "2026-04-10" /var/log/nginx/access.log >> timeline.txt

Then sort by timestamp. If log formats differ, use sort -k1,2 or import into a spreadsheet. For cleaner analysis, we use awk to normalize the timestamp as the first field.

Timeline with SIEM

With ELK or Splunk, create a temporal report. In Splunk:

index=* (sourcetype=linux_secure OR sourcetype=apache_access) earliest="2026-04-10T14:30:00" latest="2026-04-10T15:00:00"
| table _time, src_ip, user, command, file_path
| sort _time

This gives you a perfect timeline with every event.

Action now: For your next incident, immediately extract a 30-minute timeline around the alert. Use grep across multiple log files and sort with sort. Save it as the first IR document.

Practical tools for log analysis in IR: SIEM, ELK, and command line

You don't always have an enterprise SIEM. We often work on client servers that only have basic system logs. Here are the tools we use, from simplest to most complex.

Command line (always available)

• grep/awk/sed: extract and filter.
• lnav: browse multiple logs interactively with highlighting and filters.
• journalctl: for systemd systems, filter by unit, priority, timestamp.
• ausearch: for auditd, structured queries on user, file, syscall.
• tshark: analyze pcap files or capture in real time.

Wazuh (open source SIEM)

We use it for clients who want a SIEM without costly licenses. Wazuh has a web interface with correlation dashboards, custom rules, and pivot capabilities. Example correlation rule that alerts when an IP appears in more than 3 log types within 5 minutes:

<rule id="100002" level="10">
  <if_sid>502,5715,80660</if_sid>  <!-- rules for login, file change, connection -->
  <match>srcip=SUSPICIOUS_IP</match>
  <description>Same IP in auth, file and conn logs within 5 min</description>
  <options>no_full_log</options>
</rule>

ELK Stack (Elasticsearch, Logstash, Kibana)

For huge volumes. Kibana lets you create correlation dashboards and use KQL to search events with specific fields. For example to find all events for a user in a time range:

user.name: "admin" AND @timestamp >= "2026-04-10T14:30" AND @timestamp <= "2026-04-10T15:00"

Then click on a field to pivot immediately.

Action now: If you don't have a SIEM, start with lnav and a set of grep commands. If you have Wazuh or ELK, create an IR-specific dashboard showing: timeline, suspicious IPs, login attempts, file changes, outbound connections.

What to do now

1. Define a log collection procedure for IR: Before an incident occurs, prepare a list of your system's log sources (auth.log, syslog, web access, firewall, DNS) and the commands to extract them quickly.
2. Practice with a simulated incident: Create an attack scenario (e.g., a PHP shell downloaded via web) and repeat the correlation and pivot steps described here. Use only the command line.
3. Set up a correlation rule in your SIEM: If using Wazuh, implement the rule linking login + file change + outbound connection. Deploy it.
4. Document the timeline: For every real or simulated incident, produce a timeline file with UTC timestamps and sources.
5. Go deeper: Read the full guide on Incident Response and Digital Forensics for the complete picture.

We, at Meteora Web, see companies every day that suffer attacks and don't know where to start with logs. With these tools and this methodology, you can move from panic to targeted response in minutes. The rest is practice.