Fortune Teller App Ripping-off Personal Data also Appeared on Google Play

We have recently encountered a fortune teller app that isn’t just trying to forecast the future; it is also stealing user information—and not to predict good fortune for the user. Last week, the Information-Technology Promotion Agency, Japan (IPA) issued a security warning about the discovery of yet another Japanese Android app that extracts personally identifiable information (PII). In April, at least 29 malicious apps (we have reasons to believe that the total number of apps could possibly be twice this) were discovered on Google Play. The malicious apps exported not only PII about the mobile device owner, but also the details of people listed in the phone’s contacts. You can read more about this information stealing in this Symantec blog.

Symantec has confirmed that the fortune teller app also performed the same information stealing as Android.Dougalek, aka “The movie” malware. Our products, such as Norton Mobile Security, detect the app as Android.Uranico. The IPA notes that the app was hosted on a certain website. A number of sites focused on introducing various Android apps appear to have published details about the malicious app on April 18. The app was available for download for little over a month before authorities had the download site taken down. Below is an example of one of the sites introducing the app.

Notice the download button at the bottom that states “Download from Google Play” in Japanese. The link directs the browser to a download page and not, in fact, to Google Play. The button is also used on all other app pages within the sites, even though many do not lead to Google Play. It may be a good idea to stay away from fishy sites such as this.

When I began investigating Android.Uranico, I originally assumed that someone had simply jumped on the bandwagon of stealing personal information from Android devices after news broke about “The movie” malware, as this particular app surfaced shortly afterwards. Furthermore, the PII that it steals is the same as the information stolen by its predecessor. After further investigation, however, Symantec has discovered that this app also appeared on Google Play. The app, along with another app published by the same developer, was published on Google Play on April 11 and 12. This is before the aforementioned sites published details about the app on their sites. These dates are actually around the time when online discussions about “The movie” apps being dodgy were first taking place.

So did the news about “The movie” malware encourage the development of Android.Uranico? The codes of the two malware are different from each other, so they may have been developed by different developers. However, it is still possible that the apps could have originated from the same organization or from folks in the same Internet fraud industry. Furthermore, it's possible that the authors may be sharing information about their latest strategies and tactics as well as trading stolen information. I like to think that there is something related here and that someone didn’t just copycat “The movie” malware when news broke out. I don’t believe it was just coincidence that both of these malicious apps happened to exist independently.

The apps are currently unavailable from both Google Play and the download website, but for those of you that may have installed them, you can examine some of the details below. Note that the app, KoibitoSagashi, is not considered to be malware, but could potentially lead to some sort of unwanted experience as a result of using it. In my investigation, a link in the app opened up an adult-themed site in the browser and clicking on some links ultimately led to a one-click fraud site.

Google Play
Developer: nakamuraGT

Icon on Google Play

Icon on mobile device

App name on Google Play

App name on the mobile device

Number of installs

Release date




April 11, 2012




April 12, 2012



Icon on websites

Icon on mobile device

App name on websites

App name on the mobile device

Number of installs

Approximate release date




April 18, 2012


The number of estimated installations of Android.Uranico is in the thousands, which is much lower than “The movie” malware. However, just like Android.Dougalek, the people affected by this threat also include the contacts in the device as their PII may also have been stolen. Therefore, this could mean that the tens of thousands or even over a hundred thousand people are affected.

There are certainly possibilities of similar apps still being out there that we have yet to discover. So when installing an app, be sure to be aware of what the app is and understand what sort of actions it should perform. Then compare them to the permissions requested by the app during the installation. Confirm that the permissions actually make sense. For the fortune teller app, users should be suspicious of why it wants to know where they are or why it requires access to contact details, for example.

Painting a Picture of W32.Flamer

The number of different components in W32.Flamer is difficult to grasp. The threat is a well designed platform including, among other things, a Web server, a database server, and secure shell communications. It includes a scripting interpreter which allows the attackers to easily deploy updated functionality through various scripts. These scripts are split up into 'apps' and the attackers even appear to have something equivalent to an 'app store' from where they can retrieve new apps containing malicious functionality.

To get an idea of how all these components fit together, the best place to start is a file called mssecmgr.ocx. This is W32.Flamer's main file and it is the first element of the threat executed by an infected computer. The file mssecmgr.ocx contains a large number of sub-components. A breakdown of the various components and how they are stored in this file are shown in Figure 1 below:

