Unit 4: Linux and Network Forensics

I. Foundations of Linux and Network Forensics

Digital forensics is the identification, preservation, examination, analysis, and reporting of digital evidence while maintaining its integrity and evidential context. Linux and network forensics combine host artifacts—files, memory, processes, and logs—with network artifacts such as packets, flows, and connection records.

• Governing principle: Evidence must be acquired and analyzed through repeatable, documented methods that minimize alteration.
• Order of volatility: Collect short-lived evidence before persistent evidence; network connections and RAM normally disappear sooner than disk contents.
• Integrity: Calculate cryptographic hashes such as SHA-256 before and after transfer or examination.
• Chain of custody: Record who collected, possessed, transferred, analyzed, and stored each item, with dates, times, and purposes.
• Forensic soundness: Use write blockers for offline media, work from verified copies, preserve originals, and document unavoidable live-system changes.
• Time normalization: Record the system time, time zone, clock drift, and daylight-saving status; correlate events using a common standard such as UTC.
• Evidence correlation: A defensible conclusion normally combines independent sources—for example, an SSH log entry, a shell-history command, and a corresponding network flow.

II. Linux Data Acquisition — Evidence According to Persistence

A. Volatile and Non-volatile Data in Linux

Volatile data describes the current operating state that is lost or changed at shutdown, whereas non-volatile data persists on storage media.

1. Volatile data

   • Processes: /proc, ps, and pstree expose process IDs, parent-child relationships, command lines, and execution state.
   • Network state: ss -antup, interface configuration, ARP or neighbor tables, routing tables, and firewall state can reveal active communication.
   • Open resources: lsof associates processes with files, sockets, devices, and deleted-but-still-open files.
   • Memory contents: RAM may contain encryption keys, shell commands, injected code, credentials, and data never written to disk.
   • Collection order: Capture time, logged-in users, processes, network state, open files, and memory before powering down.

2. Non-volatile data

   • Persistent artifacts: File systems, logs, user accounts, cron jobs, systemd services, SSH keys, package records, and application databases survive reboot.
   • Important locations: /etc, /home, /var/log, /tmp, /boot, and /var/spool/cron commonly contain investigative evidence.
   • Acquisition: Create a bit-stream image rather than copying only visible files, because unallocated space and file-system metadata may be significant.

sha256sum disk.img > disk.img.sha256

• Interpretation caution: Live commands modify memory and may update logs or access times; every command and its output must therefore be documented.

III. Storage Examination — Reconstructing Linux File-System Activity

A. File System Image Analysis

File-system image analysis examines an acquired storage image without relying on the potentially compromised operating system installed on it.

• Image types: A raw image preserves sectors directly, while formats such as E01 can store metadata, compression, and segmented evidence.
• Partition analysis: Investigators identify partition tables, offsets, logical volumes, software RAID, and encryption before mounting a file system.
• Linux structures: In ext4, inodes contain metadata and pointers to data extents; directory entries map filenames to inode numbers.
• Key timestamps:
  • mtime: Time file content was modified.
  • ctime: Time inode metadata changed; it is not generally “creation time.”
  • atime: Time content was accessed, subject to mount options such as relatime.
  • crtime/btime: Birth time where supported and recorded.
• Deleted evidence: Deletion normally removes directory references and marks storage reusable; inode metadata or file content may remain until overwritten.
• Analysis methods: Timeline generation, metadata review, keyword search, hash-set comparison, file carving, and examination of unallocated and slack space expose hidden or deleted activity.
• Safe mounting: Prefer forensic tools or read-only mounting and avoid journal replay, which may alter the evidence image.
• Limitation: Full-disk encryption may prevent meaningful analysis unless keys, recovery material, or an unlocked live system are available.

IV. Linux RAM Examination — Recovering Runtime State

A. Memory Forensics

Memory forensics analyzes a captured RAM image to reconstruct processes, kernel activity, network state, and transient data present at acquisition time.

• Acquisition: Kernel modules or specialized agents can capture physical memory, but loading them changes system state and must be recorded.
• Frameworks: Volatility 3 and similar tools interpret Linux memory using matching kernel symbols and structural information.
• Process analysis: Investigators compare linked process lists with scanning results to detect hidden processes, unusual parentage, or terminated remnants.
• Executable evidence: Process mappings may reveal injected libraries, anonymous executable regions, altered code, or malware unpacked only in memory.
• Network evidence: Socket structures can identify local and remote addresses even when disk logs are absent or manipulated.
• Credential evidence: Command history, environment variables, clipboard data, tokens, and cryptographic material may appear in process address spaces.
• Kernel investigation: Modules, system-call structures, and hooks are checked for rootkit behavior or unauthorized modification.
• Limitations: Memory is a time-specific snapshot; unsupported kernels, symbol mismatches, corruption, and acquisition delay can reduce reliability.

V. Network Evidence — Observing Communication Between Systems

A. Network Forensics

Network forensics is the capture, preservation, and analysis of communications to determine what systems exchanged, when they communicated, and what the exchange contained.

• Evidence forms:
  • Packet capture: PCAP records packet headers and, where collected, payload bytes.
  • Flow records: NetFlow/IPFIX summarizes source, destination, ports, protocol, byte count, and duration without full payloads.
  • Device telemetry: DNS, DHCP, VPN, proxy, firewall, router, IDS/IPS, and wireless-controller logs provide contextual records.
• Layered analysis: Ethernet addresses identify local interfaces; IP addresses identify routed endpoints; TCP/UDP ports suggest services; application protocols reveal user-level activity.
• TCP reconstruction: Sequence numbers permit session reassembly, while SYN, SYN-ACK, and ACK indicate a normal three-way handshake.
• Visibility constraints: Encryption hides content but leaves metadata such as endpoints, timing, volume, TLS versions, and certificate details.
• Evidential caution: An IP address identifies an observed network endpoint, not automatically a person; NAT, DHCP, VPNs, and compromised hosts require attribution evidence.

VI. Audit Trails — Creation, Meaning, and Preservation

A. Logging Fundamentals

Logging records security-relevant events so that investigators can reconstruct system and network activity after an incident.

• Linux facilities: systemd-journald, syslog implementations, kernel messages, and Linux Audit generate records with differing formats and retention policies.
• Common sources: Authentication events, sudo use, SSH sessions, service starts, package changes, cron execution, firewall decisions, and application errors.
• Typical locations: /var/log/auth.log or /var/log/secure, /var/log/syslog or /var/log/messages, and the journal queried through journalctl.
• Essential fields: Timestamp, hostname, process, process ID, user or account, source address, event action, and result support correlation.
• Audit rules: auditd can record system calls and access to sensitive files, including actor identity and success or failure.
• Centralization: Forwarding logs to a protected remote collector prevents one compromised host from becoming the only evidence source.
• Reliability issues: Rotation, storage limits, inconsistent formats, clock drift, disabled logging, and attacker deletion can create gaps; absence of a log is not proof that an event did not occur.

VII. Preparedness — Designing Networks for Investigation

A. Network Forensic Readiness

Network forensic readiness is the planned capability to collect useful evidence efficiently before an incident occurs.

• Requirements analysis: Identify likely incidents, legal obligations, valuable assets, expected evidence, and required retention periods.
• Collection architecture: Place taps or SPAN ports at meaningful boundaries and collect firewall, DNS, DHCP, VPN, proxy, endpoint, and identity logs centrally.
• Time synchronization: Use authenticated, monitored NTP sources and record clock offsets so events from separate devices can be aligned.
• Retention strategy: Balance evidential value against storage cost and privacy; full packets require substantially more space than flow metadata.
• Evidence security: Apply access control, encryption, immutable or append-only storage, integrity checks, and audit trails for log access.
• Operational preparation: Maintain response procedures, collection tools, trained personnel, escalation paths, and tested chain-of-custody forms.
• Validation: Periodically generate known events—such as a test VPN login—and confirm that every expected sensor records them accurately.

VIII. Multi-source Reconstruction — Linking Related Events

A. Event Correlation Concepts

Event correlation links records that share time, identity, system, or behavior so that isolated observations become a coherent incident sequence.

• Normalization: Convert different vendor formats into common fields such as timestamp, source_ip, destination_ip, user, and action.
• Temporal correlation: Events occurring within a defined window may be related; clock drift and delayed ingestion must be considered.
• Attribute correlation: Shared usernames, IP addresses, hostnames, session IDs, process hashes, or TLS certificates can connect records.
• Rule correlation: A detection rule can combine ordered conditions, such as repeated SSH failures followed by one success and then privileged execution.
• Baseline correlation: Current behavior is compared with normal patterns—for example, a server making its first outbound connection to a rare country.
• Causation caution: Close timing establishes association, not necessarily cause; corroboration from independent evidence is required.
• Example sequence: VPN authentication at 02:10 UTC, an internal SSH connection at 02:12, and a large proxy upload at 02:20 may describe lateral movement and exfiltration when user and address fields align.

IX. Detectable Adversary Artifacts — Evidence of Compromise

A. Indicators of Compromise (IoCs) from Network Logs

Network-log IoCs are observable artifacts or patterns that suggest malicious activity and guide detection, scoping, and threat hunting.

• Atomic indicators: Malicious IP addresses, domain names, URLs, file hashes, email addresses, and certificate fingerprints are directly searchable.
• Behavioral indicators: Periodic beaconing, domain-generation patterns, unusual DNS tunneling, repeated authentication failures, port scanning, and abnormal outbound volume describe attacker behavior.
• DNS evidence: Rare domains, newly observed subdomains, high query entropy, or unusually long TXT queries may indicate command-and-control traffic.
• Proxy and TLS evidence: Suspicious user agents, direct IP connections, uncommon destinations, certificate anomalies, and repeated fixed-size sessions can expose malware.
• Firewall evidence: Denied probes across many ports suggest reconnaissance; an unexpected allowed connection from a database server may be more significant.
• Context and confidence: Shared hosting, cloud services, scanners, and content-delivery networks can create false positives; indicators require timestamps, source reliability, and environmental context.
• Lifecycle: IoCs age quickly because attackers change infrastructure; validated indicators should be versioned, reviewed, and retired when no longer useful.

X. Packet and Flow Examination — Conducting the Investigation

A. Network Traffic Investigation

Network traffic investigation systematically scopes suspicious communication, reconstructs sessions, extracts evidence, and correlates findings with host activity.

• Preservation: Copy PCAP or flow data to controlled storage, record capture location and filter settings, and calculate a SHA-256 hash.
• Scoping: Define the incident period, relevant hosts, subnets, protocols, and known IoCs before applying filters.
• Filtering: Wireshark display filters narrow evidence without changing the original capture.

ip.addr == 192.0.2.25 && tcp.port == 443

• Conversation analysis: Rank endpoints by packets, bytes, duration, frequency, and first-seen time to identify scanning, beaconing, or bulk transfer.
• Protocol validation: Confirm actual protocol behavior rather than trusting port numbers; malware may carry non-HTTP traffic over TCP port 80.
• Session reconstruction: Reassemble TCP streams, extract transferred objects where lawful and possible, and hash recovered files for malware comparison.
• Encrypted traffic: Examine DNS lookups, server names where visible, certificates, packet sizes, timing, and flow direction when payload decryption is unavailable.
• Correlation: Match network timestamps with DHCP leases, VPN records, endpoint processes, authentication logs, and file creation times.
• Reporting: Separate observed facts from interpretation and document filters, tools, time zones, hashes, affected systems, communication paths, and analytical limitations.