Rhino Hunt CTF
A full examination of the DFRWS 2005 "Rhino Hunt" evidence set: a USB key disk image and three packet captures, worked end to end on Kali Linux to reconstruct how a suspect gained access, what moved across the wire, and what was hidden on the drive.
About the Challenge
Rhino Hunt is a public digital forensics exercise published by NIST in its Computer Forensic Reference Data Sets collection. The evidence was contributed by Dr. Golden G. Richard III and was originally run as the DFRWS 2005 Rodeo Challenge. It has been used for training and coursework ever since, which makes it a common benchmark: the answers are documented, so the work can be checked rather than taken on faith.
The premise is deliberately absurd, and that is the point. Swapping contraband for rhinoceros photographs keeps the exercise free of anything genuinely objectionable while leaving the investigative problem completely intact. The evidence handling, the carving, the packet analysis, and the correlation work are identical to what a real case would demand.
New Orleans passes a law in 2004 making possession of nine or more unique rhinoceros images a serious crime. A network administrator at the University of New Orleans notices illegal rhino traffic on his monitoring system and calls the police.
Investigators seize a computer and a USB key from one of the university labs. The computer arrives with no hard drive in it. The USB key is imaged, and the administrator hands over three packet captures involving the same machine. The suspect is the lab's primary user, a doctoral candidate who has been at the university since 1972.
The Task
Recover at least nine rhino images from the evidence, document them in a report, and answer as many of the following as the evidence supports:
- Who gave the accused a telnet/FTP account?
- What are the username and password for that account?
- What relevant file transfers appear in the network traces?
- What happened to the computer's hard drive, and 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 connecting the USB key to the network traces?
No file listing, no timeline, no starting point. Just four files and seven questions, which is a fair approximation of how a real examination begins.
What I Did
The Rhino Hunt scenario centers on a city employee suspected of trafficking rhinoceros images. The evidence provided is a dd image of a USB key that has been reformatted, plus three packet captures taken from the network. The task is to answer a set of investigative questions using nothing but that evidence.
I worked the disk image in Autopsy 2.x, reading recoverable text at the data unit level to surface the suspect's own account of what happened, and ran Foremost against the raw image to carve out files that the reformat left behind. On the network side I used Wireshark to follow TCP streams across all three captures, pulling exported objects out of FTP-DATA and HTTP transfers and tracing a reference to an executable that appeared in IMAP traffic before the file itself turned up in a separate HTTP packet.
Two pieces required cracking rather than carving. A zip archive recovered from an FTP transfer was password protected, so I ran it through John the Ripper. Separately, two alligator images pulled off the USB key turned out to be carriers for hidden rhino images embedded with jphide, which I extracted with jpseek once I worked out the passphrase.
My Findings
- The suspect was given a gnome account by a colleague, admitted in plain ASCII text recoverable from the disk image.
- Credentials for that account crossed the wire in cleartext and were readable straight out of the TCP stream.
- Six rhino images moved across the network over FTP and HTTP, one of them wrapped inside a password-protected archive.
- The USB key was reformatted with a downloaded utility that was itself first referenced in IMAP traffic, then recovered from an HTTP packet.
- An image carved from the USB key matched one exported from the network capture, tying the physical device directly to the observed traffic.
- Files that looked like throwaway noise on the drive turned out to be the key to the hidden data.
Every one of these came out of my own examination of the evidence. My full write-up below records where each finding came from, down to the packet and data unit, so the work can be followed and checked rather than taken at my word.
What I Learned
The single biggest takeaway was that reformatting a drive destroys almost nothing. The file system metadata goes away, but the underlying blocks sit there untouched until something overwrites them, which is exactly why carving works. Reading that in a textbook and watching Foremost pull intact JPEGs out of a "wiped" image are two very different experiences.
The other lesson was about correlation. Any one artifact in this challenge is suggestive on its own but not conclusive. The case only holds together because a file carved from the drive is byte for byte the same as a file exported from a capture. That habit of pinning one source of evidence against an independent one is the part that transfers directly to detection and incident response work.
It also drove home how much unencrypted protocols give away. Watching an FTP login appear in a stream in plaintext, with no effort required, makes a better argument for encryption in transit than any policy document.
Challenges & Pivots
Steganography was where I lost the most time. Detecting that an image is carrying hidden data is one problem, and extracting it is a second, harder one that needs the right tool matched to the right embedding method. I spent a long stretch working through a Docker-based stego toolkit against the carved JPEGs before landing on jphide as the method actually in use.
The passphrase was its own detour. There were several gumbo recipe files sitting on the drive that read like filler, and I treated them that way at first. They were the hint. Once I stopped sorting evidence into "relevant" and "irrelevant" before I understood the case, the passphrase was sitting in plain sight. That is a mistake I would rather make in a practice scenario than a real one.
My Examination Report
The report I wrote at the end of this project: my findings, the exhibits I recovered, and the specific packets and data units each of my conclusions came from. My own analysis and my own write-up, not the published answer key.
Download My Report (PDF)