*Akamai would like to acknowledge the research by F5 containing additional information on the capabilities of this malware, released September 2nd.
Finding new features
The WireX botnet was discovered due to its role in a series of prolonged attacks against several organizations. It was brought to our attention, thanks to researchers at 360.cn, that some WireX samples found in the wild appeared to have additional UDP attack capabilities that weren’t discussed in the initial publication.
The set of applications discovered during the primary research into WireX all attempted communication out to the u.axclick.store domain. One of the APKs that was initially overlooked was found to have the UDP attack capabilities like those observed and documented by the researchers at 360.cn upon closer review.
In this update we cover this discovery, how it was confirmed in the decompiled APK, tested in a lab environment, and examine the attack traffic generated by a real device infected with WireX.
The first step in understanding the UDP component of Wirex was to decompile the APK and understand how the application functions. Rather than examine pseudo code (which can be found on the 360.cn blog), we reviewed the raw .smali files produced as a result of decompilation by apktool.
This component runs the show and is responsible for both preliminary bootstrapping and spinning up the command and control (C2) polling services. One of the interesting discoveries unique to this sample from our set was it’s use of the p.axclick domain.
Fig. 1) INSMainActivity checking p.axclick for directive
Fig. 2) INSMainActivity checks for <title>
Fig. 3) INSMainActivity starts service Vpxbjlowiwzg
In these three code snippets, Figures 1 through 3, we see the primary role of the INSMainActivity component as it relates to attack control. The function of this component is relatively simple: it makes a request to p.axclick, and if the response contains a <title> tag that is not empty, it will spin up the AsyncTask/Vpxbjlowiwzg service.
This service only has one goal: it is responsible for spinning up the C2 polling threads.
Fig. 4) Starting up the C2 polling services
While both the HTTP(S) and UDP services are being deployed here we’ll focus on the AsyncTask/Vxrwzmvghcbb service as it is responsible for the UDP functionality being discussed. The HTTP(S) attack logic is covered in “Appendix A: Analysis of the Malware” of the initial release.
This component is responsible for the UDP attack logic, from checking for attack directives to sending out the UDP traffic. Below are some relevant portions and their purposes.
Fig. 5) Checking C2 for attack directives
Fig. 6) Handling a proper C2 response
Fig. 7) Building and sending UDP traffic at target
The component shown in Fig 5 communicates to the C2 server on the u.axclick domain. The code shown in Fig 6 handles the response from the C2 server, and checks for the presence of the <title> tag in the response, then checks for the presence of the snewxwri delimiter. If a <title> tag is found and contains the desired delimiter the attack directive string is split() into an Array on this delimiter value. Once in Array form, the first field (0x0) is stored in Vxrwzmvghcbb->b and the second (0x1) field is stored in Vxrwzmvghcbb->c. Finally, in Fig 7 we see these same values b (target) and c (destination port) utilized in the creation of theUDP packets being built and sent to the target. Two additional values worth noting in this code segment are 0x200 (512) and 0x989680 (10,000,000). We’ll cover the importance of these values in the Attack Traffic section.
Lab setup and attack confirmation
Once the APK supporting UDP attacks was identified within our sample set, the primary goals were to confirm this attack worked and sample real world attack traffic from an infected device. Initial attempts used AVD (Android Virtual Device), a toolset used by app developers to deploy and test their code on emulated devices. While it was possible to load the app onto the device, the application appeared unable/unwilling to launch the services responsible for polling the C2 and ultimately executing the attack code. At this point in our investigation, we’re not positive if this has to do with anti-analysis techniques or not, but further investigation into this aspect of the code was beyond the scope of our work.
Ultimately, to get the APK to execute as expected, it was loaded onto a factory reset physical device (LG Leon running Android 5.1.1) using ADB (Android Developer Bridge) on a controlled wireless network. Once the app was running on the device, we began seeing network traffic exit the phone as was expected.
The device was configured with a hardcoded DNS server pointing at an instance of inetsim with the following configuration options in place.
Fig. 8) example inetsim configuration
The host at 192.168.1.134 was running a simple web server with 3 respective virtual hosts, one for each domain expected to be hit. The virtual host for u.axclick.store was configured to deliver a properly structured attack directive based on the decompiled APK and as outlined by 360.cn researchers.
Fig. 9) Example attack directive
Using this setup the Akamai Security Intelligence Response Team (SIRT) was able to trigger the proper execution path and cause the APK to begin UDP floods targeting the host at 192.168.1.135 on port 1337, as expected.
Fig. 10) UDP attack traffic from WireX infected android device
The UDP attack traffic exiting the infected device uses fairly generic attack characteristics and offers no customization capabilities for the attacker. With WireX UDP attacks, the attacker only provides the desired target and destination port. Unlike many other attack tools of this nature, there are no options allowing the operator to control packet size, padding content, or support for randomized payloads. This means that UDP traffic generated by WireX infected devices, as of this writing, will always produce the same attack traffic signature.
Every packet produced is null (0x00) padded to a length of 512 bytes. Once the polling starts on the device and a target is provided, 50 threads are spun up that generate a continuous flood until the thread has sent a total of 10,000,000 packets to the target. It’s also worth noting that the source port is dynamically assigned by the OS, while this isn’t a big tell, other tools capable of generating this type of signature will sometimes use static values when building and sending their packets, WireX cannot.
The 10,000,000 packets number is per thread per attack directive, so it is possible a victim could receive many more than 500,000,000 packets per a given attacking source. At these rates a single host is capable of generating over 250GB of attack traffic per attack directive received. The delivery rate being mostly dependent on the speed of the device building and sending the packets, as well as the network connection of the attacking device. The code does not throttle the attack, and as a result will use all resources available on the device. We noticed our Android phone got surprisingly hot to the touch as a result.
Fig 11.) attack traffic generated by WireX
It’s important to understand the various attack capabilities of the WireX botnet and the threats that those capabilities present to the Internet community as a whole.
What does this discovery mean?
This discovery is valuable because WireX was initially believed to be a botnet focused on low bandwidth attacks meant to target the application layer via HTTP(S) resource exhaustion. Discovering, and ultimately confirming, that WireX can also launch UDP-based volumetric attacks is important, as they are more likely to impact additional applications and OSI layers. This further expand the botnet’s capabilities, raising additional concerns for defenders.
How large are these UDP attacks?
As of this writing we have not observed an attack that we can confidently attribute to the UDP capabilities of WireX botnet. We also do not feel confident estimating the kind of impact a WireX UDP based attack would/could produce. Due to the wide range of possible devices and networks these bots could be running on, it would be hard to realistically estimate a number based on the previously observed attacks known to come from WireX. Taking into account the active takedown efforts and this hard problem becomes even more difficult to accurately assess.
512 byte 0x00 padded UDP packets aren’t unique enough.
There are other tools and botnets (e.g. Mirai) capable of emulating the attack signature of WireX. Just because you see a signature matching WireX’s during an attack does not mean you’re being targeted by WireX. However, if you’re seeing UDP packets with a 512 byte length that are not simply null byte padded, or is using static source ports, it’s safer to assume that whatever has your organization in its crosshairs is not WireX (for now).
From click fraud to DDoS.
Initial samples of WireX were flagged as click fraud malware. While it’s easy to see how a click fraud bot could be easily repurposed to carry out HTTP(S) attacks, this discovery and our research all but confirms that WireX wasn’t a click fraud botnet being repurposed to perform DDoS attacks. WireX was purpose built to engage in DDoS attacks from the start. To what end (ransom, ddos-for-hire, etc.), has yet to be fully realized.
This is a Security Bloggers Network syndicated blog post authored by Akamai InfoSec. Read the original post at: The Akamai Blog