Analysis -------- Download snort-0315@0005.log.zip and then do a md5 checksum of the downloaded file. $ md5sum snort-0315@0005.log.zip 8150645db3afa8286af31c6309825f25 snort-0315@0005.log.zip $ Unzip the file review snort-0315@0005.log Check the log if it is a tcpdump capture file $ file snort-0315@0005.log snort-0315@0005.log: tcpdump capture file (big-endian) - version 2.4 (Ethernet, capture length 1514) Get latest snort (snort version 1.8.1) source and compile Create a snort config file to recreate TCP sessions from the tcpdump capture $ cat snort.conf preprocessor frag2 preprocessor stream4 log tcp any any <> any any (session: binary;) Run snort using the above snort.conf to re-assemble TCP sessions $ snort -c snort.conf -r snort-0315@0005.log -l log Inside the log directory, all TCP sessions are logged and a simple grep shows the connection captured 03/15-17:33:23.616029 203.111.78.182:2656 -> 172.16.1.102:111 03/15-17:33:23.616049 203.111.78.182:2657 -> 172.16.1.103:111 03/15-17:33:29.035589 203.111.78.182:2658 -> 172.16.1.104:111 03/15-17:33:29.036241 203.111.78.182:2659 -> 172.16.1.105:111 03/15-17:33:29.044579 203.111.78.182:2660 -> 172.16.1.106:111 03/15-17:33:29.045235 203.111.78.182:2661 -> 172.16.1.107:111 03/15-17:33:29.053298 203.111.78.182:2662 -> 172.16.1.108:111 03/15-19:25:58.979448 216.118.21.131:137 -> 172.16.1.107:137 03/15-21:35:52.282971 211.180.229.190:1558 -> 172.16.1.101:515 03/15-21:35:52.282978 211.180.229.190:1564 -> 172.16.1.107:515 03/15-21:35:55.224358 211.180.229.190:1561 -> 172.16.1.104:515 03/15-21:35:55.247377 211.180.229.190:1560 -> 172.16.1.103:515 03/15-21:35:55.253008 211.180.229.190:1562 -> 172.16.1.105:515 03/15-21:35:55.259768 211.180.229.190:1563 -> 172.16.1.106:515 03/15-21:35:55.265661 211.180.229.190:1565 -> 172.16.1.108:515 03/15-22:08:30.974471 211.180.229.190:3329 -> 172.16.1.103:23 03/15-23:06:39.418960 209.123.128.12:4876 -> 172.16.1.103:53 03/16-00:29:39.936665 65.195.31.2:2473 -> 172.16.1.103:53 03/16-00:29:39.939751 65.195.31.2:2477 -> 172.16.1.107:53 03/16-00:29:42.453684 65.195.31.2:2476 -> 172.16.1.106:53 03/16-00:29:42.462830 65.195.31.2:2471 -> 172.16.1.101:53 03/16-01:34:07.018434 172.16.1.108:1025 -> 216.168.224.69:43 03/16-07:39:14.572339 216.120.30.132:137 -> 172.16.1.107:137 03/16-07:57:08.501186 216.160.17.139:137 -> 172.16.1.105:137 03/16-09:21:23.840485 211.185.125.124:3493 -> 172.16.1.101:111 03/16-09:21:23.857472 211.185.125.124:3495 -> 172.16.1.103:111 03/16-09:21:23.863730 211.185.125.124:3494 -> 172.16.1.102:111 03/16-09:21:23.873607 211.185.125.124:3499 -> 172.16.1.107:111 03/16-09:21:23.874409 211.185.125.124:3500 -> 172.16.1.108:111 03/16-09:21:23.893589 211.185.125.124:3497 -> 172.16.1.105:111 03/16-09:21:23.912707 211.185.125.124:3498 -> 172.16.1.106:111 03/16-09:21:24.452051 211.185.125.124:789 -> 172.16.1.103:111 03/16-09:21:24.730436 211.185.125.124:790 -> 172.16.1.103:32773 03/16-09:21:24.995382 211.185.125.124:790 -> 172.16.1.108:111 03/16-09:21:25.326967 211.185.125.124:791 -> 172.16.1.108:931 03/16-09:21:26.868126 211.185.125.124:3496 -> 172.16.1.104:111 03/16-09:21:36.312515 211.185.125.124:4450 -> 172.16.1.108:39168 03/16-09:36:04.694845 172.16.1.108:1026 -> 193.231.236.41:21 03/16-09:36:05.086302 193.231.236.41:1516 -> 172.16.1.108:113 03/16-09:36:07.088458 193.231.236.41:1519 -> 172.16.1.108:113 03/16-09:36:07.504259 193.231.236.41:1522 -> 172.16.1.108:113 03/16-09:36:21.451950 193.231.236.41:20 -> 172.16.1.108:1027 03/16-09:46:15.135480 172.16.1.108:1028 -> 216.136.129.14:25 03/16-09:46:23.795364 172.16.1.108:1029 -> 209.61.188.33:25 03/16-09:46:24.453124 209.61.188.33:43497 -> 172.16.1.108:113 03/16-10:04:45.664025 216.130.5.42:137 -> 172.16.1.107:137 03/16-10:05:35.311519 216.202.136.48:137 -> 172.16.1.102:137 There are a few probe for portmapper, LPR and dns from various site to the 172.16.1.X network. In particular, the following sessions indicates some extra activities besides probe. 03/16-09:21:23.840485 211.185.125.124:3493 -> 172.16.1.101:111 03/16-09:21:23.857472 211.185.125.124:3495 -> 172.16.1.103:111 03/16-09:21:23.863730 211.185.125.124:3494 -> 172.16.1.102:111 03/16-09:21:23.873607 211.185.125.124:3499 -> 172.16.1.107:111 03/16-09:21:23.874409 211.185.125.124:3500 -> 172.16.1.108:111 03/16-09:21:23.893589 211.185.125.124:3497 -> 172.16.1.105:111 03/16-09:21:23.912707 211.185.125.124:3498 -> 172.16.1.106:111 03/16-09:21:24.452051 211.185.125.124:789 -> 172.16.1.103:111 03/16-09:21:24.730436 211.185.125.124:790 -> 172.16.1.103:32773 03/16-09:21:24.995382 211.185.125.124:790 -> 172.16.1.108:111 03/16-09:21:25.326967 211.185.125.124:791 -> 172.16.1.108:931 03/16-09:21:26.868126 211.185.125.124:3496 -> 172.16.1.104:111 03/16-09:21:36.312515 211.185.125.124:4450 -> 172.16.1.108:39168 Careful look at the TCP Sessions data from 211.185.125.124 review that it is the attacking host and 172.16.1.108 is the victim. $ ls -al log/172.16.1.108/ -rw------- 1 xxx users 1420 Sep 5 16:35 SESSION:1026-21 -rw------- 1 xxx users 523405 Sep 5 16:35 SESSION:1027-20 -rw------- 1 xxx users 1434 Sep 5 16:35 SESSION:1028-25 -rw------- 1 xxx users 504 Sep 5 16:35 SESSION:1029-25 -rw------- 1 xxx users 2261 Sep 5 16:35 SESSION:39168-4450 -rw------- 1 xxx users 15348 Sep 5 16:35 TCP:1026-21 -rw------- 1 xxx users 229696 Sep 5 16:35 TCP:1027-20 -rw------- 1 xxx users 6136 Sep 5 16:35 TCP:1028-25 -rw------- 1 xxx users 6024 Sep 5 16:35 TCP:1029-25 -rw------- 1 xxx users 25766 Sep 5 16:35 TCP:39168-4450 -rw------- 1 xxx users 2452 Sep 5 16:35 SESSION:1025-43 -rw------- 1 xxx users 4534 Sep 5 16:35 TCP:1025-43 Answer ------ 1.The attackers used rpc.statd attack to get into the system. What modifications did they make to the break in process to both automate and make the process faster? >From the capture log, it indicates the attacking host 211.185.125.124 did a TCP port scan to 172.16.1.x network before actually doing a portmap request to victim host for registered RPC programs. TCP scan in general is faster than UDP scan. So the automation is: do a tcp scan of port 111 to a subnet for the host response tcp port 111 scan do rpc.statd attack 2.What system/country did the badguys come in from? Do a whois 211.185.125.124@whois.apnic.net gives [whois.apnic.net] % Rights restricted by copyright. See http://www.apnic.net/db/dbcopyright.html % (whois6.apnic.net) inetnum: 211.172.0.0 - 211.199.255.255 netname: KRNIC-KR descr: KRNIC descr: Korea Network Information Center country: KR admin-c: HM127-AP tech-c: HM127-AP remarks: ****************************************** remarks: KRNIC is the National Internet Registry remarks: in Korea under APNIC. If you would like to remarks: find assignment information in detail remarks: please refer to the KRNIC Whois DB remarks: http://whois.nic.or.kr/english/index.html remarks: ****************************************** mnt-by: APNIC-HM mnt-lower: MNT-KRNIC-AP changed: hostmaster@apnic.net 20000607 changed: hostmaster@apnic.net 20010606 source: APNIC person: Host Master address: Korea Network Information Center address: Narajongkeum B/D 14F, 1328-3, Seocho-dong, Seocho-ku, Seoul, 137-070, Republic of Korea country: KR phone: +82-2-2186-4500 fax-no: +82-2-2186-4496 e-mail: hostmaster@nic.or.kr nic-hdl: HM127-AP mnt-by: MNT-KRNIC-AP changed: hostmaster@nic.or.kr 20010514 source: APNIC The attacker machine is from Korea. 3.What nationality are the badguys, and how were you able to determine this? >From the catpure log log/172.16.1.108/SESSION:39168-4450 it shows that it is downloading file from ftp.home.ro and the language used in the attack script is Romanian. It can assume that the attacker is Romanian. 4.What do the answers to questions #1 and #2 tell us about the tactics the badguys are using? When the badguys attack some victum hosts, they do not necessarily use their own home machines for the attack. They will use machines outside their network/country to disguise their origin. It also indicates that they can be attacking hosts not just to root them for fun but also as stepping stones for later attacks. 5.What did you learn from this challenge? Get the real first use of snort and look at the source to figure out using log tcp any any <> any any (session: binary;) to capture SESSION in binary format instead of printable format. 6.How long did this challenge take you? Around 6 hours. Bonus Question: Can you recover the blackhat's rootkit from the Snort binary log file? If so, how? I should have the rootkit binary captured and it is in log/172.16.1.108/SESSION:1027-20 The filename is lk.tgz as shown in the log log/172.16.1.108/SESSION:1026-21 $ cp log/172.16.1.108/SESSION:1027-20 lk.tgz $ file lk.tgz lk.tgz: gzip compressed data, deflated, last modified: Sat Mar 3 11:09:06 2001, os: Unix $ tar ztvf lk.tgz drwxr-xr-x 1031/users 0 2001-02-27 04:40:30 last/ -rwxr-xr-x 1031/users 611931 2002-02-08 21:08:13 last/ssh tar: Skipping to next header gzip: stdin: invalid compressed data--format violated tar: Child returned status 1 tar: Error exit delayed from previous errors However, the file is corrupted. In fact, the file size 523405 is different from what expected 520333. -rw------- 1 andrew users 523405 Sep 6 17:20 lk.tgz 150 Opening BINARY mode data connection for lk.tgz (520333 bytes). Having tried different config of snort giving the same result. I have no idea.... Hope that the honeynet project team can shed a light on this. :-) Thanks Andrew