Technical details on the Fancy Bear Android malware (poprd30.apk)

Background

Recently, Crowdstrike has published details about a malicious Android APK file, named poprd30.apk or Попр-Д30.apk. It seems that the malware was created by the Fancy Bear group for tracking Ukrainian field artillery units (more info on this can be found here: https://www.crowdstrike.com/wp-content/brochures/FancyBearTracksUkrainianArtillery.pdf). The corresponding APK is identified by the MD5 hash 6f7523d3019fa190499f327211e01fcb on a related blog site https://www.crowdstrike.com/blog/danger-close-fancy-bear-tracking-ukrainian-field-artillery-units/. However, not much technical details have been given by CrowdStrike on the attack. During discussions on the topic, Jeffrey Carr initiated discussions with us and has sent some questions on if the case is real and how exactly the attack works, in particular, how the malware could have been used in military conflicts.

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.”

Details

In February 2015, Trend Micro posted details about an iOS espionage app possibly related to the Pawn Storm / Sofacy / APT28 / Fancy Bear group. The technical details can be found at http://blog.trendmicro.com/trendlabs-security-intelligence/pawn-storm-update-ios-espionage-app-found/. Figure 5 of the Trend Micro document shows possible URL GET parameters used by the malicious code:

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:

byte[] arrayOfByte = Base64.encode((“<pre> CMD 101 success” + “ GoogleAccounts: ” + str1 + “ Device ID: ” + str2 + “ Model: ” + Build.MODEL + “ Manufacturer: ” + Build.MANUFACTURER + “ Phone standart: ” + str4 + “ Country: ” + str5 + “ MCC & MNC: ” + str6 + “ Base station: ” + str3 + “ Android version: ” + str7 + “ Android SDK: ” + m + “</pre>”).getBytes(), 0);

The malware can receive the following commands:

Commands 103 105 108: stop itself
Command 100 : Send SMS History /commands are self-explanatory/
Command 101: Collect “all” information about the phone and send
Command 102: GetCallDetails (Call history)
Command 104: FetchContacts
Command 106: GetAppList
Command 107: GetWifiStatus (is any WiFi network available, what identifier, what MAC address, speed, etc.)
Command 109: Browser history and bookmarks
Command 110: Mobile data usage
Command 111: Folders and files from sdcard directory
Command 112: File download (SDcard) for command
Command 101 – Gets GSM network LAC, CID info or base station info (coordinates) if CDMA, andorid version, google accounts, device id, etc.

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:

In hex, the encryption key is 3B C6 73 0F 8B 07 85 c0 74 02 FF CC DE C7 04 FE 72 F1 5F 5E C3 56 B8 D8 78 75 50 E8 B1 D1 FA 59 5D 55 EC 83 10 A1 33 35

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: