The answers

1. What is the operating system of the honeypot? How did you determine that?
   
   The honeypot runs SunOS 5.8 (Solaris 8) on a Sun Ultra. I determined this in a few ways:
   
   
   • ICMP destination (port) unreachable packets were sent back to systems doing NMB queries to UDP port 137. Most Windows-based systems would be listening on this port. Therefor, this system is very likely not a Windows-machine.
   • Secondly, the daemon running on port 6112 sent "zoberius:SunOS:5.8:sun4u" to the connecting system. Very likely this is "<hostname>:<OS>:<OS-version>:<architecture>". I looked up port 6112: dtscpd, which comes with CDE. Default Solaris 8 installs with X installed run this.
   • Thirdly, there was some exploitcode sent to 'dtscpd'. The NOP-padding "801c 4011" are Sparc-NOPs. This was discussed in the winning paper of SotM #20.
   • Fourthly, after gaining a root-shell the attacker ran (amongst other things) a "uname -a", which returned: "SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10".



2. How did the attacker(s) break into the system?
   
   Using an exploit for a bufferoverflow in the Subprocess Control Server (dtspcd) daemon running on the honeypot. The CERT advisory can be found here.
   



3. Which systems were used in this attack, and how?
   
   
   • 61.219.90.180 (Taiwanese address). From this system the honeypot was cracked using an exploit for dtspcd. There's also been a connection from this system to a root shell bound on port 1524 to install a rootkit
   • 62.211.66.16 (tin.it, Italian). From this system 'wget', 'dlp', 'solbnc' and 'ipv6sun' are downloaded.
   • 62.211.66.53 (tin.it, Italian). From this system 'sol.tar.gz' is downloaded with the above 'wget'. This file contains a rootkit.
   • 80.117.14.44 (tin.it, Italian). A system in an ADSL IP-pool, possibly and likely the home IP-address of the attacker.



4. Create a diagram that demonstrates the sequences involved in the attack
   
   

   Time	From	To	What
   17:36:25 - 17:36:37	61.219.90.180:56399	192.168.100.28:6112	Buffer-overflow in dtscpd exploited, root-shell bound to port 1524
   17:36:37 - 18:00:00	61.219.90.180:56712	192.168.100.28:1524	Some tools and a rootkit downloaded from 2 tin.it systems. Rootkit installed, logs cleaned, some daemons patched
   17:42:42 - 17:45:13	192.168.100.28:32783	62.211.66.16:21	'wget', 'dlp', 'solbnc' and 'ipv6sun' are downloaded
   17:45:29 - 17:52:40	192.168.100.28:32789	62.211.66.53:80	'sol.tar.gz' downloaded
   17:54:25 - 17:58:32	192.168.100.28	sunsolve.sun.com:21	Two downloads of official Sun patches for a couple of daemons
   18:04:07 - 18:12:40	80.117.14.44:3934	192.168.100.28:7000	The attacker configuring the bouncer, letting it connect with irc.stealth.net (an IRCnet server in the US), letting it join #agropoli2
   18:12:39 - 19:01:17	80.117.14.44:3935	192.168.100.28:7000	Sending invalid commands to the IRC-server, idling in #agropoli2 and #bobz




5. What is the purpose/reason of the ICMP packets with 'skillz' in them?
   
   They are sent by the agents of 'Stacheldraht', a DDoS-tool. Every agent sends such a packet every 10 seconds to notify the so-called 'handlers' of their presence. See this for details.



6. Following the attack, the attacker(s) enabled a unique protocol that one would not expect to find on an IPv4 network. Can you identify that protocol and why it was used?
   
   This protocol is IPv6. It's encapsulated in IPv4, creating a so-called 'tunnel'. The attacker used it to get on IRC, using 'irc6.edisontel.it' as server.



7. Can you identify the nationality of the attacker?
   
   Yes, the attacker is Italian.



8. What are the implications of using the unusual IP protocol to the Intrusion Detection industry?
   
   They need to adjust all their tools to make them IPv6-compatible. Encapsulation should be considered too.



9. What tools exist that can decode this protocol?
   
   Both ethereal and tcpdump can decode IPv6-traffic. Snort doesn't appear to do so, however, I heard there's been done some work on this.