FluBot is a useful starting point for understanding why app impersonation is hard to catch by accident. The malware spread by convincing Android users they were installing legitimate parcel-tracking apps or banking apps, including versions impersonating Great Southern Bank, Suncorp, and Ubank. Victims got a missed-parcel phishing text with a link to a malicious site, installed what looked like the real app, and got a fake login screen laid over the top of it. The overlay captured their credentials, then the malware used their own contact list to send the same scam text to everyone in it. Nobody involved thought they were doing anything risky. That is the pattern worth internalizing before you go looking for apps impersonating your own brand: the fake doesn't need to fool a security team, it only needs to fool a customer once. Spotting these listings before your customers download them is a process, not a single search. Here is how to run it.
What makes an app a fake impersonating your brand
A fake app copies your brand's name, icon, screenshots, or interface to suggest a relationship that doesn't exist. It might also use a misleading developer name or claim outright to be the official release. None of that requires sophisticated engineering. A convincing copy is often just a repackaged version of your real app with a different login screen stitched in.
As Outtake's research on fake app detection puts it, Impersonation and malware are different findings. An app can mislead customers into thinking it's yours without containing any malicious code, and a malicious app doesn't need to copy a known brand at all to do damage. Where the two combine, the consequences compound. A copied app can steal credentials, collect personal information, intercept communications, show a fraudulent payment page, or install additional malware once it's on the device.
Build a baseline of your legitimate apps first
Before you can tell a fake from the real thing, you need a documented list of what the real thing actually is. That means an inventory of every legitimate app your brand publishes, the approved publisher name attached to each one, the store listings themselves, any approved partners authorized to distribute on your behalf, and the official download links you point customers to.
Without that baseline, detection gets confused in both directions. A legitimate regional release, say a localized version maintained by a partner in a different market, can get flagged as an impersonator because nobody on the team recognized the developer name. Meanwhile a genuine impersonator can slip past review because it superficially resembles something the team has seen before and nobody checks it against an actual approved list. The inventory is the reference point everything else in this process gets compared against.
Check a suspicious listing against four verification signals
Once you have a baseline, verifying a suspicious listing means comparing it against four signals rather than relying on any single one: publisher identity, listing content, app identity, and destination links. Each signal rules things in or out on its own, but a confident call usually needs more than one of them to agree.
Publisher identity
Check whether the developer name on the listing matches your approved publisher or a documented partner from your baseline inventory. A copied logo on its own is worth a closer look, but it doesn't establish fraud by itself. Confirm first whether your brand authorized that publisher and what the listing is actually claiming before you escalate it as impersonation.
Listing content accuracy
Look at whether the app name, icon, description, and screenshots imply official status that was never granted. Warning signs worth flagging for further review include unusual permission requests for an app of that type, download links that route through unfamiliar domains, developer contact information that doesn't match your records, or an interface that's been lifted directly from your official app's screenshots.
App identity and signing certificate
Compare the package or bundle identifier against the one your legitimate release uses. For Android apps specifically, check the app-signing certificate against your approved release and distribution channel, keeping in mind that legitimate key changes do happen over an app's lifecycle, so a certificate mismatch alone needs context before you treat it as proof. A signed APK by itself proves very little, since Android requires every APK to carry a signature regardless of who built it or why.
Destination links
Check where the support links, privacy policy, and download paths in the listing actually lead. A legitimate listing points to your authorized domains. A fake one often points somewhere unrelated, or to a domain that was registered recently and has no history tied to your brand. If those destinations don't match your baseline, treat the listing as unverified until you can confirm otherwise rather than assuming good faith.
Look beyond the official app store
Fake apps don't confine themselves to the store where your real app lives. They circulate through third-party app stores, unofficial websites, and sideloaded APKs that never go near an official review process at all. FluBot is the clearest illustration of why that distribution path matters. The malware behind it spread globally because victims believed they were installing real parcel-tracking and banking apps, and the infection chain started with a phishing text, not a storefront search.
Once installed, the malware overlaid a fake login form on top of the genuine app to capture credentials, then used the victim's own contacts to push the same scam further. None of that required getting past an app store's review team, because the install happened entirely outside the official store. A monitoring effort that only watches the official listing misses this distribution path by design. The malicious sites that host these installs sit on the website side of the same campaign, which is where a domain monitoring and takedowns program applies.
Decide whether you have impersonation, malware, or both
Once you've flagged a suspicious listing, the next step is classification, because the finding determines what you do next. Permissions requested, user reviews, and download counts all add useful context, but none of them proves legitimacy or impersonation on its own. A listing with a handful of downloads and no reviews yet isn't automatically fake, and a listing with thousands of installs isn't automatically clean.
What matters is which category the finding falls into. An app that copies your brand's name and interface without carrying malware is still misleading your customers and still worth enforcement action, even if it never steals a credential. A malicious app that never touched your brand name is a different problem with a different enforcement path, probably one that belongs with the store's malware reporting process rather than a trademark or impersonation complaint. Get this classification right before you file anything, because it determines who you're asking the store to act against and on what basis.
Preserve evidence before you request a takedown
Before requesting enforcement from a store, registrar, or hosting provider, preserve the listing URL, the developer details as they appear on the page, screenshots of the listing itself, and the time you observed it. Where you can get them safely, add the package identifier and file hash, since both help a store's enforcement team confirm you're describing the exact listing you want removed rather than a similar one.
One caution worth repeating: don't install a suspect app on an everyday device to test what it does. That kind of technical analysis belongs in an authorized, controlled environment, not on a phone that also holds your own accounts and contacts. The evidence you need for a takedown request, listing details, developer claims, and destination links, can almost always be gathered without ever running the app yourself.
What to do when the first takedown does not hold
A submitted complaint doesn't guarantee removal, and even a successful one doesn't close the case. Delisting a single app removes that one listing, not every copy of it that might already be distributed elsewhere under a different name or on a different store.
It's common for a removed listing to reappear under a new developer name, with slightly altered screenshots, or on a store you hadn't checked the first time. That recurrence isn't a sign the first takedown failed. It's a sign that one takedown request closes one instance, and the underlying campaign behind it keeps running until you catch the next copy too. Treat each successful removal as progress against a pattern, not as the end of the pattern.
Confirm the check is done by watching for new copies
A single listing is fully checked once it's been classified, the evidence is preserved, and an enforcement request has been filed against it. The broader risk to your brand stays open until new copies stop appearing under the same name or the same developer pattern, which is a different kind of completion entirely.
That's why protecting a brand from fake apps depends on continuous monitoring across stores and marketplaces rather than a single sweep. As Netcraft's guide on detecting and disrupting fake apps puts it, protecting your brand from fake apps requires continuous monitoring across app stores and marketplaces. The same logic applies to the websites and social profiles that often feed these app installs in the first place. That's why app store protection tends to sit alongside social media brand protection and phishing and scam protection as part of the same program, instead of running as a separate exercise. Bolster's digital risk protection platform runs that kind of continuous detection and automated takedown workflow across those surfaces, so new copies get caught and enforced against on an ongoing basis instead of only after the next customer complaint. If you want to see how that detection and takedown process works against your own brand's exposure, request a demo.
References
"How Can I Detect Fake Domains and Apps Impersonating My Brand | Seqrite." seqrite.com, https://www.seqrite.com/blog/how-can-i-detect-fake-domains-and-apps-impersonating-my-brand/.
