WP 650Gbps DDoS Attack from the Leet Botnet | Imperva

Archive

650Gbps DDoS Attack from the Leet Botnet

650Gbps DDoS Attack from the Leet Botnet

As the end of the year approaches, it’s natural to contemplate the future and look for signs of things to come. Sometimes, however, you don’t have to search too hard. Sometimes, these “signs” hit you like a ton of bricks.

This is how it was for us when, just ten days before the year’s end, we found ourselves mitigating a 650 Gbps (Gigabit per second) DDoS attack—the largest on record for our network.

This was a fitting end to a year of huge DDoS assault, nasty new malware types and massive IoT botnets. What’s more, it showed exactly where things are heading next on the DDoS front.

Spoiler alert: it’s about to get a lot worse.

Attack Description

The attack began around 10:55 AM on December 21, targeting several anycasted IPs on the Imperva Incapsula network.

It’s hard to say why this attack didn’t focus on a specific customer. Most likely, it was the result of the offender not being able to resolve the IP address of his actual victim, which was masked by Incapsula proxies. And so, lacking any better option, the offender turned his attention to the service that stood between him and his target.

The attack peaks at 650 Gbps

Figure 1: The attack peaks at 650 Gbps

The first DDoS burst lasted roughly 20 minutes, peaking at 400 Gbps. Failing to make a dent, the offender regrouped and came back for a second round. This time enough botnet “muscle” to generate a 650 Gbps DDoS flood of more than 150 million packets per second (Mpps).
Packet per second rate reaches 150+ Mpps

Figure 2: Packet per second rate reaches 150+ Mpps

This second burst lasted about 17 minutes and was just as easily countered by our service. Out of options, the offender wised up and ceased his assault.

Both attack bursts originated from spoofed IPs, making it impossible to trace the botnet’s actual geo-location or learn anything about the nature of the attacking devices.

Some of the spoofed IPs used for the attack

Figure 3: Some of the spoofed IPs used for the attack

We were, however, able to analyze the payload and uncover some clues about the identity of the attacking botnet.

Payload Analysis

The attack traffic was generated by two different SYN payloads:

  • Regular-sized SYN packets, ranging from 44 to 60 bytes in size
  • Abnormally large SYN packets, ranging from 799 to 936 bytes in size

The former was used to achieve high Mpps packet rates, while the latter was employed to scale up the attack’s capacity to 650 Gbps.

Attacks that combine the use of small and large payloads have become increasingly common since we first reported them in the last months of 2015. These tactics enable attackers to spread their odds by trying to both clog network pipes and bring down network switches.

Closer inspection of the two payload types revealed several curious facts about their content.

The first thing we noticed was that the offender left a “signature” of sorts in some of the regular-sized SYN packets. In the TCP Options header of these packets, the values were arranged so they would spell “1337”. To the uninitiated, this is leetspeak for “leet”, or “elite”. Notably, the 1337 sequence also occurs in regular SYN packets. In this case, however, it appears that the offender made a conscious effort to include it into the payload.

Values in TCP Options header spell out 1337

Figure 4: Values in TCP Options header spell out 1337

The next thing that caught our eye was the content of the large SYN payloads. While some payloads were populated by seemingly random strings of characters, others contained shredded lists of IP addresses.

 SYN payload that was generated from a shredded IP list

Figure 5: SYN payload that was generated from a shredded IP list

These shredded IP lists hinted at the way the payload content was generated. It seems that the malware we faced was programmed to access local files (e.g., access logs and iptable lists) and scramble their content to generate its payloads.

Basically, the entire attack was just a mishmash of pulverized system files from thousands upon thousands of compromised devices.

Besides painting a cool mental image, this attack method serves a practical purpose. Specifically, it makes for an effective obfuscation technique that can be used to produce an unlimited number of extremely randomized payloads. Using these payloads, an offender can circumvent signature-based security systems that mitigate attacks by identifying similarities in the content of network packets.

Leet Botnet Rivals Mirai’s “Achievements”

It’s fitting that this attack would signal the end of the year for us. Mitigating it was an important milestone and a great demonstration of the resilience of our network. However, we also look at it as a sign of things to come.

So far, all of the huge DDoS attacks of 2016 were associated with the Mirai malware. However, the payload characteristics clearly show that neither Mirai nor one of its more recent variants was used for this assault.

This is evidenced by the following:

  • Mirai malware is not build to carry out large SYN attacks.
    iph->tot_len = htons(sizeof (struct iphdr) + sizeof (struct tcphdr) + 20);
    
    Figure 6: Excerpt from Mirai’s code that shows how SYN payload size is hardcoded
  • Mirai has hardcoded TCP options (MSS, SACK, TSVAL, WSS), which weren’t present in 99.99% of the payloads (0.01% were accidentally similar).
           // TCP MSS
           *opts++ = PROTO_TCP_OPT_MSS;   
            *opts++ = 4;                   
            *((uint16_t *)opts) = htons(1400 + (rand_next() & 0x0f));
            opts += sizeof (uint16_t);
     
            // TCP SACK permitted
            *opts++ = PROTO_TCP_OPT_SACK;
            *opts++ = 2;
     
            // TCP timestamps
            *opts++ = PROTO_TCP_OPT_TSVAL;
            *opts++ = 10;
            *((uint32_t *)opts) = rand_next();
            opts += sizeof (uint32_t);
            *((uint32_t *)opts) = 0;
            opts += sizeof (uint32_t);
     
            // TCP nop
            *opts++ = 1;
     
            // TCP window scale
            *opts++ = PROTO_TCP_OPT_WSS;
            *opts++ = 3;
            *opts++ = 6;
    
    Figure 7: Excerpt from Mirai’s code that shows how TCP options are hardcoded
  • Mirai payloads are generated from random strings, while the payloads in this attack were structured from the content of system files.

This all points to a new botnet that can only be identified by the signature the malware’s author left in the TCP header: “1337”.

With 650 Gbps under its belt, the Leet botnet is the first to rival Mirai’s achievements. However, it will not be the last. This year we saw DDoS attacks escalate to record heights and these high-powered botnet are nothing more than a symptom of the times.

And like we said, it’s about to get a lot worse.