Data Sources for Security Investigations
Exam objective 4.8: Given a scenario, use data, artifacts and sources to support a security investigation.
This objective covers the raw material of an investigation: the many types of logs and traces that systems produce (access and accounting, device, server, application, authentication, communication, audit, endpoint, network, and metadata); other data sources such as vulnerability scans, automated reports, NetFlow and IPFIX, surveillance footage, security tools, dashboards, and packet captures; how to prove file and log integrity; how to acquire system images through memory dumps, bit-level copies, and snapshots; which business stakeholders (HR, accounts, and legal) become involved; and the techniques used to parse logs efficiently.
This is a "given a scenario" objective, so expect questions that show you a log excerpt, describe an investigation, and ask which data source would answer a specific question, what a log entry reveals, or what an analyst should collect first. Performance-based questions may ask you to read several logs and identify the compromised host or attacker IP, so practice reading the samples in this chapter. Chapter 20 covered the incident response process; this chapter is about the evidence that drives it.
Thinking Like an Investigator
Every investigation tries to answer the same questions: who did it, what happened, when it happened, where (which systems, networks, and locations) it happened, how it was done, and why (motive and root cause). No single data source answers all of them. Authentication logs answer who and when; firewall and NetFlow data answer where traffic went; endpoint telemetry answers what ran; packet captures answer exactly what was said. The analyst's skill lies in choosing the right source for the question and correlating events across sources by time, host, user, and IP address.
Correlation depends on accurate, synchronized time. Every system should use NTP against a common, trusted time source, and logs should record time zone or use UTC. Otherwise a firewall log in UTC and a Windows log in local time appear hours apart. A SIEM (Chapter 17) normalizes time automatically, but analysts must still verify offsets.
Exam tip
When a scenario asks which source would BEST answer a question, match the question word to the source: who logged in (authentication logs), what process ran (endpoint/EDR logs), how much data left and to where (NetFlow or firewall logs), what exactly was transmitted (packet capture), who physically entered (badge logs and surveillance footage).
Log and Trace Types
A log is a time-stamped record of events written by a system, application, or device. A trace is a more detailed record that follows a specific transaction, request, or path—for example, a distributed trace that follows one web request through a load balancer, microservices, and a database, or a network trace (packet capture). The objective lists ten categories.
Access and Accounting Logs
Access and accounting logs record who accessed what and when—the "accounting" in AAA (Chapter 1). The objective splits them into two forms:
- Logical access logs record access to systems and data: file share access, database queries, VPN sessions, RADIUS and TACACS+ accounting records (session start and stop, bytes transferred, commands executed), and cloud console activity.
- Physical access logs record access to facilities: badge reader entries and exits, visitor sign-in logs, access vestibule events, and alarm system logs.
Correlating logical and physical access is a powerful investigation technique. If a user's badge shows them entering the Toronto office at 9:02 a.m., a VPN login from overseas under the same account at 9:15 a.m. indicates credential compromise. Conversely, if an after-hours login occurred from a console in a locked server room, badge logs show who was physically present.
2026-09-14 21:47:03 DOOR=DC-01-MAIN BADGE=40177 NAME="R. Patel" RESULT=GRANTED 2026-09-14 21:47:11 DOOR=DC-01-CAGE4 BADGE=40177 NAME="R. Patel" RESULT=DENIED 2026-09-14 21:47:19 DOOR=DC-01-CAGE4 BADGE=40177 NAME="R. Patel" RESULT=DENIED 2026-09-14 21:52:40 DOOR=DC-01-CAGE4 BADGE=31022 NAME="M. Ortiz" RESULT=GRANTED This physical access log shows an employee repeatedly denied access to a cage after hours, followed five minutes later by a different badge opening the same cage—possibly tailgating, a loaned badge, or a cloned credential. Surveillance footage of that door would be the next source to review.
Device Logs
Device logs come from network and infrastructure devices: routers, switches, firewalls, wireless controllers, load balancers, VPN concentrators, and printers. They record configuration changes, interface up/down events, routing changes, authentication to the device, and errors. Most network devices send logs using syslog (UDP 514 traditionally, TCP 514 or TCP 6514 for syslog over TLS). Firewall logs, which are both device and network logs, record allowed and denied connections with source and destination addresses and ports.
Sep 14 22:03:51 edge-fw01 %ASA-6-302013: Built outbound TCP connection 88211 for outside:203.0.113.77/443 (203.0.113.77/443) to inside:10.20.4.31/51544
Sep 14 22:03:52 core-sw02 %SEC-6-IPACCESSLOGP: list MGMT denied tcp 10.20.4.31(51602) - > 10.0.0.5(22), 1 packet
Sep 14 22:04:10 core-sw02 %SYS-5-CONFIG_I: Configured from console by admin on vty0 (10.20.4.31)
Here a workstation (10.20.4.31) connects out to an external host, is denied SSH to a management address, and then a switch configuration change is made from that same workstation's IP—a sequence that warrants investigation.
Server Logs
Server logs are generated by the operating system of servers: Windows Event Logs (System, Security, Application) and Linux logs in /var/log/ such as syslog or messages, auth.log or secure, and the systemd journal (read with journalctl). They record service starts and stops, crashes, scheduled task creation, software installation, and kernel messages. Web servers, mail servers, and database servers add their own service logs.
Application Logs
Application logs are written by individual applications: web server access and error logs (Apache, Nginx, IIS), database logs, ERP and CRM audit trails, and custom application logs. They reveal attacks against the application layer that network devices cannot see, such as SQL injection attempts, directory traversal, and abuse of business logic.
198.51.100.23 - - [14/Sep/2026:22:11:05 -0400] "GET /products.php?id=1%27%20OR %20%271%27=%271 HTTP/1.1" 200 48211 "-" "sqlmap/1.8"
198.51.100.23 - - [14/Sep/2026:22:11:07 -0400] "GET /products.php?id=1%20UNION%20SELECT %20username,password%20FROM%20users-- HTTP/1.1" 200 51877 "-" "sqlmap/1.8"
198.51.100.23 - - [14/Sep/2026:22:11:30 -0400] "GET /../../../../etc/passwd HTTP/1.1" 404 312 "-" "sqlmap/1.8"
This web access log (combined log format: client IP, timestamp, request, status code, response size, referrer, user agent) shows URL-encoded SQL injection payloads (%27 is a single quote; UNION SELECT attempts to extract data) from an automated tool, identified by its user agent. The 200 status and larger response size on the UNION request suggest it may have succeeded. The final line is a directory traversal attempt that returned 404.
Authentication Logs
Authentication logs record login attempts, successes, failures, lockouts, MFA challenges, privilege elevation, and logoffs. Sources include Windows Security logs on domain controllers, Linux auth.log or secure, identity provider (IdP) sign-in logs such as Microsoft Entra ID or Okta, RADIUS servers, and VPN gateways. Authentication logs are central to detecting brute-force attacks, password spraying, credential stuffing, impossible travel, and use of stolen credentials.
Important Windows Security event IDs to recognize:
Event ID Meaning Investigation value
4624 Successful logon Logon type shows how (2 interactive, 3 network, 10 remote interactive/RDP)
4625 Failed logon Many failures = brute force; one failure across many accounts = spraying
4634 / 4647 Logoff Session duration
4648 Logon with explicit credentials Often seen with lateral movement (runas, PsExec) 4672 Special privileges assigned Administrative logon
4720 User account created Attacker persistence
4728 / 4732 Member added to a security group
- Privilege escalation
- 4740 Account locked out Brute force or misconfigured service
- 1102 Audit log cleared Strong indicator of anti-forensics
Sep 15 02:14:51 web01 sshd[22817]: Failed password for invalid user oracle from 192.0.2.150 port 40112 ssh2
Sep 15 02:14:53 web01 sshd[22819]: Failed password for invalid user test from 192.0.2.150 port 40118 ssh2
Sep 15 02:14:55 web01 sshd[22821]: Failed password for root from 192.0.2.150 port 40126 ssh2
Sep 15 02:15:02 web01 sshd[22830]: Accepted password for deploy from 192.0.2.150 port 40140 ssh2
Sep 15 02:15:02 web01 sshd[22830]: pam_unix(sshd:session): session opened for user deploy by (uid=0)
This Linux auth.log excerpt shows a brute-force or dictionary attack from 192.0.2.150 against several usernames, followed by a successful login to the deploy account. The successful login is the critical event: the attacker now has a foothold.
Communication Logs
Communication logs record messaging and voice activity: email server and gateway logs (sender, recipients, subject, message ID, attachments, SPF/DKIM/DMARC results), instant messaging and collaboration platform logs (Teams, Slack), and VoIP call detail records (CDRs). They are vital for investigating phishing, business email compromise, and data exfiltration by email, and they are frequent targets of e-discovery requests. Email message trace tools let administrators find every recipient of a malicious message so it can be purged.
Audit Logs
Audit logs (audit trails) record security-relevant actions for accountability and compliance: changes to permissions, policies, and configurations; creation and deletion of accounts; access to sensitive records; and administrative actions. Examples include Linux auditd logs, Windows advanced audit policy events, database audit logs, and cloud control plane logs such as AWS CloudTrail, Azure Activity Log, and Google Cloud Audit Logs. Because audit logs establish who changed what, they support non-repudiation and must be protected from tampering—ideally by forwarding them immediately to a separate, write-restricted system. {"eventTime":"2026-09-15T03:02:44Z","eventName":"PutBucketPolicy","userIdentity":
{"type":"IAMUser","userName":"ci-deploy"},"sourceIPAddress":"192.0.2.150","requestParameters":{"bucketName":"cust-exports","policy":"{\"Statement\": [{\"Effect\":\"Allow\",\"Principal\":\"*\",\"Action\":\"s3:GetObject\"}]}"}} This CloudTrail-style audit event shows the ci-deploy identity, from the same IP seen in the SSH brute force, changing a storage bucket policy to allow public (Principal: *) read access—a likely data exposure.
Figure 21.1: Pivoting on a shared source IP links authentication and audit log entries into one attack story Endpoint Logs
Endpoint logs come from workstations, laptops, servers, and mobile devices, typically collected by EDR/XDR agents, host-based IDS/IPS, antivirus, host firewalls, and tools such as Microsoft Sysmon. They record process creation (with command lines and parent processes), file creation and modification, registry changes, network connections per process, USB device insertion, and script execution. Endpoint telemetry answers "what actually ran on this machine?"
EventID=1 ProcessCreate Time=2026-09-15T13:41:09Z Host=FIN-WS22 User=CORP\jlee ParentImage=C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE Image=C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine=powershell -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBi...
A Word document spawning hidden PowerShell with an encoded (-enc) command is a classic malicious macro pattern (Chapter 8 discusses such indicators).
Network Logs
Network logs record traffic and network services: firewall allow/deny logs, IDS/IPS alerts, proxy and secure web gateway logs (URLs visited, categories, users), DNS query logs, DHCP lease logs (which host had which IP at a given time), wireless controller logs, and load balancer logs. DNS logs reveal command-and-control domains, domain generation algorithm (DGA) activity, and DNS tunneling. DHCP logs are essential for mapping an IP address in another log back to a specific device.
Common trap
An IP address is not a person, and in DHCP environments it is not even a stable device. Before attributing activity, use DHCP logs to identify which MAC address held the IP at that moment, then asset inventory and authentication logs to identify the device and user.
Figure 21.2: Attributing activity requires walking from an IP address to a MAC address, a device, and finally a user Metadata
Metadata is data about data. It describes a file, message, or transaction without being its content:
- File metadata: author, creation and modification timestamps (MAC times: modified, accessed, changed/created), owner, size, and application-specific properties in Office documents and PDFs.
- Image metadata (EXIF): camera model, date taken, and sometimes GPS coordinates.
- Email metadata: headers showing the sending server, relays, timestamps, Message-ID, Return-Path, and authentication results.
- Network metadata: who communicated with whom, when, for how long, and how much data— exactly what NetFlow captures.
- Mobile and phone metadata: call times, numbers, durations, and cell tower locations. Metadata is smaller than content, easier to analyze at scale, and often available when content is encrypted. Email headers can reveal that a message "from the CEO" came from an external server that failed DMARC.
Log type Typical sources Key questions answered
Access/
accounting (logical, physical)
RADIUS accounting, file access, badge systems
Who accessed what, when, and where
Device Routers, switches, firewalls via syslog Config changes, device events, traffic decisions Server Windows Event Log, /var/log, journald Service and OS events
Application Web, database, ERP logs Application-layer attacks and misuse Authentication Domain controllers, IdP, auth.log Logins, failures, MFA, lockouts Communicatio
n
Email, chat, VoIP CDRs Phishing, BEC, exfiltration by message
Audit auditd, CloudTrail, database audit Who changed configurations and permissions Endpoint EDR, Sysmon, AV Processes, files, registry, per-process connections Network Firewall, proxy, DNS, DHCP, IDS Traffic flows, destinations, domains Metadata File properties, headers, EXIF Context without content
Data Sources
Beyond logs, investigators draw on several other data sources.
Vulnerability Scans
Vulnerability scan results (Chapter 16) show which weaknesses existed on a system at a given time. In an investigation they help establish the likely attack vector: if the compromised web server had an unpatched remote code execution vulnerability flagged three weeks earlier, that is the prime candidate for initial access. Scan history also helps scope an incident—which other hosts share the same vulnerability and may also be compromised?
Automated Reports
Automated reports are scheduled outputs from security and IT systems: daily SIEM summaries, weekly patch compliance reports, EDR threat reports, DLP incident reports, access review exports, and cloud security posture reports. They provide baselines and history; a spike in DLP events before an employee resigned can be key evidence.
NetFlow and IPFIX
NetFlow (originally Cisco) and IPFIX (IP Flow Information Export, the IETF standard based on NetFlow v9, RFC 7011) record flow metadata rather than full packets. A flow record summarizes a conversation: source and destination IP, source and destination port, protocol, start and end time, bytes and packets transferred, and TCP flags. sFlow is a related, sampling-based technology.
Start Dur Proto Src IP:Port Dst IP:Port Packets Bytes
2026-09-15 03:10:02 1843s TCP 10.20.4.31:50112 -> 203.0.113.77:443 412,880
4.1 G
2026-09-15 03:10:05 2s UDP 10.20.4.31:61001 -> 10.0.0.53:53 2 164
Flow data is compact enough to keep for months, works when traffic is encrypted, and is ideal for spotting large outbound transfers, beaconing patterns, lateral movement, and connections to known-bad IPs. The record above shows 4.1 GB sent from an internal workstation to an external host over a half-hour session—a probable exfiltration event. What flow data cannot show is what was in those 4.1 GB; for that you need packet capture or endpoint evidence.
Surveillance Footage
Surveillance footage from CCTV and video management systems provides evidence of physical activity: who entered a data center, whether someone tailgated, who removed equipment, or who was at a workstation when a suspicious action occurred. Footage is often overwritten within days or weeks, so preserve it quickly, and check its clock against a reference.
Security Tools
Security tools generate their own evidence: SIEM correlated alerts and stored events, EDR/XDR telemetry and investigation timelines, IDS/IPS alerts with matching signatures, DLP alerts with matched content, email security quarantine records, web application firewall logs, CASB activity, and vulnerability management history.
Dashboards
Dashboards present aggregated, visual summaries of data in real time: alert counts by severity, top talkers, authentication failures over time, geographic login maps, and compliance status. Dashboards are excellent for spotting anomalies quickly—a sudden spike in outbound traffic or failed logins—and for communicating status to management during an incident. They are a starting point, not evidence in themselves: the analyst drills down from the dashboard into the underlying logs.
Packet Captures
A packet capture (PCAP) records complete network packets, including headers and payloads, using tools such as Wireshark, tcpdump, or network taps and full-packet-capture appliances. Packet captures provide the most detailed network evidence available: you can reconstruct sessions, extract transferred files, see exact commands sent in clear-text protocols, and analyze malware C2 communications. tcpdump -i eth0 -nn -w /cases/IR-2291/ws22.pcap host 10.20.4.31
tcpdump -nn -r /cases/IR-2291/ws22.pcap 'tcp port 80 and host 203.0.113.77'
Trade-offs: full packet capture consumes enormous storage, so it is typically retained only briefly or captured on demand; encrypted traffic (TLS) hides payloads unless decrypted at a proxy; and captures may contain sensitive personal data requiring careful handling.
Figure 21.3: NetFlow keeps one metadata record per conversation, while a packet capture keeps every packet including its payload
Data source Strength Limitation
Vulnerability scans
Identify likely attack vector and similar exposed hosts Point-in-time; not evidence of exploitation
Automated reports
Historical baselines and trends Summary level
NetFlow/IPFIX Long retention, works with encryption, shows volume and destinations
No payload content
Surveillance footage
Physical identity and actions Short retention, clock drift, coverage gaps
Security tools Correlated, enriched alerts and telemetry Only what the tool was configured to see Dashboards Fast anomaly spotting and status communication Aggregated; must drill down for evidence Packet captures Full content, session reconstruction Storage-heavy, encryption hides payloads
Memory aid
NetFlow is the phone bill (who called whom, when, for how long). A packet capture is the call recording (exactly what was said).
File and Log Integrity
Evidence is worthless if you cannot prove it has not been altered. Attackers routinely tamper with logs to hide their activity—clearing the Windows Security log (event 1102), deleting lines from auth.log, or timestomping files to change their timestamps. Investigators must be able to demonstrate both that logs are complete and unaltered and that evidence files are identical to what was collected. Techniques for ensuring integrity include:
- Hashing: calculate a cryptographic hash (SHA-256) of each evidence file or image at acquisition and record it on the chain of custody form. Recalculating the hash later and getting the same value proves the file has not changed. MD5 and SHA-1 are still seen in forensic tools for compatibility but are not collision resistant; use SHA-256 for new work.
- Centralized, forwarded logging: sending logs in near real time to a SIEM or log server that the source host's administrators cannot modify. An attacker who clears local logs cannot erase copies already forwarded.
- Write once, read many (WORM) storage and immutable storage (such as object lock in cloud storage) for log archives and evidence.
- Log signing and hash chaining: some systems (for example, journald's Forward Secure Sealing and many SIEMs) cryptographically seal log entries so that modification or deletion is detectable.
- File integrity monitoring (FIM): tools that baseline hashes of critical system files and alert when they change.
- Write blockers: hardware or software devices that allow reading from a drive while preventing any writes, ensuring acquisition does not alter the original.
- $ sha256sum /cases/IR-2291/fin-ws22.dd
- 9f2c4e1a7b...e83d0a /cases/IR-2291/fin-ws22.dd
- $ sha256sum -c fin-ws22.dd.sha256
- /cases/IR-2291/fin-ws22.dd: OK
Exam tip
Gaps in logs are evidence too. A missing hour of logs on a compromised server, a Windows event 1102 (log cleared), or a log file that is suddenly much smaller than usual all indicate anti-forensic activity. If a question describes missing log entries on the host but complete entries in the SIEM, the answer usually involves centralized log forwarding as the control that preserved the evidence.
System Images
When investigators need to examine a system in depth, they acquire an image—a forensic copy of its memory or storage. Acquisition must follow the order of volatility.
Order of Volatility
The order of volatility, described in RFC 3227 (Guidelines for Evidence Collection and Archiving), directs investigators to collect the most volatile (shortest-lived) evidence first, because it disappears when a system is powered off, rebooted, or simply continues running.
Order Evidence Why it is volatile
1 CPU registers and cache Changes in nanoseconds
2 Routing table, ARP cache, process table, kernel statistics, memory (RAM)
Lost at power-off; changes constantly
3 Temporary file systems and swap/page files Overwritten during normal operation 4 Disk (persistent storage) Survives power-off but changes as the system runs
5 Remote logging and monitoring data Retained by other systems, subject to rotation 6 Physical configuration and network topology Changes slowly
7 Archival media and backups Designed for long-term retention
In practice, investigators cannot capture CPU registers directly, so the first realistic step on a live system is capturing memory and the current network and process state.
Memory aid
"Really Mad Spies Don't Leave Any Backups"—Registers/cache, Memory (and network/process state), Swap/temp, Disk, Logs (remote), Archive/topology, Backups.
Memory Dump
A memory dump (memory image) captures the contents of RAM from a running system. Memory contains evidence that never touches disk: running processes and their command lines, loaded DLLs and drivers, network connections, open files and handles, encryption keys, passwords and tokens, clipboard contents, and fileless malware that runs only in memory. Tools include WinPmem, Magnet RAM Capture, DumpIt, LiME for Linux, and EDR live-response features. Analysis is commonly done with Volatility.
Memory must be captured before shutting down or rebooting. The act of capturing memory alters it slightly (the tool must load into memory), which is accepted and documented. Windows also produces crash dumps and stores hibernation (hiberfil.sys) and page files (pagefile.sys) on disk, which can contain older memory contents.
Bit-Level Copy
A bit-level copy (bit-by-bit or bit-stream image, also called a forensic image) is an exact, sector-by-sector duplicate of an entire storage device, including deleted files, unallocated space, slack space, and partition structures. A normal file copy captures only active files and changes their access times; a bit-level copy captures everything and alters nothing when made through a write blocker. dc3dd if=/dev/sdb of=/cases/IR-2291/fin-ws22.dd hash=sha256 log=/cases/IR-2291/acq.log dd if=/dev/sdb of=/cases/IR-2291/fin-ws22.dd bs=4M conv=noerror,sync status=progress Formats include raw (.dd), EnCase Evidence File (.E01, which embeds hashes and case metadata), and AFF4. Tools include FTK Imager, dd/dc3dd/dcfldd, and Guymager. Investigators hash the source and the image and confirm they match, then analyze only a working copy, never the original.
Figure 21.4: A bit-level image is taken through a write blocker and verified by matching SHA-256 hashes before only a working copy is analyzed
Snapshot
A snapshot captures the state of a virtual machine, cloud instance, storage volume, or file system at a point in time. Hypervisor snapshots can include VM memory and disk state; cloud snapshots (such as an AWS EBS or Azure managed disk snapshot) copy a volume without stopping the instance. Snapshots are fast, non-disruptive, and ideal for cloud and virtualized environments where you cannot physically remove a drive. The snapshot can be attached to an isolated forensic instance for analysis. Caveats: a snapshot is not necessarily equivalent to a bit-level forensic image, it may sit in the same account the attacker controls (copy it to a separate forensic account), and its integrity should still be documented.
Method Captures Best for Key caution
Memory dump
RAM: processes, connections, keys, fileless malware
Live systems, before shutdown
Must happen first; lost at power-off
Bit-level copy
Entire disk including deleted and unallocated space
Physical drives, legal-grade evidenceUse a write blocker; verify hashes
Method Captures Best for Key caution
Snapshot Point-in-time VM, volume, or cloud disk state
Virtual and cloud workloads
Move to an isolated account; document integrity
Real-world scenario
A cloud-hosted Linux server shows signs of a cryptominer and an unknown reverse shell. The responder uses the cloud provider's tools to isolate the instance with a restrictive security group, captures memory with LiME through the EDR live-response console, takes snapshots of the attached volumes, and copies the snapshots to a dedicated forensic account with restricted access. SHA-256 hashes of the memory image are recorded with the chain of custody. Only then is the instance terminated and rebuilt.
Stakeholders
Investigations often involve parts of the business beyond the security team. The objective names three.
- Human resources (HR): involved whenever an employee is a suspect, a witness, or a victim. HR ensures that personnel investigations follow policy and employment law, coordinates interviews, handles discipline or termination, and helps time account disablement with a termination meeting so a departing insider gets no warning.
- Accounts (finance and accounting): involved in fraud, business email compromise, invoice manipulation, payroll diversion, and ransomware payment questions. Accounts staff provide transaction records, quantify financial loss, and work with banks to recall funds; in a BEC case, accounts payable records and the bank-detail change request are central evidence.
- Legal: advises on evidence handling and admissibility, privilege (many organizations route investigations through counsel so findings are protected by attorney-client privilege), privacy laws that limit what monitoring data may be reviewed, legal holds and e-discovery, law enforcement involvement, and notification obligations (Chapter 20).
Note
Investigating an employee's activity requires authority. A security analyst should not independently open an executive's mailbox or covertly monitor a coworker. Investigations of personnel should be authorized through policy and conducted with HR and legal involvement, which protects the organization and preserves the usability of the findings.
Log-Parsing Techniques
Real investigations involve millions of log lines. Analysts must filter, extract, count, and correlate efficiently. SIEMs provide query languages (such as Splunk SPL, Microsoft KQL, and Elastic's query language), but every analyst should be comfortable with basic command-line parsing because evidence often arrives as raw files.
Searching with grep
grep searches text for lines matching a pattern. It is the first tool most analysts reach for. grep "Failed password" /var/log/auth.log # all failed SSH logins
grep -i "invalid user" /var/log/auth.log | wc -l # count, case-insensitive grep -v "200 " access.log # lines NOT containing "200 "
(non-success)
grep -E "UNION|SELECT|%27|\.\./" access.log # extended regex: SQLi and traversal patterns
grep -r "203.0.113.77" /var/log/ # recursive search across all
logs
zgrep "192.0.2.150" /var/log/auth.log.*.gz # search rotated, compressed logs
Extracting Fields with awk and cut
awk splits each line into fields (by whitespace by default; $1 is the first field) and can filter and compute. cut extracts columns by delimiter.
# Top source IPs in a web access log (field 1 = client IP)
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head
# Count failed SSH attempts per source IP ("from" is followed by the IP)
grep "Failed password" auth.log | awk '{for(i=1;i<=NF;i++) if($i=="from") print $ (i+1)}' | sort | uniq -c | sort -rn
# Show requests that returned HTTP 500 (field 9 = status in combined log format)
- awk '$9 == 500 {print $4, $1, $7}' access.log
- # Extract the 3rd comma-separated column from a CSV export
- cut -d',' -f3 firewall_export.csv | sort -u
The pipeline sort | uniq -c | sort -rn is worth memorizing: it counts occurrences of each unique value and lists the most frequent first, instantly revealing the noisiest IP addresses, usernames, or URLs.
Parsing JSON with jq
Cloud and modern application logs are usually JSON. jq filters and reshapes JSON from the command line.
- # Pretty-print and select events of one type
- jq 'select(.eventName == "PutBucketPolicy")' cloudtrail.json
- # Extract specific fields as tab-separated output
jq -r '[.eventTime, .userIdentity.userName, .sourceIPAddress, .eventName] | @tsv' cloudtrail.json
# Count events by source IP
jq -r '.sourceIPAddress' cloudtrail.json | sort | uniq -c | sort -rn
(These examples assume one JSON object per line; for a file containing a Records array, prefix the filter with .Records[] |.)
Windows and Other Tools
On Windows, PowerShell's Get-WinEvent and Select-String fill the same role:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 500 | Group-Object { $_.Properties[19].Value } | Sort-Object Count -Descending Select-String -Path C:\inetpub\logs\LogFiles\W3SVC1\*.log -Pattern "UNION SELECT"
The first command groups recent failed logons (4625) by source network address, and the second searches IIS logs for a SQL injection string. Other useful tools include head, tail -f (follow a log live), sed (stream editing), less, journalctl -u sshd --since "2026-09-15", and Wireshark display filters such as ip.addr == 203.0.113.77 && http.request.
Regular Expressions and Correlation
Regular expressions describe text patterns and power grep, SIEM queries, and log parsers. Analysts commonly write patterns for IPv4 addresses (\b([0-9]{1,3}\.){3}[0-9]{1,3}\b), email addresses, usernames, and encoded payloads.
Effective log parsing follows a repeatable method:
- 1. Normalize time zones and formats so events from different systems line up.
- 2. Filter to the relevant time window, hosts, users, and event types.
- 3. Aggregate (count, group, sort) to find outliers.
- 4. Pivot from one indicator to related data—from an attacker IP to the accounts it touched, then to those accounts' activity on other systems.
- 5. Build a timeline of confirmed events that tells the story of the incident from initial access to impact.
An analyst investigating a suspected compromise of web01 runs grep "Accepted" /var/log/auth.log and finds a login to the deploy account from 192.0.2.150. A pivot with grep -r 192.0.2.150 /var/log/ shows the same IP in the web access log performing SQL injection an hour earlier. Running jq against exported CloudTrail logs shows the ci-deploy access key—stored in a configuration file on web01—used from the same IP to make a storage bucket public. NetFlow then shows 4.1 GB leaving to an external host. Correlating four sources by IP and time produced a complete attack timeline.
Chapter Summary
- Investigations answer who, what, when, where, how, and why by correlating multiple sources using synchronized time, hosts, users, and IP addresses.
- Log types: access and accounting (logical and physical), device, server, application, authentication, communication, audit, endpoint, network, and metadata. Each answers different questions.
- Recognize key Windows event IDs (4624, 4625, 4720, 4732, 4740, 1102) and common Linux auth.log and web access log patterns.
- Data sources include vulnerability scans, automated reports, NetFlow/IPFIX (flow metadata, no payload), surveillance footage, security tools, dashboards, and packet captures (full content).
- File and log integrity relies on hashing (SHA-256), centralized log forwarding, WORM/immutable storage, log sealing, FIM, and write blockers. Missing logs indicate anti-forensics.
- Collect evidence in the order of volatility (RFC 3227): registers/cache, memory and network state, swap/temp, disk, remote logs, topology, archives.
- System images: memory dumps (capture before shutdown), bit-level copies (entire disk via write blocker), and snapshots (VMs and cloud volumes).
- Stakeholders: HR for personnel matters, accounts for financial fraud and loss, legal for evidence, privilege, privacy, and notification.
- Log parsing uses grep, awk, cut, sort, uniq, jq, PowerShell, regular expressions, and SIEM queries to filter, aggregate, pivot, and build timelines.
Key Terms
Log; trace; correlation; NTP; logical access log; physical access log; RADIUS accounting; device log; syslog; server log; application log; combined log format; authentication log; Windows event ID; communication log; call detail record; audit log; CloudTrail; endpoint log; Sysmon; network log; DNS log; DHCP log; metadata; EXIF; MAC times; vulnerability scan; automated report; NetFlow; IPFIX; flow record; surveillance footage; dashboard; packet capture; tcpdump; Wireshark; file integrity; hashing; SHA-256; WORM storage; write blocker; file integrity monitoring; anti-forensics; timestomping; order of volatility; RFC 3227; memory dump; Volatility; bit-level copy; forensic image; E01; snapshot; stakeholders; human resources; accounts; legal; attorney-client privilege; log parsing; grep; awk; cut; jq; regular expression; timeline.
Review Questions
- 1. An analyst needs to determine how much data a compromised workstation sent to an external IP address over the past 60 days. Full packet capture is retained for only 48 hours. Which data source BEST meets this need?
- A. Packet capture
- B. NetFlow/IPFIX records
- C. Vulnerability scan results
- D. Application logs
- 2. A security team responds to a server suspected of running fileless malware. The server is still powered on. What should the team collect FIRST?
- A. A bit-level copy of the hard drive
- B. Archived backups
- C. A memory dump
- D. Remote syslog data
- 3. Review the following log excerpt:
Sep 15 02:14:51 web01 sshd[22817]: Failed password for invalid user oracle from 192.0.2.150 port 40112 ssh2
Sep 15 02:14:55 web01 sshd[22821]: Failed password for root from 192.0.2.150 port 40126 ssh2
Sep 15 02:15:02 web01 sshd[22830]: Accepted password for deploy from 192.0.2.150 port 40140 ssh2
Which conclusion is BEST supported by this log?
- A. A password spraying attack failed against all accounts
- B. A brute-force attack led to a successful login to the deploy account
- C. The root account was successfully compromised
- D. The server was the source of an outbound attack
- 4. An employee's badge shows entry to the Toronto office at 8:55 a.m. At 9:10 a.m., the employee's account logs in to the VPN from an IP address in another country. Which TWO data sources were correlated to detect this anomaly? (Select TWO.)
- A. Physical access logs
- B. Vulnerability scans
- C. Authentication logs
- D. Packet captures
- E. Dashboards
- 5. An investigator wants to prove that a disk image presented in court is identical to the drive seized six months earlier. Which action provides this proof?
- A. Showing the chain of custody form
- B. Comparing SHA-256 hashes calculated at acquisition and now
- C. Displaying the file system metadata
- D. Taking a snapshot of the image
- 6. A Windows server's local Security log contains event ID 1102, and no events are present for the preceding two hours. However, the SIEM contains all events for that period. Which TWO conclusions are MOST accurate? (Select TWO.)
- A. The audit log was cleared, indicating possible anti-forensics
- B. The SIEM is malfunctioning and duplicating events
- C. Centralized log forwarding preserved the evidence
- D. The server's NTP configuration is incorrect
- E. A memory dump is no longer possible
- 7. An analyst wants to list the source IP addresses in a web server access log ordered by number of requests. Which command BEST accomplishes this?
- A. grep -v "200" access.log
- B. awk '{print $1}' access.log | sort | uniq -c | sort -rn
- C. jq '.sourceIPAddress' access.log
- D. tail -f access.log
- 8. A company's cloud-hosted virtual machine is suspected of compromise. The team needs to preserve the disk state quickly without physically accessing hardware. Which method is MOST appropriate?
- A. Bit-level copy using a hardware write blocker
- B. Volume snapshot copied to an isolated forensic account
- C. Reviewing surveillance footage
- D. Running a vulnerability scan
- 9. An accounts payable clerk paid a fraudulent invoice after receiving an email that appeared to come from a known supplier. Which stakeholders should be involved in the investigation? (Select TWO.)
- A. Accounts (finance)
- B. Marketing
- C. Legal
- D. Facilities
- E. Software development
- 10. Which log type would BEST show that a Microsoft Word process launched PowerShell with an encoded command on a user's workstation?
- A. Network logs
- B. Endpoint logs
- C. Communication logs
- D. Physical access logs
- 11. An analyst sees the IP address 10.20.4.31 in a firewall log associated with suspicious outbound traffic from three days ago. The network uses dynamic addressing. Which data source should the analyst consult to identify the device?
- A. DHCP logs
- B. Vulnerability scans
- C. Dashboards
- D. EXIF metadata
- 12. A cloud audit log is delivered as one JSON object per line. An analyst needs to extract the event time, user name, and source IP for every event. Which tool is BEST suited?
- A. tcpdump
- B. jq
- C. dd
- D. Volatility
Answers and Explanations
- 1. B. NetFlow/IPFIX records summarize flows (source, destination, bytes, duration) and are compact enough to retain for months, so they can show 60 days of transfer volumes. The packet captures expired after 48 hours. Vulnerability scans show weaknesses, not traffic, and application logs do not record network volumes to arbitrary destinations.
- 2. C. Fileless malware exists in memory, and memory is the most volatile evidence that can practically be collected. Imaging the disk, retrieving backups, or pulling remote logs can wait; the memory contents would be lost if the system were shut down.
- 3. B. Repeated failures against multiple usernames from one IP followed by an accepted password for deploy shows a brute-force or dictionary attack that succeeded. Spraying would use one password across many accounts and the attack did not fail. Root failed to authenticate. The server is the target, not the source.
- 4. A, C. Badge data (physical access logs) places the employee in Toronto, and VPN authentication logs show a simultaneous login from abroad. Vulnerability scans and packet captures are not needed, and a dashboard might display the alert but is not the underlying evidence.
- 5. B. Matching hashes from acquisition and the present prove the image has not changed. Chain of custody documents who handled the evidence but does not by itself prove the content is unaltered. Metadata can be changed, and a snapshot creates a new copy rather than proving integrity.
- 6. A, C. Event 1102 means the Security log was cleared, a common anti-forensic action. Because logs had already been forwarded to the SIEM, the evidence survived. There is no indication of SIEM malfunction or NTP problems, and memory can still be captured from a running server.
- 7. B. Printing field 1 (client IP), sorting, counting unique values, and sorting numerically in reverse produces IPs ordered by request count. grep -v only filters lines, jq parses JSON rather than web access logs, and tail -f follows new lines.
- 8. B. Cloud volume snapshots preserve disk state quickly without hardware access; copying them to a separate, locked-down account protects them from the attacker. A hardware write blocker requires physical access. Surveillance footage and vulnerability scans do not preserve disk state.
- 9. A, C. Accounts staff provide payment records, quantify loss, and work with banks to recall funds; legal advises on evidence, liability, insurance, and law enforcement. Marketing, facilities, and software development have no central role in a BEC fraud investigation.
- 10. B. Endpoint logs from EDR or Sysmon record process creation with parent processes and command lines. Network logs show traffic, communication logs show email and messaging, and physical access logs show door events.
- 11. A. DHCP logs map an IP address to the MAC address and hostname that held the lease at a specific time. Vulnerability scans are periodic and may not match the time, dashboards summarize data, and EXIF is image metadata.
- 12. B. jq parses and extracts fields from JSON. tcpdump captures packets, dd creates bit-level copies, and Volatility analyzes memory images.
- P A R T 5
- Part 5: Security Program Management and
- Oversight
- Domain 5.0 — 14% of the exam
This part steps back from technology to the management of security as a business function: the governance documents that direct a security program, the risk management processes that decide where to spend effort, the assessment of third parties and vendors, the elements of compliance and privacy, the audits and assessments that verify controls, and the awareness programs that shape how people behave.