2025-10-14 –, Main Track
The Joker toll fraud family is one of the well known Android malware families. For more than six years they have been sending malicious apps to the Play Store during which time they have become very proficient at hiding their code and behavior from app analysis systems. They quickly adapt to Google detection infrastructure improvements and constantly change their behavior.
For one variant in particular it was identified that the actors were using newly registered domains and never reusing them for other apps. It is extremely hard to discover such domains because they use different registration details and domains have meaningful names sometimes. However we discovered a flaw in their infrastructure that allowed us to quickly identify new apps before they are distributed to users.
In this talk we'll cover common tactics used by the Joker toll fraud family and go in depth on a flaw we discovered wherein the Joker threat actors would spin up new back end infrastructure making use of default configurations to service new app campaigns. Through this flaw we have been able to develop an early detection mechanism leveraging Censys APIs which allows us to identify new Toll Fraud apps in almost-real-time, and prevent the publication of malicious apps to the Play store to protect Android users.
Thesis / Takeaway: What is the core message/takeaway you want participants to get out of your session?
Threat Actors make mistakes - stay on top of understanding the tactics used by your primary threat actors, so you can identify when they slip up and use this to your advantage. For example when threat actors scale their operations they introduce patterns that can be used for their detection and tracking
Detailed Description: For more words beyond abstract.
Joker being one of the oldest and most sophisticated Toll Fraud actors are doing everything at scale - starting from experimenting with cloaking and obfuscation up to deploying modern cloud server stacks to load balance all of the different malware campaigns they manage. We have been tracking this actor's evolution over the years and have witnessed first hand as they have adapted to the detection capabilities deployed on Android.
As is common with modern TLS load balancing deployments, a centralized TLS termination server is typically deployed to handle the TLS termination for clients, and after a secure channel is established the client is free to communicate with the desired host name. A common configuration default as part of Server Name Indication (or SNI), is that a default certificate is specified as part of the load balancer configuration, in the event that a direct IP address is requested and no SNI hostname is specified as part of the request. In such cases, this default certificate is passed back to the client to establish the secure communication channel.
It was during the vetting of some new tooling capabilities, specifically integrations with Censys, that we discovered a unique TLS certificate fingerprint was associated with numerous Joker servers. After querying numerous servers values we postulated that this makes sense based off of how SNI is configured by default, but began expanding our searches based off of this certificate digest, and discovered that Joker actors, as would be expected of anyone administrators deploying TLS load balancers in the cloud, were leveraging what appeared to be a cloned image of a presumed virtual machine for every TLS terminating server they stood up. As we have been tracking their TTPs for some time, it was noted that the Nginx server version was always the same, and the default certificate passed back by navigating to any of the direct IP addresses for C2 servers would always return the same certificate digest.
Upon verifying this discovery, we were able to build some simple automations that would regularly query Censys data to identify any new hostnames that were associated with IP addresses that returned this default certificate, and were able to employ new pre-emptive detections that ensured that any new C2 infra stood up by Joker, we’d immediately catch any new malware campaigns deployed to Google Play. Through these automations we identified more than 300 fresh Joker controlled servers over the past 9 months.
Outline: A detailed outline of your presentation, panel, workshop, or BoF content. More detail is better.
We’ll start our talk by covering an introduction to Toll Fraud to ensure a base state. This will give an overview of how the attack works and common targets we’ve seen over the past several years of combatting this malware threat
Once we’ve established a common foundation, we’ll offer tactics commonly used by some of the bigger players in the Toll Fraud space - specifically a threat actor commonly referred to as Joker. We’ll cover typical app themes we see them publish, as well as abuse tactics we see employed in their Apps (DCL, obfuscation tactics, native layers, leading up to client side and server side cloaking techniques to hide their payloads)
Next, we’ll discuss a new capability that we’ve leveraged to identify server infrastructure for new campaigns. We’ll cover theoretical workflows used by the actors, and discuss how we noticed that for some malicious apps identified the C2 infrastructure was returning the same TLS certificate, and by using capabilities like Censys we were able to identify all hosts associated with this same TLS certificates, allowing us to pre-emptively detect on new apps sometimes even before they were published on the Play store.
We’ll then conclude by sharing our findings - how many IPs and domains we discovered, how many of them were associated with known apps. For some domains we never found related apps, most likely meaning that we caught them even before they started publishing malicious versions.
In the end of our presentation we are going to share some additional findings that may help us shed a light on the Joker developers - we caught them using the same configuration even for some domains not related to the toll fraud apps.
Intended Audience: Who will get the most out of your session?
Security engineers, Malware analysts, Threat intelligence
Roman is a reverse engineer with the Android Malware Research Team at Google where he is focused on projects that hunt down malicious apps as part of Google Play Protect. For more than 10 years Roman detecting and analyzing mobile malware focusing on large botnets and advanced threats. In the past Roman presented at different conferences including RSA, VB, CARO, AVAR and Kaspersky SAS.