We carried out only a short investigation on the topic. Our goal was to uncover more technical details about the attack and to confirm the existence of the backdoor in the particular APK file.

Highlights

We can confirm that the APK file known by the MD5 hash 6f7523d3019fa190499f327211e01fcb contains a backdoor that tries to communicate with a remote server.

The server IP in the sample is http://69.90.132[.]215/

The malicious APK does not use GPS to get exact location of the infected phone, it does not even ask for GPS-level position information.

We note, however, that some location information can be collected by the malicious APK, mainly related to the actual base station used by the phone and the WiFi status.

The implant in the malicious APK has similarities to the X-Agent implants of the Fancy Bear / APT28 / Sofacy group described in former reports, but this is not necessarily an evidence on the relationship as such similarities can be faked.

We uncovered two interesting items: the malware authors put the German word “nichts” as a string in the code, as well, they made a typo “phone standart.”

In the poprd30.apk code very similar items can be found related to the malicious communications:

By looking into BuildConfig it seems that one recompiled this APK modified Androdi Debug Key.

As one can see, strings in the APK file are very similar to those in the X-Agent implant, and have the same common goal: make the HTTP request similar to normal HTTP GET requests with common parameters. However, this similarity alone is not enough to state that the authors are the same, because it is very easy to copy this scheme.

Also, observe the initial value for the SERVER_ANSWER variable. It is “nichts,” which means “nothing” in German. We don’t know why a german word was used here. Note that this value is not used in the code, it stands only as a default value. That means, if no value is received from the server, then the corresponding function will return this value instead of the information received from the server. In the RegG.java file, which has the similar SERVER_ANSWER value it is set to ‘{ “no_jobs”, “or”, “error” };’ for default value. Setting a default value generally helps developers to find out if the data transmission was successful in the parts of the code not close to the transmission itself. One can simply check if the answer is still the default value, and if it is, it can be sure that the transmission was not successfull without complicated routines. However, in this APK we found no reference for checking if the SERVER_ANSWER has not been changed, and we don’t have clear idea why these two default values were used in the code.

Commands

Communication routines are spread across multiple classes: DataConstructor, DataExtractor, Reg, RegG, RegP, RegPBin. The main handling of the commands is in MainService. It is not entirely clear why there are multiple copies of some data and routines.

The malware sends basic info about the phone to the attacker as shown below:

Command 101 has a typo “phone standart” which should be “standard” both in English and German.

For command 101, it is important to note that it can provide location related information. In case of GSM , the base station related information can provide some (not so accurate) location information. Similarly, in case of CDMA, base station information is related to location, but it is not accurate either. In addition to the base station, WiFi information can also help an adversary to find out the approximate location of the phone, but it is nowhere close to accurate detection of the real location of the phone.

We have not seen any GPS related commands in the code, not even the original “D30 guidance” functionality. Most likely, the APK does not use GPS data. To be even more precise, the application Manifest information does not contain any requests related to GPS level locality permissions; it asks for ACCESS_COARSE_LOCATION only, which relates to the base station/WiFi based location information.

Encryption – RC4

The malware uses communications encrypted by RC4, encoded by Base64 (or very similar – we did not check it carefully), and CRC for error checking. These are very common, but the most important thing is the RC4 implementation and the key in use, which can be proved to be similar to the older X-Agent implants.

The corresponding RC4 key is also visible in the java byte code format:

Note: Rc4 keys can be arbitrary length, and implementation is very easy, hence it is used many times.On the other hand, RC4 is not secure enough for real crypto operations.

Conclusions

In our investigations, we tried to check if the APK indicated in the CrowdStrike report had backdooor connectivity. We can confirm, that this APK file has malicious functionality and can be used to collect intelligence from the users of the applet. Some additional technical details were discusssed. We (and probably CrowdStrike, too) had no access to the original, unmodified APK file.

UPDATE1

Some linux X-Agent versions used exactly the same RC4 key, see this screenshot: