Reading logs, images and other sources to support an investigation

Objective 4.8 is about using evidence: given a scenario, pick the log, capture or image that answers the question, trust it only as far as its integrity allows, and hand the result to the people who must act on it. It is the last objective in Domain 4 and its capstone -- the threats from Domain 2 and the architecture from Domain 3, read back off the evidence.

Why this matters

This objective produces the questions that look hardest and are actually the most mechanical: a log extract and "what does this indicate?". The answer is in the extract, and candidates lose marks by not knowing which field of which source carries it.

It also builds the most valuable habit in the exam: reading for the anomaly rather than for the villain. Almost every indicator is a deviation from a normal rate, direction, time, location or pattern. And SY0-801 adds the questions that follow the reading -- can this evidence be trusted, and who outside security needs it?

The lesson

Access, authentication, device, server, application, audit and network logs

Each log category answers a different question. Knowing which to reach for is most of the skill.

• Access and accounting logs record who reached what, and how much they used. They come in two kinds: logical (file shares, databases, VPN and cloud sessions) and physical (badge readers, door controllers, visitor books). A logical login from inside the building by someone whose badge never entered it is a classic finding.
• Authentication logs -- Windows Security events, Linux auth.log or secure, identity provider sign-in logs. They answer who proved their identity, from where, and with what factor. Bursts of failures followed by a success, or impossible travel between two locations, live here.
• Device logs from network equipment, printers and appliances, and server logs from the operating system and its services, answer what changed on the infrastructure: a configuration edit, a service stopped, a new local account.
• Application logs are the software's own record of logins, transactions, errors and administrative actions. They answer what the user did inside the application, which nothing else sees. Injection attempts show up as malformed input and unusual error rates.
• Endpoint logs -- process creation with parent process and command line, file and registry changes, scheduled tasks. They answer what ran, and what started it.
• Audit logs record security-relevant administrative actions: permission changes, policy edits, log settings being altered. An audit entry showing logging was turned off is itself an indicator.
• Communication logs -- email, chat and telephony records -- show who contacted whom and when. Email headers carry the real sending server and the SPF, DKIM and DMARC results (lesson 32).
• Network logs from firewalls, proxies and DNS answer did this host talk to that one, and was it allowed. Denied entries matter: a host repeatedly refused outbound is often scanning or beaconing.
• Metadata is data about the data: file created and modified times, author, original path, message headers. It often answers "who and when" without touching content.

NetFlow and IPFIX, packet captures, scan results, dashboards and surveillance footage

• NetFlow and IPFIX. Flow records summarise conversations: source, destination, ports, protocol, start time, duration, bytes and packets. NetFlow began as a Cisco format; IPFIX is the IETF standard that grew from it. Flow works when the traffic is encrypted, which makes it the main source for beaconing, lateral movement and exfiltration volume.
• Packet captures hold the full content. They show exactly what was sent, protocol-level oddities, and what actually left. Their limits are examinable: encryption hides content (you still see destinations, certificate names, sizes and timing), storage limits full capture to a sensor or a short window, and a capture only exists if something was capturing at the time.
• Vulnerability scan results show what was exploitable on a host at a given time, turning "how did they get in?" from speculation into a short list.
• Automated reports and dashboards give trend and situational awareness. They are for noticing something is off, not for proving what happened; every dashboard finding is taken back to the underlying records.
• Security tools -- EDR, IDS/IPS, DLP, email security -- produce alerts and telemetry. A fired rule is an assertion to verify, not a conclusion.
• Surveillance footage places a person physically: who entered the server room, who was at the desk when the session started. Retention is often short, so it must be preserved early.

The distinction the exam draws repeatedly: flow tells you who talked to whom; a packet capture tells you what they said. Volume, timing and pattern questions need flow. Content questions need the capture, and you probably cannot read it if it was TLS.

Memory dumps, bit-level copies and snapshots, captured in order of volatility

A system image preserves a machine's state for examination. Three kinds:

