# CCF Lab Assignment: Data Acquisition

### Hamidula Muslih - Rodrigo Quijarro - Artem Abramov

## Setting up your environment:

2 USB drives prepared.

Three files have been downloaded.

- CAINE.iso
- evidence1.E01
- FTKimager

#### The first one should have a CAINE live environment that will be used to collect evidence:

Bootable drive
Below we are burning a bootable CAIN.ISO image to the flash drive (CAIN) using, to complete this task we will use ultraISO tool:


Below shows its burning:


#### On the second drive (this drive will be called drive A) you should deploy that disk image.

Now, the image is loading to FTKImager:

Below **imager** shows hows to load the image into FTKImager.


As showing below, it has two types:

- Partitioned
- Unpartitioned

All the files of the filesystem is inside the partition 1, in the root folder typically.

Note that there is a [unallocated space], it is part of the drive that was perhaphs once used to hold file that were later unlinked from the filesystem. Its possible that these files will be partially or fully recovered.


Now we need to copy the evidence to the Drive A, using FTK.

As below shows FTK ussing dd command which copy bit by bit:


As we can see below, it let us to put some descriptions to identify the Evidence:


Below we select the destination and the Image file name:


After cliking the *Start* button it will beguin the copy:


After finishing, it show the detail, specially hashing for to keep its integrity:


Now, we are burning it into Drive A:



Finally it is finished, below shows the size in the Drive A


Below is the content

## Imaging:

### 1. Discuss how you can retrieve an image from an, currently off-line, USB stick in a forensically sound manner. Create and describe this method.

Its important that we access the usb only from an environment that will prevent any unauthorised modification of the data on the USB stick. For example the CAINE environment puts all block devices into read-only mode right after booting to prevent modification.

Then its necessary to create a bit-for-bit identical image of the usb.
The following steps outline the procedure:

1. In order to avoid accidental evidence modification/deletion, the usb must be accessed via hardware or software write-protect.

2. The USB flashdrive will be plugged into the USB port of a machine with specialised forensic software (CAINE) which is designed to prevent any unattended modification of data which will be special dedicated, isolated and updated forensic workstation. Making bit-for-bit identical image will be completed with GuyManager.

For example:

“/dev/sda”
#cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: xx Id: xx Lun: xx
Vendor: Model: Floppy-on-stick Rev: xxxx
Type: Direct-Access ANSI SCSI revision: xx

3. A cryptographic hash (SHA256 value, for example) of the contents of the original USB flashdrive must be obtained, using any standard Linux/Windows program.

4. This value will be verified agains the hash value of the cloned image.

Example:

#md5sum /dev/sda
338ecf17b7fc85bbb2d5ae2bbc729dd5 /dev/sda

5. Obtain a raw image of the USB flashdrive contents, using any standar copy tool. As we explained before, we will use **dd** command.

dd Tool:

dd tool
#dd if=/dev/sda of=/T8c/usbfd-64531026-rl-001.img bs=512
121952+0 records in
121952+0 records out

5. A cryptographic hash (MD5 or preferably SHA256 value) of the raw image was obtained using a hashing program, this will help us to confirm that it was an exact bit-for-bit copy of the original USB.

MD5 values matching, for example:

# md5sum /T8c/usbfd-64531026-rl-001.img
338ecf17b7fc85bbb2d5ae2bbc729dd5 /T8c/usbfd-64531026-rl-001.img

6. It is advisable to modify the file permissions image to avoid an accidental modification and some other information related with the evidence.
Non-erasable media like the old CD-R units can be used to avoid a damage or in the original evidence disk due to the usage, in order to maintain the integrity of the data.
As a last step, but no less important, the original evidence (USB disk) needs to be safely stored in a locked cabinet, the phisical CD-R disk copy in a chain of custody form, only accessible by the forensic investigator. The rest of the analysis will be based on the extracted image file.

