IoT

Wirex Android DDoS Malware Adds UDP Flood

As quickly as attackers commandeer IoT devices to build more “thingbots,” they continue to evolve their attack types and functionality.
September 01, 2017
4 min. read

An impressive recent collaboration among several security vendors resulted in a discovery and a timely reaction to a new Android DDoS thingbot dubbed WireX. As part of this joint effort, these vendors published a very good detailed report on their respective websites.

F5 threat researchers have found another variant of the malware that, in addition to the original HTTP flood, supports a UDP flood.

Just as in a GET flood, the bot browses a specific command and control (C&C) URL (in this case, “u.axclick.store”) to get the details of the attack target. The response includes the target domain and port in the HTML “title” delimeted by the constant “snewxwri” string, similar to the GET flood instruction.

 

Figure 1. Starting 50 threads

Figure 1. Starting 50 threads

 

Each thread sends 10 million UDP packets; each packet is 512 bytes in size.

 

Figure 2. Each thread sends 10 million UDP packets

Figure 2. Each thread sends 10 million UDP packets

 

Another interesting command that is currently triggered only when the application launches (in the variants that we have analyzed) is served by the “p.axclick.store” URL.

 

Figure 3. Parsing the target URL

Figure 3. Parsing the target URL

 

It results in the malware opening the default Android browser 10 times and browsing the target URL, which just seems like some basic clickfraud functionality.

 

Figure 4. Opening Android default browser 10 times

Figure 4. Opening Android default browser 10 times

 

As we can see, each attack type has its own URL that serves the corresponding attack arguments. We might speculate that the attacker meant to name the subdomain part of the C&C URL (for example, “g.axclick.store”) as an abbreviation of the corresponding attack type:

  • “g” for GET flood
  • “p” for POST flood
  • “u” for UDP flood

However, many variants mix up those URLs.

When comparing WireX DDoS functionality and modus operandi to the other Windows and Linux DDoS malware families, it still has quite a way to mature as an effective, full-fledged DDoS bot.

The attack execution routine is a bit different from most DDOS malware families. To maintain a continuous flood of packets and better orchestration, usually there are two concurrent executions—one to poll the C&C server for commands and another to execute the packet-sending loop, which executes until it is instructed to stop. Some malwares get an attack duration from the C&C server as an attack parameter. The WireX malware doesn’t seem to support this. The attack loops seem to have a constant number of requests/packets sent, and the attack might not stop until it polls the C&C again. In the malware variants we have analyzed, the C&C server is polled in 60 second intervals (and on application launch and network connectivity change events). During a single GET flood loop, it sends 100 requests.

 

Figure 5. 60 seconds C&C polling interval

Figure 5. 60 seconds C&C polling interval

 

However, although the malware is still evolving, it has good market differentiation in its HTTP functionality. Being based on Android’s WebView class, the thingbot is better equipped with browser-like functionality, making it more resistant to various bot challenges, such as cookie support, redirects, and JavaScript, which are still an obstacle for many DDoS malwares.

At those stages, the mitigation is quite simple because there are streaming HTTP request patterns, such as the empty “X-Requested-With” header, which is also sent in lowercase, although it’s uppercase in the code. Also, although the bot supports JavaScript processing, it isn’t able to pass more sophisticated browser challenges that rely on more advanced browser integrity checks.

Behavioral DDoS solutions will relatively easily spot the random user-agent strings and additional anomalies in the HTTP requests sent by the botnet.

The WireX malware still seems to be in its QA phase, judging by the many slightly different variants in the wild and the limited attack types and functionality it currently provides. Stay tuned for further developments.

Join the Discussion
Authors & Contributors
Julia Karpin (Author)
Principal Security Engineer
Liron Segal (Author)
Maxim Zavodchik (Author)
Security Research Group Manager

What's trending?

Forward and Reverse Shells
Forward and Reverse Shells
09/15/2023 article 5 min. read
Web Shells: Understanding Attackers’ Tools and Techniques
Web Shells: Understanding Attackers’ Tools and Techniques
07/06/2023 article 6 min. read
What Is Zero Trust Architecture (ZTA)?
What Is Zero Trust Architecture (ZTA)?
07/05/2022 article 13 min. read