Inside a fake Google security check that becomes a browser RAT

Disguised as a security check, this fake Google alert uses browser permissions to harvest contacts, location data, and more.

A website styled to resemble a Google Account security page is distributing what may be one of the most fully featured browser-based surveillance toolkits we have observed in the wild.

Disguised as a routine security checkup, it walks victims through a four-step flow that grants the attacker push notification access, the device’s contact list, real-time GPS location, and clipboard contents—all without installing a traditional app.

For victims who follow every prompt, the site also delivers an Android companion package introducing a native implant that includes a custom keyboard (enabling keystroke capture), accessibility-based screen reading capabilities, and permissions consistent with call log access and microphone recording.

The infrastructure uses a single command-and-control domain, google-prism[.]com. The domain is routed through Cloudflare’s content delivery network, a service widely used by both legitimate and malicious sites.

A security page without an address bar

The attack begins with what appears to be a genuine Google Account security alert. It does not rely on an exploit or browser bug. It relies on you believing you are responding to Google.

[Install Security Check app]

The user is prompted to “install” the security tool as a PWA

When installed as a PWA (a Progressive Web App, essentially a website that pins to the home screen and runs in its own window), the browser address bar disappears. The victim sees what looks and feels like a native Google app.

In testing, we were guided through four steps, each framed as a protective action.

• The user is prompted to “install” the security tool as a PWA.

• The site requests notification permissions, framed as enabling “security alerts.” Web push notifications give the attacker a persistent communication channel that can function even when the PWA is not actively open.

• The site uses the Contact Picker API—a legitimate browser feature designed for sharing contacts with web apps. The victim is prompted to select contacts for sharing. After selection, the interface displays confirmation text such as “X contacts protected,” framing the step as a security check. However, network analysis shows the selected contacts are sent directly to the attacker-controlled domain.

• The site requests GPS location under the guise of “verifying your identity from a trusted location.” Latitude, longitude, altitude, heading, and speed are all exfiltrated.

Installed web app

What happens after you close the tab

When the victim installs the PWA and grants permissions, two separate pieces of code go to work. Understanding which does what explains why closing the tab is not enough.

The page script runs as long as the app is open. It attempts to read the clipboard on focus and visibility-change events, looking for one-time passwords and cryptocurrency wallet addresses. It tries to intercept SMS verification codes via the WebOTP API on supported browsers, builds a detailed device fingerprint, and polls /api/heartbeat every 30 seconds, waiting for the operator to send commands.

The service worker is the part that survives if you close the tab.

It sits underneath the page, handling push notifications, running background tasks embedded in push payloads, and queuing stolen data locally when the device goes offline, then flushing that queue the moment connectivity returns. It includes handlers for background and periodic sync events, allowing it to wake and execute tasks where those features are supported and registered.

Close the browser tab and the page script stops. Clipboard monitoring and SMS interception end immediately.

But the service worker remains registered. If the victim granted notification permissions, the attacker can still wake it silently, push a new task, or trigger a data upload without reopening the app.

And if the victim ever opens it again, collection resumes instantly.

Your browser, their proxy

Perhaps the most concerning capability is the WebSocket relay. Once connected, the attacker can route arbitrary web requests through the victim’s browser as if they were browsing from the victim’s own network.

The malware acts as an HTTP proxy, executing fetch requests with whatever method, headers, credentials, and body the attacker specifies, then returns the full response including headers.

This means:

• If the victim is on a corporate network, internal resources could become reachable

• IP-based access controls can be bypassed

• The attacker’s traffic appears to originate from the victim’s residential IP address

The toolkit also includes a port scanner that sweeps internal network ranges (by default, all 254 addresses on the local subnet across ports 80, 443, and 8080) using a timing-based technique to identify live hosts all from within the browser sandbox.

In addition, the attacker can execute arbitrary JavaScript on the victim’s device via a remote eval command sent over the WebSocket.

Stolen data never disappears

The toolkit is engineered to tolerate poor connectivity. When the device is offline, captured data—clipboard captures, location updates, intercepted OTPs—is queued in the browser’s Cache API, stored as individual entries under keys like /exfil/{timestamp}-{random}.

[Exfiltrated clipboard data]

Exfiltrated clipboard data

When connectivity returns, a Background Sync event replays every queued item to the server. Each entry is deleted only after the server confirms receipt.

On Chromium-based browsers, the service worker includes a handler for Periodic Background Sync under the tag c2-checkin, enabling scheduled wake-ups where the feature is supported and activated. Combined with push-triggered heartbeats, this means the attacker can maintain contact with a compromised device for as long as the PWA remains installed, which could be weeks or months.

Website’s heartbeat monitor

When the browser isn’t enough: the native implant

[It requires the user to "Allow Restricted Settings"]

It requires the user to “Allow Restricted Settings”

For victims who follow every prompt, the web layer delivers a second payload: an Android APK disguised as a “critical security update.”

The download page claims it is “Version 2.1.0 · 2.3 MB · Verified by Google.”

The actual file is a 122 KB package named com.device.sync, labeled “System Service” in the app drawer.

The APK requests 33 Android permissions, including high-risk privileges such as SMS access, call log access, microphone access, contacts access, and accessibility service control.

It includes:

• A custom keyboard capable of capturing keystrokes

• A notification listener that can read incoming notifications, including potential two-factor codes

• An accessibility service that can observe screen content and perform actions in other apps

• An autofill service positioned to intercept credential fill requests

The web layer’s “Enable Autofill” screen is designed to guide the victim through turning on this malicious autofill service in Android settings.

To enhance persistence, the APK registers as a device administrator (which can complicate uninstallation), sets a boot receiver to execute on startup, and schedules alarms intended to restart components if terminated. The application includes components consistent with overlay-based UI capabilities, suggesting potential use for phishing or credential interception overlays. A FileProvider component is present, consistent with staged update delivery. Whether updates can be installed silently depends on device privilege level and policy configuration.

What to do if you may have been affected

This campaign shows how attackers can abuse legitimate browser features through social engineering rather than exploiting a vulnerability in Google’s systems.

[...]

Original source