Figure 1. Overview of W32.Flamer components

Most sub-components, including the various scripts, are stored in a large encrypted resource embedded in mssecmgr.ocx. This resource has a table at the start which lists the various entries and acts as an index to retrieve the data. It is a similar approach to a standard file system. As well as containing the scripts, several standalone executable DLL files are also included in the resource table. Some of these are advnetcfg.ocx, nteps32.ocx, boot32drv.sys, msglu32.ocx, soapr32.ocs, jimmy.dll, 00006411.dll, and more.

Outside of this resources section there exists code to implement a HTTP server, SOCKS proxy, SSH, SQL database and, of course, the Lua interpreter. Lua is a lightweight scripting language which was specifically designed for embedding into other applications. It is a simple way to extend the functionality of an application. It allows a developer to write a script which can then utilize the functionality of the program it is embedded into. By using Lua, the attacker has reduced the effort required when developing new functionality or 'apps' for W32.Flamer.

When msseccmgr.ocx is executed, it uses some convoluted tricks to embed itself into the running system as shown in Figure 2 below:

Figure 2. Initial execution of mssecmgr.ocx

It first extracts and executes advnetcfg.ocx. The mssecmgr.ocx file then passes nteps32.ocx to advnetcfg.ocx which in turn injects nteps32.ocx into the clean file shell32.dll. With these files running, mssecmgr.ocx then launches the main Lua 'app' script.

This script starts off by looking for any updated 'app' from the app database. (In the code, the repository of 'apps' is referred to as FLAME.) It also contains the ability to upload to the app repository. After this it creates several database files to store stolen data and starts running various other 'apps'.

The collection of Lua scripts can be split up as shown in Figure 3 below:

Figure 3. Lua scripts used by W32.Flamer

At the bottom, there are library scripts which provide functionality to other scripts, such as database access or network access. On top of these are the higher level scripts which perform the malicious actions.

These top level scripts are broken into sets. A brief example of some of these are:

  • ATTACKOP - Attack another machine and move onto it using a variety of techniques, including exploits
  • CASafety - Check for AV software
  • CRUISE - Steal credentials
  • Euphoria - Spread over LNK vulnerability and junction point directory

Some of the scripts rely on additional executables to operate. For example The ATTACKOP scripts can call the soapr32.ocx file. This file then steals a range of network data from the local computer and then writes it to an RC4 encrypted file.

The ATTACKOP_JIMMY script may use one of the following executables to perform its functionality:

  • mssvc32.ocx
  • msglu32.ocx
  • jimmy.dll

The above is a brief overview of W32.Flamer and how it is laid out. Full understanding of W32.Flamer requires analyzing each of the approximately 60 embedded Lua scripts, reversing each of the sub-components, and then building this all back together. As an analogy, reversing W32.Flamer as opposed to reversing standard malware is like re-creating an architectural drawing, not just for a single house, but for an entire city.

Ransomware ‘Holds Up’ Victims

The current “ransomware” campaign uses a novel approach to extort money from naive Internet users. Malware from cybercriminals infects personal computers by claiming to be a genuine Windows update. Once installed, this malware encrypts data on the hard drive and displays a message (see Figure 1) in German that translates to “Your system has been infected with a Windows Trojan encryption due to visiting pages with pornographic content and your data files are encrypted with AES 256-bit encryption algorithm” and asks the victim to pay 100 euros via a Paysafe or Ukash voucher number. These malware binaries spread through spam emails.

Figure 1:Warning message displayed by ransomware

On analysis, we found that the malware uses the RC4 algorithm for encrypting data. RC4 requires a key to generate pseudorandom numbers that are used to XOR the plain text and get the encrypted data. This family uses a technique, mentioned below, to generate keys that are different for each file being encrypted.

