Recent reporting from Malwarebytes and BleepingComputer describes a fake Google security page that leans on PWA installation and permission prompts to turn the browser into a phishing and surveillance tool. The attack is unsettling precisely because it does not need a browser exploit. It needs your trust.
According to the reports, the malicious site walks victims through a security check that asks them to install a Progressive Web App, enable notifications, and approve additional browser permissions. Once that happens, the attacker gains a far more persistent foothold than a normal phishing page would provide.
The browser does not have to be broken for this to work. The attacker only needs the victim to treat the page like a real security workflow.
This is not just another fake login page. Permission prompts, push notifications, and browser-installed apps can all become part of the phishing chain.
People treat a website differently from an app. When the malicious page is installed as a PWA, the normal browser chrome disappears and the experience feels more like a legitimate security tool. That small shift in presentation matters because it removes some of the visual cues users rely on when deciding whether a page is real.
Attackers break the compromise into steps that feel reasonable on their own. The page is framed as account protection, each permission request is explained as a security feature, and notification permission creates a channel to pull the victim back in later.
Users are not being rushed into one obvious mistake. They are being guided through a series of helpful steps that feel like normal account hardening.
Remove the installed PWA or home-screen app immediately, revoke notification permissions, clear site data, and review any passwords or MFA methods that may have been exposed while the app was present. Also check for companion mobile apps or unexpected device-admin settings if the site pushed you toward Android installation.
An installed PWA can run in a standalone window with no address bar, choose its own name and icon, set a theme color that matches the brand it copies, and send push notifications that render exactly like operating-system alerts. Stack those together and a webpage can pass as a native security tool for anyone who is not actively suspicious.
The tells are still there. An installed PWA shows up in the browser's own app-management page, not in the places real system software lives. Its window menu can reveal the site it came from, and that origin - not the icon or the window title - is the truth about what you installed. A real system security tool does not arrive by webpage, and a real Google account check happens at myaccount.google.com in an ordinary tab, with the address bar in plain view.
A permission prompt feels like a moment, but the grant is durable. Notification access keeps a channel open after the tab closes. Clipboard access can catch codes and passwords you copy later. That is why cleanup after an incident like this has to include revoking permissions and clearing site data, not just closing the window - and why a periodic sweep of your browser's site-permission settings is worth five minutes even when nothing has gone wrong. Remove grants you cannot explain; anything legitimate will simply ask again.
Flows like this are hard to catch at the network layer because each step - a page, an install prompt, a permission dialog - looks routine on its own. PhishClean works at the layer where the deception actually happens: it analyzes the page in your browser, locally, and flags brand-impersonating pages and suspicious flows before the first reasonable-looking step is taken. It is one defense against this class of phishing attack, and if you have already been through a flow like this, this recovery checklist pairs with the removal steps above.
This post is based on Malwarebytes' report Inside a fake Google security check that becomes a browser RAT and related coverage from BleepingComputer.
Why is a fake Google security check so convincing?
Because it borrows the look and language of a real account-security flow and then asks for permissions in steps that are framed as protective actions.
What makes the PWA angle important?
A Progressive Web App can run in its own window without the usual address-bar context, which makes the fake experience feel more like a native security tool than a webpage.
What should users do if they installed a suspicious security PWA?
Remove the app, revoke notification permissions, clear site data, change any passwords or MFA methods exposed during the compromise, and check for companion mobile apps or unknown device-admin settings.
PhishClean helps detect suspicious pages and browser-level signals before a fake security check turns into a persistent foothold.
Install PhishClean FreeIf this helped, share it with someone who would benefit from it, or subscribe for new browser-security guides from PhishClean.
Get practical phishing and browser-safety articles in your inbox. No salesy drip, just new guides and product updates when they are worth sending.