Reading log data and other sources to support an investigation

Objective 4.9 in this course covers data sources — CompTIA's scope note for it uses log data and other sources to support investigations. It is the last objective in Domain 4 and the domain's capstone: it is where the threats from Domain 2, the architecture from Domain 3 and the tooling from Domain 4 are 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 log type carries the answer.

It also produces the most valuable habit in the whole exam — reading for the anomaly rather than reading for the villain. Every finding in Domain 2's indicator table is a deviation from a normal rate, direction, time, geography or character set.

The lesson

Firewall, application, endpoint, OS-specific and IPS/IDS logs

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

• Firewall logs — who connected to whom, on what port, allowed or denied, and how much data. They answer did this host talk to that one. Denied entries matter as much as allowed ones: a host repeatedly denied outbound to many destinations is scanning or beaconing to blocked infrastructure.
• Application logs — the software's own record: logins, transactions, errors, administrative actions. They answer what did the user do inside the application, which nothing else can see. Injection attempts appear here as malformed input and unusual error rates.
• Endpoint logs — process creation with parent process and full command line, file and registry changes, service and scheduled task creation. They answer what ran on this machine, and what started it, which is the question encryption cannot hide.
• OS-specific security logs — Windows Security event log (logons, privilege use, account management, object access) and Linux auth.log/secure plus auditd. They answer who authenticated, from where, and what privileges were used.
• IDS/IPS logs — signature or anomaly matches, with the rule that fired and whether it was blocked. They answer did known-bad traffic appear, and they need interpreting: a fired rule is an assertion, not a conclusion.

The practical sequencing: firewall and network sources tell you that something happened and between which hosts; endpoint and OS logs tell you what happened on the machine; application logs tell you what it did to the business.

Network, metadata, vulnerability scans, automated reports and dashboards

CompTIA's other data sources:

• Network logs and flow data — NetFlow and its relatives, from 4.4. Who talked to whom, for how long, how many bytes, in which direction. Works when everything is encrypted, which makes it the primary source for beaconing, lateral movement and exfiltration volume.
• Metadata — data about the data. Email headers (the real sending server, the path, the authentication results from SPF/DKIM/DMARC), file metadata (created, modified, author, original path), and document properties. Email headers in particular answer "was this really from them?" definitively.
• Vulnerability scans — what was exploitable on that host at that time, which turns "how did they get in?" from speculation into a short list.
• Automated reports and dashboards — aggregated views for trend and situational awareness. They are for noticing that something is off, not for determining what happened; every dashboard finding has to be taken back to the underlying records.
• Packet captures — the full content, where flow data gives only the envelope. Expensive to store, and limited by encryption, but decisive when available.

The distinction the exam draws repeatedly: flow data tells you who talked to whom; packet capture tells you what they said. If the question is about volume, timing or pattern, flow is enough. If it is about content, you need the capture — and you probably cannot read it if it was TLS.

Packet captures, and what they answer that a log cannot

A capture answers questions no log was configured to record.

• Exactly what was sent — the request body of an injection attempt, the contents of an unencrypted protocol, the specific commands issued.
• Protocol-level behaviour — malformed packets, unusual flag combinations, fragmentation, and the handshake details that reveal a downgrade.
• What actually left — the difference between "a connection transferred 40MB" and knowing what those 40MB were.

Its limits are real and examinable. Encryption means most captures show metadata, certificates and SNI rather than content. Volume means full capture is usually limited to a sensor, a subnet, or a short window. And a capture only exists if something was capturing at the time, which is a preparation decision from the previous lesson, not a thing you can do retroactively.

What you can still read from an encrypted capture is more than people expect: the destination, the SNI or certificate names, the packet sizes and timing (which is how beaconing shows up), the JA3-style client fingerprint, and the negotiated protocol version — the last of which is how a downgrade attack is spotted.

Correlating two sources to establish a timeline

A single source shows one facet. The investigation is built by joining them.

The joins that carry most of the work:

• Time — the universal join, and the reason NTP matters. Two sources whose clocks differ by hours produce a timeline that is confidently wrong. Normalise everything to UTC before comparing, because a mix of local times across regions is the same error wearing a different hat.
• IP address — but be careful across NAT, DHCP and proxies, where one address is many hosts or one host is many addresses. A DHCP lease log is frequently the missing link between an address in a firewall log and a machine.
• Username and account — the join between OS, application and cloud logs.
• Host name and asset ID — from the inventory in 4.2.
• Hash and filename — for tracking a payload across machines.

A worked correlation, which is the shape of the exam's harder questions:

1. The firewall shows an internal address making regular 90-second connections to an external host, starting Tuesday 14:05 UTC.
2. The DHCP log maps that address at that time to a specific laptop.
3. The endpoint log shows a PowerShell process on that laptop, started by WINWORD.EXE, at 14:03.
4. The email gateway shows a message with a macro-enabled attachment delivered to that user at 13:58, which passed SPF for a lookalike domain.
5. The Windows Security log shows a successful logon for that user at 14:01 — ordinary — and at 03:12 the next morning a logon to a file server from the same account.

That is a timeline: phishing at 13:58, execution at 14:03, C2 at 14:05, lateral movement at 03:12. Nothing in it required a tool anyone does not have; it required five sources and a clock they agree on.

Writing the finding so somebody else can act on it

The investigation is worthless if the write-up does not produce action. What a usable finding contains:

• What happened, in one sentence, at the top. Readers stop early.
• The timeline, with timestamps in a stated timezone and the source of each entry, so any line can be checked.
• Scope — which accounts, hosts and data were affected, and equally importantly what you established was not affected, with how you established it. "We found no evidence of X" is a much weaker claim than "we checked X by this means and it was clean", and readers will treat them as the same unless you distinguish them.
• Confidence, stated. Separate what you observed from what you infer. "The account authenticated from that address" is an observation; "the attacker used the stolen credential" is an inference, and a reader making decisions needs to know which is which.
• Impact, in business terms, because that is what determines notification obligations and executive decisions.
• Actions taken and actions required, each with an owner.

Two habits worth carrying beyond the exam. Write the timeline as you go, because reconstructing it afterwards from memory and chat scrollback loses detail and takes longer. And record what you searched and found nothing in, because the next person will otherwise repeat it, and because a negative result against a source you can name is evidence.

The final connection back to the rest of the course: the quality of every finding here is decided long before the incident, by the logging that was enabled, the retention that was configured, the clocks that were synchronised and the inventory that says which host an address belongs to. Investigation is a Domain 4 activity that is mostly won in preparation.

What to take into the exam

• Match the question to the source: firewall for connections, endpoint for process ancestry, OS security log for authentication and privilege, application log for business actions.
• Flow data works despite encryption and answers who-talked-to-whom; packet capture answers what-was-said and is limited by encryption and storage.
• Email headers, with SPF/DKIM/DMARC results, settle whether a message really came from the domain it claims.
• Time is the universal join — normalise to UTC, and unsynchronised clocks produce a confidently wrong timeline.
• DHCP leases are what turn an IP address in a log into a specific machine.
• In the write-up, separate observation from inference and say what you checked and found clean.