• String Obfuscation

  Both apps made use of string-obfuscation techniques (anti-static analysis) in order to obfuscate all strings that occur in the app. Those include URLs, text that occurs in dialog boxes, etc. This was the first „challenge“ when we looked into the samples. But with the help of CodeInspect’s debugger and the „Mass Analysis“ view, this was not really challenging.

• Anti-Dynamic Analysis Checks

  Both apps also contained anti-dynamic analysis tricks. Obviously, those checks occurred before the app communicates with the „Remote-Server 1“ (see Figure 1) or in other words the C2-server. Interestingly, for both cases only a single anti-dynamic check was implemented.

• External Malware Install Check

  Next, the malware extracts device information such as the device-ID and sends it to a remote server („Remote-Server 1“). Based on the information and probably also some network-information (IP address, etc.), the server decides whether the real malware should be installed or not. This kind of information is part of the server response.

• Server Response

  The server response can contain different types of information. One response type contains information whether the malware-install shall be triggered on the smartphone. Another one can contain an arbitrary text with the purpose of displaying it in form of a dialog on the phone. This is used for social engineering purpose like „As a next step, please enable Third-Party Installations…“.

• Download Malware

  Finally, the malware gets downloaded. The „Remote Server 2“ URL and also the implementation for the malware-download is already part of the app and does not get dynamically loaded.

App1: SMS-Tracker Spyware Downloader

• Package-Name: com.mobmonapp.appd
• MD5: 158cc5a66e1c265220f8fc4f03861a76
• Advisory
• Installs: 100,000 – 500,000

The app advertises itself as a monitoring application, which does not violate the Android Developer Policy if it complies a few requirements listed here. However, the app distributed on GooglePlay had very limited functionality, which can be reduced to a downloader app. There were no real monitoring features implemented in that app. However, the app that gets downloaded afterwards contained all the monitoring features, which are described in detail on the website of the spyware developers www.spy-phone-app.com.

Details about the main parts of the sideloading process:

• String Obfuscation

  They made use of a very „complex“ string obfuscation technique, which expects a string that is represented in binary format (e.g., „10001101“). It gets converted into alphabetic format with the following pseudocode snippet:

  public static String bytesToAlphabeticString(String binaryFormatOfString) {
    int length = binaryFormatOfString.length();
    String deobfuscatedString = "";
    for(int i = 0; i < length-8; i+=8) {
      String subStringOfBytesAsString = binaryFormatOfString.substring(i, i+8);
      char c = (char)Integer.parseInt(subStringOfBytesAsString, 2);
      deobfuscatedString += c;
    }
    return deobfuscatedString;
  }
  

  Since this is just a byte-to-string converter, we can use CodeInspect's decoder for that:

  
  
  Figure 2: Codeinspect's mass-decoder view.
• Anti-Dynamic Analysis Checks

  In order to prevent automated dynamic analysis approaches from triggering the malware-app download (sideloading), they made use of a captcha that needs to be entered:

  
  
  Figure 3: Captcha inside the malware sample.
