In this post I will share my analysis of the Android FakeMarket application Trojan. I will observe its behavior and take a look at the decompiled code to better understand its functionality. I’ll briefly discuss my sandbox environment and setup, but will be focusing more on the analysis process. Lab setup: For dynamic/behavioral analysis:
- Windows 7* with android-sdk installed
- adb (android debug bridge)
- Genymotion free version for android device virtualization
- HTTP proxy set to 127.0.0.1 / Port 8080
- Galaxy S3 4.1.1 as the emulated device
- FakeMarket live malware sample (thanks to contagionminidump blog)
- WireShark
For static analysis/decompiling:
*It is important to note that I observe more than just DNS requests made by the malware here. The Windows 7 machine is essentially hosting the malware via the Genymotion VM, and is connecting out to the internet. The Windows 7 machine is a standalone machine that is the only device on the network, and is being allowed to serve the requests of the malware. Even though this malware is on the Android Genymotion machine, it is ultimately bridging through the Windows machine for network activity, and it would not be wise to do this on a non-disposable machine.
The first step to obtain the Java source code is to rename the APK file to .zip. This will allow us to extract the classes.dex file, which will be used next:
Using dex2jar.bat, we can convert the classes.dex file to a .jar file:
Now, using jd-gui, we can open the new “classes_dex2jar” file that was generated and examine the Java code. I started by examining the BootCompleted class, which starts a new service when the phone is done booting up. The service that is started is ZamanServisi.class:
Following the ZamanServisi class, we can find some activity over the network occuring, along with a timer for which the application uses to make connections. This is found in the onCreate() function, which is triggered whenever the service is started. The below snippet defines a timer, which is to trigger the bilgiVer() function if internetBaglantisiVarMi() is true ((Turkish roughly translates to: “Is there a link”)), which checks if there is an internet connection:
So if there is an internet connection, this piece of code gets executed:
The kaynakal() function creates a request with a parameter as an Opera user-agent. If the returned results of the request are not null, they are stored into the ‘kaynak’ variable. The ipal() function is also called and goes through the same process as described above, but with address: http://www.xxxx.com/ipzaman.php . In short, the function is gathering some data from two servers, storing it, and formatting it.
I’m going to stop here with the static analysis and turn to behavioral analysis. So far I’ve found that the program can start at bootup, which is a common Android malware technique, and makes some network requests triggered by a timer. To begin the behavioral analysis, I will use the Android SDK adb program to install the malware to my Genymotion emulator:
The “adb devices” command will show what devices are connected. “adb -s”specifies what device we want to use, and is combined with the the “install” command, which specifies the path of the APK to install.
AFTER creating the device, we want to set the HTTP Proxy to 127.0.0.0 on port 8080 (if we set this up before creating the device, we won’t be able to sync with Genymotion to find available devices!).
We do this so that we can sniff any network traffic from the device:
After installing the APK there is a “Google Play Store” application icon, clicking the icon opens a fake Google Play application:
As seen in the code, when opening the application, it starts the ZamaServisi service. We can observe this using the built in app monitor:
(Memory usage tends to be between 30-50MB)
Using WireShark , we can observe the network activity taking place. There are two initial GET requests made to adveritising.php and ipzaman.php. These requests are made every 2 minutes. The advertising.php file contains a list of other hosts to which requests are made, and the ipzaman.php request returns back the victims public IP address (which is stored in the applications local preferences using dbyaz() in the biligVeri() function ). HTTP serving ipzaman.php:
HTTP serving advertising.php:
A request made to one of the sites listed in advertising.php, which is actually referred to by a google.it search made by the malware:
Fortinet‘s writeup of this malware shows that there is some JavaScript code executing clicks on the ads of these websites without requiring user interaction. I was unable to find this JavaScript code, but it seems like a likely scenario.
Thanks for reading!