Play Store Fleeceware: Detecting Fake Call History Apps in the Wild
Just saw the report on the 7.3 million downloads for those fake call history apps. It’s wild that these made it past the Play Store vetting, but looking at the technical side, this is classic fleeceware behavior—social engineering masked as a utility tool.
While these don't leverage a zero-day CVE, the methodology is consistent: they aggressively request READ_CALL_LOG and READ_CONTACTS permissions, then immediately funnel users to a subscription wall. The malicious payload is the fraudulent billing logic, not a traditional exploit.
For those managing BYOD or corporate devices, blocking these purely by reputation is tough since they aren't flagged as malware by most AVs (they technically do show a call history, just a fake one). We need to look at behavioral heuristics.
I've put together a quick Python script using adb to scan connected devices for packages matching the naming conventions and high-risk permission sets typically associated with this campaign:
import subprocess
import re
# Regex patterns derived from similar fleeceware campaigns
suspicious_pkg_patterns = [
r"com\..*call.*history.*",
r"com\..*tracker.*pro.*",
r"com\..*lookup.*2026.*"
]
def check_high_risk_permissions(device_id):
# Check for apps holding READ_CALL_LOG and CONTACTS simultaneously
cmd = f"adb -s {device_id} shell pm list packages -f"
result = subprocess.run(cmd.split(), capture_output=True, text=True)
for line in result.stdout.splitlines():
for pattern in suspicious_pkg_patterns:
if re.search(pattern, line):
print(f"[!] Suspicious package detected: {line}")
# Iterate over connected devices
device_check = subprocess.run(["adb", "devices"], capture_output=True, text=True)
for dev in device_check.stdout.splitlines():
if "device" in dev and "List" not in dev:
check_high_risk_permissions(dev.split()[0])
Has anyone else seen these popping up in their mobile telemetry? What are you using to flag 'fleeceware' that doesn't trip standard malware signatures?
We spotted a few of these in our SOC last week. They don't trigger AV, but the telemetry on Microsoft Defender for Endpoint showed high 'Cost' events associated with obscure package names. We ended up creating a custom detection rule in KQL to flag any app installation that immediately requests billing permissions within the first 5 minutes of launch.
DeviceAppInstallEvents
| where Timestamp > ago(7d)
| join kind=inner (DeviceEvents | where ActionType == "BillingEvent") on DeviceId
| project DeviceName, AppName, Timestamp
From a pentester's perspective, the user is the vulnerability here. The apps just call standard APIs; the 'hack' is convincing the user to pay $20/month for a fake UI. I tried reverse engineering one of the APKs mentioned in the blog—no obfuscation, just standard Android code calling the Google Billing Library v5. It's frustrating because technical controls are less effective against this than user awareness training.
We manage a fleet of about 200 Android tablets for field work. Our policy is strictly 'Allowlisted Apps only' via the Play Store EMM API. It adds overhead to the onboarding process when a new tool is requested, but it completely kills the fleeceware vector. If it's not on the pre-approved list, it doesn't install.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access