All is revealed
I left off in Part 2 of the article just at the point where we had converted the “ASM” to what it actually is ie: a PERL script. This script as we saw actually created a socket on the local computer, which in turn connected to an IRC server. The ultimate goal of this? In all likelihood to create a bot army that will probably be used in a DDoS attack on some site or online user.
When doing this kind of analysis always make sure that you are logging the packets themselves. To that end I would recommend using windump for win32, or tcpdump for Linux. If you do use these programs please remember to also download and install the appropriate winpcap, or libpcap library as well. You will find links to these libraries on the pages of both aforementioned packet capturing programs. This is very important as you will later on want to review exactly what transpired at the packet level.
Lastly I would encourage you to always log your packets in binary format vice ascii. Why? Simply because logging in binary gives you more options. Snort the open source IDS will process binary input but not ascii. The same can be said for windump and tcpdump, which will also process binary logs. They will not however as mentioned process flat ascii logs. Bottom line here is that you can always output an ascii file from a binary one. You cannot however create a binary log from an ascii file.
All that being said how about we start looking at the packet trace, which was generated when I executed the exploit code. I will comment on the packets that we see below directly beneath the packets themselves. The first packet seen is indeed the very first packet generated by the trojan PERL script.
linux:/home/Don/Documents # tcpdump -nXvSs 0 ip and host 192.168.1.102
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
Seen above are the command line options I gave to tcpdump to collect this traffic.
10:46:36.797201 IP (tos 0x10, ttl 64, id 50697, offset 0, flags [DF], length: 55) 192.168.1.102.1037 > 24.153.22.67.53: [udp sum ok] 42190+ A? ir3ip.net. (27)
0x0000 4510 0037 c609 4000 4011 83b2 c0a8 0166 E..7..@.@……f
0x0010 1899 1643 040d 0035 0023 18bd a4ce 0100 …C…5.#……
0x0020 0001 0000 0000 0000 0569 7233 6970 036e ………ir3ip.n
0x0030 6574 0000 0100 01 et…..
My lab box sends a query to my ISP’s DNS server to resolve the address
10:46:41.797473 IP (tos 0x10, ttl 64, id 55698, offset 0, flags [DF], length: 55) 192.168.1.102.1038 > 24.153.23.66.53: [udp sum ok] 42190+ A? ir3ip.net. (27)
0x0000 4510 0037 d992 4000 4011 6f2a c0a8 0166 E..7..@[email protected]*…f
0x0010 1899 1742 040e 0035 0023 17bd a4ce 0100 …B…5.#……
0x0020 0001 0000 0000 0000 0569 7233 6970 036e ………ir3ip.n
0x0030 6574 0000 0100 01 et…..
My lab box is again hitting my ISP’s other DNS server to resolve the address. Another exact same packet was sent, but was snipped out by me for reasons of brevity.
10:46:54.087925 IP (tos 0x0, ttl 248, id 19941, offset 0, flags [DF], length: 149) 24.153.23.66.53 > 192.168.1.102.1038: [udp sum ok] 42190 1/2/2 ir3ip.net. A 212.210.194.124 (121)
0x0000 4500 0095 4de5 4000 f811 4289 1899 1742 E…M.@…B….B
0x0010 c0a8 0166 0035 040e 0081 85e8 a4ce 8180 …f.5……….
0x0020 0001 0001 0002 0002 0569 7233 6970 036e ………ir3ip.n
0x0030 6574 0000 0100 01c0 0c00 0100 0100 0002 et…………..
0x0040 5800 04d4 d2c2 7cc0 0c00 0200 0100 0002 X…..|………
0x0050 5800 1003 6e73 3207 7068 6f65 6e69 7802 X…ns2.phoenix.
0x0060 6974 00c0 0c00 0200 0100 0002 5800 0603 it……….X…
0x0070 6e73 31c0 3bc0 5300 0100 0100 0009 6400 ns1.;.S…….d.
0x0080 043e a921 0ac0 3700 0100 0100 0009 6300 .>.!..7…….c.
0x0090 043e a920 0a .>…
My ISP’s DNS responds with the answer to the query the laptop sent it.
10:46:54.088752 IP (tos 0x0, ttl 64, id 2073, offset 0, flags [DF], length: 60) 192.168.1.102.1063 > 212.210.194.124.6667: S [tcp sum ok] 1976828302:1976828302(0) win 5840 <mss 1460,sackOK,timestamp 5245335 0,nop,wscale 0>
0x0000 4500 003c 0819 4000 4006 d945 c0a8 0166 E..<..@[email protected]…f
0x0010 d4d2 c27c 0427 1a0b 75d4 018e 0000 0000 …|.’..u…….
0x0020 a002 16d0 385e 0000 0204 05b4 0402 080a ….8^……….
0x0030 0050 0997 0000 0000 0103 0300 .P……….
With the name now resolved to an IP address my lab box now proceeds with setting up a connection. The packet above is the first step in the TCP/IP three way hand shake, and is also known as the syn packet. This is used to synchronize sequence numbers. You can see in this packet that my lab laptop is indeed initiating communications with the remote IRC server after having had the trojan code executed on it.
10:46:57.088090 IP (tos 0x0, ttl 64, id 2074, offset 0, flags [DF], length: 60) 192.168.1.102.1063 > 212.210.194.124.6667: S [tcp sum ok] 1976828302:1976828302(0) win 5840 <mss 1460,sackOK,timestamp 5248335 0,nop,wscale 0>
0x0000 4500 003c 081a 4000 4006 d944 c0a8 0166 E..<..@[email protected]…f
0x0010 d4d2 c27c 0427 1a0b 75d4 018e 0000 0000 …|.’..u…….
0x0020 a002 16d0 2ca6 0000 0204 05b4 0402 080a ….,………..
0x0030 0050 154f 0000 0000 0103 0300 .P.O……..
We see above that my lab laptop sends out another syn packet to the IRC server. This is odd, or is it? Not odd at all actually. What is happening here is that the IRC server did not respond within three seconds so my laptop sent another syn packet. For those of you who don’t recognize this it is called a syn retry. A legal packet as it follows the conventions of TCP/IP.
10:46:57.761177 IP (tos 0x0, ttl 42, id 0, offset 0, flags [DF], length: 60) 212.210.194.124.6667 > 192.168.1.102.1063: S [tcp sum ok] 3389802460:3389802460(0) ack 1976828303 win 5792 <mss 1460,nop,nop,timestamp 67593225 5245335,nop,wscale 0>
0x0000 4500 003c 0000 4000 2a06 f75e d4d2 c27c E..<..@.*..^…|
0x0010 c0a8 0166 1a0b 0427 ca0c 47dc 75d4 018f …f…’..G.u…
0x0020 a012 16a0 c184 0000 0204 05b4 0101 080a …………….
0x0030 0407 6409 0050 0997 0103 0300 ..d..P……
Ah ha! Finally the IRC server wakes up, and responds to my lab laptop with the next step in the TCP/IP handshake ie the syn/ack.
10:46:57.761259 IP (tos 0x0, ttl 64, id 2075, offset 0, flags [DF], length: 52) 192.168.1.102.1063 > 212.210.194.124.6667: . [tcp sum ok] ack 3389802461 win 5840 <nop,nop,timestamp 5249008 67593225>
0x0000 4500 0034 081b 4000 4006 d94b c0a8 0166 E..4..@[email protected]…f
0x0010 d4d2 c27c 0427 1a0b 75d4 018f ca0c 47dd …|.’..u…..G.
0x0020 8010 16d0 debf 0000 0101 080a 0050 17f0 ………….P..
0x0030 0407 6409 ..d.
My laptop then finishes the handshake by sending the IRC server the ack packet seen above. The two computers are now ready to exchange data.
10:46:57.761562 IP (tos 0x0, ttl 64, id 2076, offset 0, flags [DF], length: 76) 192.168.1.102.1063 > 212.210.194.124.6667: P [tcp sum ok] 1976828303:1976828327(24) ack 3389802461 win 5840 <nop,nop,timestamp 5249008 67593225>
0x0000 4500 004c 081c 4000 4006 d932 c0a8 0166 E..L..@[email protected]…f
0x0010 d4d2 c27c 0427 1a0b 75d4 018f ca0c 47dd …|.’..u…..G.
0x0020 8018 16d0 74ca 0000 0101 080a 0050 17f0 ….t……..P..
0x0030 0407 6409 5553 4552 206b 202b 6920 6b20 ..d.USER.k.+i.k.
0x0040 3a6b 7631 0a4e 4943 4b20 6b0a :kv1.NICK.k.
Wasting little time my now trojaned laptop signs into the IRC server with the nick K. We can see this is the ascii content on the right of the packet. In the interests of brevity I have snipped out the remaining packets, which were exchanged during the sign on to the IRC server. All that is missing is the remainder of the normal logging when one signs onto an IRC server.
10:48:31.900760 IP (tos 0x0, ttl 64, id 2081, offset 0, flags [DF], length: 77) 192.168.1.102.1063 > 212.210.194.124.6667: P [tcp sum ok] 1976828327:1976828352(25) ack 3389804070 win 8688 <nop,nop,timestamp 5343162 67602681>
0x0000 4500 004d 0821 4000 4006 d92c c0a8 0166 E..M.!@.@..,…f
0x0010 d4d2 c27c 0427 1a0b 75d4 01a7 ca0c 4e26 …|.’..u…..N&
0x0020 8018 21f0 8abc 0000 0101 080a 0051 87ba ..!……….Q..
0x0030 0407 88f9 4a4f 494e 2023 3078 0a50 5249 ….JOIN.#0x.PRI
0x0040 564d 5347 2023 3078 203a 4869 0a VMSG.#0x.:Hi.
Now we pick up where my trojaned laptop is actually joining a specific chat room on the IRC server. Then my laptop sends the words “Hi” as evidenced by the “PRIVMSG”. This would be the chat room the person who wrote this trojan created to see how his/her bot army is going.
10:48:32.043346 IP (tos 0x0, ttl 42, id 9116, offset 0, flags [DF], length: 163) 212.210.194.124.6667 > 192.168.1.102.1063: P [tcp sum ok] 3389804070:3389804181(111) ack 1976828327 win 5792 <nop,nop,timestamp 67602700 5343111>
0x0000 4500 00a3 239c 4000 2a06 d35b d4d2 c27c E…#.@.*..[…|
0x0010 c0a8 0166 1a0b 0427 ca0c 4e26 75d4 01a7 …f…’..N&u…
0x0020 8018 16a0 45d8 0000 0101 080a 0407 890c ….E………..
0x0030 0051 8787 7365 7276 2068 656c 700d 0a3a .Q..serv.help..:
0x0040 6972 3369 702e 616d 7072 2e6f 7267 2033 ir3ip.ampr.org.3
0x0050 3732 206b 203a 2d20 0d0a 3a69 7233 6970 72.k.:-…:ir3ip
0x0060 2e61 6d70 722e 6f72 6720 3337 3220 6b20 .ampr.org.372.k.
0x0070 3a2d 200d 0a3a 6972 3369 702e 616d 7072 :-…:ir3ip.ampr
0x0080 2e6f 7267 2033 3736 206b 203a 456e 6420 .org.376.k.:End.
0x0090 6f66 202f 4d4f 5444 2063 6f6d 6d61 6e64 of./MOTD.command
0x00a0 2e0d 0a …
This is just a message from the IRC server. I have snipped the next two packets as they held no important information.
10:48:32.279645 IP (tos 0x0, ttl 42, id 9118, offset 0, flags [DF], length: 230) 212.210.194.124.6667 > 192.168.1.102.1063: P [tcp sum ok] 3389804181:3389804359(178) ack 1976828352 win 5792 <nop,nop,timestamp 67602723 5343344>
0x0000 4500 00e6 239e 4000 2a06 d316 d4d2 c27c E…#.@.*……|
0x0010 c0a8 0166 1a0b 0427 ca0c 4e95 75d4 01c0 …f…’..N.u…
0x0020 8018 16a0 639f 0000 0101 080a 0407 8923 ….c……….#
!! These lines have been snipped for privacy !!
0x0070 6d20 4a4f 494e 203a 2330 780d 0a3a 6972 m.JOIN.:#0x..:ir
0x0080 3369 702e 616d 7072 2e6f 7267 2033 3533 3ip.ampr.org.353
0x0090 206b 2040 2023 3078 203a 6b20 404b 2d4c .k.@.#0x.:k.@K-L
0x00a0 4f52 5420 404b 696e 6120 4057 6172 4368 ORT.@Kina.@WarCh
0x00b0 696c 6420 0d0a 3a69 7233 6970 2e61 6d70 ild…:ir3ip.amp
0x00c0 722e 6f72 6720 3336 3620 6b20 2330 7820 r.org.366.k.#0x.
0x00d0 3a45 6e64 206f 6620 2f4e 414d 4553 206c :End.of./NAMES.l
0x00e0 6973 742e 0d0a ist…
It is here in this packet that my laptop has its identity revealed to the channel, which is why I snipped out the offending lines. This was done for privacy reasons. Also in the packet above we see what appears to be the chat room moderators ie: @K-LORT @Kina , and @WarChild. These may be the people who are attempting to harvest a bot army. I stress the maybe part. There is about another half dozen packets I have snipped out following this one, as they do not contain anything interesting.
115) 192.168.1.102.1063 > 212.210.194.124.6667: P [tcp sum ok] 1976828352:1976828415(63) ack 3389804429 win 11584 <nop,nop,timestamp 5353340 67603702>
0x0000 4500 0073 0825 4000 4006 d902 c0a8 0166 E..s.%@.@……f
0x0010 d4d2 c27c 0427 1a0b 75d4 01c0 ca0c 4f8d …|.’..u…..O.
0x0020 8018 2d40 4705 0000 0101 080a 0051 af7c ..-@G……..Q.l
0x0030 0407 8cf6 5052 4956 4d53 4720 2330 7820 ….PRIVMSG.#0x.
0x0040 3a75 6964 3d30 2872 6f6f 7429 2067 6964 :uid=0(root).gid
0x0050 3d30 2872 6f6f 7429 2067 726f 7570 733d =0(root).groups=
0x0060 3028 726f 6f74 292c 3634 2870 6b63 7331 0(root),64(pkcs1
0x0070 3129 0a 1).
Seemingly in this packet my laptop reports to the chat room that it has root access on the laptop. This is seen by the uid=0 and gid=0
It is at this point that I have snipped out the remainder of the traffic log I sniffed. I have done this largely for any possible legal issues. Though I am not a lawyer I do practice CYA in certain areas. Reason it is snipped is because at this point the apparent moderators of this group start chatting about the exploited boxes. Lastly there are other boxes signing in as well, and whose privacy I do not wish to infringe upon. So having found out what is going on exactly at this point I myself pull the plug on this venture and simply disconnect the CAT 5 jack.
To sum up I hope that you have learned some valuable lessons here. It is fine to play with exploit code, as it is a legitimate computer security exercise. Bearing in mind though what I just chronicled you would be wise to do so in a safe lab environment. When something appears too good to be true it is probably because it is. The authors of the trojan preyed upon peoples desire of 0 day exploit code. All told it was a semi-effective ploy, but it would only fool the novice computer user. I sincerely hope that this article series was of some use to you. Should you have any questions please do not hesitate to contact me.