### 2. Write a one-line description, or note a useful feature for the following tools included in CAINE: Guymager, Disk Image Mounter, dcfldd / dc3dd, kpartx.

- Guymager: Forensic imaging designed to support different image file formats.

- Disk Image Mounter: Disk Image Mounter is a way to mount the contents of an ISO so they can be viewed. Forensic file extension E01 also supported.

- dcfldd: enhanced version of GNU dd with features useful for forensics and security. Based on the dd program found in the GNU Coreutils package, dcfldd has the following additional features:
- Hashing on-the-fly.
- Status output.
- Flexible disk wipes.
- Image/wipe Verify.
- Multiple outputs.
- Split output.
- Piped output and logs.

- dc3dd: is a patched version of GNU dd with added features for computer forensics: on the fly hashing (md5, sha-1, sha-256, and sha-512) possibility to write errors to a file. group errors in the error log. pattern wiping.

- kpartx: Device mapper that creates entries and so can be used by devices that the kernel does not natively support partitioning, such as multipath device mapper devices ("kpartx" is part of multipath-tools) or files.

### 3. Follow your method to retrieve the image from drive A. Please use timestamps, explain every tool and note down the version. For the purpose of speed. Make sure both team members have access to the retrieved image. You can use your PCs as an evidence sharing platform.

We verify that the USB is **Read Only**, in order to use the **UnBlock** version .


Starting GuyMager to adquire data. We will verify the version.


Selec the Drive A which has the Image. In our case /dev/sde

Below are the settings that we have set.
The destination, file name, info name, and etc..
Note: that source verification is turned on, it will verify.

Below shows the imaging is on process and the start time is "16-Apr- 11:44:54" And it took "10:17 sec"

Note: that we found a bug in this software, If you see the April month the the Fig. it is misspelled, and in official case in court it could make a problem.

After the Imaging with the Guymager finishes, we checked the info file.
`cat /home/caine/Desktop/Image/BlackTeam.info`, as below shows the it verified the source, and the data is the same.


The output mentioned before can be consulted in Append 1.

### 4. Read about CAINE Linux and its features while waiting on the dump to finish.

#### a. Why would you use a Forensic distribution and what are the main differences between a regular distribution?

We can say that the **Forensic distribution** has some particular good characteristics, like forensic analysis tools already installed for uncovering Windows and Linux residual information post-incident, it allows us to search hidden information.

CAINE main differences between forensic and normal distribution are:

* **Integration** The graphical enviroment of makes an easy interaction with the already installed forensic tools.

* **Optimization** In the Forensic distribution the number of system processes and their choice is optimised in order to reduce the loading time and make the system smaller.

* **Operative System Featuring** In Caine Forensic version we can find specialized tools to perform specific forensic analysis in Linux and Windows OS.

* **Script integration** To perform specific analysis, CAINE forensic version allows the Windows registry validation, metadata, unit partitions and hiden files.

#### b. When would you use a live environment and when would you use an installed environment?

* When to use a live enviromnt?
A live enviroment will give us a bootable operating system that will run as a read only unit, this means that all the information which we are working on it will be writing protected. In this way we can be sure that the tools we'll use in the analisys will no affect the information integrity.

Many forensics cases are presented as a matter of time, this means perform tasks within a short periods of time, runing a live enviroment will not require the all installation process and also to have a movility reasearch.

* When to use a istalled enviroment?

An installed version will be used when characteristics like Speed and storing are required. For example, a live installation will be slower than an installed environment, because all the physical resources will be not dedicated, Storing settings also are available in an installation environment, because the restrictions at the moment of storing data.

Some issues with the live enviroment is that some distributions, at the moment of restrict devices to read-only access mode will only protect the file system memory from a process running in user space, this means that a driver code running in kernel space will be allowed to change the file system memory.

#### c. What are the policies of CAINE? - Date: 07.04.2020

The following CAINE polies can be founded in https://www.caine-live.net/page8/page8.html

