Analyzing Android/SpyBanker

    Today we will take a look at an Android malware that is generally labeled as "Android/SpyBanker" (part of the Android.Gepew family). The sample we will be look at has the MD5 0d28fa54f9c0d41801e8fb5a7b0433dd. Attention was brought to us looking at Symantec's blogpost, so we were quite interested to see if Joe Sandbox Mobile, our Android analysis system, would allow similar or even more insights into the malware behavior without much reverse engineering effort and minimal time.

    To be more concrete, the sample is part of a larger attack vector that stems from Windows, in an attempt to infect an USB connected device with a fake Android App Store that acts as a banking trojan, but has some interesting functionality. This type of attack vector is rather new, albeit we have seen the opposite direction (mobile device trying to infect Windows) before (see Android.Backdoor.Ssucl found about a year ago). Finally, we may note that we've introduced a "harmful classification" of samples and Joe Sandbox Mobile was able to mark the APK as malicious straight away. A fresh VirusTotal result determined that only 29/50 AV engines detected the APK as malicious (timestamp 2014-02-18).

    Report Overview

    As always when analyzing an APK (or any file in another Joe Sandbox product) we start out looking at the head of the report, that is where the behavior signatures are located that give a good first idea of what the sample is capable of doing and offer entrypoints into the disassembly code.


    Besides the suspicious signatures dealing with the network part, the "Boot Survival" (starting a service on phone boot), SMS Sending and Phone call Blocking signatures are usually a strong indicator for malicious behavior, if they appear in combination. The "Deletes other packages" signature, as we will see later, is part of an automatic "app re-installation" functionality that overwrites local banking apps with malicious versions.
    As a next step, let's take a look at the "Static Info" area of the report to get a better idea of the permissions requested or additional entrypoints, such as the registered receivers or services. It is usually quite easy to find interesting code locations following these points.


    As we can see, the APK wants to be notified about BOOT_COMPLETED, PACKAGE_ADDED, PACKAGE_REMOVED and some Phonestate/SMS related events. All of which are probably used to intercept incoming banking SMS (TAN numbers) and for persistance functionality.  Also, we see that a service called "CoreService" is created where we will probably find a lot more interesting code. Seems like an easy deal so far. Let's dive into the code!

    Taking a deeper look

    Joe Sandbox Mobile uses Hybrid Code Analysis and allows the viewer to differentiate between executed and non-executed functions (at least for what is algorithmically determined as executed based on the instrumented subset), as well as annotated disassembly code for better understanding of in-out parameter data. Either way, it is easy for us to find the main entrypoint browsing the disassembly listings, as we know the main activity name from the prior static info analysis. So what does the APK do? Upon startup, the user is prompted to activate device administrator rights, if the phone is not rooted yet. Then, irregardless of the user choice, the CoreService is started.


    In the CoreService, sensitive user data is gathered and sent initially to a C&C server. The C&C server URL is read from a shared preference file (in this case it is http://www.slmoney.XXX):


    Sensitive phone information, such as the phone contacts, the IMSI and the IMEI are extracted and appended to an opening URL connection:


    Depending on the C&C server result, a variety of commands may be executed. The command handler expects a JSON string and has a variety of commands, among of which the "changeapp" command is probably the most interesting, as it is used to replace existing APKs with malicious versions (in this case, banking apps):


    The C&C "auto installer" functionality to replace existing apps can be found here:


    First, as we can see in the screenshot above, a list of installed APKs is queried (we have a signature hit on the call, thus the function name is highlighted). The list of installed APKs is compared against a list of known banking target package names (e.g. com.korea.kr_nhbank):

    An "app.auto.install" event is sent to the core service handler:


    ... and finally CoreService.autoChangeApk is called.

    The last parts were not executed, because the C&C server is down and not responding to our initial request. In a future release version of Joe Sandbox Mobile, we will extend the cookbook with a command to simulate custom APK specific broadcast events, that would allows us to simulate some internal C&C trojan commands in a second run, but it is out of the scope of this blogpost.

    Full Analysis Report: