Hunting potential C2 commands in Android malware via Smali string comparison and control flow analysis

Hunting potential C2 commands in Android malware via Smali string comparison and control flow analysis

Speakers: JunWei Song, Senior Malware Researcher, Recorded Future

Conference: Virus Bulletin

YouTube: https://www.youtube.com/watch?v=BVMEHN_D-Gg

Overview

In the dynamic landscape of Android malware, understanding the Command and Control (C2) infrastructure and its associated commands is paramount for effective threat intelligence and defense. This talk by JunWei Song, a Senior Malware Researcher at Recorded Future, introduces a novel and efficient methodology for automatically identifying potential C2 command handling functions within Android malware. The research addresses a critical bottleneck in malware analysis: the time-consuming and often incomplete process of manually reverse engineering C2 communication logic.

Song's presentation posits that while C2 command strings themselves can be easily changed or obfuscated by malware authors, the underlying code architecture used to process these commands tends to follow predictable and repeatable patterns. By shifting focus from the volatile command strings to these more stable code structures and control flow patterns at the Smali bytecode level, analysts can significantly expedite the identification of critical C2 functions. The talk culminates in the introduction of C2 Hung, an open-source tool designed to implement this methodology, dramatically reducing the time required to pinpoint and extract C2 commands, even when encrypted.

Background

▶ Watch: Introduction and C2 command analysis challenge (0:00)

The Android malware ecosystem is in a constant state of evolution, with new techniques emerging daily to evade detection and compromise user data. Despite this rapid change, a fundamental constant remains: nearly all sophisticated malware relies on a C2 server to receive instructions. These C2 commands dictate the malware's core functionalities, from stealing credentials and encrypting files to performing various other malicious actions. Consequently, understanding these commands is crucial for comprehending a malware's true capabilities, classifying families, and tracking their evolution.

However, the process of identifying C2 commands presents significant challenges for malware analysts. Static analysis, while foundational, often involves extensive and time-consuming manual reverse engineering, requiring analysts to sift through thousands of functions. This manual effort is not only inefficient but also susceptible to human error. On the other hand, dynamic analysis, which involves executing malware in a controlled environment, frequently falls short when dealing with encrypted or obfuscated network traffic, or when the C2 server is offline. Furthermore, sandbox environments often fail to trigger all functionalities, meaning many C2 commands might never be observed, leading to an incomplete understanding of the malware's full potential.

Recognizing these limitations, the research proposes a paradigm shift. Instead of exhaustively chasing ephemeral C2 command strings, which are prone to change and obfuscation, the focus moves to the more stable and architectural code structures that universally process these commands. Malware authors, despite their efforts to hide malicious intent, often reuse common programming constructs for tasks like parsing, comparing, and dispatching commands. This underlying structural consistency forms the basis for a scalable and family-independent detection mechanism, aiming to overcome the inherent bottlenecks of traditional static and dynamic analysis methods.

Key Findings

▶ Watch: First pattern: Conditional jumps (if-else/switch) (4:17)

The core discovery presented in this talk is that malware authors, regardless of their specific C2 commands or obfuscation techniques, tend to employ a limited set of recurring architectural patterns for handling C2 instructions. These patterns manifest as distinct Smali opcode sequences and Android API call frequencies, creating a "bytecode fingerprint" that can be programmatically detected. By focusing on these stable code structures rather than the volatile command strings themselves, the analysis becomes more resilient to changes in command content or encryption.

The research identified four primary C2 command handling patterns prevalent across various Android malware families:

1. Conditional Jumps (If-Else / Switch Statements): This is characterized by a high density of string comparisons, typically using String.equals(), within a series of if-else or switch statements to match received commands with specific actions.
2. Dictionary Mapping (HashMap-based): Malware authors often utilize HashMap objects to map command strings directly to corresponding functional modules or handler objects. This pattern is identified by frequent HashMap.put() calls.
3. Array-Based Command Storage: Commands are stored in large arrays, which the malware then iterates through or accesses via index to retrieve and process. This pattern involves the initialization of string arrays (new-array) and subsequent population (aput-object).
4. Constant Definition within a Class: C2 commands are defined as numerous constant strings, either static fields or instance fields, within a single class. This approach is identified by a high concentration of sput-object (static put) or iput-object (instance put) opcodes within the class initialization or constructor methods.

These patterns, though varied in their implementation, share the common characteristic of creating observable structural fingerprints in the Smali bytecode. The ability to automatically identify these fingerprints allows for a more efficient and scalable approach to C2 command discovery, even for previously unknown or highly obfuscated malware.

Technical Deep Dive

▶ Watch: Automated detection methodology using Smali opcodes (13:30)

The methodology hinges on a lightweight static analysis of Smali bytecode, the assembly-like language for Android's Dalvik/ART virtual machine. The process involves parsing Smali opcodes from disassembled APK or DEX files, counting occurrences of specific opcodes and Android API calls within each function, and then applying a set of predefined rules with thresholds to flag potential C2 command handling functions.

Let's delve deeper into each of the four identified patterns and their technical fingerprints:

1. Conditional Jumps (If-Else / Switch Statements):

• High-level logic: This is the most classic approach, where a received C2 command string is compared against a series of predefined command strings using if-else or switch statements. If a match is found, the corresponding malicious action is executed.
• Android API characteristic: Frequent calls to Ljava/lang/String;->equals(Ljava/lang/Object;)Z.
• Smali opcode fingerprint: A high density of opcodes such as const-string (to load a command string), invoke-virtual (to call String.equals), move-result (to store the comparison result), and if-eqz (to check the result). Additionally, the presence of sparse-switch or packed-switch opcodes is a strong indicator of a switch statement. The speaker highlighted TGToxy malware as an example, which contained 94 C2 commands processed this way, creating a "repeating DNA sequence" of these opcodes.

1. Dictionary Mapping (HashMap-based):

• High-level logic: Malware utilizes a HashMap (or similar key-value store) to directly map command strings to handler objects or function pointers. This often results in cleaner code but still leaves a distinct pattern.
• Android API characteristic: Frequent calls to Ljava/util/HashMap;->put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;.
• Smali opcode fingerprint: A high frequency of const-string (for command keys), new-instance (to create handler objects), invoke-virtual (to call HashMap.put), and crucially, iget-object (to retrieve the HashMap instance from another object for use). XLoader (also known as Mocow), an Android banking trojan, was cited as an example, demonstrating the rapid initialization and population of a HashMap with 20 different C2 commands and their corresponding handlers.

1. Array-Based Command Storage:

• High-level logic: Commands are stored as strings within a large array. The malware then iterates through this array or uses an index to retrieve and process specific commands.
• Smali opcode fingerprint: The presence of new-array (to initialize the array), followed by a high concentration of const-string (to load command strings) and aput-object (array put, to place strings into the array). CopyBar banking trojan was presented as an example, where a string array was initialized with 59 distinct command strings, serving as a clear red flag for analysts.

1. Constant Definition within a Class:

• High-level logic: Instead of being processed in a single function, commands are defined as numerous constant string fields (either static or instance) directly within a single class. These strings might then be decrypted or decoded before use.
• Smali opcode fingerprint:
• Static Field Pattern (e.g., Nexus Trojan): A high number of sput-object (static put object) opcodes within the class initialization method (<clinit>), each assigning a value to a static field. Nexus Trojan showed a class with 39 static string variables, each a C2 command.
• Instance Field Pattern (e.g., Samber Banking Trojan): A high concentration of iput-object (instance put object) opcodes inside the constructor method (<init>). This pattern often involves const-string (for encrypted strings), invoke-virtual (to call decryption/decoding routines), move-result-object (to store the decrypted string), and then iput-object to set the instance field. Samber, which uses RC4 encryption with Base64 encoding for its strings, exemplifies this.

Detection Methodology:

The automated detection process involves defining rules in a flexible JSON format. Each rule specifies:

• target_opcode: The primary Smali opcode(s) to look for.
• api_call: The specific Android API call(s) characteristic of the pattern.
• threshold: A minimum count for the combined occurrences of these opcodes/APIs within a single function or class. For instance, for the conditional jump pattern, a threshold of 10 for string comparisons and associated opcodes was suggested, based on analysis of various malware families. This threshold is adjustable to balance efficiency and precision.

When a function or class meets the criteria of a defined rule, the tool outputs the function's method signature (in Java) and extracts all strings found within that function or class. This entirely static approach offers significant speed advantages over dynamic analysis.

Demo / Proof of Concept

▶ Watch: Handling encrypted C2 commands with the tool (17:50)

The research culminates in the development of an open-source tool named C2 Hung, available on GitHub. This tool embodies the static analysis methodology described, providing a practical implementation for identifying C2 command handling routines.

The demonstration highlighted C2 Hung's capabilities through practical examples:

1. TGToxy Malware Analysis: When C2 Hung was executed against the TGToxy malware (using the command-line option -f for the APK/DEX file), it quickly identified a specific function as containing C2 commands. More impressively, it extracted all potential C2 command strings from within that function, such as "screen relay," "read SMS list," and others. This process, which traditionally takes hours or even days of manual reverse engineering, was completed in a matter of seconds.

1. Samber Malware with Encrypted Commands: C2 Hung was also demonstrated against the Samber banking trojan, which employs encryption (RC4 with Base64 encoding) for its C2 commands. While the tool cannot decrypt the strings itself, it successfully flagged the relevant class and extracted the encrypted strings. For an analyst, this is a crucial "red flag" – instead of sifting through the entire application, C2 Hung pinpoints the exact location where valuable, albeit encrypted, C2 information resides. The next logical step for the analyst then becomes clear: focus reverse engineering efforts on that specific class to find the decryption routine.

The speaker acknowledged that no tool is perfect and C2 Hung can produce false positives, such as flagging functions that do not genuinely contain C2 commands. However, this is presented as a strategic trade-off between efficiency and precision. The tool's primary goal is not to achieve 100% accuracy but to significantly reduce the analyst's workload by narrowing down thousands of potential functions to a manageable handful of highly suspicious candidates, thereby accelerating the overall analysis process.

Defensive Implications

▶ Watch: Conclusion and future work on rule expansion (21:00)

The methodology and the C2 Hung tool have profound implications for defensive security operations and malware analysis workflows:

• Accelerated Triage and Analysis: By automating the identification of C2 command handling functions, C2 Hung drastically reduces the time required for initial triage and in-depth analysis of Android malware samples. Analysts can quickly ascertain the core capabilities of a new or unknown sample.
• Enhanced Malware Classification: The ability to reliably extract C2 commands, or at least pinpoint their handling routines, provides key indicators for classifying malware into families. Changes in command sets or handling patterns can help identify new variants of existing families, as demonstrated with the discovery of a new TGToxy variant.
• Proactive Threat Intelligence: Understanding the C2 architecture and commands allows security teams to develop more targeted detection rules, network indicators of compromise (IOCs), and behavioral signatures. It helps in predicting potential malicious actions and preparing defenses.
• Overcoming Obfuscation and Encryption: While C2 Hung doesn't decrypt strings, its ability to identify the location of encrypted C2 commands is invaluable. It directs reverse engineering efforts to the specific decryption routines, saving significant time otherwise spent searching aimlessly.
• Family-Independent Detection: The focus on architectural patterns rather than specific strings makes the detection mechanism scalable and resilient to minor changes in malware implementation. Malware authors can easily alter command strings, but fundamentally changing the processing architecture is far more challenging.
• Identification of Unknown Malware: If a sample exhibits clear C2 command handling structures but doesn't match known patterns in a database, it can be a strong indication of a novel, previously unknown malware family, prompting deeper investigation.

Key Takeaways

• Predictable C2 Patterns: Android malware authors consistently use predictable code structures (conditional jumps, hash maps, arrays, constant definitions) to handle C2 commands, creating detectable bytecode fingerprints.
• Static Smali Analysis is Key: By analyzing specific Smali opcodes and Android API call frequencies, C2 command handling functions can be identified efficiently and automatically, overcoming limitations of traditional static and dynamic analysis.
• C2 Hung Tool Speeds Analysis: The open-source C2 Hung tool implements this methodology, significantly reducing the time required to locate and extract potential C2 commands, turning hours/days of manual work into seconds.
• Locates Encrypted Commands: C2 Hung can pinpoint the exact locations of encrypted C2 commands, guiding analysts to the relevant decryption routines and focusing reverse engineering efforts.
• Aids in Malware Classification and Discovery: The tool helps in classifying known malware families, identifying new variants (e.g., TGToxy), and even flagging potentially unknown malware based on its C2 command structure.
• Focus on Architecture over Strings: The core philosophy is that malware authors find it harder to change their C2 processing architecture than to simply modify command strings, making architectural analysis a more robust detection strategy.

About the Speaker(s)

JunWei Song is a Senior Malware Researcher at Recorded Future. His work primarily involves malware analysis and supporting the triage team in identifying and categorizing various types of malware. Beyond his professional role, JunWei is a dedicated volunteer for Pyong Taiwan, demonstrating his passion for contributing to the open-source community. His research, as showcased in this talk, reflects his commitment to developing innovative solutions that enhance the efficiency and effectiveness of malware analysis.