Recently I solved a CTF kind challenge with focus on forensic analysis of an USB drive image.
The introduction story of the challenge was that a company was most probably blackmailed by an employee, who is suspected to have stored relevant data on an USB drive. USB drives can often hold key evidence in an investigation phase. The goal is to analyze and investigate the drive to find out if there is suspicious data and evidence relating to the blackmailing. The employee might haved tried to delete the data from the USB stick to cover his tracks.
The following summary does not reflect how a professional forensic analyst would proceed in such a scenario, moreover I want to shed light on some forensic tools which can be used for conducting an analysis. I am not a forensic analyst, but eager to learn new stuff.
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 BOOTMGRFrom 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.
Please refer to the above source , for getting detailed information about the specific Bytes. The 0x55aa indicates the end of the MBR sector.
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.ddAfter 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 zipAs 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.docxThe 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.
Please leave me a note if you feels so.
Sources
