Chain of custody · analysed image
| File | synapse-lab-01.raw |
| SHA-256 | 8f1f0c94d35c70a7d0cad5087fcd353d062ed7078c6d4f2099fde41df90e2461 |
| Type | Linux ext4, volume "SYNAPSE_LAB", UUID 8cc7c565-e64c-435a-99f8-5fa8e1fc1e06 |
| Size | 50,331,648 bytes (48 MiB) |
| Last mount | 2026-08-15T12:09:50 UTC (image acquisition) |
| Tools | sleuthkit 4.12.1 · fsstat · fls · istat · icat · strings |
1. Context and scope
The security team received an alert about unusual access to classified documents on the workstation of user alex. A raw image of the home partition was acquired for analysis. The goal: reconstruct the sequence of actions, identify the files involved, and assess the extent of the potential exfiltration.
Classification: this investigation concerns Project ORION, whose data is classified Confidential, internal use only. Any unauthorised access is documented in line with the internal security policy.
2. Artefact inventory
2.1 Filesystem structure
After mounting the image read-only (mount -o ro,loop), Sleuth Kit's fls -r reveals the full tree, including entries marked * (deleted but not overwritten):
fls -r synapse-lab-01.raw
d/d 13: home/alex
r/r 14: .bash_history
d/d 19: Documents/
r/r 20: confidential-clients.txt
r/r 21: meeting-notes.txt
r/r * 22: orion-report.pdf <- DELETED
d/d 23: Downloads/
r/r * 24: orion-export.zip <- DELETED
r/r * 25: orion-report.pdf <- DELETED (copy)
d/d 28: var/log/
r/r 29: activity.log
Three deleted files are identified (inodes 22, 24, 25). Their data blocks have not been reallocated yet, so recovery is possible.
2.2 Live artefacts
| File | Inode | Size | Mtime (UTC) | Content |
|---|---|---|---|---|
| .bash_history | 14 | 169 B | 2026-06-18 06:12:03 | 5 commands, includes history -c |
| activity.log | 29 | 527 B | 2026-06-18 07:25:10 | 7 timestamped system events |
| meeting-notes.txt | 21 | 48 B | 2026-06-18 07:27:00 | References USB "TRANSFER", 09:30 meeting |
| confidential-clients.txt | 20 | 161 B | 2026-06-18 07:27:00 | Names Project ORION and the affected clients |
2.3 Deleted artefacts, recovery
icat extracts the content of an inode straight from its data blocks, independently of the directory entry:
icat synapse-lab-01.raw 22 > orion-report.pdf # original PDF (Documents/) icat synapse-lab-01.raw 24 > orion-export.zip # archive built for export icat synapse-lab-01.raw 25 > orion-report-copy.pdf # copied PDF (Downloads/)
| Recovered file | SHA-256 | Inode deleted at (UTC) |
|---|---|---|
| orion-report.pdf | 58e5e670dd1310ce5894ea53b8511bb0aeaf6149… | 2026-06-18 07:18:33 |
| orion-export.zip | efcf223d1b05b77f5c3e525c80e64109e25394f0… | 2026-06-18 07:19:10 |
| orion-report-copy.pdf | 58e5e670dd1310ce5894ea53b8511bb0aeaf6149… | 2026-06-18 07:19:40 |
Both PDFs share the same SHA-256: they are identical copies of one document. The ZIP itself contains that same PDF. This confirms a single source document was staged, packaged and deleted in sequence.
2.4 Content of the exfiltrated document
Extracting text from the recovered PDF with strings shows:
SYNAPSE LAB - PROJECT ORION - CONFIDENTIAL
The document is a classified Project ORION report. Cross-referenced with confidential-clients.txt, the project involves clients Northwind, Contoso and Fabrikam.
3. Chronological reconstruction
Event timing is cross-checked across three independent sources: the system journal (activity.log), inode timestamps (access / modify / delete via istat), and the contents of .bash_history. All times below are local CEST (UTC+2).
orion-report.pdf activity.log + istat atimeInode 22, atime confirmed at 07:03:14 UTC. The document is read before any action.~/Downloads/ .bash_historycp ~/Documents/orion-report.pdf ~/Downloads/, order reconstructed from bash_history.orion-export.zip created activity.log + istat atimezip ~/Downloads/orion-export.zip ~/Downloads/orion-report.pdf, inode 24 atime confirmed.orion-report.pdf from Documents/ activity.log + istat deleteFirst attempt to erase traces. Inode 22 marked Not Allocated, blocks not reallocated, recovered in full.Downloads/ istat delete inodes 24 and 2537 seconds to delete both files. The three deletions are sequential, deliberate rather than accidental.history -c activity.logOPSEC fail #1. history -c empties the in-memory buffer, but the on-disk .bash_history file is left intact. Every command is still readable.meeting-notes.txt istat mtimeRead or edited 2 minutes before the 09:30 meeting. Content: "USB label TRANSFER; meeting at 09:30."4. Key artefact analysis
4.1 The .bash_history file, first OPSEC fail
ls -la ~/Documents cp ~/Documents/orion-report.pdf ~/Downloads/ zip ~/Downloads/orion-export.zip ~/Downloads/orion-report.pdf rm ~/Documents/orion-report.pdf history -c
The .bash_history file faithfully records the operations: listing, copy, compression, deletion, attempted wipe. Despite running history -c, the on-disk file is intact. Bash writes .bash_history when the session closes; history -c only clears the current session's memory buffer. To wipe the file, the operator would have had to run cat /dev/null > ~/.bash_history or rm ~/.bash_history.
Timestamp anomaly: the mtime of .bash_history is 2026-06-18 06:12:03 UTC, identical to the login time. That corresponds to Bash reading the file at session start, not writing it. Yet the commands it holds date from after 09:03. The file was therefore written in an earlier session, or the mtime was manipulated with touch.
4.2 meeting-notes.txt, evidence of premeditation
Reminder: USB label TRANSFER; meeting at 09:30.
This file establishes that the USB use was planned before the incident. The label "TRANSFER" is referenced explicitly as a reminder, which points away from an impulsive act. The note was read at 09:27, three minutes after the key was disconnected and three minutes before the 09:30 meeting.
4.3 The activity.log system journal
2026-06-18T08:12:03+02:00 login user=alex source=console 2026-06-18T09:03:14+02:00 file_open path=/home/alex/Documents/orion-report.pdf 2026-06-18T09:06:41+02:00 usb_device action=connected label=TRANSFER serial=SN-LAB-042 2026-06-18T09:11:08+02:00 archive_created path=/home/alex/Downloads/orion-export.zip 2026-06-18T09:18:33+02:00 delete path=/home/alex/Documents/orion-report.pdf 2026-06-18T09:20:02+02:00 shell command="history -c" 2026-06-18T09:24:55+02:00 usb_device action=disconnected label=TRANSFER serial=SN-LAB-042
The journal captured the whole sequence, including the cover-up attempt (history -c). Unlike bash_history, this log was not modified by the user: it does not live in their home directory and would need root privileges to alter.
5. The operator's mistakes
history -c is not enough
It only clears the memory buffer. The on-disk .bash_history file stays intact and readable.
Files deleted, not overwritten
On Linux, rm unlinks the inode from the directory but does not destroy the data blocks. icat allows full recovery.
activity.log not purged
The operator did not target the system journal, which captures every event, including the USB connection and the wipe command itself.
Premeditation note kept
The meeting-notes.txt file referencing the USB label and the meeting was never deleted.
6. IOC and forensic-indicator summary
| Category | Indicator | Source |
|---|---|---|
| Account | alex, local console access | activity.log · bash_history |
| Exfiltrated document | orion-report.pdf, "PROJECT ORION, CONFIDENTIAL" | inode 22 (recovered) |
| Document hash | 58e5e670dd1310ce5894ea53b8511bb0aeaf6149… | inodes 22 and 25, identical |
| Exfiltration vector | USB, label TRANSFER, serial SN-LAB-042 | activity.log · meeting-notes.txt |
| Export archive | orion-export.zip (hash efcf223d…) | inode 24 (recovered) |
| Impacted clients | Northwind · Contoso · Fabrikam | confidential-clients.txt |
| Suspicious meeting | 2026-06-18 · 09:30, per meeting-notes.txt | Possible physical handover |
| Track covering | history -c · rm on 3 files | activity.log · istat delete times |
7. Recommendations
Short term
- Immediately revoke the alex account's access.
- Locate and seize the SN-LAB-042 USB key.
- Identify and interview the participants of the 09:30 meeting.
- Notify the teams handling clients Northwind, Contoso and Fabrikam.
Medium term
- Enable auditd journaling (
audit.rules) with monitoring of operations on sensitive files. - Deploy a DLP (Data Loss Prevention) solution that blocks or logs unapproved USB transfers.
- Enforce an explicit USB device allow-list (
usbguardor the Windows GPO equivalent). - Stand up a SIEM with event correlation: USB connect + archive creation + deletion inside a short window = automatic alert.
Long term
- Classify and encrypt sensitive documents (Project ORION and equivalents) with role-based access control.
- Run regular internal threat-hunting exercises to catch similar behaviour before a full exfiltration.
Conclusion
The investigation establishes, with a high level of confidence, that a confidential Project ORION document was intentionally exfiltrated over USB by user alex, on 18 June 2026 between 09:03 and 09:24 CEST.
The sequence, opening the file, connecting a pre-labelled USB key, creating an archive, cascading deletions, clearing history, a meeting six minutes later, characterises a premeditated act.
Despite three attempts to cover the tracks, the system journal, the resilience of ext4 inodes and the persistence of .bash_history allowed the full chain of events to be reconstructed. The deleted files were recovered in full.
8. Tools and references
- The Sleuth Kit, fsstat, fls, istat, icat
- MITRE T1052.001, Exfiltration Over Physical Medium: USB
- MITRE T1070.003, Clear Command History
- MITRE T1485, Data Destruction (post-exfiltration deletion)
- auditd, Linux kernel journaling
- USBGuard, USB device control on Linux
Entirely fictional environment, for educational use only.
A Belgium-based provider of cybersecurity solutions, and the team behind SynapseRM / TPRM.