15. Analysis and correlation

21. Analysis

Other analysis techniques

Filesystem analysis, carving, reconstruction and the detection of hidden data are covered in sections 17 to 20. Two further techniques bear on what must be preserved on site and how findings are assembled.

Memory forensics

Examining a memory capture with a framework such as Volatility for running and hidden processes, their command lines and loaded modules, open network connections, injected code, decrypted data, encryption keys (section 12), cached credentials and command history. The memory image is also the source for much of the volatile state listed in section 7. Every finding from memory is subject to the caveats there: the image reflects the moment of capture, includes the capture tool's footprint, and may be internally inconsistent. Findings that depend on a structure that was partially overwritten are reported at reduced confidence.

Timeline analysis

Combining timestamps from every source (filesystem, journals, logs, registry, browser history, email headers, EXIF, cloud audit logs, badge access records, the memory capture) into a single ordered sequence. This is where the sequence of events emerges and where reconstructed artefacts are placed among observed ones. A timeline is itself a derived artefact: each entry carries its source, and each source's clock offset (section 3) is applied and recorded. Entries drawn from reconstructed material are marked as such, so the reader can see which parts of the sequence rest on intact metadata and which on inference.

Example. A timeline shows an external drive connected at 19:07 (registry, observed fact), forty files accessed from its drive letter between 19:08 and 19:21 (link files, observed fact), the drive removed at 19:22 (event log, observed fact), and a JPEG reconstructed from unallocated space whose EXIF timestamp is 19:15 (derived artefact, strongly supported). The report shows the four entries with their labels rather than presenting them as a single seamless narrative.

22. Preservation, acquisition, analysis

Multi-device triage and cross-device correlation

Most examinations involve more than one device, and the difficult ones involve several encrypted devices found in different states. The order in which they are handled decides what evidence survives, and the correlation between them is usually where the answers are.

Triage order

1. Secure and document all devices before acquiring from any (sections 2 and 3). A device left unattended while another is imaged is a device someone else can touch.
2. Identify which systems are powered on and unlocked, and which of those are encrypted. These are the ones whose evidence is disappearing.
3. Prioritise volatile evidence from those systems, most fragile first: a laptop on battery before a desktop on mains; a machine with an idle-lock timer before one without; a machine with an unlocked container before one with only the system volume unlocked.
4. Acquire memory and encryption-related state from each, in that order (sections 7 and 13 to 15), before anything else runs on any of them.
5. Preserve mounted and decrypted volumes by logical or block-level acquisition from the live systems, where the volume may not be decryptable later.
6. Acquire forensic images of the storage of every device, powered-off devices included, in order of hardware condition and evidential value: failing media before healthy media, primary devices before peripherals.
7. Verify hashes of every acquisition before any device is released from the examiner's control or any image is moved.
8. Conduct rapid triage on verified working copies for evidentially significant material: keyword and hash searches, recent activity, encryption indicators, the artefact classes in section 6. The purpose is to direct effort, and triage results are hypotheses, not findings.
9. Perform deeper recovery, carving and reconstruction on the devices and regions triage points to (sections 17 to 20).
10. Correlate evidence across all devices (below), and validate the results (section 20) before reporting.

Priority between devices at any step is set by volatility; the likelihood of permanent loss (battery, idle lock, failing hardware, remote-wipe exposure); evidential value to the investigative questions; encryption state (an unlocked encrypted device outranks an unencrypted one, which can wait); hardware condition; the investigative objectives; and the time and people available. Write the order chosen and the reason for it into the notes at the time; a later reader should be able to see why the third laptop waited.

Cross-device correlation

Evidence on one device is tested against evidence on the others. Across Windows, Linux and macOS the useful points of contact are:

• Timestamps, normalised as below, for the same event seen from two sides: a file copied from one machine appears with a creation time on the other.
• User identities: account names, security identifiers, user IDs, email addresses and display names, which link activity on different systems to the same person, or show that they differ.
• Filenames and paths, including ones seen only in recent-items lists, link files, shell history or logs on a machine where the file itself is absent.
• Hashes: the same file on two devices is the strongest link available, and a hash set built from one device is searched against every other, including unallocated space and carved output.
• Network activity: addresses, host names, connection times and volumes in one machine's logs against the other's, and against firewall, proxy and DHCP records.
• Removable media: the same device serial number in the Windows registry, the Linux kernel log and journal, and the macOS Unified Log and preference files, with first and last connection times on each.
• Cloud services and synchronisation systems: the same account on several devices, sync client databases showing what was uploaded from where, and files present in the cloud export but on no device.
• Messaging and browser activity: the same conversation or session from both ends, and browser history that shows a download on one machine matching a file on another.
• SSH and file transfers: a client's known-hosts and connection logs against the server's authentication log; a key on one machine authorised on another; transfer tool logs at both ends.
• Shared encryption containers: the same container file, by hash or by header, on more than one device, or a container on one device whose passphrase is in the keychain or password manager of another.

Normalising timestamps

Each source stores time differently and the differences are large enough to reverse an apparent order of events. NTFS, the Windows event log and the registry store UTC; FAT stores local time with no zone and exFAT local time with an optional offset field; ext4 and XFS store UTC as seconds and nanoseconds since the epoch; APFS stores UTC in nanoseconds; the Unified Log displays local time by default but stores UTC; application databases vary, and some store local time in a field named as if it were UTC. Before correlating, convert every timestamp to UTC, record the conversion applied to each source, record the time zone and daylight-saving state each device was configured with, and apply the clock offset measured at the scene (section 3) to each device. Record every assumption ("device B's zone taken from its registry; no reference clock was recorded for it") as an assumption. A correlation that depends on a one-hour difference is reported with the zone reasoning shown.

Testing hypotheses, not confirming them

Cross-device evidence is most valuable when it is used to try to disprove a hypothesis. If the hypothesis is that a file was copied from machine A to device C and then to machine B, it predicts artefacts on all three: a connection record and file access on A, the file or its remains on C, a connection record and a creation on B, with times in that order. Look for each predicted artefact, and look equally hard for artefacts the hypothesis forbids: the file on B before the copy, a different device serial, a connection to a fourth machine. An absent predicted artefact is a finding to explain, not to omit, and a contradicting artefact is reported with the same weight as a supporting one. The confidence grade in section 23 is assigned to what survives that test.

Example. Three devices: a Windows laptop found unlocked, a Linux desktop found powered off, and a USB drive. The laptop is handled first (memory, BitLocker state, logical acquisition, then imaging), the USB drive is imaged next because its evidential value is high and it takes minutes, and the desktop last. The USB drive's serial number appears in the laptop's registry with a last-connected time and in the desktop's journal with an earlier first-connected time. Twelve files on the drive match by hash files in the desktop user's home directory and match nothing on the laptop, but the laptop's recent-items list names three of them. The report presents the hypothesis that the files moved desktop to drive to laptop, the supporting artefacts, the missing artefact (no copies on the laptop) with two candidate explanations, and a grade of probable.