209.67.78.200.3411 > mydns.com.33434: udp 36 [ttl 1] 209.67.78.200.3412 > mydns.com.33434: udp 36 (ttl 2)

This output is much like you might see with a UNIX traceroute. Traceroute has the signature of attempting a UDP connection to a high-numbered port in the 33000+ range, such as seen here. This is slightly different because the standard implementation of traceroute uses incrementing destination ports. These are to static UDP destination port of 33434. The anticipated response will be a port unreachable error, in which case response time can be computed when the 3DNS software receives the response. The incrementing TTL values can also be a signature of

Traceroute, if the DNS server is inside the sensor that captured this activity.

3DNS to TCP Port 53

A final attempt to establish a connection to TCP port 53 is made if all others fail. This attempt differs from most SYN connections because you will see that 64 bytes have been included in the payload. Normal traffic has no payload until after the three-way handshake has been completed. The 64 data bytes are sent to approximate a reasonable-sized payload, one that is neither too small nor too large. The anticipated response will be either a SYN/ACK from a

listening server or a RST/ACK from one that is not listening:

209.67.78.202.2202 > mydns.com.53: S 997788921:997788985(64) win 2048 209.67.78.202.2200 > mydns.com.53: S 869896644:869896708(64) win 2048 209.67.78.202.2201 > mydns.com.53: S 1386586413:1386586477(64) win 2048 216.32.68.11.3102 > mydns.com.53: S 765045139:765045203(64) win 2048 216.32.68.11.3100 > mydns.com.53: S 865977968:865978032(64) win 2048 216.32.68.11.3101 > mydns.com.53: S 565178644:565178708(64) win 2048

This approach seems destined to fail for many sites, especially if this is the final attempt when all others have failed because of blocked access to the other methods. The problem is that most security-conscious sites block access to TCP destination port 53 because that can be used to download the DNS maps that contain all registered hosts and their IP numbers. Therefore, if traffic is blocked, perhaps they could do the measurements from an ICMP unreachable received from the router blocking the access. What if the block was done by a router that has been silenced from delivering host unreachable errors? This is just as fruitless as the other failed attempts.

Worms as Information Gatherers

If all users at your site share a common mail server, and it is configured to examine mail for viruses that have been identified, many might be eliminated before they can infect the target host. But, users might not all use the same mail server; they might not run virus eradication software; and if they do, they might not update it frequently. This increases the risk of infection.

Viruses and worms have not been viewed conventionally as information gatherers. We are starting to see a new class of worm that acts as some kind of agent to harvest or seek information. This might involve attempting connections to other hosts after a host has been infected. If this is the case, and there is some kind of IDS at an egress point of the infected host, we can observe the activity. Two such worms are examined here: Pretty Park and RingZero.

Pretty Park Worm

I was reviewing an alert about outbound blocked activity at one of our sites and discovered that an internal host was attempting to connect to an Internet Relay Chat (IRC) port 6667 on many different destination IPs. This site had blocked outbound activity to many of the conventionally used IRC ports just because the site was hard pressed to find redeeming quality in many. I'm sure it can be argued that there are many reputable and upstanding chat rooms, but often times users gravitate to ones that aren't work related. And, every summer when the new crop of cyber-connected summer students arrived, this site usually saw a couple of them try to engage in IRC activity and fail.

It was late February, a Friday afternoon to be exact, and I was seeing this activity. I reported it to the appropriate contact, and he said that he had informed the owning administrator of the detected activity. I also dumped logs of the rejected outbound activity, but didn't give them much scrutiny. Had I been more thorough, I would have discovered that the host was attempting connections to IRC sites about five times a minute. This either reflects an obsessivecompulsive desire to connect or an automated program.

On the following Monday, I received another alert about outbound IRC activity—no big deal. I just thought it was the same host I had already identified trying once again. But, I searched the logs again and found four more hosts engaged in similar activity. The scary part was that they were all going to the same destination hosts, many of them in foreign countries. And, so the inevitable thought of horror arose in my paranoid analyst's brain: We had suffered multiple compromises using a common vulnerability, and the intruder was trying to contact her home base to report the triumph. Another, more comforting (compared to a compromise) thought occurred that maybe there was some kind of worm infection.

Sure enough, when my Windows-savvy coworker examined one of the infected hosts, he located some strange programs running (FILES32.VXD and PRETTY PARK.EXE) and identified this as the Pretty Park worm. Using netstat, he discovered that the host had sent a TCP SYN to destination port 6667. Apparently, Pretty Park is a worm that arrives via an email attachment and one of the duties of the worm is to go to these IRC sites in hopes of sending back information about the hosts—things such as passwords and details about the infected host. You can get a more thorough description of Pretty Park at http://vil.nai.com/vil/wm98500.asp.

Here is an excerpt of the activity captured by TCPdump. The destination port is 6667, and the destination hosts change:

09:30:34.470000 infected.com.1218 > ircnet.grolier.net.6667: S 662405:662405(0) Âwin 8192 (DF)

09:30:37.370000 infected.com.1218 > ircnet.grolier.net.6667: S 662405:662405(0) Âwin 8192 (DF)

09:30:43.370000 infected.com.1218 > ircnet.grolier.net.6667: S 662405:662405(0) Âwin 8192 (DF)

09:30:55.370000 infected.com.1218 > ircnet.grolier.net.6667: S 662405:662405(0) Âwin 8192 (DF)

09:31:04.050000 infected.com.1220 > irc.ncal.verio.net.6667: S 691990:691990(0) Âwin 8192 (DF)

09:31:06.970000 infected.com.1220 > irc.ncal.verio.net.6667: S 691990:691990(0) Âwin 8192 (DF)

09:31:12.970000 infected.com.1220 > irc.ncal.verio.net.6667: S 691990:691990(0) Âwin 8192 (DF)

09:31:24.970000 infected.com.1220 > irc.ncal.verio.net.6667: S 691990:691990(0) Âwin 8192 (DF)

09:32:34.130000 infected.com.1222 > mist.cifnet.com.6667: F 722101:722101(0) ack 1426589426 win 8680 (DF)

09:32:43.070000 infected.com.1224 > krameria.skybel.net.6667: S 782083:782083(0) Âwin 8192 (DF)

09:32:55.070000 infected.com.1224 > krameria.skybel.net.6667: S 782083:782083(0) Âwin 8192 (DF)

09:33:04.170000 infected.com.1226 > zafira.eurecom.fr.6667: S 812112:812112(0) Âwin 8192 (DF)

The lesson here is that the theory of fusing host-based and network-based software yields the best results.

On the host-based side, we would like to believe that worm-eradication software prevents infection, but this doesn't work for all hosts. Detection was network-based in this case because logging the denied traffic was what identified a possible problem.

RingZero

Another worm, a Trojan horse known as RingZero, that sent out network traffic was discovered in September 1999. The first identified traffic pattern associated with RingZero was a Shadow detect of a scan of many different hosts for TCP port 3128, the squid proxy server port. Here is a sample of the captured activity seen by Shadow:

12:29:48.230000 4.3.2.1.1049 >	172.16.54.171.3128: S	9779697:9779697(0) win
8192 Â<mss 1460> (DF) (ttl 19,	id 9072)	9779697:9779697(0) win
12:29:58.070000 4.3.2.1.1049 >	172.16.54.171.3128: S
8192 Â<mss 1460> (DF) (ttl 19,	id 29552)	9779697:9779697(0) win
12:30:10.960000 4.3.2.1.1049 >	172.16.54.171.3128: S
8192 Â<mss 1460> (DF) (ttl 19,	id 39792)	356330349:356330349(0)
12:44:54.9600001.2.3.4.3243 > 172.16.187.212.3128: S
win Â8192 <mss 1460> (DF) (ttl	242, id 962)
12:44:57.930000 1.2.3.4.3243 >	172.16.187.212.3128: S 356330349:356330349(0)
win Â8192 <mss 1460> (DF) (ttl	242, id 11714)
12:45:03.930000 1.2.3.4.3243 >	172.16.187.212.3128: S 356330349:356330349(0)
win Â8192 <mss 1460> (DF) (ttl	242, id 22466)
12:45:15.930000 1.2.3.4.3243 >	172.16.187.212.3128: S 356330349:356330349(0)
win Â8192 <mss 1460> (DF) (ttl	242, id 33218)	20315949:20315949(0) win
12:46:13.070000 1.1.1.1.2262 >	172.16.99.110.3128: S
Â8192 <mss 1460,nop,nop,sackOK> (DF) (ttl 116, id 35676)
12:46:16.080000 1.1.1.1.2262 >	172.16.99.110.3128: S	20315949:20315949(0) win
Â8192 <mss 1460,nop,nop,sackOK> (DF) (ttl 116, id 46428)
12:46:22.070000 1.1.1.1.2262 >	172.16.99.110.3128: S	20315949:20315949(0) win
Â8192 <mss 1460,nop,nop,sackOK> (DF) (ttl 116, id 57180)
12:46:34.080000 1.1.1.1.2262 >	172.16.99.110.3128: S	20315949:20315949(0) win

Â8192 <mss 1460,nop,nop,sackOK> (DF) (ttl 116, id 2397)

Three hostile hosts (1.1.1.1, 1.2.3.4, and 4.3.2.1) scanned different internal 172.16 hosts for port 3128. When an additional investigation was performed, it was discovered that the scanning host also attempted connections to destination ports 80 (HTTP) and 8080 (alternate HTTP). Shadow filters don't look for those destination ports because they are likely to trigger a lot of false positives. A lot of sites saw similar activity, and it appeared to be coming from many different source hosts from all over the world with as many as a half dozen different scans per hour. Most of these scans hit destination addresses that didn't exist, indicating that no prior