Mobile botnets meet social networks: design and analysis of a new type of botnet

Abstract

The ubiquitous nature of smartphone services and the popularity of online social networking can be a lethal combination that spreads malware and computer viruses in a quick and efficient manner to a large number of Internet users. In this article, we propose a new cellular botnet named SoCellBot that exploits online social networks (OSNs) to recruit bots and uses OSN messaging systems as communication channels between bots. Our proposed botnet is the first that uses the OSN platform as a means to recruit and control mobile cellular bots. The structure and characteristics of OSNs make this botnet harder to detect, more resilient to bot failures and more cost-effective to cellular bots. We present a comprehensive study of this new type of botnet in this article. We first analyze the characteristics of the botnet via simulations. We then present an analytical model to estimate the number of infected users (smart phones) over time. We also provide a real-life implementation of the botnet on a small-scale social network as proof of concept. Finally, we study and recommend effective mechanisms to detect recruitment malware spread by such a botnet in its early stages of propagation. The objective of this work is to raise awareness of new mobile botnets that exploit OSNs to recruit and control bots so that preventive measures can be implemented to deter this kind of attack in the future.

Appendices

Appendix A: Extension to the proposed model: multiple attackers

In a more sophisticated attack, there may be multiple fake profiles (attacker nodes) infiltrating into a social network at the same time, for example, to avoid a single point of failure. The case of multiple attackers can be implemented in several ways, as follows:

• A bot can hold a list of multiple botmasters. When a bot receives a command from any of the listed botmasters, it can execute the provided command and return the results to the botmaster(s).

• A bot can also retrieve a new list of botmasters by periodically visiting one or more web pages maintained by the attacker. This way, if many of the attackers’ accounts are blocked, a new set of botmaster accounts can be created and linked to the web page(s). To avoid single points of failure on those web pages themselves, the attacker can use domain generation algorithms (DGA) to hinder the detection of such web pages by network administrators.

• A new botmaster can be chosen among the bots if another is blocked. This would require an “update” command from the attacker and a signature validation scheme. The “update” message must be signed by the attacker and validated by the bots, in order to avoid command and control channel hijacking by other adversaries or even by the network administrators.

To model the propagation of a recruitment malware in a scenario with multiple infiltrating nodes, we propose the following algorithm to estimate the number of new infections $N_w$ in each wave. If we assume a highly pervasive malware, then each user v will be infected after $d_v$ hops from one of the attackers, where $d_v$ is the shortest distance from v to any of the attackers. In this case, the wave number w ranges from 1 to d, the network diameter.

We create a vector of d elements $\{k_1, k_2, \dots , k_d\}$ and initialize all elements to zero. Assume that there are m attackers $a_1, a_2, \dots , a_m$. For each user v in the network, we calculate the shortest path from v to each attacker $a_i$, $i = 1, 2, \dots , m$. Let $d_{v,a_i}$ denote the length of this shortest path. We find the minimum of all the $d_{v,a_i}$ values; that is, $j = \min \limits _{i = 1 \dots m}\{d_{v,a_i}\}$. We then increment variable $k_j$ by one.

After the algorithm terminates (i.e., all nodes have been processed as described above), we have $N_w = k_w$, where $w = 1, 2, \dots , d$. Note that $\sum _{j = 1}^d k_j = V - m$.

To validate the above algorithm, which estimates the value $N_w$ when there are multiple attackers, we performed simulations using the same setup and parameters as described in Sect. 4. The only difference is that in this experiment we randomly selected five nodes to be the attackers infiltrating into the network ($m = 5$). We plotted the graphs of $N_w$ as the waves progress for $q = 0.95$ (see Fig. 15). The graphs show that the model closely follows the simulation results. For example, when $w = 2$, the $N_w$ values are 2153 and 2259 from the model and the simulation, respectively, a difference of 372 or $372/4039 \approx 2\%$ of the population (Fig. 15).

Fig. 15

The case of multiple attackers (5 attackers, $q = 0.95$). a$N_w$ over 8 waves

Appendix B: An implementation using Facebook Messenger

In order to demonstrate the feasibility of using OSN messaging systems to propagate and deliver command and control messages, we implemented a botnet whose recruitment is done via a self-propagating benign malware that leverages Facebook Messenger to deliver command and control messages. Similar to the approach discussed in Sect. 7, the malware exploits an existing vulnerability in a series of Android devices (CVE-2012-6636) [60].

In order to use an OSN messaging system to send and receive bot commands, the botmaster needs to escalate his/her privilege to the root level. Bergman [44] discusses several methods of privilege escalation to gain root access after exploiting CVE-2012-6636.

It is common for an Android malware to escalate its privilege after gaining access to a mobile phone. Zhou and Jiang [41] stated that around one third of their 1260 collected malware sample (36.7%) leverage kernel-level exploit to gain root-level access after infection. RootSmart and DroidDream are two of the high-profile mobile botnets that escalate their privilege after infecting mobile phones to gain root-level access [66,67,68].

Fig. 16

A contained Facebook community to test the propagation of malware

1.1 B.1 Propagation Mechanism

We did not deploy out bots via exploiting CVE-2012-6636 on Facebook (or Twitter) as we may accidentally impose security threats to real-life users otherwise. Furthermore, Facebook and Twitter do not allow users to propagate malicious codes on their platforms, as stated in their terms of service [81, 82]. In order to contain the experiment and to ensure that no real-life user would be affected by our benign malware, we created 10 Facebook accounts and hosted the malicious page on our local laboratory server, only accessible via our emulated Android systems while developing this proof of concept (PoC). Our implementation involves the following components:

