Lately I’ve been getting into digital forensics investigation and in order to train myself I’ve been looking for some challenges. I found this awesome website which has a great compilation of challenges, research results and CTFs.
I skimmed over the different options and decided to challenge myself with The Rhino Hunt, developed by NIST.
Context
The Rhino Hunt data set requires examination of a small image file and three network traces.
This image was contributed by Dr. Golden G. Richard III, and was originally used in the DFRWS 2005 RODEO CHALLENGE.
Scenario:
The city of New Orleans passed a law in 2004 making possession of nine or more unique rhinoceros images a serious crime. The network administrator at the University of New Orleans recently alerted police when his instance of RHINOVORE flagged illegal rhino traffic. Evidence in the case includes a computer and USB key seized from one of the University’s labs. Unfortunately, the computer had no hard drive. The USB key was imaged and a copy of the dd image is on the CD-ROM you’ve been given.
In addition to the USB key drive image, three network traces are also available—these were provided by the network administrator and involve the machine with the missing hard drive. The suspect is the primary user of this machine, who has been pursuing his Ph.D. at the University since 1972.
For the purpose of solving this challenge, I have to do the following task:
Recover at least nine rhino pictures from the available evidence and include them in a brief report. In your report, provide answers to as many of the following questions as possible:
- Who gave the accused a telnet/ftp account?
- What’s the username/password for the account?
- What relevant file transfers appear in the network traces?
- What happened to the hard drive in the computer? Where is it now?
- What happened to the USB key?
- What is recoverable from the dd image of the USB key?
- Is there any evidence that connects the USB key and the network traces? If so, what?
Let’s begin!
The USB key image
First I check the integrity of the image file that I have been given. The MD5 checksum of said file can be found in the challenge’s formulation.
80348c58eec4c328ef1f7709adc56a54 RHINOUSB.dd
We acknowledge that the checksum of our file is the same:
$ md5sum RHINOUSB.dd
80348c58eec4c328ef1f7709adc56a54 RHINOUSB.dd
Now we know we are dealing with an untampered image file. Let’s gather some more information of the file:
$ fsstat RHINOUSB.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT16
OEM Name: mkdosfs
Volume ID: 0x4092d9d1
Volume Label (Boot Sector):
Volume Label (Root Directory):
File System Type Label: FAT16
Sectors before file system: 0
File System Layout (in sectors)
Total Range: 0 - 506847
* Reserved: 0 - 0
** Boot Sector: 0
* FAT 0: 1 - 248
* FAT 1: 249 - 496
* Data Area: 497 - 506847
** Root Directory: 497 - 528
** Cluster Area: 529 - 506840
** Non-clustered: 506841 - 506847
METADATA INFORMATION
--------------------------------------------
Range: 2 - 8101622
Root Directory: 2
CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 2 - 63290
FAT CONTENTS (in sectors)
--------------------------------------------
529-536 (8) -> EOF
537-544 (8) -> EOF
Before I perform any file recovery or string search on the image, I open it with a hex editor. I wanna take a look at it. The root directory of the FAT filesystem begins on sector 497, at 512 bytes per sector, this means that the offset is 254464. I find that the USB key had only two allocated files. gumbo1.txt and gumbo2.txt
A huge portion of the file is filled with the same bytes over and over. It’s like part of the disk has been manually overwritten with the message “SORRY” and “CHARLIE” (Coincidence? :P)
Ok, time to recover some data, I will be using PhotoRec, and see what I can retrieve from this weirdo.
After going through the whole image file, PhotoRec has retrieved 134 files:
- 1 .doc file
- 7 .jpg files
- 2 .gif files
- 124 .txt files
So… have I found the 9 rhino images yet? Sadly, no. There are 4 rhino images, and 5 alligator images. I proceed to document the images found by computing the MD5 checksum.
Ok, so the next logical step is to take a look at the other recovered files, staring by the .doc file, which title is
f0335017_She_died_in_February_at_the_age_of_74.doc
This seems to be some sort of personal diary. I skim over them, I’m looking for a lead. And I find it in the las two entries:
This piece of evidence shows that the suspect freaked out and got rid of the hard drive of the computer. This makes sense as the computer was found without a hard drive. Also, this leads point to the existence of more hidden pictures in the USB. The accused then formatted the USB drive, thinking that such action would erase the contents of the memory. The suspect also talks about changing a password of a “gnome account” that Jeremy gave him/her. I should take a look at the network traces and see if I can find activity related to this sentence. But first, let’s take a look at the .txt files.
At first glance, the .txt can be grouped as follows:
- Two files containing recipes
- One 53MB file, filled with the message “SORRY” over and over
- One 116.8MB file, filled with the message “CHARLIE” over and over
- 120 files of different sizes filled with the message “CHARLIE” and one last character.
I suspect that there must be a lead embedded somehow in this files. But I’m not familiar with the stego technique that may have been used. I can only guess. Also, speaking about stego… Is it possible that the alligator pictures contain rhino images or secret messages embedded in them? It would make sense, but I have no clue of which algorithm could have been used.
Maybe it’s time to look at the network traces and see if I can get any relevant data from them. The suspect had to use some script or program to hide the images and maybe I can find the download among the trace.
First network trace
I first check the integrity of the files rhino.log, rhino2.log and rhino3.log. Once I’ve done this, I proceed to open the first file with Wireshark.
It looks like the IP address used by the suspect’s machine is 137.30.122.253. This first trace contains 6557 captured packets. I decide to filter by the TELNET protocol. The TELNET communication happens between the suspect machine and a machine with IP address 137.30.120.40. There seems to be two TELNET sessions in this trace.
First TELNET session
The session starts by exchanging some parameters and the remote maching asking for a username and a password. The suspect enters the following credentials.
- Username: gnome
- Password: gnome123
After the login, the user gnome starts executing some commands on the shell: ls, du, df… and then, passwd. He wants to change his password. The first try was gnome1234 but the terminal prompted “passwd: Old and new passwords must differ by at least 3 positions.”, so he tried gnome12345. The program then exits with the message “Permission denied”.
Then the user tried to logout twice with the non-existing command “logout”, after which he wrote “exit” and successfully logged out from the remote machine.
Second TELNET session
The session starts by exchanging some parameters and the remote machine asking for a username and a password. The user tries to login with the username “golden” but fails. The user then logs in with the same credentials as the first session and then executes:
cat > JOHNREADME
And starts typing:
I tried to hack Golden’s account but the password was wrong.
- Georgia
It looks like someone is leaving a message for John. After saving the file, Georgia executes ls -l and something catches my attention. I did not mention it, but during the first session, when the user gnome executed ls -l there was only three files and now there are 7. This is a screenshot of the first session:
And here’s a screenshot of the second one:
Here are some suspicious files: rhino1.jpg, rhino3.jpg and contraband.zip. Someone must have uploaded them between the first and the second session.
After that last command the user tries to logout with the non-existing command “logout” (again), after which she wrote “exit” and successfully logged out from the remote machine.
Someone uploaded the files to the remote machine… If this has been done using the same machine that the suspect uses, there are several protocols that he could have used. But something tells me it’s gonna be FTP.
FTP session
My hypothesis was right. Just after the first TELNET session, a FTP session is started and the user gnome uploads the file rhino1.jpg
The file rhino3.jpg is uploaded right after.
The file contraband.zip on the other hand, is uploaded right before the second TELNET session.
I should be able to retrieve the files from the network packets, I’ll begin with rhino1.jpg.
First we have to find the packet with the beginning of the file. I find right after the STOR request has been accepted.
The file signature of a JPEG file is composed of two bytes: FF D8 as can be seen in the screenshot. In order to extract the whole file, I only have to right-click the packet and select Follow->TCP Stream. The We just save the data as RAW with the name “rhino1.jpg”
Looks like I found the fifth rhino! I repeat the process with the file rhino3.jpg and obtain the following image:
Now I can recover the file contraband.zip, following the same steps. But after I do it, I find that it has been encrypted. There’s only one file in it, called rhino2.jpg. What could the password be?
Second network trace
This trace contains HTTP traffic. I take a look at the HTTP objects and see that two more rhino images have been transfered. The images have been downloaded to a machine with IP 137.30.123.234 from a machine with IP 137.30.120.37 and hostname www.cs.uno.edu. The route of the images at the remote machine is: /~gnome. The names of the pictures are rhino4.jpg and rhino5.gif.
Third network trace
This trace also contains HTTP traffic. The user has downloaded an executable program called rhino.exe from a machine with IP 137.30.120.37 and hostname www.cs.uno.edu to a machine with IP 137.30.123.234. This program is maybe the one that the suspect has used to hide rhino images among those TXT files.
Second round
Let’s list all the loose ends that we still have:
- We have found an encrypted rhino picture inside a zip container, but don’t know the password.
- We have a bunch of TXT files and alligator pictures that may or may not hide relevant data.
- We have an .exe file which purpose we so far ignore.
Relevant retrieved data (so far)
Four rhino images (1 - 4) have been found stored on the USB drive. These images had been deleted, but have been recovered from the unallocated space. Two images (5 - 6) have been recovered from the rhino.log trace. Two images (7 - 8) have been recovered from the rhino2.log trace.
- f0106393.jpg with MD5sum ca03f2eed3db06a82a8a31b3a3defa24
- f0106409.jpg with MD5sum ed870202082ea4fd8f5488533a561b35
- f0106865.gif with MD5sum 76610b7bdb85e5f65e96df3f7e417a74
- f0106889.gif with MD5sum d03dc23d4ec39e4d16da3c46d2932d62
- rhino1.jpg with MD5sum d5a83cde0131c3a034e5a0d3bd94b3c9
- rhino3.jpg with MD5sum b058218ea0060092d4e01ef3d7a3b815
- rhino4.jpg with MD5sum aa64102afff71b93ed61fb100af8d52a
- rhino5.gif with MD5sum 1e90b7f70b2ecb605898524a88269029
I’ll continue the hunt in the next post!