The History of XXShenqi and the Future of SMS Phishing

On Aug 3rd, Chinese social media websites reported on the latest and largest SMS phishing (smishing for short) attack in China. The public security authorities of multiple cities in Guangdong, Jiangxi, and Jiangsu provinces have posted on their blogs warning Android users of this latest phishing attempt. As shown in Fig. 1, by the time the exploitation attempts were identified, over 100,000 Android users were infected and over 20 Million SMS were sent by the phishing malware. On average, each user was charged ¥30 (RMB) or about US$5.


Fig. 1. Timeline of the XXShenqi malware infecting over 100,000 Android users

The package name of this new SMS phishing malware is com.example.xxshenqi and the app name appears as XX神器 (XX Powerful Equipment). As shown in Fig. 2, the icon and the title of the malware give the impression of a video player to attract common Android users.

According to QQ WeChat news, the malware was written out of boredom by a 19 year old freshman student of Central South University on Jul 24th and sent out from his cell phone on Jul 28th. By Aug 3rd, the malware had drawn attention from public media; nine hours later, police authorities had identified and detained the hacker.

Not only is the Android software being distributed a costly nuisance, but it also contains another embedded, malicious apk file that intercepts and sends SMS messages to the hacker’s email address. The behavior has been detected by FireEye Mobile Threat Protection platform in Fig. 8 and will be explained in detail later. Both the main malware and the embedded malware are not publicly well known according to VirusTotal until very recently:

The detection of the main malware is just 5 out of 53 anti-virus vendors:


Fig. (a)

Out of 53 different anti-virus vendors, only two were able to detect it the embedded Trogoggle malware:


Fig. (b)

Prequel – Known SMS Phishing Malware:

SMS phishing is a well-known type of malware in the Android world. It collects personal information through SMS while masquerading as a trustworthy app.

For example in 2012, a Russian smishing malware – neobook.rubakov.strah (version 1.8), sent premium SMS text message with hashed contents to a predefined number that would enable in-app purchases. Based on FireEye Dynamic Threat Intelligence, that app was downloaded thousands of times before it was taken down from Google Play.

Another Spanish smishing malware popular in 2013 was com.ikangoo.whatssex (version 1.7). It mimicked the Whatsapp icon with title Wassapp del Sexo, or Sex Wassapp in English. It has been removed from Google Play but is still available from the developer’s website. This malware would send SMS with user’s device ID for payment purposes at least in one of the older versions.

There have been many smiting malwares to appear in the last few years and the XXShenqi is not as novel as it seems to be.

New SMS Regulation in Android:

Due to the historical prevalence of SMS phishing, the Android platform began to tighten the reading and writing rights of SMS for Android developers.

In Android 4.4 (KitKat), the concept of the default SMS app was introduced, allowing users to choose their default SMS app. Only the default SMS app would be allowed receive the new SMS_DELIVER_ACTION intent, which the system broadcasts when a new SMS message arrives. Furthermore, only the default SMS app receives the new WAP_PUSH_DELIVER_ACTION intent when a new MMS arrives.

However in Android 4.4, non-default SMS apps can still send SMS if it has the SEND_SMS permission.  In the Android developer’s page of sendMultipartTextMessage method, it reads: Beginning with Android 4.4 (API level 19), if and only if an app is not selected as the default SMS app, the system automatically writes messages sent using this method to the SMS Provider (the default SMS app is always responsible for writing its sent messages to the SMS Provider).

As shown in Fig. 3 and Fig. 8, the XXShenqi SMS phishing malware can still operate in Android 4.4 however because it has the SEND_SMS permission.

Technical Analysis of XXShenqi:

After installation, the icon of the malware appears as the following:


Fig. 2. The icon of the “XX神器“ (XXShenqi) malware

Most Android applications use MainActivity class as an entry point, however, according to the AndroidManifest.xml configuration file in the malicious application, XXShenqi calls WelcomeActivity class to evade signature-based anti-virus detection. The WelcomeActivity class is then used to send SMS phishing to contacts located in the Android user’s contact list.


As shown in the source code above, the ReadCONTACTS()method is called to send the link to the malicious apk file to all contacts. Below is a detailed analysis of the ReadCONTACTS()method:


WelcomeActivity.this.phoneString is the phone number of the entry in the contact list, and WelcomeActivity.this.nameString is the contact name of the entry.


Fig. 3. The abnormal SMS traffic detected by the FireEye MTP platform