1. Mounting policy of CAINE
It's not recommendable mount automatically any device and when the user clicks on the device icon the system will mount it in read only mode on loop device.

Users cannot mount a device through the Disk Mounter applet, but only by Terminal Window or by Mounter (GUI) Mounter and the system will always mounted with the following options:
*ro,noatime,noexec,nosuid,nodev,noload.*

For UMOUNTING a device you can use Caja by root (eg. gksudo Caja) or by terminal window (xterm or sudo umount) or Mounter GUI.

2. Live USB pendrive creation

In the Live USB cretaion, using RUFUS suggestion... it mention that:

ONLY for Caine 4.0 and its previous releases, you cannot create LiveUSB Caine from this distro, you have to DOWNLOAD NBCaine from Caine's website to get it! () OR if you need CAINE on pendrive (USB), you can sobstitute the file /usr/share/initramfs-tools/scripts/casper with THIS and use your preferred tool for making it.

4. Installing Caine

CAINE versions like 6.0, SWAP partition can't set, it is necessary the swap creation that can be done after installation using gparted.

6. Language Support
The CAINE report supports the following languages: English, Italian, French, German and Portuguese.

### 5. As soon as your dump finishes, start a tool to create a timeline on the image. You will need this timeline later in the assignment. Hints: log2timeline.py.

As per hint from the LAB, we needed to use `log2timeline.py` But I dont know in our case it did not worked it crashed the LIVE CAIN, three times, so We found there is another method to use GUI, (NBTempoX). As below shows We have created the timeline.


Below is the file name and case number and generating the report as PDF and etc..

Below is the source image the destination of the timeline file:


Below the timeline file is generated,


Below is the output, for official use, it need the sign of the guy to take the responsibility of the document.


Below is the CSV file output that shows all the timeline in rows:


## Verification:

### 6. Create and describe a method that enables the verification of your method. Write this down in steps that the other team can follow.

Below we used the `ewfexport evidence1.E01` to export a raw file.

as below shows the file name is `verify` and the file type is `raw`.
and the shows the MD5 hash value `50decb45c3d56ffe1a3c538bb7898fd9`. that should be matched once the other forencic guy will recieves and verifies.


Once we have the .raw file and the hash of it in info file, as below shows:


The below we copy it to the flash drive, `dcfldd` command.

dcfldd if=verify.raw hashconv=after bs=512 conv=sync of=/dev/sdb


Once the flash is revcieved to another specilist we can verify it as below:

`lsblk` to list if the device is pluged.

Now time to mount the

mount -o ro /dev/sdc1 ~/rodry/Desktop/mnt

check the bytes with `fdisk -s --bytes /dev/sdc1`:


**Now to calculate the hashes of evedence**

Below is the hash of the evedince from rodry's PC which has CAIN LIVE:

dcfldd if=/dev/sdc bs=4096 count=15154240 conv=notrunc,noerror | md5sum -b


Below shows the both hashes were matched.

dcfldd if=/dev/sdc bs=4096 count=15154240 conv=notrunc,noerror | md5sum -b


### 7. Exchange USB images with another team. Verify the procedure that they used and the resulting image. Write a small paragraph of max 200 words. Write as if you were verifying the evidence gathering procedure for a court case.

Next, we'll describe the procedure of how to verify digital forensic evidence.

The most critical aspect is establishing the chain of custody, that is being able to prove that the evidence that was discovered and is being shown in court is exactly the data that was initially stored on the USB stick.

The diagram below details the disctinction between the work done during investigation and work done in court.


First, basic Pre-requisites to verify:
- CD or USB with CAINE (Computer Aided Investigative Environment)
- External hard drive with enough free space to hold the raw image of the hard drive to be acquired.
- Access to the machine under investigation.

Connection to USB connect to the computer. The following stesps were verified:

- Live CAINE USB is booting from the CAINE-USB unit, some configuration changes in BIOS were required.
- CAINE did not mount any hard drives to prevent unwanted changes on the evidence when CAINE has started
- External hard drive in read-write mode is mounted
- The Make Writable option was verified and mounted
- GUYMAGER is now used to create the image of the disk:
- Choose MENU -> Forensic Tools -> Guymager
- From the list of devices in the main window the sda device is selected.
- The option *Acquire image* is selected.
- The file format E10 was selected, but no recommended split size of 2047 MiB was considered.
- The Optionally fill-in additional notes (case, evidence, examiner, description, etc.) are writing.
- The destination of the image is selected ad idenfied and the acquisition start.
- Once finished the machine is turned off and the unit removed.
- The usb stick is taken into custody as the original source of evidence

As we described our method in task 6, and how the other team (2nd specialist) will verify the file of the evedince. In task 7 we have got the USB which has the evidince files from the Rustam and we followed his method and got the same hash which shows that it did not change on the way to transfermation, In the real world it could be used to prove the authenticity of the file during demonstration to the court.

Once we got the USB from Rustam we did the below steps:

`lsbls` to see is it listed in the dev files:


Then we have checked the block size with the `fdisk -s --bytes /dev/sdc1` command. The bock size was `151552200`.

Below command is to read the file from the /dev/sdc block device file and check it hashsum. As it shows that the hashsum is ` 5ca44527dba72c374e10c9f384fe917f`
`dcfldd if=/dev/sdc bs=4096 count=151552200 conv=notrunc,noerror | md5sum -b`


Below is the hashsum of the evedince file that Rustum send to as for the verification of the file, Since we have followed his method and got the hashsum which macheches.


It means in the real world we can verify the evedince with this method.

## Technical analysis:
### 8. Mount your image (image of drive A) and make sure that it is mounted as read-only.

There are many way to do mount as read only, as we can use the mount command with the `-o ro ` parameter or we can use the Ublock GIU software which is also doing that task to mound it as the read only FS:

`mount -o ro /dev/sdd1 /mnt`

since CAINE mounts all block devices automatically in read-only mode at startup we don't need this command.

Below is the Ublock Gui software that we can use to verify that it is read only:


Note: that in the mount command is mentioned as well at the GUI text

### 9. Identify and write a small paragraph of max 200 words about what kind of image it is. Don’t go into file specific details just yet. This includes but is not limited to:
a. What is the size of the image?

There are many ways for to check the size of the USB flash.

with `lsblk` since that usb does not have any thing instead of the evedince file you can use this command:


Also we can use `df /dev/sdb1`


moreover we can use `sfdisk -l /dev/sdb1`:


b. What partition type(s) does this image have?

We can use the `blkid /dev/sdb1` and `sfdisk -l /dev/sdb1` that shows the partition type of it.


c. Does it have an MBR/GPT?

As below show it has MBR only


d. etc.

we can learn some more detail about the disk, starting sector and ending sector, the GUID, and many more at the disk level:


### 10. Using the information from the timeline you create above, write a small paragraph on what you think happened on this specific USB device. The device owner is suspected in a crime. Try to find the evidence that can support this accusation. Please remain objective, as you would be preparing evidence for a court case. Make it a maximum of 300 words, and use timestamps.

As we have all the timeline above but we have used the new tool to learn more, this tool is called Autopsy
Below we have created new case:


Below we have created the database for the case and we will assing the source of the data:

Below is the out put of selecting the device, but the Autopsy has the problem:


Below is the problem of Autopsy with the modules:


Rodry use atuopsy in his Windows machine, since it lots of features we needed to learn how it works:

Below is the graph view of the event in the evedince files:


Below is content of the catch folder:


As below shows his name was `thomas Ehrhart`

and here are us the zone identifier:
"A file with a "Zone.Identifier" extension is an alernate data stream (ADS) file that contains information about another file. It describes the security zone associated with the file, which may the Internet, local intranet, trusted site, or restricted site."

Below show in the description of the above file.


