How to Stop a DDoS Attack + WireX Botnet Code Analysis / Cloud4Y Blog

On August 17, 2017, several content providers and content delivery networks (CDNs) were attacked by a botnet called WireX. The WireX botnet includes mainly Android devices and is designed to create DDoS traffic. A few days ago, Google deleted hundreds of infected applications that were available for download on the Play Store, and launched the process of removing them from all devices.

Researchers from Akamai, Cloudflare, Flashpoint, Google, Oracle Dyn, RiskIQ, Team Cymru, and others have collaborated to team up to fight this botnet. Evidence indicates that the botnet may have been active already on August 2, but it was the attack of August 17 that attracted attention. This article includes aggregate knowledge and describes the efforts of researchers working to neutralize a botnet.

Attack details

WireX left the first traces of the botnet on August 2 in the form of attacks that at that time went unnoticed. They were discovered when the researchers began searching for User-Agent entries, consisting of 26 characters in the logs. Initial attacks were minimal and it was likely that the malware was in development or in the early stages of deployment. Longer attacks were detected starting on August 15, with at least 70,000 IP addresses participating in some (Figure 1).

WireX is an application-level DDoS attack. The traffic generated by the attack nodes is mainly HTTP GET requests, although some application variants seem to be able to issue POST requests. In other words, the botnet creates traffic that resembles real requests from regular HTTP clients and web browsers.


Figure 1: Estimated botnet growth based on the number of unique IP addresses observed during attacks per hour.

Most of the traffic from this botnet was distinguished by the use of User-Agent HTTP requests in the form of a random sequence of lowercase English letters.

Some of the User-Agent entries: Malware variants have also been discovered that emit User-Agent entries of various lengths with an extended character set. Here are some examples:

User-Agent: jigpuzbcomkenhvladtwysqfxr
User-Agent: yudjmikcvzoqwsbflghtxpanre
User-Agent: mckvhaflwzbderiysoguxnqtpj
User-Agent: deogjvtynmcxzwfsbahirukqpl
User-Agent: fdmjczoeyarnuqkbgtlivsxhwp
User-Agent: yczfxlrenuqtwmavhojpigkdsb
User-Agent: dnlseufokcgvmajqzpbtrwyxih



User-Agent: xlw2ibhqg0i
User-Agent: bg5pdrxhka2sjr1g
User-Agent: 5z5z39iit9damit5czrxf655ok060d544ytvx25g19hcg18jpo8vk3q
User-Agent: fge26sd5e1vnyp3bdmc6ie0
User-Agent: m8al87qi9z5cqlwc8mb7ug85g47u
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1b3)
Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.5.30729)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7)
Gecko/20071018 BonEcho/2.0.0.7
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_7; en-us)
AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2

Attack Node Tracking

An analysis of the data on the DDoS attack on August 17 showed that devices from more than 100 countries of the world participated, which is an uncharacteristic feature for botnets. The distribution of the attacking IP addresses along with the special User-Agent record led researchers to speculate that other organizations might also have noticed or been the victims of such attacks. The experts who started the investigation turned to colleagues from other organizations to test this hypothesis. Together, the investigation began to develop rapidly. Log analysis showed a connection between attacking IP addresses and malicious Android apps.

The first and subsequent attacks included requests from the application with the same signature. This led the researchers to the twdlphqg_v1.3.5_apkpure.com.apk Android application, which they began to study to understand how the botnet works and to identify related applications. Searches revealed several more applications from the same authors or authors with the same name and comparable description (Figure 2). When new applications were found, work began on the analysis of their functionality.


Figure 2: Screenshot of search results with similar malware.

There were several cases where these applications were found in well-known mobile app stores. In response to a malware notification, Google provided the following comment:

We identified approximately 300 applications related to the problem and blocked them in the Play Store. We are in the process of removing them from all infected devices. The findings of the researchers, combined with our own analysis, allowed us to better protect Android users.

Malware Overview

Many of the applications were in the categories of media / video players, ringtones or utilities, such as file managers and application stores with additional features hidden to end users. When applications were launched, malicious components began their work by asking the command server, which was most often g.axclick.store, for a command to start and direct the attack.

Applications with features for participating in DDoS attacks were benign for the users who installed them. These applications also used the features of the Android service architecture, which allowed applications to use system resources, even in the background. Thus, attacks could be launched when the application is not in use. Currently, antiviruses recognize this malware as the Android Clicker Trojan, but it has nothing to do with click fraud. This malware was likely to be associated with similar fraud, but it was redrawn for DDoS attacks.

Malware analysis

When checking various decompiled applications, several subdomains of one root domain (axclick.store) were discovered, which were supposed to be part of the command and control (C2) infrastructure for the botnet.

$ grep http * -R
com/twdlphqg/app/ExplorationActivity.smali:    const-string v3, "http://u[.]axclick[.]store/"  
com/twdlphqg/app/services/Ryiidrxcjmfb.smali:    const-string v1, "http://g[.]axclick[.]store/"  

The first domain (u [.] Axclick [.] Store) did not return content, but transmitted an empty 200 OK response and, apparently, was used to test the Internet connection.

The second domain (g [.] Axclick [.] Store) turned out to be related to the DDoS components of malware. An application component that references this domain was responsible for creating the Android service equipped with two instances of WebView. Android allows you to create your own window for browsing the web or even create your own browser clone using the WebView element. The first WebView instance served as a beacon, polling the C2 server for attack directives. The second served as a link to clone WebView for attack purposes. This component also contains logic to configure these attacking instances.

Component Overview

Below, using pseudo-code based on knowledge obtained from decompiled APKs, parts of components are separately considered.

ServiceRunner

The purpose of the component is to continue running the application in the background. Execution will be terminated only if the application is stopped by the user of the mobile device or if the device is rebooted.

Service Runner Pseudo Code

Class ServiceRunner extends Object {  
    Public function run() {
        DDoS_Service->poll_c2();
    }
}

The C2

AttackCommandParser parser starts when the C2 WebView detects that a page has loaded. The parser loads the contents of the page and retrieves the body as a command to attack. Based on the observed samples, the payload from C2 is as follows:

Example command to attack

The value retrieved from the title tag is then checked with String-> contains () to make sure it contains the snewxwri delimiter. If it is found, the content is split. Then the result is used as parameters that should be passed to the DDoS_Service-> attack () method.

Parsing Parsing Responses

Class AttackCommandParser extends WebViewClient {  
    Public function onPageFinished(C2_WebView,C2_url) {
        String pageTitle = C2_WebView->getTitle();
        if (pageTitle->contains(“snewxwri”) == true) {
            pageTitle = pageTitle->trim();
            Array commandParts = pageTitle.split(“snewxwri”);
            String target = commandParts[0];
            String userAgent = commandParts[1];
            String referer = commandParts[2];
            DDoS_Service->attack(target, userAgent, referer);
        }
    }
}

DDoS Service

The main function of the DDoS_Service component is to create a WebView to load any specified URL selected in C2 WebView into the WebView container itself, and not launch the browser. After that, the attack starts.

Pseudo-code DDoS Service

Class DDoS_Service extends Object {  
    Public function onCreate() {
        Handler OS_Handler = new Handler();
        Object Runner = new ServiceRunner();
        OS_Handler->postDelayed(Runner,2);
    }
    Public function poll_c2() {
        WebViewClient C2_Parser = new AttackCommandParser();
        WebView C2_WebView = new WebView();
        WebViewSettings C2_WebView_Settings = C2_WebView->getSettings();
        C2_WebView_Settings->setCacheMode(LOAD_NO_CACHE);
        C2_WebView->clearCache(true);
        C2_WebView->clearHistory();
        C2_WebView->setWebViewClient(C2_Parser);
        C2_WebView->loadUrl(“http://g[.]axclick[.]store”);
    }
    Public function attack(String target, String userAgent, String referer) {
        HashMap WebViewHeaders = new HashMap();
        WebViewHeaders->put(“Referer”,referer);
        WebViewHeaders->put(“X-Requested-With”,””);
        WebView[] AttackerViews = new WebView[100];
        for (int i=0; iclearHistory();
            AttackerViews[i]->clearFormData();
            AttackerViews[i]->clearCache(true);
            WebViewSettings AttackWebViewSettings = AttackerViews[i]->getSettings();
            AttackWebViewSettings->setJavaScriptEnabled(true);
            AttackWebViewSettings->setUserAgentString(userAgent);
            AttackWebViewSettings->setCacheMode(LOAD_NO_CACHE);
            this->deleteDatabase(“webview.db”);
            this->deleteDatabase(“webviewCache.db”);
            AttackerViews[i]->loadUrl(target,WebViewHeaders);
        }
    }
}

The onCreate () method creates a new instance of android / os / Handler and ServiceRunner. The poll_c2 () method is responsible for continuously reloading the WebView using the C2 URL. Before polling C2 domains, the service clears and disables the cache, and also clears the history of WebView instances. These steps are performed to ensure that the client always receives relevant information and does not process requests using the cache. The attack () method is responsible for generating the actual attack traffic.

Malware user experience

Although many of the infected applications have already been removed from the Google Play Store, there are mirrors left on the network from which it is possible to download APK files. We downloaded “twdlphqg” (one of the attacking apps) onto the physical Samsung Galaxy S4 with Android Lollipop and 2015 security patches.



This application, like the others that we tested, had innocuous names, such as “Device Analysis”, “Data Storage”, “Package Manager” and more.

When the application starts, it looks like a simple ringtone application. Only three ringtones are provided. It can play and set ringtones and has no other functions.



This application launches additional processes in the background that continue to work and can participate in a DDoS attack, even when the phone screen is locked. When we put the phone on the charger in sleep mode, the processes responsible for the DDoS attack did not stop.



It is noteworthy that at the moment it is impossible to install these applications, since the PlayProtect function from Google blocks them. All applications that have been identified have become part of the campaign to remove problematic and already installed applications from devices. Now, to run this malware, you need to disable PlayProtect in the settings.

Conclusion

These discoveries were possible only thanks to the collaboration between various IT organizations. Each had its own piece of the puzzle: without the contribution of each company, this botnet would probably remain a mystery for a long time.

The best that organizations can do with a DDoS attack is to share detailed metrics related to the attack. With this information, those who specialize in DDoS protection will be able to learn much more and minimize the negative consequences.

Useful information may include captured packets, lists of attacking IP addresses, ransom records, request headers, and any suspicious patterns. Such data should not contain legitimate client traffic in order to minimize privacy issues, and also because such traffic can slow down the analysis. And most importantly, give permission to transfer this data to trusted contacts in the wide IT security community who may have the necessary experience.