Individuals who are a member of the victim’s contact list will then receive a copy of the link to the malicious apk. Assuming the individual receives the text, downloads the file, opens the file and side loads the APK file into the phone, the individual will then spread the malware to other individuals who are in the their contact list. It’s important to note that these methods for downloading apps are common in many regions where Google Play is not the dominant Android app market.

While sending the SMS, the malware starts the MainActivity, popping up a window to install the trojan SMS uploader embedded in the XXShenqi app – . The message reads: Please install the installation package which has been included into the app. The installation can be done by clicking the install button.  After the install button is clicked, the trojan SMS sender will be installed on the device and run in the background because it kills its processes once the job is done.


Fig. 4. The pop up window asking for permission to install the embedded malware

The malware then shows the two pages depicted in Fig. 5: the login page and the registration page. The login page asks for the username and password and has two buttons: login and register.

If the user clicks register, a registration page opens, as shown in the right picture of Fig. 5, requesting a username, password, citizen ID number, and their real name. The bottom button is the register button.


Fig. 5. The login page (Left) and the registration page (Right) of XXShenqi

Usernames for either of the pages are not connected to any real services. The registration page does however verify the citizen ID number by checking the format, the length, and the inherent coding of the number. A random number of “1234567890” will trigger a pop up of Please input the correct citizen ID number, as shown on the bottom right of Fig. 5.

After inputting an acceptable citizen ID number, as shown in the left picture of Fig. 6, and clicking the register button, a pop up of Successful registration! is displayed at the bottom, as shown on the right picture of Fig. 6.


Fig. 6. The malware checks the format, the length and the inherent coding of the 18-digit citizen ID number in the registration page (Left) before showing successful registration! (Right)

As demonstrated in the code snippet below, the credentials do not attempt to log into any accounts.


In the code, if the log in is successful, it just shows being verified; please wait… and wrong password, or username doesn’t exist. The two toasts are shown at the bottom of both screenshots in Fig. 7:


Fig. 7. The fake pages of verification (Left) and the error message of wrong password or the account doesn’t exist. (Right)

While the Android user is distracted by the login and registration pages, in the MainActivity class, a subclass of BroadcastReceiver called MyReceiver is started. The MyReceiver class is to start the to send SMS messages to the hacker.

As shown in the source code below, it sends the SMS to an email address and kills its process after completing so that neither thread is seen from the Android system setting tab, nor is the icon shown in the home screen of the phone.




Fig. 8. More abnormal SMS traffic in the embedded malware as detected by the FireEye MTP platform

Even when the hacker was finally identified and detained, the only way that authorities could stop the exponential expansion of infected users was by removing the app from its web hosting service. Yet the malware can easily be resurrected when repackaged and hosted in numerous cloud storage services. As few security mechanisms and detection capabilities exist for mobile malware, it’s easy to see why 20 million SMS were sent and 100,000 users were infected in only a few days.

Another reason for the spread is the social engineering aspect of smartphones where individuals tend to trust the links sent by someone on their contact lists. This is particularly true as we do share links containing pictures or even executable files over the SMS to groups from time to time.

Finally, many individuals believe that they cannot get malware on their devices still. This lowers the guard for the individual using the phone, making them more likely to click on a random link. Individuals should be educated that unexpected links such as bargain recommendation or prize information may be not only harmless tricks but also malicious phishing attempts. Even if the device in question is just smart phone or tablet, the same precautions that are taken on a PC should be the same as those on a mobile device.

Prediction of Further SMS Phishing Attacks:

FireEye analysis of this series of SMS phishing and sending malware that infected over 100,000 users in China and charged $500,000 SMS fees in a few days could continue to expand exponentially even though the hacker has been detained.

The growth rate of this SMS phishing malware reveals the fact that such app can be developed easily and spread epidemically in the future. Although the Android OS has received certain fixes to its wide open permissions for reading and sending SMS in KitKat, malware can still send out SMS in those versions, meaning the newer versions of Android can’t prevent the prevalence of such malware.

If an Android Has a Heart, Does It Bleed?

The OpenSSL Heartbleed vulnerability “allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read” [1]. Heartbleed surprised the public by allowing attackers to steal sensitive information from vulnerable websites by sending crafted SSL heartbeat messages. However, due to the fact that servers can send heartbeats to clients as well, malicious servers can, in turn, attack vulnerable clients and steal sensitive information. For the Android platform, we find that roughly 150M downloads of Android apps contain OpenSSL libraries vulnerable to Heartbleed.