As below show he was using TrueEcrypt and TrueCrypt is a discontinued source-available freeware utility used for on-the-fly encryption.


Below shows that he was searching about the Artefacts hiding in Google. means he was always to hidd and encrypt the files:

Below shows that he was about the download the truecrypt from the truecrypt.sourceforge.com

Below shows that he want to use veracrypt.codeplex.com which is again a software for encryption:


Below shows some type of spam emails, we think that he was also doing spam to which is a cybercrim itself.


After lots of hours of investigation, we think that this guy was a cookie stoler, since that was alot of cookie found the evedince file, like paypal.com, veracrypt.com, livefilestore.org, redintellegence.net, maybe use was using the cookie and useing fake sessions on behalf of the victim user.
he was searching for the artefacts in the google means he was doing somthign to hide it and you can refer to the screenhot when he tried to do that (date).
There was many emails addresses that found in the email address book, that shows a kind of spaming.
Downloaded some software that is related for the security and hiding of the files like Truecrypt and veracrypt while he was using the Windows 10 OS, we think he was a spammer and to send binary file to victim and get the cookies, he might use the zone identifier parameter to sustitute the ADS alternative Data stream identifier to the other side which could be the victim machine.

Another interesting thing that we got is that this guy deleted the web catch to delete the tracking and he has good knowledge of how to hide his footpring and do cybercrime. he was also using the onedrive that could help him to exchange his data with other devices.

### 11. What would help to investigate this evidence further?

A better analysis can be done performing an analysis of the files and directories, which includes the names of deleted files and files with Unicode-based names. Also, files can contain can be viewed in raw, one property that Autopsy gives us is the extraction of hex, or the ASCII strings. Analysis in the hash database can also be done, identify if hashes are good or bad.

A Timeline of File Activity is recommendable, in order to track the activity and identify areas of a file system that may contain evidence.File system details can including times stamps of activity which provides rich information in content during data recovery.

A Meta Data Analysis is highly suggested, these structures contain the details about files and directories that can help us to view the details of any meta data structure in the file system for recovering deleted content. and identify the full path of the file that has allocated the structure.

Finally but very important is considering the integration of the Time-based events located in the file activity or IDS and firewall logs to track the network activity that could be performed.

## References

- https://www.caine-live.net/
- https://www.caine-live.net/page8/page8.html
- https://www.researchgate.net/publication/322921757_Lab_1_Acquiring_Disk_Image_with_FTK_Imager
- https://www.linuxinsider.com/story/81353.html
- https://guymager.sourceforge.io/
- https://rufus.ie/
- http://manpages.ubuntu.com/manpages/bionic/man8/kpartx.8.html
- https://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_12_004_v1_3.pdf
- https://accessdata.com/product-download
- https://geekflare.com/forensic-investigation-tools/
- https://www.binarytides.com/linux-command-check-disk-partitions/

## APPENDS.

### Append 1

caine@caine:~/Desktop/Image$ cat BlackTeam.info 

GUYMAGER ACQUISITION INFO FILE
==============================

Guymager
========

Version            : 0.8.11-1                                                                               
Version timestamp  : 2019-06-26-09.00.00 UTC                                                                
Compiled with      : gcc 6.3.0 20170516                                                                     
libewf version     : 20140608 (not used as Guymager is configured to use its own EWF module)                
libguytools version: 2.1.0                                                                                  
Host name          : caine                                                                                  
Domain name        : (none)                                                                                 
System             : Linux caine 5.0.0-32-generic #34~18.04.2-Ubuntu SMP Thu Oct 10 10:36:02 UTC 2019 x86_64


Device information
==================
Command executed: bash -c "search="`basename /dev/sdb`: H..t P.......d A..a de.....d" && dmesg | grep -A3 "$search" || echo "No kernel HPA messages for /dev/sdb""
Information returned:
----------------------------------------------------------------------------------------------------
   No kernel HPA messages for /dev/sdb

