Given a scenario, use data sources to support an investigation

This objective is "given a scenario", which means you will be shown log output and asked what it means or where to look. It is one of the most practical objectives on the exam, and one of the few where reading skill beats memorisation.

The core question is always the same: which source answers this question?

Matching the source to the question

OS-specific security logs (Windows Security event log, Linux /var/log/auth.log) record authentication, privilege use and account changes. These are where you go for "who logged in".

IDS/IPS logs record signature or anomaly matches — traffic that looked like a known attack. Remember from 1.1 that an IDS only alerts while an IPS blocks, so the log tells you which happened.

Network logs cover switch, router and NetFlow data: who talked to whom, how much, and when. NetFlow gives you volume and endpoints without payload.

Metadata is data about data — email headers, file creation times, EXIF in images. Email headers are the standard exam example, because they reveal the true sending path when a display name is spoofed.

Check yourself

You need to determine whether a phishing email's sender address was spoofed. Which data source?

• Firewall logs
• Email metadata (headers)
• NetFlow records
• Vulnerability scan output

Packet captures

A packet capture (pcap, via Wireshark or tcpdump) is the highest-fidelity source: full payload, every byte.

That fidelity has costs. Captures are enormous, they may contain sensitive data subject to privacy rules, and encrypted traffic reveals only metadata — you see that a TLS session occurred, with whom and how big, but not what was said.

Aggregated sources

Vulnerability scan output tells you what was weak — often the answer to "how did they get in" during a post-incident investigation.

Automated reports and dashboards are SIEM outputs summarising across sources. Useful for trends and for spotting the anomaly; not where you go for detail.

Reading a log the exam's way

Most log questions are answered by looking for three things:

1. A source that repeats. One IP, one account, one process appearing far more than anything else.
2. A parent-child relationship that should not exist. Office spawning a shell is the classic — WINWORD.EXE launching powershell.exe is almost never legitimate.
3. A sequence. Failures, then a success, then something privileged. That shape is a successful brute force followed by escalation, and it appears repeatedly on the exam.

Nov 14 09:22:41 web01 sshd: Failed password for invalid user admin from 203.0.113.42
Nov 14 09:22:43 web01 sshd: Failed password for invalid user root from 203.0.113.42
Nov 14 09:22:45 web01 sshd: Failed password for invalid user oracle from 203.0.113.42
Nov 14 09:23:02 web01 sshd: Accepted password for deploy from 203.0.113.42
Nov 14 09:23:04 web01 sudo: deploy : USER=root ; COMMAND=/bin/bash

Five rapid failures for common service accounts from one address, then a success from that same address, then immediate escalation to root. The failures alone are noise the internet generates constantly; the success from the same source is what makes it an incident.

Check yourself

In the log above, which single line changes this from routine noise to a confirmed incident?

• The first failed password attempt
• The repeated failures for different usernames
• The accepted password from the same source IP
• The sudo command

Time and correlation

Two practical points the exam does test:

Timestamps and time zones. Correlating sources requires synchronised clocks, which is why NTP matters and why logs should be normalised to UTC. Drifting clocks make a timeline impossible to build.

Log aggregation. Centralising logs to a SIEM or syslog server means an attacker who compromises a host cannot erase the copy that already left it. Local-only logs are exactly what gets wiped first.