Recently we blogged about a new threat to Polish e-banking users called “E-Security”. When a user, whose machine was infected, tried to access her internet banking site she was greeted with a message that instructed her to install “E-Security Certificate” application on her Android phone. This “certificate” was nothing more than a malware capable of forwarding short messages to the attacker. As the attacker had a login, password to the banking transaction system (this is because initially the user machine had to be infected) and could access the SMS one time password it was easily possibly for the attacker to initialize an unauthorized wire transfer from the victim’s account.

We then speculated about the other possible C&C communication channel. Instead of sending short messages via SMS, the malware could send all the messages using the HTTP protocol to a C&C server. This article presents a history of this malware that we were able to recover based on 10 different samples that claimed were four different versions. All of the samples were created for the Android platform.

Version 1.2.3

This was first version that we were able to obtain. It was marked as

and was first seen a year ago, on 7th of June 2012. Instead of pretending to be a security certificate, it was known as Android Security Suite Premium. It also had a different graphic layout. Supported languages were English, Spanish and Portuguese. The application used HTTP to communicate with the C&C server. The server address was obfuscated with additional characters, removed during every communication attempt. This is a simple mechanism designed to prevent automated tools from URL harvesting.

The second version of the trojan control is called “AlternativeControl” and was described in details in our previous post. It utilized short messages that started with the special characters (percent, exclamation point, comma etc). In this version the control characters were: percent (for “GET INFO” message), colon (”new number” message), asterisk (”fin” message) and dot (”uninstall” message). This version also required all of the possible Android permissions. The graphic presented on the left was shown to user upon application startup. The presented “Activation code” is based on the phone IMEI number (or, as will be described later, Device ID).

Version 1.2.7

Version 1.2.7 came with a series of improvements. The Italian language was now supported. The bug in a function that was used to generate an “Activation code” was solved. The previous version did not consider that the return value of the

could not be a decimal number. This function return the IMEI number for the GSM phones. This is composed entirely of decimal digits. However, for the CDMA based phones (CDMA is a set of standards that compete with GSM) this function return either the ESN (for older phones) or MEID, which can be presented as a hexadecimal number. This prevented the application from working on CDMA based phones. The problematic line is marked in red in the source code presented below.

The control characters for the short messages were changed to the ones present in the previously described version. To prevent researchers from redirecting the sample to a different URL a CRC32 check of the C&C URL was added. This checksum was compared to the one hardcoded in the malware.

Versions 1.2.8 and 1.2.9

Version 1.2.8 only slightly differs from the previous one. There was a small change in the way the CRC32 checksum was calculated and German language support was added. However, 1.2.9 version changed the graphic layout and evidently targeted Polish e-banking users. Instead of “Android Security Suite Premium” we had a “Certyfikat E-SECURITY” (Polish for “E-Security Certificate”). This change in graphic is presented on the right. Despite the “rebranding”, all field names are still referring to the “Antivirus” features of the previous application. Some samples have HTTP communication disabled and only use short messaged to connect to the C&C. In other versions URL address was still present, but it was not obfuscated despite the fact that the deobfuscating function was still present in the source code.

HTTP communication and SMS forwarding

In our previous post, we gave a detailed description of the SMS channel used for the C&C communication. However, the application can also send HTTP GET requests to the C&C servers. The response has to have a 200 status code. Commands are passed to the application using a set of HTTP response headers. These headers can either have a value

or any other value. When the

header is set to

the application will uninstall itself. Similarly, when the

header is set to

message forwarding will be temporarily disabled. If the forwarding is enabled, emssages are first forwarded by the SMS and, if this channel is disabled, sent using an HTTP protocol. The HTTP request contains

,

and

parameters that correspond to the number from which the message came and a message text. The

parameter indicates whether it was a last message in this batch.

If it is impossible to send a message via HTTP (either because there is no Internet connection or the server does not respond with 200 status code) message is saved in the SQLite database named

. Next, after a specified amount of time, a report is sent to the C&C server with all of the messages present in that database. This happens of course if the server is available.

Summary and samples data

Android malware is constantly evolving and changing its functionality. This particular trojan, despite its simplicity and vast amount of debug logs, has been a constant threat for over a year. It is now also capable of saving short messages in case of a lack of network connectivity. Additionally, it has a mechanism that hides the controlling mobile phone number.

MD5 hashes of the samples referenced in this article are presented below.