Command executed: bash -c "smartctl -s on /dev/sdb ; smartctl -a /dev/sdb"
Information returned:
----------------------------------------------------------------------------------------------------
   smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.0.0-32-generic] (local build)
   Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
   
   /dev/sdb: Unknown USB bridge [0x03f0:0x5307 (0x1100)]
   Please specify device type with the -d option.
   
   Use smartctl -h to get a usage summary
   
   smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.0.0-32-generic] (local build)
   Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
   
   /dev/sdb: Unknown USB bridge [0x03f0:0x5307 (0x1100)]
   Please specify device type with the -d option.
   
   Use smartctl -h to get a usage summary

Command executed: bash -c "hdparm -I /dev/sdb"
Information returned:
----------------------------------------------------------------------------------------------------
   SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   
   /dev/sdb:
   
   ATA device, with non-removable media
   Standards:
   	Likely used: 1
   Configuration:
   	Logical		max	current
   	cylinders	0	0
   	heads		0	0
   	sectors/track	0	0
   	--
   	Logical/Physical Sector size:           512 bytes
   	device size with M = 1024*1024:           0 MBytes
   	device size with M = 1000*1000:           0 MBytes 
   	cache/buffer size  = unknown
   Capabilities:
   	IORDY not likely
   	Cannot perform double-word IO
   	R/W multiple sector transfer: not supported
   	DMA: not supported
   	PIO: pio0

Hidden areas: unknown


Acquisition
===========

Linux device            : /dev/sdb                                                           
Device size             : 4026531840 (4,0GB)                                                 
Format                  : Expert Witness Format, sub-format Guymager - file extension is .Exx
Image meta data         
   Case number          : 1                                                                  
   Evidence number      : 1                                                                  
   Examiner             : BlackTeam                                                          
   Description          : LAB1 CCF                                                           
   Notes                : 0422450000006484                                                   
Image path and file name: /home/caine/Desktop/Image/BlackTeam.Exx                            
Info  path and file name: /home/caine/Desktop/Image/BlackTeam.info                           
Hash calculation        : MD5, SHA-1 and SHA-256                                             
Source verification     : on                                                                 
Image verification      : on                                                                 

No bad sectors encountered during acquisition.
No bad sectors encountered during verification.
State: Finished successfully

MD5 hash                   : 89602560872e1016ac37481a5842d93e                                
MD5 hash verified source   : 89602560872e1016ac37481a5842d93e                                
MD5 hash verified image    : 89602560872e1016ac37481a5842d93e                                
SHA1 hash                  : 317138212fc006be74674264ba1a55455e5f9132                        
SHA1 hash verified source  : 317138212fc006be74674264ba1a55455e5f9132                        
SHA1 hash verified image   : 317138212fc006be74674264ba1a55455e5f9132                        
SHA256 hash                : bd06c5d8e30f1063e828a681d8379ee751305c42c97f13ef440df9df7eba046a
SHA256 hash verified source: bd06c5d8e30f1063e828a681d8379ee751305c42c97f13ef440df9df7eba046a
SHA256 hash verified image : bd06c5d8e30f1063e828a681d8379ee751305c42c97f13ef440df9df7eba046a
Source verification OK. The device delivered the same data during acquisition and verification.
Image verification OK. The image contains exactly the data that was written.

Acquisition started : 2020-04-16 11:44:54 (ISO format YYYY-MM-DD HH:MM:SS)    
Verification started: 2020-04-16 11:51:37                                     
Ended               : 2020-04-16 11:55:11 (0 hours, 10 minutes and 17 seconds)
Acquisition speed   : 9.53 MByte/s (0 hours, 6 minutes and 43 seconds)        
Verification speed  : 18.03 MByte/s (0 hours, 3 minutes and 33 seconds)       


Generated image files and their MD5 hashes
==========================================

No MD5 hashes available (configuration parameter CalcImageFileMD5 is off)
MD5                               Image file
n/a                               BlackTeam.E01
n/a                               BlackTeam.E02