When WhatsApp Isn’t WhatsApp: Third party app store risk
Fake Apps, Phishing and Silent Callbacks: What 12 Weeks of Mobile Traffic Revealed
Findings from a recent Corrata proof of value with a pan-African financial services organisation
Earlier this year we ran a 12 week proof of value with a leading financial services organisation operating across Africa. The brief was specific: could Corrata detect advanced spyware and mobile threats that their existing controls were missing? The deployment covered 20 users, a deliberately small sample chosen to allow deep analysis of every alert.
Twelve weeks of traffic from 20 devices produced a genuinely broad threat picture: live phishing infrastructure, malware distribution networks, suspicious command and control patterns, aggressive adware and unencrypted data leakage. It also made a strong case for mobile spyware detection built on traffic inspection rather than app inventory alone.
In this post we focus on one area of interest that stood out for how preventable it is: fake versions of popular apps distributed outside official app stores, requesting permission sets that would make a surveillance tool blush. We then walk through the other notable findings from the trial.
Area of interest: fake versions of the apps everyone uses
The most striking discovery of the trial was not an exotic piece of malware, but the apps everybody recognises.
On one enrolled device, Corrata identified unofficial versions of X (Twitter), Facebook, WhatsApp and, remarkably, the Android Settings app itself. Each one was convincing on the surface. The package names matched the genuine apps exactly. The version numbers matched current official releases. To the user, and to any security tool doing a superficial app inventory check, these looked legitimate.
The cryptographic hashes told a different story. Every one of these apps failed verification against the official builds. Same name, same version, different binary. That is the signature of a repackaged app: a genuine application that has been unpacked, injected with additional code, and rebuilt for distribution through third party channels.
The injected functionality was visible in the permission manifests. Compared to their official counterparts, the fake apps requested a set of additional capabilities that reads like a wiretap specification:
- Accessibility service binding on the fake X, Facebook and WhatsApp. Accessibility abuse is the workhorse of modern Android banking trojans and spyware. With this permission, an app can read everything on the screen, capture credentials as the user types them, and interact with other apps on the user’s behalf.
- Call control on the fake Facebook: the ability to answer incoming calls programmatically, place calls without showing the dialler, read the device’s phone number and read the full call log. Together these allow silent call interception and the mapping of everyone the user speaks to.
- System-level powers on the fake Settings app, including the ability to shut the device down, start activities from the background and manage role holders. Impersonating a system app is a persistence strategy: users do not uninstall Settings, and most would never think to question it.
The same device was also making callbacks to two algorithmically generated domains on low-reputation TLDs, the classic fingerprint of command and control communication. Fake apps and C2 traffic on one handset is not a coincidence. An infection chain is observed end to end.
And it was not a one-off. A second device in the same 20 user deployment carried the identical trio of fake X, Facebook and WhatsApp. A third showed suspicious versions of Package Installer and Settings. A fourth combined a modified WhatsApp with traffic to APK download sites and multiple malware distribution domains. Behavioural analysis of the malware on that device showed dynamic code loading, foreground service abuse for persistence, wake locks to keep the device alive, connections to unusual ports including SMTP, and external IP checks. That is a device being operated, not just infected.
The sideloading connection
Where do fake versions of Facebook and WhatsApp come from? Not from Google Play. Official stores are not perfect, but they verify developer signatures, scan submissions, and remove known-bad packages at scale. A repackaged com.facebook.katana with a mismatched hash cannot survive there.
Sideloading inverts that model. Third party app stores and direct APK downloads let anyone upload a rebuilt APK. Popular apps are cloned within days of release, injected with adware, credential stealers or full surveillance toolkits, and served to users looking for a free, unlocked or region-unrestricted version of something they already trust. Third party apps carry the trust in the brand. The scrutiny does not carry with them.
We saw this dynamic from another angle in the same trial. One device carried a fake GPS camera utility downloaded from APKPure, a popular third party Android store. Its permission set combined camera access, fine location, full read access to stored photos and video, persistent background execution and unrestricted network access: the functional definition of spyware, wearing a utility app’s icon. Corrata detected it and quarantined the device, cutting off its network access. The user removed the app. Over the following six days the same malware was detected on the same device five more times, each removal followed by a reinstall. Uninstalling a binary is not remediation when the distribution source is still one tap away.
The infrastructure side was visible too. Devices in the deployment generated blocked traffic to APK download sites and to a regional third party app store whose own client was transmitting device data over unencrypted HTTP: device make and model, operating system version and location, readable by anyone on the network path. No malware required. The store itself was the leak, a reminder that third party app store risk extends beyond the apps on offer to the store client itself.
The wider findings: what else 20 devices surfaced
Fake apps were one thread among several. The same 12 weeks of traffic produced findings across the full mobile threat surface, each significant in its own right.
Malware distribution and C2 infrastructure. Corrata blocked connections to well over a dozen active malicious domains. Several used algorithmically generated names on cheap TLDs such as .cfd, .top, .shop, .help and .world, classic indicators of Domain Generation Algorithms, the technique malware uses to locate its command and control servers even when individual domains are taken down. One device alone was linked to six distribution domains. Another, an iOS device, generated over 300 blocked malware connections during the trial period.
Phishing. Multiple devices attempted to reach live phishing infrastructure, including a domain impersonating a well known pan-African bank and a site harvesting usernames and passwords through a popup. For a financial services workforce, a convincing clone of a peer institution is exactly the lure most likely to succeed.
Suspicious command channels. One device generated simultaneous UDP traffic to four external IP addresses on a port associated with trojan activity. Two of the destination IPs were listed on the Spamhaus blocklist for suspected malicious activity. This is the traffic signature of a callback: an implant checking in with its operators.
Aggressive adware. A single device made 438 blocked connection attempts to one ad-tracking network, the pattern of a persistent process hammering away in the background and degrading privacy, performance and battery life.
Advanced spyware indicators on iOS. The original brief for this trial was advanced spyware detection, and iOS was not exempt from scrutiny. Seven iOS devices in the deployment, spanning multiple OS versions, exhibited traffic patterns that warranted escalation for investigation against known mercenary spyware behaviour.
Sophisticated spyware on iOS leaves almost no trace on the device itself. Its network behaviour is where it becomes visible, which is why mobile spyware detection at the traffic level was central to this engagement.
The pattern underneath the findings
Almost every serious finding in this trial shares a common thread. The threats did not arrive through email, and they did not exploit an unpatched operating system. They arrived through content: an app downloaded from the wrong place, a link tapped in the wrong context, an ad network with malicious intent.
This matters because most mobile security tooling cannot see content. A solution relying on superficial app inventory would have seen com.whatsapp at the current version number and moved on. What surfaced these threats was on-device deep packet inspection combined with cryptographic app verification: the ability to inspect the actual traffic leaving the device and validate what is genuinely installed, on the device, in real time.
That is how you spot a repackaged app with a matching version string, cleartext data leakage, DGA callbacks and phishing connections at the moment they happen, without routing user traffic through the cloud.
What security teams should take from this
- Verify apps cryptographically, not cosmetically. Package name and version number are trivially spoofed. Hash verification against official builds is the only reliable test, and it caught four fake apps on a single device in this trial.
- Treat sideloading as a policy decision, not a user preference. If your fleet includes Android devices, define whether third party app stores and direct APK installs are acceptable and enforce it. For BYOD populations where enforcement is harder, visibility becomes the control.
- Assume uninstall is not remediation. Our repeat-detection data shows malware coming back within hours of the user removing it. Quarantine contains the risk while it is present, but the fix is to root cause the installation source, not just the binary.
- Treat accessibility permission requests as high-signal events. Legitimate social and messaging apps do not need accessibility service binding. Its presence in a familiar app is close to a smoking gun.
- Inspect traffic, not just apps. Unencrypted data leakage, C2 callbacks and phishing connections are all network events, and on iOS the network is often the only place advanced spyware shows itself. If your mobile security stack cannot see traffic content, it cannot see the majority of what we found here.
- Small fleets still produce real findings. This was 20 devices over 12 weeks. Scale the numbers to a 2,000 device estate and consider what is currently going unseen.
Mobile devices are where your users read email, approve MFA prompts and access corporate data. In this deployment, apps indistinguishable from WhatsApp and Facebook at a glance were carrying the permissions needed to read screens, intercept calls and map every contact a user speaks to. They were caught because the device itself was doing the inspection.
If you want to see what 12 weeks of visibility looks like on your own fleet, a Corrata proof of value deploys in under 24 hours, with no MDM required. Book a demo today.