How is the key generated?

  1. A random base key is generated from a hard-coded string in the file
  2. Another random four-character string is generated
  3. A new string is formed by appending another hard-coded string to the file that is being encrypted in Steps 1 and 2
  4. An MD5 check sum of the string in Step 3 is computed and used by the RC4 algorithm to encrypt this particular file
  5. On successful encryption, the malware renames the file by prepending “locked-“ and appending the string generated in Step 2 as the extension, for example, locked-filename.1234 (locked-<original name>.<four random characters>



There are some files on the system that are not encrypted by this malware. It doesn’t encrypt any file if its full path contains any one of these elements:

  • Program, Application, temp, tmp, Recycled, $, cache (some common system locations)
  • Desk.Log, .sys, .lnk, .com, .bin, .ini , .sys, .dat, .bat, .pif, .inf
  • Ntldr, ntdetect, bootmgr, osloader, winload, pagefile (filenames related to Windows)
  • winsh (It is the image file name that is downloaded from server which contains warning messages shown in Figure 1)

Must you pay the ransom?

Because the malware uses RC4, which is a symmetric encryption (the same key is used to decrypt), it looks like we can decrypt the files without paying the ransom. But here is the catch: the key for RC4 is an MD5 checksum of some combination of the elements already mentioned. Data in Steps 2 and 3 can be obtained from the encrypted filename and malware, respectively. But where is the base key generated in Step 1?

The base key

Our preliminary analysis shows that the random base key is sent to a remote server in encrypted form, as explained in Figure 2:

server communicationFigure 2: Sending the base key to a remote server in encrypted format

The random base key is encrypted using RC4 and the key used is an MD5 checksum of the data, consisting of the serial number of boot drive volume concatenated with the first six characters of the computer name and another hard-coded string. The ciphered data is passed to another encryption routine and the returned value of this routine along with the volume’s serial number followed by the computer name are passed in the query string of the HTTP request as “data” and “id,” respectively. A graphical representation of the key encryption logic is shown in Figure 3.

Key encryption algorithm

Figure 3: How the base key is encrypted and sent to a remote server

McAfee products detect these malware binaries as Ransom-AI. The “heat map” below shows where this threat has surfaced.

Heat Map of the ransomware

Assange Loses Appeal, But Granted Stay to Apply to Re-Open Case on Technicality

WikiLeaks founder Julian Assange is driven away in a taxi after leaving his hearing at the Supreme Court in London, Thursday, Feb. 2, 2012. Sweden's public prosecutor was right to demand the return of Julian Assange, a lawyer told Britain's Supreme Court Thursday, saying that failing to hand over the WikiLeaks chief would break with precedent and wreck European extradition rules. Photo: Matt Dunham/AP

WikiLeaks founder Julian Assange lost his Supreme Court extradition appeal on Wednesday, and an order to extradite him to Sweden to face sex crimes allegations was upheld.

But his lawyers were also granted a 14-day stay on the judgment while they consider applying to re-open the case on a technicality. One of his attorneys asserted that the Vienna Convention on Law of Treaties had not been argued by attorneys in the case and therefore should be re-opened. The attorney asked the court for two weeks to prepare an application to re-open the case, which the court granted.

Assange, who has been under house arrest for a year and a half, asked the Supreme Court last February to overturn an order extraditing him to Sweden on grounds that the European arrest warrant issued against him by the Swedish Prosecuting Authority was invalid because the Swedish prosecutor behind it was “working for the executive” and was therefore not a proper judicial authority, as the law requires.

But the seven Supreme Court justices ruled 5-2 that the prosecutor was a valid authority.

Assange lost his initial fight against extradition last year, but appealed it before a High Court. That court rejected his appeal last November.

He then appealed to the Supreme Court earlier this year. In order to do so, his attorneys had to show that his case related to a matter of public importance that went beyond Assange. The case was viewed as significant because if the justices ruled that the Swedish prosecutor was not a valid authority for requesting an arrest warrant, it would have called into question other extradition cases in the United Kingdom and elsewhere in Europe.

Assange will be able to remain in he United Kingdom for the next two weeks while his attorneys work out the details of his application to reopen the case.

Assange has not been charged with any crime in Sweden. He is being sought for questioning in Sweden on rape and coercion allegations stemming from sexual relations he had with two women in that country in August 2010. One woman has claimed that Assange pinned her down to have sex with her and intentionally tore a condom he wore. The second woman claims that he had sex with her while she was initially asleep, failing to wear a condom despite repeated requests for him to do so. Assange has denied any wrongdoing, asserting that the sex in both cases was consensual.