The starting point of the analysis was a .dd image, a bit to bit copy of the original USB drive. It’s good practise to make an image/copy of the device for further analysis and keep the original USB drive for evidence. Furthermore, to be sure that the image is the same copy of information a integrity check can be done. The goal is to find suspicous files (most probably deleted) on the drive. In order to recover deleted data one can use one of the many digital forensics tools. Below I will go through some of the tools which come pre-installed with Linux distributions. There exist heap of investigation tools for forensic analysis, please leave me a note with other suggestions. Success in actually recovering deleted files will vary from file system types.
Linux “file “Command
Running the “file” command provides information on the file system and other relevant data.
root@hlkali:#file usb.dd
usb.dd: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2048, dos < 4.0 BootSector (0x0), FAT (1Y bit by descriptor); NTFS, sectors/track 63, physical drive 0x80, sectors 1048575, $MFT start cluster 43690, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 0ae78e78878e74da1; contains bootstrap BOOTMGR
From the above output it is visible that there is a DOS/MBR Boot Sector.
minfo from mtools
Alternatively one can use minfo from the mtools package. You can skip this section if you are not interested in the NTFS boot sector layout and bootsector information.
# minfo -i usb.dd device information: =================== filename="usb.dd" sectors per track: 63 heads: 255 cylinders: 0media byte: f8mformat command line: mformat -t 0 -h 255 -s 63 -i "usb.dd" ::bootsector information ====================== banner:"NTFS " sector size: 512 bytes cluster size: 8 sectors reserved (boot) sectors: 0 fats: 0 max available root directory slots: 0 small size: 0 sectors media descriptor byte: 0xf8 sectors per fat: 0 ...
xxd hex dump
With the xxd command it is possible to view the hex dump of the NTSF Boot Sector. I found this source, which gives insight to the NTFS boot sector layout and a detailed explanation thereof. It is nothing new, that we could not extract from other tools. The first 3 Bytes define the Jump Instruction, the following 8 Bytes give infomoration about the OEM ID, and so on. The last part of the BPB part gives us the volume serial number.
Disk Analysis with Foremost
Foremost is a forensic and simple CLI tool that tries to recover deleted files by reading the headers,footers and data structures of the file. It works on image files, such those generated by dd.
#foremost usb.dd
After foremost has finished, a folder called output will be created incl. the audit.txt which contains a summary of what it has found, along with size and file offset location. Note that no alternative path was defined, which could have been achieved with the option -o.
# cat output/audit.txt Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus Audit FileForemost started at Tue Oct 29 17:23:35 2019 Invocation: foremost usb.dd Output directory: /home/Downloads/output Configuration file: /etc/foremost.conf ------------------------------------------------------------------ File: usb.dd Start: Tue Oct 29 17:23:35 2019 Length: 512 MB (536870912 bytes) Num Name (bs=512) Size File Offset Comment0: 00190200.wav 45 KB 97382400 ... 6: 00192148.htm 396 KB 98380080 7: 00192942.htm 15 B 98786413 8: 00195347.htm 908 B 100017803 9: 00137687.jar 25 MB 70495757 10: 00198696.zip 5 MB 101732352 ... 32: ... Finish: Tue Oct 29 17:23:44 201933 FILES EXTRACTED jpg:= 7 gif:= 3 bmp:= 1 rif:= 1 htm:= 12 zip:= 4 png:= 2 pdf:= 3 ------------------------------------------------------------------
Foremost has carved out 33 files of 8 different types. The zip folder contains zip files which can be converted to docx files. The docx files look very suspicous and delivers me the evidence that the employee indeed stands behind the blackmailing.
# ls -l output
total 40
-rw-r--r-- 1 root root 2265 Oct 29 17:23 audit.txt
drwxr-xr-- 2 root root 4096 Oct 29 17:23 bmp
drwxr-xr-- 2 root root 4096 Oct 29 17:23 gif
drwxr-xr-- 2 root root 4096 Oct 29 17:23 htm
drwxr-xr-- 2 root root 4096 Oct 29 17:23 jar
drwxr-xr-- 2 root root 4096 Oct 29 17:23 jpg
drwxr-xr-- 2 root root 4096 Oct 29 17:23 pdf
drwxr-xr-- 2 root root 4096 Oct 29 17:23 png
drwxr-xr-- 2 root root 4096 Oct 29 17:23 wav
drwxr-xr-- 2 root root 4096 Oct 29 17:23 zip
As only the file headers and footers are examined it is not possible to determine the original file name. The name is given by the program. This is the one disadvantage using Foremost.
Disk Analysis with fdisk, fsstat and fls
When starting with the forensic analysis of an image, a good first start ist to have a complete overview of files and directories on the system.
fls
The fls tool from Sleuth Kith Toolkit lists all files and directories in a file system and can also display file names of recently deleted files. In the below output the deleted file is marked with an *.
# fls usb_stick.dd
r/r 4-128-4: $AttrDef
r/r 8-128-2: $BadClus
r/r 8-128-1: $BadClus:$Bad
r/r 6-128-1: $Bitmap
r/r 7-128-1: $Boot
d/d 11-144-4: $Extend
r/r 2-128-1: $LogFile
r/r 0-128-6: $MFT
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure:$SDS
r/r 9-144-11: $Secure:$SDH
r/r 9-144-14: $Secure:$SII
r/r 10-128-1: $UpCase
r/r 10-128-4: $UpCase:$Info
r/r 3-128-3: $Volume
d/d 717-144-1: docs
d/d 39-144-1: html
d/d 36-144-1: System Volume Information
d/d 57-144-1: Tools
d/d 708-144-5: ZZZ
-/r * 716-128-1: blackmail.docx
The command “fls -rp -f ntfs <image>” displays the Directories with the files in recursive. To only show the deleted files from the image the -rd option can be used. The above output shows that various folders exist on the USB disk and among other the suspicious file, which has been recovered. In Linux it is possible to run fdisk directly on the image with the -l option in order to list the main partitions:
fdisk -lu usb.dd Disk usb.dd: 512 MiB, 536870912 bytes, 1048576 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x73736572Device Boot Start End Sectors Size Id Type usb.dd1 1920221984 3736432267 1816210284 866G 72 unknown usb.dd2 1936028192 3889681299 1953653108 931.6G 6c unknown usb.dd3 0 0 0 0B 0 Empty usb.dd4 27722122 27722568 447 223.5K 0 EmptyPartition table entries are not in disk order.
fsstat
The fsstat command can be used to learn the the general known information, such as layout, allocation structures and boot blocks. This information is retrieved – as seen from above hexdump – from the boot sector/superblock of a file system. The following output shows the total range of the file system, metadata & content information and more.
# fsstat usb.dd FILE SYSTEM INFORMATION -------------------------------------------- File System Type: NTFS Volume Serial Number: AE78E78878E74DA1 OEM Name: NTFS Volume Name: USB Drive Version: Windows XPMETADATA INFORMATION -------------------------------------------- First Cluster of MFT: 43690 First Cluster of MFT Mirror: 2 Size of MFT Entries: 1024 bytes Size of Index Records: 4096 bytes Range: 0 - 768 Root Directory: 5CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 4096 Total Cluster Range: 0 - 131070 Total Sector Range: 0 - 1048574
Please have a further look into the cli tools from Sleuth Kit (TSK).
Autopsy 4.14.0
Autopsy is a free / open source GUI-based digital forensic platform. For this analysis I used my Windows system. Autopsy is not part of the Kali Linux Tools, but there is a download for Linux machines. It can be used as a Single Desktop User or in a Multi-User Environment. There are many tutorials on how to use Autopsy, so I will not go into detail here. Autopsy provides various functionality for the analysis part, such as file listing & file content and meta data analysis, keyword search and much more. Among other it is possible to get an overview of the deleted files and to reconstruct the file, respectively to export it.
How to proceed after successfull installation:
- Make a case
- Add/Import the source (in our case the Disk Image)
- Check Findings
Directory and the file listings allows the examination of directories and files. For each directory and file it is visible when the item was written, accessed, changed and created incl. size and meta data information. And most important, it is possible to see the directory structure and the file names as used in the original version.
Please note, that the views panel shows the same files as the data source panel, just differently organized (by filetype, allocation status and size).
In the content view one can even see the content of the blackmail.docx. Some Strings might not make sense, but one can get an idea of the content.
With clicking to the metadata field it is possible to get more information about a specific file (hash, etc.). Browsing through the files, one can see, that there are other suspcious files. Thus it is clear that it was a employee who stands behind the blackmail. With this write up I intended to give a basic introduction using some of the forensic tools. As I told above, I am not a forensic analyst, I came accross this topic while solving a challenge and wanted to summarize my findings in more depth. Maybe it can be of help to someone else. With the above tools I was able to proof that the employee’s USB flash drive contained the files which were used for the blackmailing.
Learn More:
For solution, online support and query email us at .