In the cyber-underground, one can never be too careful. Between researchers and law enforcement, cybercriminals are always wary of being shut-down or worse, caught and prosecuted. The developers of the iBanking Trojan—a malicious mobile app targeting Android devices— are no exception. Following in the footsteps of its older PC-based brothers that—looking to stay ahead in the cat-and-mouse game—implemented protection mechanism such as code obfuscation and stronger encryption, recent iBanking versions have been seen deploying measures to harden the malware infrastructure and its operation.
Even though the panel’s source-code was leaked a couple months ago, the bot itself is still under regular development and now has several new features including enumeration of all installed apps on the infected device, harvesting of images from the device and collection of precise geo-location data. Not to mention the growing support for additional targeted entities. Our most recent analysis identified nearly 30 “graphic” templates for iBanking, but the most intriguing is the use of self-protection mechanism such as AES encryption, code obfuscation and anti-SDK/VM.
Self Protection Mechanisms
Evasion is a natural evolution of malware. As security researchers advance their analysis and detection methods, malware developers race to implement counter-measures to keep their operations protected and undetected.
Equivalent to “FUD crypting” in PC-Trojans, iBanking now employs stronger encryption methods to hide its resources and uses packers and obfuscators to protect its code from reverse-engineering attempts and anti-virus detection. It has also implemented “anti-SDK” protection features to evade sandbox environments.
As with everything else mobile, these developments have happened faster than expected.
AES Encryption
iBanking’s first attempt at protecting itself appeared in the form of AES encryption. In order to hide its different resources, iBanking made use of a hardcoded private key (within the app) that encrypted the contents of XMLs and of the communication resources. XMLs included data relating to external resources such as imagery, but also information relating to the app’s settings. As mentioned encryption was also applied to the app’s communication resources including both URLs and telephone control numbers.
Figure 1: Resulting AES encrypted communication resources
Obfuscation of Application Code
The next “stage” of evasion manifested itself in the form of code obfuscation. Closely following the announcements the developer was making in the underground, we came across a newer version of iBanking that at first appeared buggy. Our analysis indicated a completely new code-base and structure.
Upon decompilation of the app, we were greeted with an unpleasant surprise. In an effort to further protect the bot from reverse engineering attempts, the developer made use of code obfuscation to complicate code analysis. Once applied, obfuscation bloated the number of class-files from a mere 23 to an exaggerated 245, assigning random names to the newly created classes. Furthermore, it replaced all static variable names with meaningless strings and encoded string values. As can be seen in the image below, the obfuscator was smart enough to avoid encoding/obfuscating system variables such as “app_name”. String encoding was done with a hardcoded, relatively simple function.
Figure 2: Obfuscated variables and their encoded values
Anti-SDK Mechanism
But the above obfuscation did not explain why the app was buggy. An extensive debugging of the application uncovered a clever Anti-SDK protection mechanism that can be compared to the widespread anti-sandbox mechanism found in PC-based malware.
Our analysis revealed that in the early stages of the app’s execution, it runs a function that compares unique identifiers, collected from the infected device, with hardcoded values. A match against anyone of these values would “tell” the app that it was running within a virtual machine and terminate its operation. We identified the following 4 values:
- Is the device IMEI equal to “000000000000000”?
- Does the Phone-number start with “1555521”?
- Is the Operator “Android”?
- Does the SIM Serial Number equal “89014103211118510720”?
If one of these expressions returns the condition ‘True’, the application terminates its process immediately, giving the appearance that it has crashed. The hard coded values correspond to default values that are commonly provided by the Android SDK, and commonly used in app analysis environments.
Figure 3: Anti-SDK comparison function – trying to prevent dynamic analysis efforts
Summary
Being aware of security-researchers and analysts, and employing anti-analysis mechanism has been a standard among PC-malware developers for quite a while; but is far from standard practice in the mobile malware field. The iBanking malware shows that mobile malware developers are becoming aware of the necessity to protect their bots against analysis, and indicates a possible new trend in this new and evolving mobile malware space.
Our continued analysis of the iBanking mobile bot reveals an advanced and mature malware that targets Android devices. Its growing adoption by botnets in an attempt to gain unauthorized access to smartphones is a trend that we continue to monitor.
The research was done in collaboration with RSA FirstWatch researcher Lior Ben-Porat.
The post iBanking Mobile Bot Raising Its Shields appeared first on Speaking of Security - The RSA Blog and Podcast.