The Headless Android Bot: DDoS and a Mobile Botnet

Gartner estimates there will be over 6 billion devices connected to the IoT of which 4 billion are in the consumer sector. With mobile devices comprising a large proportion of the “things,” security and privacy while connected to the IoT is a big concern for administrators.

Take the example of a compromised smartphone in a BYOD corporate environment. One mobile application that is widely downloaded is Pokémon Go. However there are regional licensing restrictions that make it available only in certain countries. Due to its massive popularity, a lot of anxious players are downloading versions directly from websites and not through the Google app store. This may expose them to malicious content, as the content is not verified as being sourced from a trusted vendor.

We first saw an attack from a mobile device connected to a mobile botnet that tried to bypass our protection services by disguising itself as a common user and browser running JavaScript.

A few weeks later we saw another DDoS attack from the same Android botnet. This attack was much larger than the previous one. It started Aug. 22 at 6 a.m. Israel Standard Time (IST) and finished at Aug. 23 at 8 p.m. In total it lasted 38 hours, with an average size of 400 RPS, all coming from 27,000 unique IPs distributed all around the world.

In this second attack the client’s user agent was “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html).” It was the same signature used by Google’s crawler. Like the first attack the bot had an Android application footprint.

We’re seeing more of these, and expect this trend to increase as attackers find it harder to bypass DDoS mitigation solutions without having any JavaScript capabilities. Here’s a look at what happened with the first attack.

The Attack: What Happens When that Hotline Lights Up

All of these requests were from clients supporting JavaScript, and the majority displayed the following user agent:

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

This specific user agent suggested that the client was an updated version of a Google Chrome web browser, and the user operating system was Windows 10 64 bit. In other words, this user-agent string was very commonly used and the second most popular user-agent string.

Except it wasn’t. Although the user string supported JavaScript, it failed some of our behavioral and classifications challenges causing our DDoS mitigation engine to block it. This was not Google Chrome, nor was it running on a Windows 10 operating system. All of these requests came from a mobile devices botnet, all powered by Android OS.

The attack itself had no distinct geographical origin of the bots (the infected devices), and was spread across the globe. Here’s the list of unique source IPs and/or # of sessions, and a list of top 10 IPs the attack was coming from.

35593 (BR)

15229 (MX)

14787 (DE)

11372 (AR)

10261 (ES)

9486 (FR)

8613 (IQ)

7916 (IT)

6899 (RU)

5809 (TR)

We concluded that this was a generic application downloaded by innocent users from around the world who did not know they were participating in a DDoS attack.

It’s All In the (Headless) HTTP Headers

When we took a closer look at the attack data, we noticed the following HTTP headers sent with the requests:

The X-Requested-With HTTP header implies that this was a request committed with XMLHTTPREQUEST (XHR), although not necessarily. However, the values show a certain pattern (com.XXstudio(s).X), which is typical to the naming convention for Android applications. Recently the X Viking Horde, an Android malware behaved in a similar manner.

Going back to Google, we found a pattern of a certain “off-market” jigsaw puzzle application, which had the same naming pattern for its APK (Android Package). This application was not downloaded through the normal Google Play store, but through unofficial sites. In these websites, for example, it showed up in one of the listings as: “Download 3394 Puzzle APK” by JK Entertainment.

On closer look it didn’t seem connected in any way to the Australian company JK Entertainment. The app  describes itself as an “Extra large, mega, jumbo, giant pack of all the 3394 Puzzle game.” Other listings also had obscure descriptions.

The application itself requests the following permissions:

android.permission.INTERNET: Allows applications to open network sockets.
android.permission.ACCESS_NETWORK_STATE: Allows applications to access information about networks.
android.permission.ACCESS_WIFI_STATE: Allows applications to access information about Wi-Fi networks.
android.permission.CHANGE_WIFI_STATE: Allows applications to change Wi-Fi connectivity state.
android.permission.READ_PHONE_STATE: Allows read only access to phone state.
android.permission.SYSTEM_ALERT_WINDOW: Allows an app to create windows using the type TYPE_SYSTEM_ALERT, shown on top of all other apps.

Therefore, this application can actually open network sockets and create pop-up alerts. This doesn’t mean that it’s the same application that was used for the attack. An attacker may also modify the X-Requested-With HTTP header, but that doesn’t seem the case here.

It looked like users were downloading that jigsaw puzzle application, and unknowingly became a part of a mobile botnet. In addition to being used for DDoS attempts, malicious mobile applications can encrypt files such as ransomware, transfer information from the mobile device, or let attackers take control over the mobile device.

×

Nov 7 Upcoming Webinar

Elevate your Security Posture by Balancing Effectiveness and Efficiency

Register Now

Four Ways to Avoid Becoming a Node In a Mobile Botnet

So with sophisticated attacks on the rise, how do you avoid becoming another node in an Android mobile botnet? Here are tips to secure your mobile.

• If you don’t really know what you’re doing, never install any Android application which you did not download from the Google Play store.
• Even when downloading applications from the Google Play store, stick with popular and verified applications.
• Read the permissions the application requires. If it seems like it’s too much, don’t install.
• Don’t let your kids mess with your mobile (I got mine broken that way–Ben). Our advice: Buy them a cheap tablet that doesn’t connect anywhere.

Have any questions for us? Please leave us your comments.