15. Analysis and correlation

21. Analysis

Other analysis techniques

In short: memory forensics and timeline analysis shape what you preserve on site and how you assemble findings.

Filesystem analysis, carving, reconstruction and the detection of hidden data are covered in sections 17 to 20. Two further techniques follow.

Examine the memory capture

Use a framework such as Volatility to look for:

• Processes: running and hidden processes, their command lines and loaded modules.
• Network: open network connections.
• Code and data: injected code and decrypted data.
• Secrets: 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 carries the caveats there:

• It is a moment: the image reflects the moment of capture.
• It includes your footprint: the capture tool's own traces are in it.
• It may disagree with itself: the image may be internally inconsistent.
• Damage lowers the grade: findings that depend on a partially overwritten structure are reported at reduced confidence.

Build the timeline

Combine timestamps from every source into one ordered sequence: filesystem, journals, logs, registry, browser history, email headers, EXIF, cloud audit logs, badge access records and the memory capture. This is where the sequence of events emerges and where reconstructed artefacts are placed among observed ones.

• It is a derived artefact. Each entry carries its source.
• Apply each clock offset. Each source's offset (section 3) is applied and recorded.
• Mark reconstructed entries, so the reader can see which parts of the sequence rest on intact metadata and which on inference.

22. Preservation, acquisition, analysis

Multi-device triage and cross-device correlation

In short: handle devices in the order their evidence is disappearing, then test each device's story against the others.

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

Work through devices in this 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.
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.

Set priority between devices

At any step, priority between devices is set by:

• Volatility.
• 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.
• The time and people available.

Correlate across devices

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. Build a hash set from one device and search it 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.

Normalise every timestamp to UTC

Each source stores time differently, and the differences are large enough to reverse an apparent order of events.

Before correlating:

1. Convert every timestamp to UTC.
2. Record the conversion applied to each source.
3. Record each device's configured time zone and daylight-saving state.
4. Apply the clock offset measured at the scene (section 3) to each device.
5. Record every assumption as an assumption, for example "device B's zone taken from its registry; no reference clock was recorded for it".

Test hypotheses, do not confirm them

Cross-device evidence is most valuable when you use it to try to disprove a hypothesis.

• List what it predicts. If a file was copied from machine A to device C and then to machine B, expect: 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.
• Look equally hard for what it forbids: the file on B before the copy, a different device serial, a connection to a fourth machine.
• Explain the gaps. An absent predicted artefact is a finding to explain, not to omit.
• Give contradictions equal weight. 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.