• A: OSN We created a tiny social network with 10 Facebook users, including the botmaster. The users are connected to each other using the algorithm defined by [39] with an average degree of 4.2. The users are logged into 10 different Facebook Messenger accounts, installed on Android emulators. Figure 16 shows the OSN network using the created profiles.

• B: Exploit Page The botmaster hosts a page on an address (in our case, a local address) that exploits CVE-2012-6636 vulnerability which pushes (“drops”) the malware payload into the mobile phone.

• C: Mobile Sets The mobiles sets are emulated Nexus S using Android Emulator [63] running Android version 4.1.2. Each user is associated with an emulated mobile set. The users use the native Android browser. Each user has a Facebook Messenger application installed on his/her Android device.

• D: The Command and Control (C&C) Channel The botmaster communicates with bots via Facebook Messenger using the “dropped” malware.

Prior to launching the attack, the botmaster creates a web page that contains the CVE-2012-6636 exploit code. In the first step, using an infiltrated profile, the botmaster posts the URL of the exploit page to her friends via a group OSN messenger chat. In the second step, a friend of the infiltrating profile sees the URL and will click on the link. In the third step, the friend’s Android browser runs the exploit code which would drop the payload into the infected Android. Finally in the fourth step, the bot would wait to receive commands from botmaster through Facebook Messenger.

1.2 B.2 C&C Implementation

In our implementation, a bot uses Facebook Messenger to receive commands and control messages. In order to receive commands, the bot monitors one of the locally stored databases on the infected Android phone, created by Facebook Messenger to cache the existing Messenger’s conversations (“chat”). This database is called threads_db2 and is located at data/data/com.facebook.orca/databases. This database is not encrypted and does not requires credentials to get access to.

In particular, the bot monitors the threads table where column thread_key equals to

The BMasterID and VictimID represent the unique Facebook ID of the botmaster and the infected Android user, respectively. The bot monitors this table and extracts the commands that are sent to execute them.

For the purpose of this PoC, we designed five commands for bots to receive. In our future work, we will expand the botnet capabilities to perform other tasks as well, based on different Android models.

Following are high-level descriptions of the five commands:

• 1. Forward Forward a malicious URL to all the friends

• 2. Capture Take a photo with the smartphone’s camera and send it back to the botmaster

• 3. SMS Send a particular text to a number using SMS (e.g., for fraud or advertisement purposes)

• 4. Browse Force the smartphone to visit a page

• 5. Delete Delete the commands sent by the botmaster to avoid detection

Following are the detailed description of each command and its implementation on a Nexus S running Android 4.1.

1. Forward: This command is used to forward a (malicious) URL (MaliciousURL) inside a message (SampleBody) to all of the infected user’s friends. The syntax of the command is as follows:

To implement the command, the bot needs to pull out the list of infected user’s friends from a locally stored database on the infected Android device. This database called contacts_db2 is created by Facebook Messenger app to cache Messenger contact information. This database is located in data/data/com.facebook.orca/databases folder and stores information in plain text. Within this database, there is a table called “contacts” where the contact information of each friend is stored. The bot then composes a group message and enters the first name and last name of each friend (retrieved from the “contact” table) in the TO section of the composed message. At the end, the bot puts the

along with the

link (retrieved from the bot command) into the body of the message and sends it to the infected user’s friends. The following script shows the implementation of this method on our Android model:

2. Capture: This commands forces the smartphone to take a picture and send it back to the botmaster with the following syntax:

$$\begin{aligned} {\small {{\varvec{BComm\, CPTR}}}} \end{aligned}$$

To implement the command, the bot opens up a chat message with the botmaster, activates the camera button via a simulated tap action on the screen, takes a picture and sends it to the botmaster. The following script shows the implementation of this command, where BMasterID represents the unique Facebook ID of the botmaster:

3. SMS This command forces the smartphone to send a text message to a number via SMS (e.g., for fraud or advertisement purposes). This command uses the following syntax:

The following script shows the implementation of this command, where PhoneNo and TextBody represent the phone number and the message to be sent, respectively.

4. Browse This command forces the smartphone browser to visit a page. This command could be used to launch denial-of-service attacks against a particular website, or to make money through advertisement fraud [83]. The botmaster sends the following command to the bot, in order to force them to visit a web page:

The bot implements the following method to force the browser to visit a page:

5. Delete This command forces the Facebook Messenger to delete the conversation between the bot and the botmaster in order to avoid detection in the future.. Although this method should always be called after each command, there are cases where the botmaster may want to make sure that all past commands and responses are deleted. The syntax to invoke this command is as follows:

$$\begin{aligned} {\small {{\varvec{BComm\, DEL}}}} \end{aligned}$$

The following method implements the removal of the conversation from all the Facebook views, including Facebook Web Messenger.

We conducted our experiment using the social network shown in Fig. 16. In the first step, the infiltrating node controlled by the botmaster posted the malicious link via a composed message. An Android phone user received the message, clicked on the malicious link and became infected by the “dropped” malware. The same cycle continued until all the Android phones became infected. Our experimental results show that within two steps of the infiltrating node (the red node in Fig. 16), more than 60% of the population were infected, which is consistent with the result we observed in Sect. 7.

In our future work, we will enhance our bot features to include more commands along with more stealthy methods of communication. We will create custom payloads for different Android phones and will use more exploitation techniques to target different smartphone families.