RedAlert2, an Android banking Trojan, has received a significant amount of attention since first noted last week by Securify Labs (read more in this article by Bleeping Computer). The high level of interest in this Trojan is due to the fact that the code base appears to be completely new and the Trojan itself includes some unique functionality. The PhishLabs Research, Analysis, and Intelligence Division (R.A.I.D.) recently identified a new sample which exhibits changed tactics, techniques, and procedures relative to previous samples. We’ll review some of the interesting features of RedAlert2 before identifying the changes observed in the most recent sample.
What’s Old is New Again
RedAlert2 includes much of the same functionality as existing Android banking Trojans. RedAlert2 runs in the background, monitors application activity, and overlays the screen with customized phishing sites when it detects activity related to a targeted organization. Additional capabilities include stealing system information, stealing user data including contacts, SMS history, and call history, intercepting or blocking SMS messages and phone calls, sending SMS messages and USSD requests, and launching other applications.
Figure 1: Command List
One of the things that makes RedAlert 2 unique is that, unlike many existing Android banking Trojans, RedAlert2 does not appear to be based on leaked source code of a previous family like BankBot or AceCard. Another thing that sets RedAlert2 apart is the unique approaches it takes to some common Android banking Trojan tasks: determining the foreground application, updating the command and control server, and retrieving configuration data.
Determining Active Application
One of the most crucial tasks for an Android banking Trojan is to be able to determine what application is currently active in the foreground. This allows the banking Trojan to select the appropriate overlay to display based on the package name. Historically, banking Trojans have used the getrunningtasks or getrecenttasks methods of the ActivityManager class in order to determine the active application. However, these methods were deprecated starting with Android Lollipop (API Level 21). This technique precludes all devices running Android 5.0 and newer. As a workaround, RedAlert2’s author utilizes the Android Toolbox, a set of Linux command line utilities, in order to determine the current running application. The comments in Figure 2 show the control flow for determining the currently active application for different Android API Levels and Figure 3 is a code snippet displaying the Android Toolbox command utilized.
Figure 2: Determine Active Application
Figure 3: Android Toolbox Invocation
It is worth noting that for API Level 20, which is KitKat 4.4W and is unique to Android Wear devices, RedAlert2 uses UsageStatsManager to determine the current app. This explains the inclusion of the PACKAGE_USAGE_STATS permission. It is interesting that the developers have made specific accommodations for these Android Wear devices.
Figure 4: UsageStatsManager Method for Android 4.4W
Updating the Command and Control Server
Chat clients and Social Media have long been used for command and control in Desktop malware, but these techniques have not been used as extensively in the mobile realm. RedAlert2 bucks this trend by utilizing Twitter for updates to the command and control server. Upon initial delivery, the command and control server for a sample is specified in the application’s resources, as show in Figure 5.
Figure 5: Basic Configuration Data in Application Resources
If this command and control server is offline, the sample will calculate a Twitter username and query that account’s posts in order to retrieve an updated C2. I The code in the snippet shown in Figure 6 examines the account’s tweet and uses a regular expression to confirm that the tweet is an IP address formatted as 4 octets with the first two and last two octets separated by a space rather than a period. An example of such a tweet might take the form “10.19 142.7”. Once confirmed, this IP address is reconstructed, adding the HTTP protocol, the period between the second and third octet, and appending port 8060 before saving this as the new command and control server for the sample.
Figure 6: Twitter Command and Control Server Update Code
Retrieving Configuration Data
Many Android banking Trojans hard-code their configuration into the APK itself or download the entire configuration from a command and control server once installation is complete. RedAlert2 takes a ‘Go Fish’ approach to delivering its configuration that allows it to protect its configuration from researchers. All configuration data resides on the command and control server and data is only provided to an infected device once the device “proves” that a targeted application is already installed.
Following installation, RedAlert2 beacons to its command and control server and is supplied with a Bot ID to track the infection. The infected device then sends a list of installed applications to the C2. Figure 7 shows an infected device making a POST to the command and control server. The base64-encoded data shown here contains a list of installed applications. The command and control server responds with a list of targeted applications which correspond with installed applications. HTML code is supplied for overlays corresponding to the installed targeted applications. This code remains in device storage and is displayed when the Trojan detects that a targeted application is active in the foreground. The full configuration data of this Trojan is never provided to the infected device, which makes analysis more difficult.
Figure 7: List of Installed Applications Posted to C2
As noted previously, PhishLabs R.A.I.D. Team has recently observed changed tactics, techniques, and procedures relative to the samples identified in initial write-ups for RedAlert2.
Initial samples of RedAlert2 analyzed by the R.A.I.D. targeted a consistent set of financial organizations, social media sites, payment sites, and retail businesses. As noted previously, without direct access to the command and control server, it is challenging to obtain a complete list of targeted applications; however, we detected 64 targets for each of these initial samples. The most recent sample targeted 66 applications with the difference accounted for by four omissions and six additions. Omitted targets include Westpac Bank, St. George Bank, Skype and Ulster Bank. Additions include five Russian banks and Uber. The new targeted applications are detailed in Table 1. Figure 8 displays an overlay for newly-targeted Tinkoff Bank.
Table 1: New RedAlert2 Targets
Figure 8: Tinkoff Bank Overlay
RedAlert2 currently has one of the most geographically diverse target distributions of any mobile banking Trojan. Actors often target a narrow geographic area that they are familiar with, but RedAlert2 appears to be interested in targeting popular organizations across the globe. Figure 9 displays a choropleth of all observed RedAlert2 targets by country.
Figure 9: Number of Targeted Organizations by Country
Domain-based C2 and Cloudflare
The new sample is the first our team has observed which utilizes a domain for command and control rather than a hard-coded IP address. The use of a domain for command and control is not particularly significant, but it opens the window for the use of a CDN proxy like Cloudflare. The sample analyzed for this post did just that, opting for a .club domain coupled with Cloudflare service. Utilizing Cloudflare provides the attacker with multiple protections, including anti-bot measures and obfuscation of the C2s true IP address. These anti-bot measures make it more difficult for researchers to automate analysis and the obfuscation of the C2 location makes it more difficult to block.
Figure 10: C2 Domain Behind Cloudflare Proxy
Server-side Target Identifiers
Another observed change, albeit minor, is a change in the unique identifiers used for retrieving overlays from the command and control server. After an infected device provides a list of installed applications to the command and control server, the server responds with a list of applications and their corresponding unique IDs for retrieval. A subsequent POST by the device containing this unique ID prompts the server to return the HTML code for the corresponding overlay. In the initial versions of RedAlert2, this unique ID was an hexadecimal string in the form shown in Figure 11.
Figure 11: Hexadecimal Unique ID
In the most recent samples, this unique identifier has been amended to a base64-encoded string which decodes to the targeted package name. In some cases, a second overlay screen is requested with the unique identifier being the package name with the number two appended. This new format is shown in Figure 12.
Figure 12: New Base64-encoded Unique ID
While none of these changes are drastic in nature, they illustrate the fact that RedAlert2 is actively being developed. The updated targets demonstrate the ability to quickly expand the Trojan’s reach. Ultimately, we expect the RedAlert2 actor to continually make changes to the code and the targeted organizations in order to keep demand high in an increasingly saturated mobile banking Trojan marketplace.
Sample Analyzed: 05888c0f55d23c8c4f3b1ad0fe478c3d1610449f45abb9247f59563ac12ff82c
Need to fight back against mobile threats targeting your customers? Click below to find out how PhishLabs can help.
*** This is a Security Bloggers Network syndicated blog from The PhishLabs Blog authored by Joshua Shilko. Read the original post at: https://info.phishlabs.com/blog/redalert2-mobile-banking-trojan-actively-updating-its-techniques