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
Each thread sends 10 million UDP packets; each packet is 512 bytes in size.
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
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
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
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.
