Joker is one of the most prominent malware families that continually targets Android devices. Despite awareness of this particular malware, it keeps finding its way into Google’s official application market by employing changes in its code, execution methods, or payload-retrieving techniques. This spyware is designed to steal SMS messages, contact lists, and device information along with silently signing up the victim for premium wireless application protocol (WAP) services.
Our Zscaler ThreatLabZ research team has been constantly monitoring the Joker malware. Recently, we have seen regular uploads of it onto the Google Play store. Once notified by us, the Google Android Security team took prompt action to remove the suspicious apps (listed below) from the Google Play store.
This prompted us to evaluate how Joker is so successful at getting around the Google Play vetting process. We identified 17 different samples regularly uploaded to Google Play in September 2020. There were a total of around 120,000 downloads for the identified malicious apps.
The following are the names of the infected apps we discovered on the Google Play store:
(As of this writing, all of these apps have been removed from the Google Play store.)
In this blog, we will discuss the tactics used by the Joker malware author to bypass the Google Play vetting process.
In some of the Joker variants, we saw the final payload delivered via a direct URL received from the command and control (C&C) server. In this variant, the infected Google Play store app has the C&C address hidden in the code itself with string obfuscation. We observed the string “sticker” was used to break the C&C address to hide it from the simple grep or string search, as shown in Figure 1.
Figure 1: The C&C address string obfuscation.
Once installed, the infected app contacts the C&C server, which then responds with the URL of a final payload. This JSON file also has the information related to the class name that needs to be executed from the final payload to do all the malicious activities.
Figure 2: The C&C JSON response.
Upon receiving the JSON configuration from the C&C, the infected app downloads the payload from the received location and executes it.
Figure 3: The final payload download.
In some apps, we observed that for retrieving the final payload, the infected Google Play app uses a stager payload. Here the infected Google Play store app has the stager payload URL encoded in the code itself encrypted using Advanced Encryption Standard (AES). Upon infection, unlike scenario 1, it downloads the stager payload rather than a final payload, as seen in Figure 4 and Figure 5.
We also saw two varieties of the stager payload—an Android Package (APK) or a Dalvik executable file.
Figure 4: The Dalvik executable stager payload download.
Figure 5: The APK stager payload download.
The job of this stager payload is to simply retrieve the final payload URL from the code and download it. Along with the payload download, it is responsible for executing the final payload as well.
In the stager payload, we also saw some different tactics used by the malware author to hide the final payload URL. We saw instances where the final payload is obfuscated with AES and, in some cases, we saw simple shift operation was used to obfuscate the final payload URL.
In some cases, the final payload URL was also in plain text.
Figure 6: AES encryption for the end payload URL.
Figure 7: The plain text end payload URL.
Figure 8: The plain text end payload URL.
Figure 9: The obfuscated end payload URL with Shift encoding
Upon execution, it downloads the final stage payload, which is the core Joker malware doing all the infection activities ranging from premium SMS subscription scam to spyware activities, as seen in Figure 10.
Figure 10: The end payload download.
In some groups of infected Google Play store apps, we saw two-stager payload downloads used to retrieve the final payload. Here, the Google Play infected app downloads the stage one payload, which downloads the stage two payload, which finally loads the end Joker payload.
Interestingly, unlike previous two scenarios, the infected app contacts the C&C server for the stage one payload URL, which hides it in response location header.
Figure 11: The C&C response for the stage one payload URL.
Upon infecting the device, the infected app downloads the stage one payload from the received URL from the C&C in the response header. Like scenario two, the job of this payload is to simply download another payload but this time it won't be the final payload. Observe the below screenshot for the same activity.
Figure 12: The stage two URL in stage one code.
Upon execution of the stage one payload, it downloads the stage two payload. The stage two payload exhibits the same behavior as the stage one payload. It includes the hard-coded URL, which retrieves the final payload as shown in Figure 13.
Figure 13: The final payload URL in the stage two code.
Although these variations were used by Joker to reach the end payload, we saw the same end payload downloaded in all the cases. Here are some highlights of the final payload activities.
The final payload employs DES encryption to execute the C&C activities.
Figure 14: The DES encryption for the C&C post request.
Figure 15 shows the network patterns used by Joker to execute the C&C activities.
Figure 15: The C&C pattern for the post request.
The end payload also employs string obfuscation to hide all the important strings. It uses string “nus106ba” to break all the important strings to hide it from simple string search.
Figure 16: The string obfuscation.
Figure 17 shows the SMS harvesting and WAP fraud done by Joker.
Figure 17: The WAP fraud.
This post provides in-depth details related to end payload activities done by Joker.
We recommend paying close attention to the permission list in the apps that you install on your Android device. Always watch out for the risky permissions related to SMS, call logs, contacts, and more. Reading the comment or reviews on the app page aslo helps identify compromised apps.