Log Analysis for Incident Investigators

Memory and disk forensics answer what happened on a single host. Logs are what let you connect that host to everything else — which account logged in, which firewall rule allowed the connection, which other systems the same source IP touched. In most incidents, the investigative timeline that eventually goes into the final report is built primarily from log correlation, with host forensics used to confirm and deepen specific findings.

The sources available during an incident are determined by decisions made long before it — retention settings, what's forwarded to a central store, and whether command-line logging is even enabled. Mapping your log sources in advance is preparation work, not incident-time work.

• •Authentication logs (Windows Security event log, sshd/auth.log, IdP/SSO logs)
• •Network logs (firewall, proxy, DNS resolver, NetFlow/VPC flow logs)
• •Endpoint telemetry (EDR process and network events, Sysmon)
• •Cloud control-plane logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs)
• •Application and database logs specific to the affected systems

Correlating events across sources depends on accurate, synchronized time. Hosts with clocks that have drifted, or that are logging in local time instead of UTC, will produce a timeline that's subtly or badly wrong. Before trusting cross-source correlation, confirm NTP is functioning and normalize every timestamp to a single timezone — UTC is the standard choice for incident timelines specifically because it avoids ambiguity across systems and daylight saving transitions.

A SIEM or centralized log platform makes correlation practical at scale, but centralization is also a target — retention windows and forwarding configuration should be checked as part of preparation, not discovered to be inadequate mid-incident.

In a SIEM like Splunk, most investigative queries start broad — count events by a field to find outliers — before narrowing to specific hosts or accounts.

index=windows sourcetype=WinEventLog:Security EventCode=4625
| stats count by user, src_ip
| where count > 10
| sort -count

Not every environment has centralized logging, and even where it exists, raw flat-file logs are sometimes the fastest path to an answer. Standard Unix tools chain together well for this.

grep "Failed password" /var/log/auth.log \
  | awk '{for(i=1;i<=NF;i++) if ($i=="from") print $(i+1)}' \
  | sort | uniq -c | sort -rn | head -20

Once relevant events are pulled from each source, the next step is aligning them chronologically into a single timeline — a technique sometimes called a super timeline. Purpose-built tools such as plaso/log2timeline can automate this for disk and filesystem artifacts, but for log-driven investigations a simple normalized spreadsheet (timestamp in UTC, source, host, account, event, raw reference) is often clearer and easier to hand to non-technical stakeholders than a tool-generated output.

A handful of recurring issues account for most flawed timelines, and most of them are preparation gaps rather than analysis mistakes — by the time an investigator notices the problem, the missing data usually can't be recovered.

• •Clock skew between systems producing an apparently impossible event order
• •Log rotation or retention limits deleting the relevant window before it's collected
• •Attackers clearing event logs — Windows Security Event ID 1102 records an audit log clear and is itself a strong indicator worth alerting on
• •Treating a single log source as authoritative instead of corroborating across sources
• •Command-line logging (Event ID 4688 with command-line auditing enabled) not turned on until after the fact, leaving a visibility gap for the incident period
• •Assuming a gap in the logs means 'nothing happened' rather than 'nothing was recorded' — the two are not the same thing

A single log entry is rarely conclusive on its own — a failed logon could be a typo, and an unusual outbound connection could be legitimate software phoning home. Confidence comes from correlation: the same source IP appearing in a failed-logon spike, then a successful logon, then an unusual process launch, then an outbound connection to an uncommon destination, tells a much stronger story than any one of those events alone. Structuring queries to walk that chain — authentication, then endpoint, then network — is generally more productive than searching each source independently and trying to merge the results afterward.

Keep a clear line between raw evidence and analytic conclusions. Preserve original log exports read-only and reference them by query and timestamp in the report, rather than paraphrasing from memory — this keeps findings reproducible if the timeline is challenged or needs to be reviewed by a second analyst.