Part A: Guided file recovery

Use either your host system or a Windows VM to complete this lab. You will need the disk image

dfr-01-ntfs.dd.bz2 and the tool AccessData FTK Imager, which must be installed.

Reference tutorial: https://eforensicsmag.com/how-to-investigate-files-with-ftk-imager/

1. Unzip the disk image to obtain the original file dfr-01-ntfs.dd, then open it from FTK

using the menu option Add Evidence Item. Finally, expand the evidence tree up to [root]

and click on $MFT in the file list pane. Explain what this special file contains and what

its general purpose is.

2. After clicking on $MFT, on the viewer pane at the bottom, the contents are divided into

sections each beginning with FILEO. This is called the magic marker. Select the 5

characters and check their hexadecimal value. What is it? How many hex digits are

needed for each ASCII character?

3. Scroll down to the last magic markers, belonging to the files Arcturus.txt, Bunda.txt and

Castor.txt. Focus on the first of these three files. Right click on its magic marker and

select Find. Look for the binary string "80000000". After this string you will see "48 00

00 00". What the next 2 hex digits are? What their meaning is?

4. Four lines below "80 00 00 00", you will find the hex digits "21 01", where 21 is the data

run and 01 is the number of clusters this files takes, that is, the size in clusters. To know

the exact amount of bytes a cluster takes, click on "NTFS" on the Evidence Tree pane

and enable the Properties view from the top menu. Capture a screenshot of its properties.

What is then the size of Arcturus.txt in bytes?

5. Click back on [root] → $MFT and locate again the hex digits "21 01" below "80 00 00

00". Select the next 3 hex digits after "21 01". This would be the cluster where the actual

data is located, but you need to convert it from hexadecimal to decimal. To do so, enable

the Hex Value Interpreter pane from the top menu, option View. Capture a screenshot

showing the hex value and its decimal conversion./n6. You have now the 1st cluster and the number of clusters, which is one (this is a small file

taking 4096 bytes or less). To recover the data, click on "NTFS" in the Evidence Tree

pane. Then, on the bottom right pane, right click, select "Go to sector/cluster", and

introduce the decimal number you converted. Capture a screenshot before accepting.

7. Look at the bottom for a reference to the file Arcturus.txt. Right click on the 1st hex digit,

which is "OA" and choose "Set Selection Length". Enter the cluster size in bytes. Without

undoing the selection, right click on it and choose "Save selection...", then save to a file

named recovered.dat on the Desktop. Capture a screenshot of the file properties from

Windows OS.

8. Open it with WordPad and scroll down to the last block. Capture a screenshot.

Part B: Another simple file recovery

In this section you will recover the file Castor.txt following the same steps. Answer all questions

and capture a screenshot of each finding or relevant information.

9. Is it a file or directory? Proof it as well as that it has not been deleted.

10. This file only takes one cluster. What the 1st and only cluster is? Show it both in hex and

decimal.

11. In the file's data there is a reference to the file and many plus signs. Show the reference

to the file and the first line of plus signs.

Part C: Using Autopsy

Copy dfr-01-ntfs.dd.bz2, which must be uncompressed, in your Kali Linux VM. Then, using

Autopsy, follow the steps below capturing relevant screenshots and answering all questions.

12. Create a new case. Show the form you filled./n14. After adding the image, analyze the NTFS filesystem. Choose File Analysis. Capture the

data at the bottom, which correspond to the txt files.

15. Why two of the are in red? Why the last file is shown twice?

16. Click on Bunda.txt and scroll to the last lines of this file. Capture them.

17. Browse the different options on the top menu to find out what the original operating

system was. Proof it.

Part D: Conceptual questions

18. Discuss what files can be recovered (if any) in each of these scenarios using tools similar

to those you used in this lab. Assume the filesystem is NTFS in all cases.

A) A file deleted using the file explorer and sent to the recycling trash

B) A file deleted using the file explorer, directly removed.

C) Files belonging to a drive formatted with the quick format option.

D) Files belonging to a drive formatted without the quick format option (full format).

19. Why you should avoid mounting the disk image as an actual drive?/n6. The webserver's logs were stored originally in the standard directory /var/log. Therefore,

to access them you need to mount the corresponding logical volume in /mnt/blog/var and

access them using the new path /mnt/blog/var/log. Capture a screenshot of the

corresponding mount and is commands.

7. Execute "mount" without parameters and double check that both filesystems are mount as

read-only. Why do we need to make sure? What would happen if forensic evidence is

altered somehow?

Part B: Logs analysis

Based on the information in ENISA_Webserver_Analysis.pdf, provided with the lab, you need to

analyze the webserver logs as part of your forensic investigation. The server with IP

195.251.97.97, which runs WordPress and hosts http://blog[.]mycompany[.Jex, was

compromised on August 19th, 2016. Refer to the section 3.4.1 as a guideline, but you do not need

to perform all tasks.

8. Move to /mnt/blog/var/log/apache2 to find Apache's logs. Execute "tail -5 access.log" to

get identified with the fields found in every single entry. What browser was used in the

last log entry?

9. The first field is the IP address of the system that accessed the webserver. As you can see,

the last entries show the server itself. To avoid them, use the parameter -v in grep. Show

the last 3 lines that do not relate to the server itself, either by 195.251.97.97 or ::1.

10. You can observe the IP address in these lines is 10.0.0.15, but there could be other IP

addresses. Obtain them all using the command-line example in the PDF that combines

cat, awk, sort and uniq.

11. Nonetheless, most connections are originated in this local IP address. Execute "grep

^10.0.0.15 access.log | tail -5". It seems the attacker uploaded a file c99.php somewhere/nin the WordPress document root. Usually WP's document root is under /var/www/html.

However, we are working with all mounted under /mnt/blog. Therefore, the full path is

/mnt/blog/var/www/html. Move there, then to the wordpress directory. From this point

on, you need to move to where the file c99.php is, as per the information you observed in

the log. What is the full path of this file?

12. Move to the folder (you can press TAB to complete the directories' names). Execute

"head -20 c99.php". What is suspicious?

13. What kind of file is it (other than a PHP script), used by attackers to gain persistence?

14. What are 3 ways of mitigating vulnerabilities in jQuery-File-Upload?