• External Malware Install Check

  The malware fist communicates with it's C2 server - "http://www.florile.ro/app/test_net.php" - via POST request without any parameters. So for this case, it does not send any device specific data to the C2 server, which was described in the overview figure above. The server triggers a malware download by sending the following JSON response: {"net":"ok","test":"uu"}

  This is also what you see in the code

  ...
  boolean $String22 = $param02.getString("net").equals("ok");
  if (!$String22) break block8;
    $String22 = $param02.getString("test").equals("uu");
    if ($String22) {
      this.step1 = true;
  ...
  

• Download Malware

  Finally, the malware gets downloaded from http://www.florile.ro/app/mondows.apk.

App 2: Cell Tracker

• Package-Name: es.cell.tracker.kids
• MD5: be8d1c46b46af4176faf5d09fc7ae914
• Advisory
• Installs: 1,000,000 - 5,000,000

This application is designed in a very similar fashion as the previous one. It is a "kids tracking" application where the app that got distributed in GooglePlay acts as a downloader and the real spyware application gets sideloaded from a server outside of GooglePlay. It slightly differs from the main functionality, which will be explained in the following:

• String Obfuscation

  The string obfuscation was realized by AES encryption (AES/CBC/NoPadding) with hardcoded IV (A1$qh#eQVb7uA7Yr) and hardcoded key (m315ZY?af2MxM58Y). It took a string as input and decrypted it with symmetric encryption. A little bit more advanced compared to App 1, but still not a big deal to automatically de-obfuscate. From an academic perspective, Harvester would be one approach that could have been used to automatically de-obfuscate those strings.

• Anti-Dynamic Analysis Checks

  In this case, there was no real anti-dynamic analysis check. The only dynamic task that needs to be done is to click on a specific button.

• External Malware Install Check

  The malware extracts different kind of device information including:

  • IMEI
  • Phone language
  • Timestamp

  [[action, firstcheck], [website, 64.140.158.18], [typeapp, 2], [imei, 395960584275410], [appid, 85], [langphone, en], [time, 1503606833687], [minname, 5], [maxname, 15], [minpass, 5], [maxpass, 20], null, null, null, null]

  encrypts them again with AES (see String Obfuscation)

  [a2ea1e93bdd8d380765f43489123c97a=d94574f1b957733ceb711eaff166dbe2, d4b60576694169abbed4baf5104dcf09=429aafb401154c1179cf72bc4fc022c8, 1a2dc2b354e50df1b1a3177c5d120862=bea050311d9927ae89b26a76333d50aa, 350157108d53e404e278e9fc3730a518=0c53dd2bb38d58ba57e6ed857a38b880, ba75a0c4130667e23533b8192a940d36=7951e20b569badb78485fdbb3ecdedfe, a7ef27db6153f9d6e97a9d04b2aa935a=c1d61bb16a199d03de52779b23e5c9ef, 6fc9dc8926973b0137305e320d6708d7=1b2463fa59de0ff801a65c2c3983b3b0, fb2c0648b89ac71e19a26df6fc68e402=d756ee9ab3d61f9384192c65a5865edf, c0a0f2d639394a4cf5677274b7f42e8c=6abbde6ecb273bb5e9b718f23e55f786, 2c361554155fac5c288e26dd2e88aa68=d756ee9ab3d61f9384192c65a5865edf, d5a03f3ffd23029f231dbc04ec129db8=58cc99c69a1f6454c9b51766c2f9dfb7, 3dd7583889475bfad844f87f2af2567f=f33f09e47f4bd1fef726c944e3a9c957]

  and sends it to the C2 server located at http://64.140.158.18/douarnaamat/rao.php. With the help of a MITM attack, one would be able to intercept the traffic, but since the key/value pairs are encrypted with AES, it is not obvious what kind of information is transferred.

  It is also important to mention that the C2 server seems to implement an external emulator check, because if the app runs on an emulator, it sends the following information to the C2 server:

  [[action, firstcheck], [website, 64.140.158.18], [typeapp, 2], [imei, null], [appid, 85], [langphone, en], [time, 1503606833687], [minname, 5], [maxname, 15], [minpass, 5], [maxpass, 20], null, null, null, null]

  The difference between this two data is the IMEI information:

  • Smartphone: [imei, 395960584275410]
  • Emulator: [imei, null]
• Server Response

  The response of the C2 server differs when the request from the client is sent from a real device ([imei, 395960584275410]) vs. an emulator ([imei, null]). It either replies with information that triggers the external malware installation process or it replies with something like "There is a technical problem", which gets displayed to the user. In the former case, it replies with a social engineering text, which gets displayed to the user saying something similar to "You need to enable Third-Party Installation on your Android device. Everything is ok...".

  It is very interesting to see that the malware outsources the emulator check - even though it is a very simple check - to the server, which makes a simple emulator detection routine on client-side harder.

• Download Malware

  Afterwards, the malware gets automatically downloaded from http://64.140.158.18/douarnaamat/besseoula/egby_s1. The URL targets a file with a file ending of txt, which is actually an apk file.