Scan of the month challenge #27

Introduction

This is my submission for Scan of the month challenge #27. It attempts to provide answers to the #27 Scan of the Month Challenge proposed by the Honeynet Project. It is my second submission to the Honeynet Project challenges.

Answers to questions

Preliminary tasks

First at all, let's check file integrity :

[laurent@azathoth scan27]$ md5sum sotm27.gz
b4bfc10fa8346d89058a2e9507cfd9b9 sotm27.gz

OK, it's good. Now, we can uncompress the GZip archive.

[laurent@azathoth scan27]$ gzip -d sotm27.gz

One file is deflated, now, let's check what kind of file it is.

[laurent@azathoth scan27]$ file sotm27
sotm27: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 1514)

As it is a classic tcpdump capture file, we can use our favorite network protocol analyser, Ethereal. Flags are -r (Read File) and -n (Don't resolve).

[laurent@azathoth scan27]$ ethereal -nr sotm27 &

For information, capture file represents 119 hours of activity on the honeypot.

Beginning Questions

1. What is IRC?

IRC (Internet Relay Chat) is a very commonly used protocol. It is a chat protocol which allows servers to link all users wanting to access them with a special protocol (IRC) in real time. It is heavily used by underground people, in order to exchange informations, or to attack other people, that's one of the reason, IRC networks are subject to frequent attacks (and particularly, Distributed DoS).

2. What message is sent by an IRC client when it asks to join an IRC network?

Section 4.1 in RFC 1459 (Internet Relay Chat Protocol) defines the Connection Registration procedure during an initial connection between a client and an IRC server.

[PASS] PROT
NICK <nick>
USER <username> <hostname> <servername> :<realname>

Extracts from RFC 1459 :
The PASS command is used to set a 'connection password', but it seems to be deprecated.
NICK message is used to give user a nickname or change the previous one.
The USER message is used at the beginning of connection to specify the username, hostname, servername and realname of s new user. It is also used in communication between servers to indicate new user arriving on IRC, since only after both USER and NICK have been received from a client does a user become registered.

3. What is a botnet?

A good link to read is http://www.fedcirc.gov/library/documents/botNetsv32.doc.

The definition is quite straightforward: a botnet is collection of connected IRC "bots". These "bots" use IRC or related capabilities for communication, command and control. Of course, these elements are a combination of scripts and software in order to engage automated malicious activities.

4. What are botnets commonly used for?

Botnets are commonly used to perform malicious activities. Malicious activities may vary, but most are targetting massive denial of service attacks aiming at victim's bandwidth. The effectiveness of such attacks is directly linked with the number of compromised stations, and associated bandwidth. These attacks are called Distributed Denial Of Service, which can disrupt every network or service in the Internet.

5. What TCP ports does IRC generally use?

[laurent@azathoth scan27]$ grep irc /usr/local/share/nmap/nmap-services | grep tcp
irc               194/tcp    # Internet Relay Chat
irc-serv          529/tcp    #
ircs              994/tcp    # irc protocol over TLS/SSL
irc-serv          6666/tcp   # internet relay chat server
irc               6667/tcp   # Internet Relay Chat
irc               6668/tcp   # Internet Relay Chat

But, most commonly used port are 6667/TCP and 6668/TCP.

6. What is a binary log file and how is one created?

As it is said in the abstract, this binary log file is created by using snort to capture honeypot activity in tcpdump binary format. This specific one is created using snort.conf rules in order to log all network activity, with an output plugin (output log_tcpdump). This binary file is used to log every network activity. Binary log files are naturally smaller than text log files (for example, IP address field is 4 bytes in binary log file, contrary to ascii representation of an IP address...); and are faster to access (because smaller so search/matching operations can be drastically speeded up).

7. What IRC servers did the honeypot, which has the IP address 172.16.134.191, communicate with?

Let's search all connection requests for the honeypot to 6667/TCP. This could be acheived with an Ethereal filter, which is "tcp.dstport == 6667 and tcp.flags == 0002".

    No. Time        Source                Destination           Protocol Info
34821 412112.717027 172.16.134.191        209.126.161.29        TCP      1127 > 6667 [SYN] Seq=3377670478 Ack=0 Win=16384 Len=0
34849 412115.655011 172.16.134.191        209.126.161.29        TCP      1127 > 6667 [SYN] Seq=3377670478 Ack=0 Win=16384 Len=0
34930 412121.702884 172.16.134.191        209.126.161.29        TCP      1127 > 6667 [SYN] Seq=3377670478 Ack=0 Win=16384 Len=0
35739 412630.079021 172.16.134.191        66.33.65.58           TCP      1129 > 6667 [SYN] Seq=3523948626 Ack=0 Win=16384 Len=0
35740 412633.054600 172.16.134.191        66.33.65.58           TCP      1129 > 6667 [SYN] Seq=3523948626 Ack=0 Win=16384 Len=0
35741 412639.073148 172.16.134.191        66.33.65.58           TCP      1129 > 6667 [SYN] Seq=3523948626 Ack=0 Win=16384 Len=0
35742 413000.978880 172.16.134.191        66.33.65.58           TCP      1131 > 6667 [SYN] Seq=3616690575 Ack=0 Win=16384 Len=0
35743 413003.911119 172.16.134.191        66.33.65.58           TCP      1131 > 6667 [SYN] Seq=3616690575 Ack=0 Win=16384 Len=0
35744 413009.912954 172.16.134.191        66.33.65.58           TCP      1131 > 6667 [SYN] Seq=3616690575 Ack=0 Win=16384 Len=0
35745 413286.204510 172.16.134.191        63.241.174.144        TCP      1133 > 6667 [SYN] Seq=3688527302 Ack=0 Win=16384 Len=0
35762 413307.053048 172.16.134.191        217.199.175.10        TCP      1139 > 6667 [SYN] Seq=3694305514 Ack=0 Win=16384 Len=0
35776 413308.629749 172.16.134.191        209.126.161.29        TCP      1145 > 6667 [SYN] Seq=3694866121 Ack=0 Win=16384 Len=0
35777 413311.530089 172.16.134.191        209.126.161.29        TCP      1145 > 6667 [SYN] Seq=3694866121 Ack=0 Win=16384 Len=0
35778 413317.533557 172.16.134.191        209.126.161.29        TCP      1145 > 6667 [SYN] Seq=3694866121 Ack=0 Win=16384 Len=0
35779 413465.350716 172.16.134.191        66.33.65.58           TCP      1147 > 6667 [SYN] Seq=3739426084 Ack=0 Win=16384 Len=0
35780 413467.425931 172.16.134.191        66.33.65.58           TCP      1147 > 6667 [SYN] Seq=3739426084 Ack=0 Win=16384 Len=0
35781 413471.685229 172.16.134.191        66.33.65.58           TCP      1147 > 6667 [SYN] Seq=3739426084 Ack=0 Win=16384 Len=0
35782 414410.208341 172.16.134.191        209.126.161.29        TCP      1150 > 6667 [SYN] Seq=3990400851 Ack=0 Win=16384 Len=0
35783 414413.137919 172.16.134.191        209.126.161.29        TCP      1150 > 6667 [SYN] Seq=3990400851 Ack=0 Win=16384 Len=0
35784 414419.130588 172.16.134.191        209.126.161.29        TCP      1150 > 6667 [SYN] Seq=3990400851 Ack=0 Win=16384 Len=0
35794 414909.249998 172.16.134.191        209.196.44.172        TCP      1152 > 6667 [SYN] Seq=4114925005 Ack=0 Win=16384 Len=0

Five different IP address are : {209.126.161.29, 66.33.65.58, 63.241.174.144, 217.199.175.10, 209.196.44.172}.

Multiple SYN are sent to two IP address : {209.126.161.29, 66.33.65.58}. So, these servers are not responding (no RST, or no SYN/ACK), that's the reason why multiple SYN are sent.

Another Ethereal filter can provide us with interesting information, and confirm us that only 3 IRC servers were contacted. This can be acheived by sorting with Ethereal filter "irc and tcp.flags == 0002" all IP addresses that the honeypot communicate with.

209.196.44.172
217.199.175.10
63.241.174.144

Longer conversation occurs between the honeypot and IRC server located at 209.196.44.172, which is stored into a file named IRC_209.196.44.172.

63.241.174.144
NOTICE AUTH :*** Looking up your hostname...
NOTICE AUTH :*** Checking Ident
NOTICE AUTH :*** No Ident response
NICK eohisou
USER eohisou localhost localhost :eohisou
NOTICE AUTH :*** Found your hostname
:irc4.aol.com 433 * eohisou :Nickname is already in use.
ERROR :Closing Link: [eohisou@255.255.255.255] (Connection Timed Out)

217.199.175.10
TICE AUTH :*** Looking up your hostname...
NOTICE AUTH :*** Checking Ident
NOTICE AUTH :*** No Ident response
NOTICE AUTH :*** Found your hostname
NICK rgdiuggac
USER rgdiuggac localhost localhost :rgdiuggac
ERROR :Closing Link: rgdiuggac[~rgdiuggac@255.255.255.255] (Sorry, server is full - try later)

The two connection attempts to IRC servers have failed because of errors ("Nickname is already in use" or "Server is full").

8. During the observation period, how many distinct hosts accessed the botnet associated with the server having IP address 209.196.44.172?

With the help of Ethereal, i extracted the entire conversation between the IRC server (209.196.44.172) and the honeypot (172.16.134.191) into a file named IRC_209.196.44.172.

Then, i selected all JOIN requests, and count different stations joining the botnet.

[laurent@azathoth scan27]$ grep "JOIN :#" IRC_209.196.44.172 | cut -f 2 -d '@' | cut -f 1 -d ' ' | uniq | wc -l
176

So there were about 176 different stations joining the botnet during the observation period. Note that multiple identifiers are DNS names, but probability that a same station joins the network with two distinct identifier types (IP address and DNS name) is very low.

9. Assuming that each botnet host has a 56 kbps network link, what is the aggregate bandwidth of the botnet?

If each botnet has a 56 kbps network link, and if there is 15,164 distinct hosts, a simple multiplication can give us a an approximative idea of the aggregate bandwidth.

[laurent@azathoth scan27]$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
15164 * 56 / 1024
829
quit

So an aggregate bandwidth of 829 Mbps is available to malicious users, which can be very disrupting!

Intermediate Questions

1. What IP source addresses were used in attacking the honeypot?

As it is an honeypot, no connection should be present, i.e. all connection requests from the Internet to the honeypot must be considered as malicious requests (errors are possible, but it should be marginal).

Sorting all connection requests from the Internet to the honeypot should do the job for TCP connections.

Ethereal filter "ip.dst == 172.16.134.191 and tcp.flags == 0002" will catch all TCP SYN packets to the honeypot. As a lot of TCP SYN are present from different IP addresses, this can be also done via command-line utilities.

[laurent@azathoth scan27]# tcpdump -tnr sotm27 'dst host 172.16.134.191 and tcp[tcpflags] == 0002' | cut -f 1 -d ' ' | cut -f 1,2,3,4 -d '.' | sort | uniq | wc -l
     77

This give us all different IP addresses attempting to connect with TCP/SYN to the honeypot, which is stored in file SYN_list.

Looking at this file, and using the "uniq -c" command, i am able to find that some IP addresses are *really* frequent! Our efforts will be focused on these IP addresses.

105    210.22.204.101
1229   24.197.194.106
10    129.116.182.239

The same approach can be done for UDP pseudo-connections, but it is more difficult to distinguish between connection attempts from the Internet and connection responses. But if we remember that it is an honeypot, so there wouldn't be any UDP requests from the honeypot (if not compromised!).

[laurent@azathoth scan27]# tcpdump -tnr sotm27 'dst host 172.16.134.191 and udp' | cut -f 1 -d ' ' | cut -f 1-4 -d '.' | sort | uniq | wc -l
    113

This give us all different IP addresses attempting to connect with UDP to the honeypot, which is stored in file UDP_list.

IP source addresses attaking the honeypot are located in SYN_list for TCP-based attacks, and UDP_list for UDP-based attacks.

Now, my job is to focus on specific IP addresses according to ports used and frequency.

I will sort by ports used towards the honeypot in order to have a more precise idea of what happened on the honeypot.

[laurent@azathoth scan27]# tcpdump -tnr sotm27 'tcp[tcpflags] == 0002' | cut -f 3 -d ' ' | cut -f 5 -d '.' | sort | uniq -c

This give us the distribution of destination ports with TCP SYN to the honeypot, which is stored in file SYN_destport_list.

Futher analysis below will try to focus on attacks launched from IP addresses listed in file SYN_list, and discover *real* attackers that compromised the honeypot.

2. What vulnerabilities did attackers attempt to exploit?

In this part, i have tried to have multiple methodologies in order to correlate between each others. I have tried to retreive clues from an IDS, statistics of most frequent IP addresses and most frequent protocols.

Clues from an IDS:
With the famous IDS Snort, i am able to analyse a capture file off-line, i also downloaded the last rules updated for Snort in order to have a better accuracy for reducing overall amount of "false negative". Moreover, i was obliged to tune snort.conffile in order to improve detection, even if analysis will require more time, false negative overall rate will be lower.

[laurent@azathoth src ]# ./snort -c ../etc/snort.conf -r ../../scan27/sotm27

All alert messages are located in "alert" file. This file sums up about 663 alerts raised in sotm27 file! In the analysis below of attempted attacks is summarized

In this file, there were several kinds of attacks detected:

MS-SQL attacks:

[**] [1:2003:2] MS-SQL Worm propagation attempt [**]
[Classification: Misc Attack] [Priority: 2] 
03/01-15:19:11.073849 68.37.54.69:1034 -> 172.16.134.191:1434
UDP TTL:114 TOS:0x0 ID:797 IpLen:20 DgmLen:404
Len: 376
[Xref => http://vil.nai.com/vil/content/v_99992.htm][Xref => http://www.securityfocus.com/bid/5311][Xref => http://www.securityfocus.com/bid/5310]

First kind of attack is a worm propagating via a MS-SQL exploit on 1434/UDP port. A full analysis is located at http://www.caida.org/analysis/security/sapphire/. With this analysis, i learned that the MS-SQL Worm propagate itself immediatly from a successfully exploited victim to a randomly choosen IP address. So, it is possible to conclude if the honeypot has been successfully compromised or not, with a simple Ethereal filter "ip.src == 172.16.134.191 and udp.dstport == 1434" which gives nothing. So, the honeypot was not compromised with this MS-SQL Worm.

These attempts were not successfull.

[laurent@azathoth scan27]# grep 1434 alert | cut -f 2 -d ' ' | cut -f 1 -d ':' | sort | uniq | wc -l
47

For information, there are 47 different IP addresses that attempted to propagate the MS-SQL Worm unsuccessfully. Knowing that capture file is about 119 hours, that gives to us a rate of 1 attempt every 2,5 hours; and knowing that this worm was critically fast, the rate is rather low, so the capture file period was not performed during the initial propagation of the MS-SQL Worm.

SCAN SOCKS attack:

[**] [1:615:3] SCAN SOCKS Proxy attempt [**]
[Classification: Attempted Information Leak] [Priority: 2]
03/02-14:24:55.179508 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/]

This alert raised by Snort is not really interesting as the honeypot has answered to this request with a RST. So, the honeypot is not compromised with this attack or more precisely attempt to bounce via open proxies on 1080/TCP port.

SHELLCODE NOOP:

[**] [1:1390:3] SHELLCODE x86 inc ebx NOOP [**]
[Classification: Executable code was detected] [Priority: 1] 
03/05-04:39:25.163950 210.22.204.101:1678 -> 172.16.134.191:80
TCP TTL:107 TOS:0x0 ID:27400 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x7616A79E  Ack: 0x8B5A4420  Win: 0xFAF0  TcpLen: 20

11 attacks are reported from always the same source IP address: 210.22.204.101. This is a very malicious activity as executing code is transfered between the attacker and the victim, which is an obvious sign of an attempted exploit on x86 architecture.

WEB-IIS cmd.exe:

[**] [1:1002:5] WEB-IIS cmd.exe access [**]
[Classification: Web Application Attack] [Priority: 1] 
03/05-04:40:24.325966 210.22.204.101:1801 -> 172.16.134.191:80
TCP TTL:107 TOS:0x0 ID:48595 IpLen:20 DgmLen:650 DF
***AP*** Seq: 0x826B037E  Ack: 0x8C413F44  Win: 0xFAF0  TcpLen: 20

Very numerous attacks from both 210.22.204.101 and especially 24.197.194.106 which seems to have launched a CGI Scanner to the honeypot!
This kind of access attempt can be very dangerous if there is a misconfigured / vulnerable IIS server on the honeypot.

Multiple "Web" attacks:

[**] [1:1129:4] WEB-MISC .htaccess access [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/05-12:49:40.242531 24.197.194.106:4276 -> 172.16.134.191:80
TCP TTL:114 TOS:0x0 ID:30040 IpLen:20 DgmLen:73 DF
***AP*** Seq: 0x6E827F42  Ack: 0x525CDC56  Win: 0x4470  TcpLen: 20

[**] [1:974:6] WEB-IIS .... access [**]
[Classification: Web Application Attack] [Priority: 1] 
03/05-12:49:47.149246 24.197.194.106:4426 -> 172.16.134.191:80
TCP TTL:114 TOS:0x0 ID:31089 IpLen:20 DgmLen:101 DF
***AP*** Seq: 0x6EEF96FD  Ack: 0x52920E74  Win: 0x4470  TcpLen: 20
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-0229][Xref => http://www.securityfocus.com/bid/2218]

[**] [1:1142:5] WEB-MISC /.... access [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/05-12:49:47.313839 24.197.194.106:4430 -> 172.16.134.191:80
TCP TTL:114 TOS:0x0 ID:31121 IpLen:20 DgmLen:89 DF
***AP*** Seq: 0x6EF35342  Ack: 0x529484F0  Win: 0x4470  TcpLen: 20

[**] [1:1113:4] WEB-MISC http directory traversal [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/05-12:49:53.962073 24.197.194.106:4507 -> 172.16.134.191:80
TCP TTL:114 TOS:0x0 ID:31816 IpLen:20 DgmLen:69 DF
***AP*** Seq: 0x6F4A73FB  Ack: 0x52C79793  Win: 0x4470  TcpLen: 20
[Xref => http://www.whitehats.com/info/IDS297]

[**] [1:988:6] WEB-IIS SAM Attempt [**]
[Classification: Web Application Attack] [Priority: 1] 
03/05-12:49:54.864278 24.197.194.106:4522 -> 172.16.134.191:80
TCP TTL:114 TOS:0x0 ID:31915 IpLen:20 DgmLen:90 DF
***AP*** Seq: 0x6F59A3A5  Ack: 0x52D0E9DE  Win: 0x4470  TcpLen: 20
[Xref => http://www.ciac.org/ciac/bulletins/h-45.shtml]

[**] [1:1661:3] WEB-IIS cmd32.exe access [**]
[Classification: Web Application Attack] [Priority: 1] 
03/05-12:50:20.641215 24.197.194.106:1156 -> 172.16.134.191:80
TCP TTL:114 TOS:0x0 ID:34394 IpLen:20 DgmLen:74 DF
***AP*** Seq: 0x713921D7  Ack: 0x53ADE58E  Win: 0x4470  TcpLen: 20

[**] [1:1165:6] WEB-MISC Novell Groupwise gwweb.exe access [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/05-12:51:12.097419 24.197.194.106:1340 -> 172.16.134.191:80
TCP TTL:114 TOS:0x0 ID:35484 IpLen:20 DgmLen:74 DF
***AP*** Seq: 0x7284D571  Ack: 0x54C96FAE  Win: 0x4470  TcpLen: 20
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-1006][Xref => http://www.securityfocus.com/bid/879]

[**] [1:1373:5] WEB-ATTACKS conf/httpd.conf attempt [**]
[Classification: access to a potentially vulnerable web application] [Priority: 2] 
03/05-12:51:16.253421 24.197.194.106:1359 -> 172.16.134.191:80
TCP TTL:114 TOS:0x0 ID:35581 IpLen:20 DgmLen:94 DF
***AP*** Seq: 0x729BD514  Ack: 0x54E2DAED  Win: 0x4470  TcpLen: 20

I have listed several web attacks attempts from IP 24.197.194.106, which can be very classic such as "Directory traversal" and ".htaccess".

IRC-based alerts:

[**] [1:542:8] CHAT IRC nick change [**]
[Classification: Misc activity] [Priority: 3] 
03/06-05:56:16.794916 172.16.134.191:1133 -> 63.241.174.144:6667
TCP TTL:127 TOS:0x0 ID:37983 IpLen:20 DgmLen:95 DF
***AP*** Seq: 0xDBDA75C7  Ack: 0x926718DE  Win: 0x42DD  TcpLen: 20

[**] [1:542:8] CHAT IRC nick change [**]
[Classification: Misc activity] [Priority: 3] 
03/06-05:56:37.569359 172.16.134.191:1139 -> 217.199.175.10:6667
TCP TTL:127 TOS:0x0 ID:38012 IpLen:20 DgmLen:101 DF
***AP*** Seq: 0xDC32A0EB  Ack: 0x97EE9F11  Win: 0x43D7  TcpLen: 20

[**] [1:542:8] CHAT IRC nick change [**]
[Classification: Misc activity] [Priority: 3] 
03/06-06:23:19.767469 172.16.134.191:1152 -> 209.196.44.172:6667
TCP TTL:127 TOS:0x0 ID:38687 IpLen:20 DgmLen:101 DF
***AP*** Seq: 0xF544C5CE  Ack: 0xFE4C0163  Win: 0x43D7  TcpLen: 20

[**] [1:1463:5] CHAT IRC message [**]
[Classification: Misc activity] [Priority: 3] 
03/06-09:19:32.965697 209.196.44.172:6667 -> 172.16.134.191:1152
TCP TTL:52 TOS:0x0 ID:7796 IpLen:20 DgmLen:132 DF
***AP*** Seq: 0xFE52376D  Ack: 0xF544C8DA  Win: 0x7D78  TcpLen: 20

Such alerts are interesting as IRC activities is *always* malicious activities, especially from an honeypot!

WEB-IIS attack:

[**] [1:1042:6] WEB-IIS view source via translate header [**]
[Classification: access to a potentially vulnerable web application] [Priority: 2] 
03/06-09:57:28.942032 66.8.163.125:3746 -> 172.16.134.191:80
TCP TTL:114 TOS:0x0 ID:5314 IpLen:20 DgmLen:190 DF
***AP*** Seq: 0x6E394D48  Ack: 0xDEE2EA62  Win: 0xFF3C  TcpLen: 20
[Xref => http://www.securityfocus.com/bid/1578][Xref => http://www.whitehats.com/info/IDS305]

Another IIS-based attack...

Clues from statistics of most frequent IP addresses:

Looking at SYN_list with "uniq -c" command, i am able to grep some very frequent IP addresses.

105 210.22.204.101
1229 24.197.194.106
10 129.116.182.239

24.197.194.106:
First a scan on low numbers TCP ports (full handshake scan : TCP_connect): 1-80, 111, 1433, 21, 139, 110
From frames 21378 to 31668 : Multiple SYNs to 80/TCP.
Brute force attack with a CGI scanner!

129.116.182.239:
From frames 32902 to 33205 :
Connexion to IPC$, retreiving informations about Domains, Users and Shares
Connection to \srvsvc to retreive informations about Shares
Connection to \samr to retreive informations about Users & Domains
Tried to connect to C$ share, but didn't succeed.

210.22.204.101:
From 901 to 1151: just retreiving informations.
3 SYNs to 1433, 139 and 445. Only 139 and 445 are open as SYN/ACK are returned by the honeypot.
Via 445/TCP, attacker tries to retreive some informations about the honeypot by accessing to \samr via IPC$ share.
The honeypot gives this information :
DOMAINS : PC0191, Builtin
USERS : Administrator, Guest, IUSR_PC0191, IWAM_PC0191, TsInternetUser

From 1157 to 1179:
Connection attempt to IPC$ share with "Administrator" username, which is successfull.

From 1180 to 1356:
21 requested authentications with "Administrator" username. Server doesn't accept these authentications. This seems to be a little brute force access on Administrator account.
All requested authentications are rejected with "STATUX_LOGON_FAILURE" and "Bad Userid" error codes.

From 1357 to 1824 (timeframe : 21 seconds):
Frame 1369 shows that the attacker tries to connect to the honeypot with username "Administrator".
Frame 1371 shows that the attacker tries to connect to the IPC$ share.
Frame 1390 same that up.
All attacks are success (STATUS_SUCCESS) in honeypot responses.
Frame 1392 shows that attackers tries to get C$ file, but an error of transaction occured (NO_SUCH_DEVICE)
Frame 1396 is important as the attacker tries to upload in \WINNT\System32\ a file called r_server.exe. Next result code informs us that transaction is accepted.
Frame 1649: file raddrv.dll is uploaded.
Frame 1688: file admdll.dll is uploaded.

These files uploaded are successfull, this is a backdoor called radmind located at http://www.radmin.com.

Frame 1800:

1800 322270.373430 210.22.204.101 -> 172.16.134.191 DCERPC Request: call_id: 6 opnum: 24 ctx_id: 0

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

This shows us that after the radmin tool was uploaded, the attacker wanted to start it as a service, in order to have a full activation of the remote backdoor even after a reboot...

From 1829 to 2038 :
First validation that there is an http listener on 80/TCP port. Then multiple GET /NULL.IDA?[BUFFER] attacks, there were 11 attacks performed with this exploit.

Banner presented by the honeypot is :

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 05 Mar 2003 02:01:58 GMT
Connection: Keep-Alive
Content-Length: 1270
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQQQQGSDY=HJEPJAHAMHNCEDKBGNIFPBEN; path=/
Cache-control: private

Which allows the attacker to launch specific IIS attacks.

From 2052 to 2069: 210.22.204.101 tries to connect to 172.16.134.191 on 6129/TCP port, but target answers with RST to inform that TCP port is closed. This is weird, because 210.22.204.101 now tries to connect to 4899/TCP port. Timeframes can give us the information that this is a human controlled action since 133 seconds have been past.

From 2070 to 3082: conversation between 210.22.204.101 and 172.16.134.191 on 4899/TCP port.

The extracted conversation is not cleartext, and strings doesn't help us anymore. This could be very interesting, as a backdoor conversation with data ciphering. Looking at http://www.radmin.com, i learned that default communication port for this backdoor (or Remote Administration!) is 4899/TCP, and this communication is encrypted ("128 bit strong encryption is used to encrypt all data streams and and it's optimized with a performance loss of only 5%").

Elapsed 237 seconds give us the information that there is a high probability that the backdoor is controlled manually.

Frames 3083-3087 are resent SYN from 210.22.204.101 to 172.16.134.191 on 4899/TCP.

Clues from statistics of most frequent TCP ports:

Looking at SYN_destport_list, i am able to grep some very frequent and interesting destination protocols.

 1 1080
 9 110
 84 139
 23 1433
 15 21
 3 31337
 19 445
 10 4899
 10 57
 9 6129
 21 6667
 1159 80
 43 99

With such informations, i am able to use Ethereal filters to have an improved accuracy in my analysis.

Port 80/TCP or HTTP attacks
A simple filter "tcp.dstport == 80 and tcp.flags == 0002 and ip.dst == 172.16.134.191" on Ethereal gives us a list of 7 different IP addresses.

213.23.49.158
68.169.174.108
210.22.204.101
24.197.194.106
192.130.71.66
218.25.147.83
66.8.163.125

213.23.49.158, 68.169.174.108, 192.130.71.66:
Nothing special, just HTTP requests.

210.22.204.101:
Several attacks with NULL.IDA IIS vulnerability. Further informations about such attacks can be found at http://www.eeye.com/html/Research/Advisories/AD20010618.html.

24.197.194.106:
HTTP attacks cgi scanner, not succeeded, because there is no CODE HTTP 200 OK resulting from these requests.

218.25.147.83:
Attack with GET /default.ida?BUFFER, but not succeeded. This is a Code Red worm attack.

Content-type: text/xml
HOST:www.worm.com
Accept: */*
Content-length: 3569
c:\notworm LMTH
<html><head><meta http-equiv="Content-Type" content="text/html; charset=english"><title>HELLO!</title></head><bady><hr size=5>Welcome to http://www.worm.com ! Hacked By Chinese!</hr></bady></html

66.8.163.125:
This is not an attack.

All HTTP attacks were not successfull as no return trafic was observed.

SAMR attacks
129.116.182.239:
Nothing special: EnumDomains and EnumDomainsUsers. This is successfull.
195.36.247.77:
Nothing special: EnumDomains and EnumDomainsUsers. This is successfull.
209.45.125.69:
Nothing special: EnumDomains and EnumDomainsUsers. This is successfull.
210.22.204.101:
Analysed in specific IP address attacker analysis.
61.111.101.78:
Nothing special: EnumDomains.
66.139.10.15:
Nothing special: EnumDomains and EnumDomainsUsers. This is successfull.

Of course, most are asking informations about "Administrator" account!

SMB attacks
What is the most insteresting is filtering with "Path" access, such as uploading attemps to Windows shares.

Two IP addresses have successfully uploaded tools on the honeypot:
210.22.204.101: files raddrv.dll, r_server.exe, admdll.dll
61.111.101.78: file inst.exe

Back Orifice attacks
In this case, with "tcp.dstport == 31337" Ethereal filter, i observed that the honeypot attempted to connect to 199.107.7.2 to 31337/TCP port! This is an obvious proof of a compromised honeypot. This occured at frames 39390-39397. No server were listening at this IP address.
These attempts were not successfull.

Port 110/TCP attempts
In this case, with "tcp.dstport == 110" Ethereal filter, i observed that 24.197.194.106 attempted to connect to the honeypot on 110/TCP port! No server were listening at this IP address.
These attempts were not successfull.

Port 1433/TCP attempts
In this case, with "tcp.dstport == 1433" Ethereal filter, i observed that multiple IP addresses (and particularly 24.197.194.106) attempted to connect to the honeypot on 1433/TCP port! No server were listening at this IP address.
These attempts were not successfull.

Port 21/TCP attempts
In this case, with "tcp.dstport == 21" Ethereal filter, i observed that multiple IP addresses (and particularly 24.197.194.106) attempted to connect to the honeypot on 21/TCP port! No server were listening at this IP address.
These attempts were not successfull.

Port 4899/TCP attempts
In this case, with "tcp.dstport == 4899" Ethereal filter, i observed that two IP addresses (210.22.204.101 and 24.197.194.106) attempted to communicate with the honeypot on 4899/TCP port! A server was listening at the honeypot address, which is a sign of a compromised honeypot. Note that second IP 24.197.194.106 is only noise, as it is a request from a CGI Scanner.
Communication between the attacker and the compromised honeypot is successfull!

Port 99/TCP attempts
In this case, with "tcp.dstport == 99" Ethereal filter, i observed that 210.22.204.101 attempted to connect to the honeypot on 99/TCP port! No server were listening at this IP address. These attempts are before successfull 4899/TCP requests, that shows that attacker has done first an error!
These attempts were not successfull.

Port 6129/TCP attempts
In this case, with "tcp.dstport == 6129" Ethereal filter, i observed that 210.22.204.101 attempted to connect to the honeypot on 6129/TCP port! No server were listening at this IP address. These attempts are before successfull 4899/TCP requests, that shows that attacker has done first an error!
These attempts were not successfull.

Attempts from the honeypot on 80/TCP port
Looking carefully at the capture file with an Ethereal filter "ip.src == 172.16.134.191 and http.request" gives us the file GET_list_from_honeypot.
This is a clear sign (like for Back Orifice attempts) that the honeypot was compromised, as no connection should be initiated from the honeypot.
In particular, the attacker (or scripts) attempted to retreive some tools such as Fport.zip from http://www.foundstone.com.

3. Which attacks were successful?

Reponses are based on analysis below.

MS-SQL Worms attacks were not successfull because the honeypot didn't performed same MS-SQL attacks.
Attacker 218.25.147.83 is a Code Red worm, which attack was not successfull.
Attacker 24.197.194.106 has done a low-numbered TCP port scanning, and then used a CGI scanner to take control over the honeypot. No attacks were successful as no HTTP replies were detected from the honeypot.
SAMR information leaks are successfull, with enumeration of sensible informations (Domains, Users, ...)
Attacker 210.22.204.101 successfully hacked the honeypot with uploading a backdoor, via SMB shares. Then he controlled the honeypot with a stealthy channel, and then he joined an IRC botnet.
Attacker 61.111.101.78 successfully uploaded a file called "inst.exe".

Summary

Lot of attack attempts were performed on the honeypot, especially with SMB-based protocols and MS-SQL worms during a 119 hours capture log. This challenge shows one more time that a default system directly connected to the Internet has a very short life esperancy, and it can be very critical as the system can be used to engage malicious activities as DDoS...

General Questions (not judged)

1. What did you learn about analysis as a result of studying this scan?

I was obliged to focus on specific aspects of SMB mechanisms that are rather *complex* in my opinion. I have also learned to improve analysis methodology in order to both reduce time needed, and false negative.

2. How do you anticipate being able to apply your new knowledge and skills?

Perhaps in next SOTM challenges ;)

3. How can we improve the SotM challenge? What would you like to see added? What would you like to see done differently?

Keep up good work guys! Such technical challenges are a real opportunity to validate skills, and of course to improve skills in both technical area and redactional efforts. From an other point of view, I would like to see more challenges based on Rootkit analysis, especially a LKM rootkit if possible!

References

Snort -- www.snort.org
Tcpdump -- www.tcpdump.org
Ethereal -- www.ethereal.com
Mozilla for HTML editing -- www.mozilla.org
Google for Web searching -- www.google.com

Contact information

Laurent Butti
e-mail: laurent.butti@francetelecom.com

Last revision: April, 25th.