Currently there are about 17 antivirus apps on Google Play branded as “Heartbleed detectors”. Six of them scan the OpenSSL library belonging to the Android platform for vulnerabilities. Unfortunately, this method isn’t sufficient for detecting the Heartbleed vulnerability on Android. Except in limited Android versions (mainly 4.1.0-4.1.1), the majority of Android platforms are not vulnerable, as most versions use OpenSSL libraries that are not vulnerable or simply have the OpenSSL heartbeat functionality disabled.

However, Android apps frequently use native libraries, which either directly or indirectly leverage vulnerable OpenSSL libraries. Therefore, even though the Android platform itself is not vulnerable, attackers can still attack those vulnerable apps. They can hijack the network traffic, redirect the app to a malicious server and then send crafted heartbeats messages to the app to steal sensitive memory contents.

We studied apps with vulnerable OpenSSL libraries and confirmed this attack. Most of the vulnerable apps are games, and some are office-based applications. Although there is not much valuable information in the game apps, attackers can steal OAuth tokens (access tokens and refresh tokens) to hijack the game accounts; as such, the information might be useful for hijacking those linked social network accounts with incorrect configurations. Office apps vulnerable to Heartbleed are much more dangerous due to further potential data leakage.

During our investigation of the office apps that contains a vulnerable version of OpenSSL, we were surprised that they were not vulnerable to the Heartbleed attack. How could it be? A deeper look shows that these apps either make a mistake in the native code linkage, or just contain dead code. Therefore, when they try to invoke SSL functions, they directly use the non-vulnerable OpenSSL library contained within the Android OS, instead of using the vulnerable library provided by the app. The linkage mistake is common for Android applications built with native code. As such, the side-effect of this mistake helps reduce the apps’ overall risk profile.

Within the 17 Heartbleed detector apps on Google play, only 6 detectors check installed apps on the device for Heartbleed vulnerability. Within the 6, 2 report all apps installed as “Safe”, including those we confirmed as vulnerable. One detector doesn’t show any app scan results and another one doesn’t scan the OpenSSL version correctly. Only 2 of them did a decent check on Heartbleed vulnerability of apps. Although they conservatively labeled some non-vulnerable apps as vulnerable, we agree it is a viable report which highlights both the vulnerabilities and the linkage mistakes. We’ve also seen several fake Heartbleed detectors in the 17 apps, which don’t perform real detections nor display detection results to users and only serve as adware.

On April 10th, we scanned more than 54K Google Play apps (each with over 100K downloads) and found that there were at least 220 million downloads affected by the Heartbleed vulnerability. We have notified some of the app developers and library vendors about the OpenSSL Heartbleed vulnerability found in their products. Fortunately, it seems most app developers and library vendors take Heartbleed seriously, as we have started to see apps updated with proper fixes. The total number of vulnerable apps download has since decreased to 150 million on April 17th.

[1] Vulnerability Summary for CVE-2014-0160

Occupy Your Icons Silently on Android

FireEye mobile security researchers have discovered a new Android security issue: a malicious app with normal protection level permissions can probe icons on Android home screen and modify them to point to phishing websites or the malicious app itself without notifying the user. Google has acknowledged this issue and released the patch to its OEM partners.

Normal vs. Dangerous Permissions: A Background

Android Open Source Project (AOSP) classifies Android permissions into several protection levels: “normal”, “dangerous”, “system”, “signature” and “development” [1][2][3].

Dangerous permissions “may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities”. In contrast, normal permissions are automatically granted at installation,  “without asking for the user's explicit approval (though the user always has the option to review these permissions before installing)” [1].

On the latest Android 4.4.2 system, if an app requests both dangerous permissions and normal permissions, Android only displays the dangerous permissions, as shown in Figure 1. If an app requests only normal permissions, Android doesn’t display them to the user, as shown in Figure 2.

Figure 1. An Android app asks for one dangerous permission (INTERNET) and some normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS). Android doesn’t notify the user about the normal permissions.

Figure 1. An Android app asks for one dangerous permission (INTERNET) and some normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS). Android doesn’t notify the user about the normal permissions.

Figure 2. An Android app asks for normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS) only. Android doesn’t show any permission to the user.

Figure 2. An Android app asks for normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS) only. Android doesn’t show any permission to the user.

Normal Permissions Can Be Dangerous

We have found that certain “normal” permissions have dangerous security impacts. Using these normal permissions, a malicious app can replace legit Android home screen icons with fake ones that point to phishing apps or websites.

The ability to manipulate Android home screen icons, when abused, can help an attacker deceive the user. There’s no surprise that the permission, which allows an app to create icons, was recategorized from “normal” to “dangerous” ever since Android 4.2. Though this is an important security improvement, an attacker can still manipulate Android home screen icons using two normal permissions: and These two permissions enable an app to query, insert, delete, or modify the whole configuration settings of the Launcher, including the icon insertion or modification. Unfortunately, these two permissions have been labeled as “normal” since Android 1.x.

As a proof of concept attack scenario, a malicious app with these two permissions can query/insert/alter the system icon settings and modify legitimate icons of some security-sensitive apps, such as banking apps, to a phishing website. We tested and confirmed this attack on a Nexus 7 device with Android 4.4.2. (Note: The testing website was brought down quickly and nobody else ever connected to it.) Google Play doesn’t prevent this app from being published and there’s no warning when a user downloads and installs it. (Note: We have removed the app from Google Play quickly and nobody else downloaded this app.)

Lastly, this vulnerability is not limited to Android devices running AOSP. We have also examined devices that use non-AOSP Launchers, including Nexus 7 with CyanogenMod 4.4.2, Samsung Galaxy S4 with Android 4.3 and HTC One with Android 4.4.2. All of them have the protection levels of and WRITE_SETTINGS as “normal”.

Google acknowledged this vulnerability and has released the patch to its OEM partners. Many android vendors were slow to adapt security upgrades. We urge these vendors to patch vulnerabilities more quickly to protect their users.



A Little Bird Told Me: Personal Information Sharing in Angry Birds and its Ad Libraries

Many popular mobile apps, including Rovio’s ubiquitous Angry Birds, collect and share players’ personal information much more widely than most people realize.

Some news reports have begun to scratch the surface of the situation. The New York Times reported on Angry Birds and other data-hungry apps last October. And in January, the newspaper teamed up with public-interest news site ProPublica and U.K. newspaper the Guardian for a series of stories detailing how government agencies use the game (and other mobile apps) to collect personal data. Even the long-running CBS show 60 Minutes reported earlier this month that Rovio shares users’ locations.

The Android version of Angry Birds in the Google Play store, updated on March 4, continues to share personal information. In fact, more than a quarter billion users who create Rovio accounts to save their game progress across multiple devices might be unwittingly sharing all kinds of information—age, gender, and more — with multiple parties. And many more users who play the game without a Rovio account are sharing their device information without realizing it.

Once a Rovio account is created and personal information uploaded, the user can do little to stop this personal information sharing. Their data might be in multiple locations: Angry Birds Cloud, Burstly (ad mediation platform), and third-party ad networks such as Jumptap and Millennial Media. Users can avoid sharing personal data by playing Angry Birds without Rovio account, but that won’t stop the game from sharing device information.

In this blog post, we examine the personal information Angry Birds collects. We also demonstrate the relationships between the app, the ad mediation platform, and the ad clouds — showing how the information flows among the three. We also spell out the evidence, such as network packet capture (PCap) from FireEye Mobile Threat Prevention (MTP), to support our information flow chart. Finally, we reveal how the multi-stage information sharing works by tracking the code paths from the reverse-engineered source code.

Continue reading »

Amazon’s Mobile Shopping Clients and CAPTCHA

Amazon is a popular online retailer serving millions of users. Unfortunately, FireEye mobile security researchers have found security issues within Amazon’s mobile apps on both Android and iOS platforms through which attackers can crack the passwords of target Amazon accounts. Amazon confirmed our findings and hot fixed the issue. Recently, we found two security issues within Amazon’s mobile apps on both Android and iOS platforms:
  • No limitation or CAPTCHA for password attempts
  • Weak password policy
Attackers can exploit these two security issues remotely against target Amazon accounts. Continue reading »

Background Monitoring on Non-Jailbroken iOS 7 Devices — and a Mitigation

Background monitoring mobile applications has become a hot topic on mobile devices. Existing reports show that such monitoring can be conducted on jailbroken iOS devices. FireEye mobile security researchers have discovered such vulnerability, and found approaches to bypass Apple's app review process effectively and exploit non-jailbroken iOS 7 successfully. We have been collaborating with Apple on this issue.
Fig.1 Background Monitoring
We have created a proof-of-concept "monitoring" app on non-jailbroken iOS 7.0.x devices. This “monitoring” app can record all the user touch/press events in the background, including, touches on the screen, home button press, volume button press, and TouchID press, and then this app can send all user events to any remote server, as shown in Fig.1. Potential attackers can use such information to reconstruct every character the victim inputs. Continue reading »

