Research

Analysis of Storm Worm DDoS Traffic


Filed under Research category.

The Peacomm (Storm Worm) botnet is known to launch DDoS attacks against networks which appear to be investigating the botnet — the cyber equivalent of explosive reactive armor. It is still unclear whether the decisions to launch an attack are made by the botnet, a human operator, or both. In exploring this, SecureWorks was able to compile and analyze information regarding timing and types of traffic that may help victims of these distributed denial-of-service attacks mitigate the impact.

If triggering an attack is a decision made by the botnet that logic would be on the C&C (command-and-control) servers. Researchers have found no code in the Trojan client-side executable for triggering a DDoS attack.

The attacks do show signs of being automated. Certain actions reliably trigger attacks. Investigators who can withstand the onslaught and have decided to test their theories (with cooperation from their ISPs, of course) can reliably trigger DDoS attacks on themselves. In one case, probing more than four unique Peacomm botnet HTTP proxies within ten seconds results in a flood of TCP SYN and ICMP packets, which last for about two hours. That’s all fairly regular.

The general characteristics of the DDoS traffic are as follows:

1. ICMP packets are echo requests (pings, icode:0 and itype:8) less than 50 bytes with payloads like:

002A                                 61 62 63 64 65   66            abcdef
0030   67 68 69 6a 6b 6c 6d 6e  6f 70 71 72 00 00 84 a2    ghijklmnopqr....
0040   d4 00 7c a2 d4 00 4c a2  d4 00                      ..|...L...

2. The TCP SYN flood includes SYN packets from spoofed IP addresses. The destination ports are high ports (1024 to 65535). Many of them have the same TCP sequence number of 3217589126.

3. All packets seem to have abnormally high TTL values. For Windows-generated packets — and botnet members would be running Windows — these would start with a value of 128 or below, which would be decremented at each “hop” along the route to the destination address. However, most of these packets have TTLs higher than 200 even at the destination. Only a fraction of a percent of the packets even have a TTL below 128.

One expects the amount of traffic measured by the target to vary based on factors such as upstream filtering, available downstream bandwidth, botnet configuration, and current botnet resources. It appears most commercial targets are seeing traffic rates that vary from a trickle (4-6 Kbps) to a sizeable flood (40-60 Mbps). REN-ISAC has been monitoring the threat to .edu networks. Those networks typically have a lot of available bandwidth. Those targets have been able see the maximum traffic flow the botnet is capable of generating. With the current configuration (how many bots are allocated to DDoS activities, etc.) and resources available to it, the Peacomm botnet has flooded .edu targets with traffic at 70 Mbs (sustained) with peaks as high as 1 Gbps.

Some evidence points to a human actually pushing the button on the attacks. Although the HTTP proxy probe trigger works, the attacks don’t start until some variable amount of time has lapsed. It may be a few minutes or it may take several hours before the flood begins. While most attacks last around two hours, some last much longer. Are these multiple, overlapping/queued attacks? Or is some operator meting out a harsher “punishment” for some of the more curious parties?

Share This Information | Analysis of Storm Worm DDoS Traffic

SlashDot | del.ico.us | Digg it | Technorati | Reddit
Other SecureWorks Blog Categories:
  • General (24)
  • Links (7)
  • Phishing (3)
  • Research (61)
  • Spam (1)
  • Trojans (4)
  • Next Steps

    Start With SecureWorks Request More Information Now
    Call SecureWorks Call Us Today
    877-905-6661

    Send to a Friend

    *Your Name: 
    *Your Email: 
    *Their Name: 
    *Their Email: 
    Comments:

    Info Request


    Newsletter Signup

    * First Name:
    * Last Name:
    * Email Address:


    SecureWorks Authors
    SecureWorks Blog Topics
    Search Our Blogs