Phishing

Fake Chrome app bought a top spot on Google Play

By Yaali. October 17, 2026, 6 min read, Phishing, Threat intel.

A fake Chrome listing from Hizbartech ran as a sponsored Play Store result and passed 100,000 installs. How it worked and how IT can find and block it.

On October 14, a user on the r/browsers subreddit spotted an app called Chrome sitting above Google's real browser in Google Play search results, marked as sponsored. The listing used Chrome's icon and Google's own description text. Its developer was Hizbartech, not Google LLC, and the listing showed over 100,000 downloads. People who installed it found no browser at all: Beebom and Digit describe a chat-style app full of AI avatars, and Digit reports that it flooded the screen with ads. Google removed the listing the same day, and Google has not commented publicly.

On current evidence this is adware-style abuse of the store and its ad system. Beebom and Digit both report no evidence so far that the app stole passwords or installed malware, and testers reported no data-stealing behaviour. It still matters to anyone who manages Android phones: a paid placement put a fake app first for one of the most searched app names on the store, and the only visible difference on the listing page was the developer name.

How it works

A Google Play listing has two kinds of identity. The parts a user sees, such as the app name, icon, screenshots and description, can be edited by the developer at any time after publication. The parts that stay fixed are the package name (the unique ID Android uses for the app, such as com.android.chrome for the real Chrome) and the developer account it belongs to. A rename changes the first set and leaves the second alone.

That is what happened here. PiunikaWeb, Beebom and Digit all report that the app was first published in August as a game called Ball Bounce and was changed to look like Chrome in late September. Digit gives exact dates of August 22 for the launch and September 30 for the rename; the others say only "August" and "late September". The package name, com.ballbounce.Hizbartech according to PiunikaWeb and SammyGuru, still carried the game's name. None of the reports says whether the rename went through a fresh review, or what Google checked before accepting a Chrome name and icon from a developer that is not Google.

The second ingredient is paid placement. Google Play shows sponsored results at the top of search, and the r/browsers report and Android Authority both say the fake listing appeared that way for "Chrome". A sponsored tag tells a user that someone paid for the position. It says nothing about who the developer is, as Digit points out, and neither does a high download count. PiunikaWeb could not reproduce the sponsored result itself when it searched "Google Chrome", though searching for "Hizbartech" still brought up the listing.

What we know about the app

The reported facts are short. PiunikaWeb and Beebom both list the app at 42 MB and over 100,000 downloads. SammyGuru adds a caution: while a screenshot shows 100,000+, an indexed copy of the same Play listing showed 10,000+, and neither figure says how many installs happened while the app was posing as Chrome. SammyGuru also notes that the app tracker AppBrain dates the Ball Bounce package to July, not August, so the timeline is not settled.

After install, users saw setup prompts, including one to pick an avatar, and then the chat interface. A second Reddit post, on r/chrome, urged users to flag the listing as adware. No researcher has published an analysis of the app's code or network traffic. "No evidence of theft" therefore means nobody has reported any; the app has not been audited.

What to do

The listing is gone, so nobody can install it now. The work is to find copies already installed and to make the next lookalike harder to install.

1. Check your inventory for the package. Search for com.ballbounce.Hizbartech and for the developer name Hizbartech. In Microsoft Intune, the Discovered apps report (Apps, then Monitor, then Discovered apps) lists apps found on enrolled devices. In the Android Management API, devices report installed apps in applicationReports once statusReportingSettings.applicationReportsEnabled is set to true in the policy.
2. Know what your inventory cannot see. Microsoft's documentation says Intune cannot inventory apps in the personal profile, even on corporate-owned devices with a work profile. On personally owned phones, ask users directly: open Settings, then Apps, and look for a second app named Chrome. On a phone connected to a computer with USB debugging on, adb shell pm list packages ballbounce returns the package if it is present.
3. Remove it. On managed devices, add the package to the policy with installType: BLOCKED, which Google's documentation says uninstalls an app installed under a previous policy and stops it being installed again. On personal devices, uninstall it from Settings, then run a scan from the Play Store app (profile icon, then Play Protect, then Scan). Since no credential theft has been reported, a password reset is not required on current evidence; if a user typed work credentials into the app, treat those as exposed and reset them.
4. Allowlist the store for work. Set playStoreMode to WHITELIST in the Android Management API (MDM consoles built on it usually present this as allowing only approved apps). Only the apps in the policy are then available in the work profile, and anything else is removed. Approve Chrome by its package name, com.android.chrome, published by Google LLC, so a lookalike never reaches the approved list.
5. Report lookalikes. On the Play Store listing, open the menu and choose "Flag as inappropriate". The r/chrome post asked users to do exactly that, and the listing came down the same day.

Store listings as a brand risk

Teaching staff to "check the developer name" helps, and Digit's advice is just that: real Chrome comes from Google LLC. It is weak as the only control, because the developer name is a single line of small text under a copied icon, and the user already trusts the result enough to have searched for it. On work devices, an allowlist removes the decision from the user entirely.

The same tactic works against any organisation with a mobile app. An old listing with an unrelated name can be renamed, given your icon and description, and pushed above your app with a paid ad. If you publish apps, search the stores for your own brand name now and then, note which package names and developer accounts are legitimately yours, and give your support team that list so they can answer quickly when a customer asks whether an app is real.

Our safeguarding and hardening work includes mobile device management baselines such as managed Google Play allowlists and app inventory, and our mobile penetration testing team looks at how your own apps hold up when someone copies or repackages them. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: PiunikaWeb, Android Authority, Beebom, Digit, SammyGuru, Android Management API, Policy reference, Microsoft Learn, Intune discovered apps, Microsoft Learn, personal apps in discovered apps.