|
|
Authors: Arno Wagner,
wagner@tik.ee.ethz.ch,
Thomas Dübendorfer,
duebendorfer@tik.ee.ethz.ch IntroductionOn August 11th, the W32.Blaster worm appeared. It exploits an RPC vulnerability that has been known for some weeks. Characteristic for an infection attempt is a TCP connection to port 135 of the target host. Below are some observations of the network traffic the W32.Blaster generated in the SWITCH network, a moderately sized backbone network carrying roughly 5% of all Internet traffic from and to hosts in Switzerland. Observation SetupThe graphs are based on Cisco Netflow data exported by the SWITCH border routers. Due to the amount of data captured, it is split into one-hour intervals, which currently start each full hour. For all graphs the time given is the start time of such an interval. Processing an one-hour interval of data to generate these graphs took about 12 minutes on an Athlon XP 2200+.
The first graph shows the total number of unique hosts that
initiated connections to port 69/UDP (Trivial FTP) respectively to
port 135/TCP. The connections do not have to be successful to be
counted. The numbers are shown accumulated for each one-hour
measurement interval.
The second graph shows the number of unique hosts that initiated
connections to port 135/TCP. The source hosts are split into two groups
depending on whether their IP address belongs to the SWITCH autonomous
system (AS559). The numbers are shown accumulated for each one-hour
measurement interval.
The third graph shows the total number of flows to port 135/TCP, i.e. the total number of connections to this port in each one-hour measurement interval. The source hosts are split into two groups depending on whether their IP address belongs to the SWITCH autonomous system (AS559).
The fourth graph shows the total number of unique source hosts sending out ICMP packets. Additionally, the source hosts are split into two groups depending on whether their IP address belongs to the SWITCH autonomous system (AS559). Local time in Switzerland is CEST, subtract 2 hours to get UTC. InterpretationThe first unique source host graph shows that there is a base number of hosts connecting to port 135 TCP before W32.Blaster went active. This seems to be roughly 140 hosts per hour. There is an interesting small peak of 327 hosts at Sunday, 10.8.2003 18:00-19:00 UTC, 263 of which were observed in the single 5 minute interval 18:35-18:40. The activity of port 69 UDP used for trivial ftp to transfer the Blaster executable was magnified by 10 times to make it visible at all. The Blaster outbreak starts on 11.8.2003 around 16:35 UTC and results in a maximum of approx. 5'500 unique source hosts connecting to port 135 TCP in the hour of Monday, 11.8.2003 20:00-21:00 UTC. The second unique source host graph splits the traffic by origin shows that the hosts within AS559 were rather nonresponsive to the attacks until the early moring working hours of 12.8.2004. This is mostly due to Windows Internet PCs having been shut down during the night and becoming almost instantly infected after having beeing booted on this day. The flow graph shows the development a lot clearer. The normal number of connections is around 1.1 mill. per hour before the outbreak. In the hour of the outbreak the number of connection raise sharply up and reach 14.2 mill. during the interval 18:00-19:00 UTC. A peak of 21.4 mill. is reached during 12.8. 2:00-3:00 UTC. We assume that most of the ICMP traffic packets were "port" or "destination unreachable" messages. The ICMP graph shows a significant increase of ICMP messages at the time of the outbreak. ThoughtsClearly this worm had a fast initial propagation phase. However it seems to have slowed itself down very soon. More detailed analysis will hopefully show what the reasons where. The number of unique hosts generating possible attack traffic as well as the number of connections did both show a significant increase during the outbreak phase. Furthermore the number of attacking hosts seen from the SWITCH network is surprisingly low, which could be due to a very low propagation rate of the worm after the first hour. It could also be due to flaws or characteristics in the scanning strategy the worm uses. Limitations in this Observation
|
(c) 2004
at TIK CSG
ETH Zurich,
Thomas Dübendorfer,
Arno Wagner,
last change: 29th March 2005