Analyzing "Pincer.A", a SMS based trojan for Android with Joe Sandbox Mobile 1.0

    As we are getting closer to the release of Joe Sandbox Mobile 1.0, we would like to outline the new report structure and some interesting and cool features of the Joe Sandbox Mobile using an analysis of the relatively new malware sample "Pincer.A". In this blogpost we will show how reading the report enables us to understand the SMS command interface and trigger/simulate trojan command handlers using a custom mobile cookbook.

    Joe Sandbox Mobile 1.0 will be available at the beginning of June and you can read more about it on the product page.

    Introducing the new Report Structure

    Lets start out by analyzing the malware (MD5: f05839eb7156b434a893bbeddb68ad85) with the default cookbook that looks as following (screenshot taken from the cookbook editor of the Joe Sandbox Mobile Web Interface):


    In the default cookbook, the APK is instrumented, installed, executed and after 30 seconds an incoming SMS, as well as an incoming and outgoing call are simulated. After these simulated events that possibly trigger malicious payloads, a final screenshot is taken and the APK is uninstalled. What one does not see in the cookbook is the intelligent user-input simulation that automatically clicks e.g. "OK" buttons to forward the APKs execution. The goal of the cookbook is to trigger as much payload as possible - and as we will see later - rerunning the analysis with a custom cookbook may reveal much more details about the malware.

    Running the malware with the default cookbook already reveals a lot of information about the malware. The mobile report structure is very similar in principle to the Windows report structure. At the top of the report, general information, matched signatures and static information about the APK is available (e.g. manifest related information, such as receivers, activities, requested permissions, etc.).


     
    Following the top section you find extensive network traffic analysis (as on Windows), the actually requested permissions based on logged API calls (with links to the associated disassembly) and extensive API related dynamic data (API calls sorted chronologically, by the entire APK, by method and by class including all parameter data).

     
    Finally, for deep analysis you find all methods with and without associated dynamic data in two groups "executed" and "non-executed" in the "Disassembly" section of the report. This is our new technology that we call "Hybrid Code Analysis" (HCA) This is especially interesting when understanding the behavior of certain receivers or internal functions. As live data from dynamic analysis is available and combined intelligently with the static data (disassembly), it is quite easily possible to understand otherwise obfuscated code that uses e.g. reflective invokes. More on that later.

    Understanding Pincer.A Command Interface

    In the first step we check out the matched signatures to get a basic overview of what malicious behavior might be available in the trojan (full signature matched overview at screenshot above). "Monitors incoming SMS" sounds interesting, pressing the "show sources" button reveals the receiver:


    Checking out the "onReceive" method (the standard Android function to handle events) reveals the following:


    Here we see that all the method and class names are obfuscated and thus its hard to understand what they are doing. However due to dynamic data added to the function disassembly it is easy to determine the function behavior. The calls on line 25/28 extract the SMS message from the SMS PDU array. On line 31 an interesting check on the SMS message text happens as outlines in the following screenshot:


    It basically checks whether or not "command:" string is in the message body, which indicates a trojan SMS text. Further down we can see that a JSON object is being created out of the SMS message text body and passed to the "SMS command handler" at line 38. The command handler further reveals that the SMS text format really needs to be a JSON formatted text, what the expected syntax is and what commands are available in the trojan:


    As you can see in the screenshot, no live data is available (although we are instrumenting JSON related functions), because execution never made it that far, as the default SMS text in the default cookbook is just "testtest". Nevertheless, we can extract already a list of commands based on the strings found in this function. The full list contains commands:

    • start_sms_forwarding
    • start_call_blocking
    • stop_sms_forwarding
    • stop_call_blocking
    • send_sms
    • execute_ussd
    • ussd_query
    • simple_execute_ussd
    • stop_program
    • show_message
    • delay_change
    • ping
    What we will now do is to update the cookbook and rerun the malware simulating two SMS commands in the expected JSON format to trigger two types of behaviors:

    a) We will send an SMS that configures the trojan to block a certain call with the "start_call_blocking" command
    b) We will simulate an incoming call with the configured phone number and see the call being blocked
    c) We will send another SMS that triggers the trojan to send an SMS to a configured destination with a custom text

    Incorporating the information extracted from the report the default cookbook was changed to simulate SMS/incoming calls as following:


    The idea is to "configure" the trojan to block phone calls from "+41987654321", then simulate an incoming call with the same number and verify the expected behavior. As a second step, we will forward the command to send an SMS with the text "Joe Security says hello world!" and verify the expected behavior again for this second command. All part of the same simulation.

    Running the malware again with the new cookbook shows that the SMSReceiver forwards our SMS as a JSON-object to the proper command hander as outlined in the next screenshot.


    The IllegalStateException is suppressed by the Joe Sandbox Mobile engine internally to forward execution as much as possible. In the report we have two different parameter data sets listed representing different execution pathways in time (see Time 165027 and Time 188007). This verifies that the command handler is actually called twice (for the first and second incoming SMS simulation). A very handy feature if interesting code locations are called multiple times. Of course, every call is passed to the signature interface and could trigger different signatures. Checking out the command handler we can further verify that the configuration was successful:


    Again, we see the different commands being passed to the handler. Next, we will check out how the call blocking works and look if we can see our Hello World SMS being sent out to +41666666.

    How Call Blocking works

    If we want to know how the call blocking works, the first step is to look at the phone call receiver's onReceive function and follow the different subfunction calls. The receiver class name is available through the static information of the report. After running the malware with our custom cookbook, the onReceive function quickly reveals how how the malware decides when to block a phone call or not. First the shared preferences are read to check if a number is configured to be blocked (may also be a number in regex pattern):


    When a phone call is incoming, the incoming_number is checked against the configured number and based on a pattern match the number is then blocked.


    The actual call blocking is a known method. Basically, the private "ITelephony" interface is retrieved using a private method of the TelephonyManager "getITelephony", as outlined here:



    Quite interestingly, the "ITelephony" interface is casted to the malware's own interface "com.a.a.a.d", which contains only a single virtual function that - by "accident" - matches the endCall method specification of the ITelephony interface:

    .class public interface abstract Lcom/a/a/a/d;
    .super Ljava/lang/Object;
    # interfaces
    .implements Landroid/os/IInterface;
    # virtual methods
    .method public abstract a()Z
    .end method

    When a call needs to be blocked, the malware then invokes its own interface virtual method (that in turn calls endCall). A nice trick to obfuscate the interface access:

    As we decided it's suspicious in general if an APK tries to obtain the private ITelephony interface using reflection, we quickly created a signature that triggers on exactly this behavior:


    Writing signatures for Joe Sandbox Mobile is just as simple as it is for the windows version.

    Checking if the Custom SMS was sent

    Finally, let's take a look if our trojan sent the custom SMS that we provided with our simulated "send_sms" command. The fastest way is to navigate to the code location using the triggered "Sends SMS" signature (at the top of the report) or clicking on "show source" of the associated API call in the "By Permission (Executed)" part of the behavior report. The behavior data verifies that the SMS was sent, just as the dynamic data available in the relating disassembly function as outlined in the following:


    Again, the parameter data quite nicely shows what happened during execution.

    Conclusion

    In this blogpost we learned about the new report structure of Joe Sandbox Mobile, saw how dynamic data (API calls and their parameter data) is linked with the disassembly code to give a deeper understanding of the malware's behavior (e.g. the SMS command interface syntax, the "endCall" obfuscation trick). We learned that creating custom cookbooks is a powerful tool to penetrate malware even more and utilized the signature interface to detect the same obfuscation trick at any malware thrown at the engine in the future.
    For those that are interested in viewing the full report with the custom cookbook, it is published and online available at: