Introduction
In the past weeks we have been working on Joe Sandbox Mobile implementing some engine improvements to enhance code coverage, adding more powerful behavior signatures and extracting even more dynamic data from APK sample analysis. In the previous blogposts we focused more around reflective invoke resolvement and string decryption techniques.
Taking a deeper look at Chuli.A
Running the sample on our free apk-analyzer.net service does not show much activity (see first run here). We see some "relatively harmless" signatures, very little dynamic analysis data and no internet traffic, as can be seen in the following screenshots:
In Kaspersky's blogpost the authors claim that "It is important to note that the data won't be uploaded to C&C
server automatically. The Trojan waits for incoming SMS messages (...)". This is not quite true, as we will later see. So, why is the sample not showing its real behavior? Let's take a look at the receivers defined in the AndroidManifest.xml (see "Static File Info" - "Receivers" in the report):
We noticed that none of the intents are simulated by our default cookbook and most of the intent actions are protected intents that are only sent by the operating system. Meaning that it is not possible to receive these intents by declaring components in the manifest, e.g. android.intent.TIME_TICK:
"Broadcast Action: The current time has changed. Sent every
minute. You can not receive this through components declared
in manifests, only by exlicitly registering for it with
Context.registerReceiver(). This is a protected intent that can only be sent
by the system." (see the Android Reference Manual)
Taking a look at the "onReceive" method of ScreenReceiver in the disassembly shows that it checks to see if the "com.google.services.PhoneService" is running and then starts it accordingly. Following this, a chain of receivers and services are registered and executed.
Before we continued analysis here, we decided to quickly implement a new cookbook command "_JBSimulateTimeTick()" which sends the android.intent.TIME_TICK action to all components that have an intent-filter specified. Why? Because it is easier to understand malware if we combine static analysis with dynamic data. After rerunning the sample, the first glance at the detected signature and internet traffic looks very promising:
Now that we obviously triggered a lot of behavior, let us take a look at the PhoneService. To summarize the analysis, when the PhoneService.onCreate() is executed this is what happens:
- The service calls sendInfo using the "create" command (see first HTTP POST above): hxxp://64.78.161.133/android.php?create=phone<timestamp>
- It checks if the sendInfo was successful
- *IF* sendInfo was successful (status code 200), it continues execution and does this:
- Another receiver "sendReceiver" is registered for the action "com.google.system.receiver":
- Following PhoneService.serviceInit() is called, which registers an "AlarmService":
Let's continue with AlarmService. AlarmService.onCreate() does the following:
- Sets up a receiver for android.provider.Telephony.SMS_RECEIVED (the "alarmReceiver" mentioned in the blogpost by Kaspersky)
- Gathers sensitive information, such as phone name, location, contacts and sms data
- Creates a "com.google.system.receiver" action, stores the gathered data in a Bundle and sends a broadcast
The last broadcast causes the previously registered "sendReceiver" to be triggered, which in turn sends the sensitive phone information. A good entrypoint into these code locations is the "APK behavior" -> "Installation" section of the report:
As can be seen in the screenshot above, the started services and registered receivers that happen during runtime are outlined quite nicely. Clicking the links directly navigates into the associated disassembly code.
Dynamic Data Refined: HTTP POST parameters
As outlined previously, sensitive phone information is being sent to the C&C server. This data is sent using the following url sheme: hxxp://64.78.161.133/data/phone<timestamp>/process.php?datatype=<base64encodeddata>
The actual data transmission is visible in the report's dynamic data column as one of the calls to DefaultHttpClient.execute() in SendInfo.run() (duplicate code exists in SendInfo.reSendInfo()):
Besides presenting simple toString() output per parameter object/primitive, the Hybrid Code Analysis engine of Joe Sandbox Mobile also displays special meta-data for certain parameters. The "HttpPost" object is one of these. In this case, we also print the "getURI", "getEntity", "getEntity.getContentType" and a special base64 decode result for "getEntity", which also URL decodes the getEntity string (see EntityUtils.toString()). This way the POST variables can become visible to the analyst in some cases where a simple encoding, such as base64 is chosen by malware authors.
Code Coverage Improved: Spoofing the C&C Server Status Code
The reason why the action broadcast might have slipped by is that the "sendReceiver" registration and "AlarmService" registration depends fully on whether or not the HTTP POST request to hxxp://64.78.161.133/android.php succeeds (status code 200). It is a lot easier to detect these kind of checks when you see "live data" in the disassembly. Here is where the status code is checked (part of SendInfo.sendInfo()):
As we can see, the status code prevents execution from properly advancing (the C&C server is down). That is why we added a new feature to our engine that allows us to spoof the status code to 200 (OK) no matter what the real status code was. This feature is turned off by default and can be enabled using the _JBSetEngineOption('spoofHttpStatusCode', 'true') command as part of a custom cookbook:
Rerunning the sample with the new cookbook command provides the desired result:
Using this spoofing technique, we were able to enhance code coverage and progress execution as far as possible. Without this trick (or patching the code manually) the APK would not execute its malicious payload.
New Behavior Signature: Detecting Phone Information Leakage
As the most important static and dynamic data is propagated and made available to the behavior signature interface of Joe Sandbox Mobile, we decided to write a new signature that checks whether or not phone information, such as the device id, sim serial number, phone number, etc. is "leaked" via HTTP POST parameters to web servers. In this case, not only the "raw" POST bytes are analyzed, but also the decoded base 64 version. Here is how the signature looks in the Chuli.A sample when triggered
How easy is it to create signatures like that? Well, the open signature interface allows users to quickly implement and activate new signatures. In this case, the signature itself was not all that difficult to implement, here is an excerpt:
As can be seen, the signature interface is quite straightforward and offers the ability to detect malicious behavior in a generic way and mark samples as malicious (only 1/46 antivirus solutions detect Chuli.A as malicious).
Posts