• Memory dump -- the contents of RAM: running processes, network connections, logged-on sessions, injected code, decryption keys. Fileless malware may exist nowhere else. Lost at power-off.
• Bit-level copy -- a sector-by-sector image of a disk, including deleted files and slack space, which a normal file copy misses. Taken through a write blocker and hashed at once.
• Snapshot -- a point-in-time copy of a virtual machine or cloud volume, quick to take and the natural method in virtualised and cloud environments. Take it before the instance is terminated.

The order of volatility says to collect the most fragile evidence first. From most to least volatile:

1. CPU registers and cache;
2. RAM, captured as a memory dump;
3. network state and running processes;
4. temporary files and the swap or page file;
5. disk, captured as a bit-level copy;
6. remote logs and monitoring data already forwarded elsewhere;
7. physical configuration and network topology;
8. archival media such as backups.

The instruction that follows: isolate a compromised machine from the network, but do not power it off before taking the memory dump.

Proving a log has not been altered, and parsing it fast enough to matter

Evidence is only as good as your ability to show it was not changed. An intruder with administrator rights can edit or clear local logs, so integrity is designed in beforehand:

• Forward logs off the host as they are written, to a central collector or SIEM the attacker's account cannot reach.
• Write-once or append-only storage for retained logs and evidence.
• Hashing. Hash an image or log file at collection and again before analysis; matching values show it is unchanged. Some systems also sign or chain log records so a deleted or edited entry breaks the sequence.
• Time synchronisation. Every source on NTP, ideally recording UTC. Clocks that disagree produce a timeline that is confidently wrong.
• Access control and auditing on the log store itself.

Parsing is how you get from millions of lines to the ten that matter, quickly:

• Filter by time window first, around the known event.
• Search with patterns -- grep or regular expressions for an address, username, hash or event ID (on Windows, 4624 is a successful logon and 4625 a failed one).
• Extract fields so you can work with columns, not raw text.
• Count and sort -- the rare value and the sudden spike are what you are looking for.
• Normalise in a SIEM, where parsers map each product's format to common field names so a username means the same thing in every source.

Correlating sources into a timeline, and the HR, finance and legal people who need it

A single source shows one facet; the investigation is built by joining them. The joins that carry the work are time (normalised to UTC), IP address (careful across NAT and DHCP -- a lease log is often the missing link between an address and a machine), username, host name or asset ID from the inventory in lesson 33, and file hash.

A worked correlation:

1. Network logs show an internal address making connections every 90 seconds to an external host from 14:05 UTC.
2. The DHCP log maps that address at that time to a specific laptop.
3. The endpoint log shows PowerShell started by the word processor on that laptop at 14:03.
4. The email log shows a macro-enabled attachment delivered to that user at 13:58, sent from a lookalike domain.
5. The authentication log shows the same account logging on to a file server at 03:12 the next morning, while the badge log shows nobody in the building.

That is phishing, execution, command and control, then lateral movement -- five sources and a clock they agree on.

The finding then goes to people outside security:

• HR when an employee is involved, for disciplinary process. They need facts and a defensible evidence trail, not speculation.
• Accounts or finance when money moved or may move: a fraudulent payment, a changed supplier bank detail, or the cost of response.
• Legal for notification duties, preservation, contracts and any proceedings.

Write for them: one sentence on what happened, the timeline with sources, what was and was not affected and how you know, observation kept separate from inference, and actions with owners.

What to take into the exam

• Match the question to the source: authentication logs for who logged in, endpoint for what ran, audit for admin changes, physical access logs for who was in the building.
• Flow (NetFlow/IPFIX) works despite encryption; packet capture shows content but is limited by encryption and storage.
• Memory dump, bit-level copy, snapshot -- collected most volatile first, and memory before power-off.
• Log integrity comes from forwarding, append-only storage, hashing and synchronised clocks.
• Parse by narrowing the time window, then searching, extracting, counting and normalising.
• Time is the universal join; HR, finance and legal each need the finding in their own terms.