JS-Binding-Over-HTTP Vulnerability and JavaScript Sidedoor: Security Risks Affecting Billions of Android App Downloads

Third-party libraries, especially ad libraries, are widely used in Android apps. Unfortunately, many of them have security and privacy issues. In this blog, we summarize our findings related to the insecure usage of JavaScript binding in ad libraries.

First, we describe a widespread security issue with using JavaScript binding (addJavascriptInterface) and loading WebView content over HTTP, which allows a network attacker to take control of the application by hijacking the HTTP traffic. We call this the JavaScript-Binding-Over-HTTP (JS-Binding-Over-HTTP) vulnerability. Our analysis shows that, currently, at least 47 percent of the top 40 ad libraries have this vulnerability in at least one of their versions that are in active use by popular apps on Google Play.

Second, we describe a new security issue with the JavaScript binding annotation, which we call JavaScript Sidedoor. Starting with Android 4.2, Google introduced the @JavascriptInterface annotation to explicitly designate and limit which public methods in Java objects are accessible from JavaScript. If an ad library uses @JavascriptInterface annotation to expose security-sensitive interfaces, and uses HTTP to load content in the WebView, then an attacker over the network could inject malicious content into the WebView to misuse the exposed interfaces through the JS binding annotation. We call these exposed JS binding annotation interfaces JS sidedoors.

Our analysis shows that these security issues are widespread, have affected popular apps on Google Play accounting for literally billions of app downloads. The parties we notified about these issues have been actively addressing them. Continue reading »

Monitoring Vulnaggressive Apps on Google Play

Vulnaggressive Characteristics in Mobile Apps and Libraries

FireEye mobile security researchers have discovered a rapidly-growing class of mobile threats represented by popular ad libraries affecting apps with billions of downloads. These ad libraries are aggressive at collecting sensitive data and able to perform dangerous operations such as downloading and running new code on demand. They are also plagued with various classes of vulnerabilities that enable attackers to turn their aggressive behaviors against users. We coined the term “vulnaggressive” to describe this class of vulnerable and aggressive characteristics. We have published some of our findings in our two recent blogs about these threats: “Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions” and “Update: Ad Vulna Continues”.

As we reported in our earlier blog “Update: Ad Vulna Continues”, we have observed that some vulnaggressive apps have been removed from Google Play, and some app developers have upgraded their apps to a more secure version either by removing the vulnaggressive libraries entirely or by upgrading the relevant libraries to a more secure version which address the security issues. However, many app developers are still not aware of these security issues and have not taken such needed steps. We need to make a community effort to help app developers and library vendors to be more aware of these security issues and address them in a timely fashion.

To aid this community effort, we present the data to illustrate the changes over time as vulnaggressive apps are upgraded to a more secure version or removed from Google Play after our notification. We summarize our observations below, although we do not have specific information about the reasons that caused these changes we are reporting. Continue reading »

Update: Ad Vulna Continues

This is an update to our earlier blog “Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions”.

Since our last notification to Google and Ad Vulna (code name for anonymity), we have noticed a number of changes to the impacted apps that we reported to both companies. We summarize our observations below, although we do not have specific information about the reasons that caused these changes we are reporting.

First, a number of these vulnaggressive apps and their developers’ accounts have been removed from Google Play, such as app developer “Itch Mania”. The total number of downloads of these apps was more than 6 million before the removal. While removing these apps from Google Play prevents more people from being affected, the millions of devices that already downloaded them remain vulnerable. Continue reading »

Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions

FireEye researchers have discovered a rapidly-growing class of mobile threats represented by a popular ad library affecting apps with over 200 million downloads in total. This ad library, anonymized as “Vulna,” is aggressive at collecting sensitive data and is able to perform dangerous operations such as downloading and running new components on demand. Vulna is also plagued with various classes of vulnerabilities that enable attackers to turn Vulna’s aggressive behaviors against users. We coined the term “vulnaggressive” to describe this class of vulnerable and aggressive characteristics. Most vulnaggresive libraries are proprietary and it is hard for app developers to know their underlying security issues. Legitimate apps using vulnaggressive libraries present serious threats for enterprise customers. FireEye has informed both Google and the vendor of Vulna about the security issues and they are actively addressing it.

Recently FireEye discovered a new mobile threat from a popular ad library that no other anti-virus or security vendor has reported publicly before. Mobile ad libraries are third-party software included by host apps in order to display ads. Because this library’s functionality and vulnerabilities can be used to conduct large-scale attacks on millions of users, we refer to it anonymously by the code name “Vulna” rather than revealing its identity in this blog. Continue reading »