Author: Tsukasa Ooi
Date: 2010/11/27
It is an obvious attack. SYN flood. But It has single problem. Where these SYN flood packets came from? There are two possibilities.
I guess these attack packets are from inside. For instance, malware infection.
This packet capture consists of two parts:
Each part is completely separated. The user is not (could not be?) browsing the Internet while SYN flood attack.
Enough. Let's see each parts.
Looking at the Ethernet (MAC) frame, two "machines" are communicating.
There are nothing special for now.
Look at Ethernet (MAC) frame again. I find all packets have exactly same MAC frame.
Source MAC address is exactly same as the "machine" at web-browsing part. But destination MAC address is different.
Next, I look at the IP frame.
It is obvious. If these packets came from outside and this packet capture is a whole-network capture, There must be some TCP SYN,ACK response from 192.168.0.2. But this packet capture doesn't contain any response from this server.
This packet capture is not a whole-network packet capture. It's possibly captured by the machine itself (or some network appliance.) More of that, MAC frames show me these SYN flood packets came from web-browsing machine.
So, I guess this machine is already infected and started SYN flood attack by some trigger.
It's doubtless that GIGABYTE's NIC of the web-browsing machine is a source of SYN flood attack. We need to stop these (dst=192.168.0.2) packets using router and/or firewall. We can also shut down this machine.
More of that, malware must be removed from this client machine.
I didn't know what it mean. So I decided to check web-browsing part of packet capture. Hmmm.... I think nothing here, but...
After some attempt, I checked the HTTP requests with no "Referer" header.
(Wireshark filter: http.request && !http.referer
)
Most of HTTP requests must have "Referer" (because he/she is browsing
the web as usual) so I thought many of "normal"
requests are filtered out. And that was right. All HTTP requests with
no "Referer" header is following one only:
Some requests are no suspicious. Maybe he/she entered the URL or clicked a favorite.
Some others are also no suspicious. Just a PNG file. Maybe these PNG files are read from dynamic contents (e.g. JavaScript.)
First I thought gms.ahnlab.com is suspicious (because this is the only HTTP request which User-Agent is not IE but "MeDCore".) but I could not find anything here.
Looking at http://pc200.mine.nu/pc/cmd.htm, I found this is not a HTML file. It's a password-protected ZIP file. In this time, I found pc200.mine.nu is really suspicious. This domain (mine.nu) is a (priced) domain of DynDNS service and malware author can use this service to place C&C server.
There are only two requests to pc200.mine.nu so I have to check logo1.jpg. Soon I found this (possibly) JPEG file is corrupted. Using binary editor, I found the header of the JPEG file is corrupted.
000000 09 09 ff e0 00 10 4a 46 49 46 00 01 01 01 00 60 >......JFIF.....`< 000010 00 60 00 00 ff e1 00 22 45 78 69 66 00 00 49 49 >.`....."Exif..II< 000020 2a 00 08 00 00 00 01 00 00 51 04 00 01 00 00 00 >*........Q......< 000030 00 00 00 00 00 00 00 00 ff db 00 43 00 08 06 06 >...........C....< 000040 07 06 05 08 07 07 07 09 09 08 0a 0c 14 0d 0c 0b >................< 000050 0b 0c 19 12 13 0f 14 1d 1a 1f 1e 1d 1a 1c 1c 20 >............... < 000060 24 2e 27 20 22 2c 23 1c 1c 28 37 29 2c 30 31 34 >$.' ",#..(7),014< 000070 34 34 1f 27 39 3d 38 32 3c 2e 33 34 32 ff db 00 >44.'9=82<.342...< 000080 43 01 09 09 09 0c 0b 0c 18 0d 0d 18 32 21 1c 21 >C...........2!.!< 000090 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 >2222222222222222< ...
Valid JPEG file must have {ff d8} as first two bytes. So I fix this.
000000 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 60 >......JFIF.....`< 000010 00 60 00 00 ff e1 00 22 45 78 69 66 00 00 49 49 >.`....."Exif..II< 000020 2a 00 08 00 00 00 01 00 00 51 04 00 01 00 00 00 >*........Q......< 000030 00 00 00 00 00 00 00 00 ff db 00 43 00 08 06 06 >...........C....< 000040 07 06 05 08 07 07 07 09 09 08 0a 0c 14 0d 0c 0b >................< 000050 0b 0c 19 12 13 0f 14 1d 1a 1f 1e 1d 1a 1c 1c 20 >............... < 000060 24 2e 27 20 22 2c 23 1c 1c 28 37 29 2c 30 31 34 >$.' ",#..(7),014< 000070 34 34 1f 27 39 3d 38 32 3c 2e 33 34 32 ff db 00 >44.'9=82<.342...< 000080 43 01 09 09 09 0c 0b 0c 18 0d 0d 18 32 21 1c 21 >C...........2!.!< 000090 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 >2222222222222222< ...
OK, I can open this. It's a... "Google" logo... Fine, I simply entered the password "Google" and cmd.php is decrypted successfully. content of cmd.php is as follows:
OK,1278946800,1279292400,192.168.0.2,80,0
Obvious. This is a comma-separated list and its field is formed like:
So, I will convert these UNIX-time to "normal" time.
This is the answer. Actually, about 30-seconds after requesting these files, the SYN flood attack starts! (because the time when the malware requested this file is Jul 15 already.)
TCP port number used in SYN flood attack was not "truly" random. After plotting the port number, I found bit 7 of port number is always unset. First, I thought this is a some sort of information hidden but I could not find anything else from these port numbers. I guess the program used in SYN flood attack is really a "hack". For instance, in Visual C++, RAND_MAX is 32767 (0x7fff). Not 65535 (0xffff). In this case, we don't get any random numbers >= 0x8000 (bit 15 is set.)
Of course, x86 is a little-endian machine. Number 32768 (0x8000) can represented as a byte array {00 80}. But many of network protocol -- including TCP -- is a big-endian (network byte order) protocol. So, binary array {00 80} indicating 32768 of little-endian machine, is interpreted as 128 (0x0080).
This is the answer. SYN flood program uses RAW-socket to attack and stores raw rand() number to the source port number without any conversion (like endian conversion). Bit 15 of little-endian machine is interpreted as bit 7 of network byte order. rand() in Visual C++ does not return any number which bit 15 set so port number seems really no random.