The Files Were Deleted. The Evidence Wasn't.
Deleted files, cleared history — digital forensics rebuilt the insider threat timeline from NTFS artefacts, memory, and Windows registry entries.
The suspect had deleted the files. They had cleared the browser history. By the time the investigation started, the most obvious traces were gone.
Digital forensics rarely begins with intact evidence. It begins with what is left after someone has tried to clean up.
What "Deleted" Actually Means on an NTFS Volume
On a Windows NTFS file system, deleting a file marks the Master File Table entry as unallocated. The data on disk doesn't go anywhere — the sectors are flagged as available for reuse. Until something writes over them, a forensics tool can recover the file.
The disk image in this investigation contained 47 deleted files recoverable from the subject's user profile: compressed archives containing HR and financial documents, with creation timestamps that predated the investigation trigger by three weeks. The archives were gone from the active file system. The MFT still knew they had existed, including when they were created and last modified.
Deleted files are often the most significant artefacts in a forensics case, precisely because the person who deleted them believed they were gone.
What Memory Reveals That Disk Analysis Doesn't
Disk analysis tells you what files existed. Memory analysis tells you what was running — including processes that left no trace on disk.
The memory capture contained a process list that included a personal cloud storage sync client. No installation record was present on the disk image. The application had either been run portably or uninstalled after use. The disk wouldn't have shown it at all.
The memory also contained DNS query records: the system had resolved the cloud storage service's synchronisation endpoints multiple times in the hours before the capture was taken. The browser history had been cleared. The DNS resolver cache — held in memory, not written to disk — had not.
Volatility confirmed three things from the memory image:
- The sync client process had been active
- An outbound connection to the cloud storage service was open at the time of capture
- DNS resolutions to the service's endpoints had occurred within the capture window
The subject had cleared the history. They hadn't cleared the memory.
The Registry as a Silent Witness
Windows logs every USB storage device connection in the USBSTOR registry hive: device class ID, serial number, first and last connected timestamps. This data persists until the registry key is manually removed — and most people attempting to cover their tracks don't know it exists.
The subject had connected a personal USB device on four separate occasions. The registry provided timestamps for each connection. The SetupAPI logs provided the device serial number. Both entries were intact.
Cross-referencing those timestamps with the file access timeline from the disk image placed the USB connections during the same after-hours windows as the unauthorised access to confidential records — across three weeks of activity.
The USB device wasn't present for the investigation. The registry confirmed it had been there.
Timeline Reconstruction — When Three Sources Agree
The three evidence sources covered different ground and none of them told the complete story alone:
- Disk image — which files were accessed, when, and what had been deleted; NTFS journal entries; browser artefact remnants
- Memory capture — what was running, what connections were open, what DNS lookups had occurred
- Network logs — outbound data volume by destination, timestamps correlated with disk activity
The disk image established the file access and deletion pattern. The memory capture explained the exfiltration route that the disk didn't show. The network logs confirmed the volumes of data transferred. The registry anchored the physical device connections to the same timeline.
The reconstructed sequence covered 14 discrete events across three weeks. Each event was supported by at least one recoverable artefact. The cross-source correlation is what made the findings defensible — not just technically, but in the HR and legal context the report needed to support. A finding anchored to a single source can be challenged. A finding that appears independently in disk, memory, and network logs is a different conversation.
The Takeaway
An insider who deletes files and clears browser history has addressed one of many evidence sources. The NTFS file system, the registry, the memory image, and the network logs don't synchronise. Clearing browser history doesn't touch the DNS resolver cache. Deleting a file doesn't rewrite the MFT. Unplugging a USB device doesn't remove the USBSTOR key.
Digital forensics works precisely because these sources are independent. The methodology — preserve integrity, analyse each source separately, then correlate — is what produces findings that hold up to scrutiny.
The evidence was there. It just wasn't where the subject expected anyone to look.
This investigation was part of my MSc Cybersecurity at Robert Gordon University. Full project write-up: Digital Forensics Investigation — Insider Threat