A convincing fake Google Account security page is being used as the front end for a surprisingly sophisticated browser-based surveillance toolkit that can convert an installed Progressive Web App (PWA) into a persistent command-and-control (C2) channel, steal one-time passcodes and clipboard contents, exfiltrate contacts and GPS coordinates, and even turn a victim’s browser into an attacker-controlled HTTP proxy — with Microsoft Edge among the affected browsers.
Background
The campaign was analyzed and documented in detail by Malwarebytes Labs after researchers encountered a deceptive site hosted on the domain google-prism[.]com. The site impersonates Google’s security-check flow and lures victims through a four-step process that culminates in installing a PWA labeled as a “Security Check” application. From there the web-based payload leverages standard web platform features — service workers, push notifications, the Contact Picker API, WebOTP, and geolocation — to create both an active data-harvesting agent and a background “service worker” that persists after the PWA window is closed.
Multiple mainstream outlets and regional security reporters have independently confirmed the core findings, noting the same domain and the same sequence of permissions requests (notifications, contact sharing, location, clipboard access), and reporting that the operation can optionally deliver a native Android package (APK) to escalate privileges for victims who follow additional prompts.
Why this matters: social engineering + legitimate platform features
This campaign is more dangerous than a standard phishing page for two reasons:
- It uses trusted browser capabilities that were not designed to be malicious but can be abused when combined with targeted social engineering.
- It does not rely on a zero-day or exploit; it works through user consent and legitimate web APIs, making it easy for attackers to scale without finding bugs.
PWAs are a legal, widespread way to install web apps on desktops and mobile devices. When a site is “installed” as a PWA, the browser can open it in its own window without the visible address bar and UI chrome — a UX change that
legitimately improves usability but here is being weaponized so the fake app looks like an official Google utility. The absence of an address bar reduces the user’s cues that they are still interacting with a website rather than an official native app.
Technical anatomy of the attack
1. Initial vector: deceptive pop-up or phishing link
Victims are typically directed to google-prism[.]com through phishing emails, redirected ad fraud, or other social-engineering vectors. The landing page is styled to mimic Google’s account-security flows and prompts the user to run a “quick Security Check.” The copy and UI are crafted to build trust and urgency.
2. Install as a PWA (the critical pivot)
The page asks the user to “install” the Security Check app. If the user agrees, the PWA is registered with the browser and opens in a separate window. Because many browsers show installed PWAs in app lists and allow them to behave like native apps, users can be easily fooled into trusting them. When installed, the PWA registers a
service worker — a background script that the browser runs independently of the open page. This service worker becomes the persistent element of the attack.
3. Push notifications as a C2 channel
The PWA requests push notification permission under the guise of “security alerts.” Once granted, the attacker can deliver push payloads that the service worker will handle. These push payloads are capable of triggering background tasks, waking the service worker, and carrying command data that instructs the PWA to perform actions such as data uploads or executing code embedded in the payload. That’s effectively a remote command-and-control channel that survives the PWA’s visible window being closed.
4. Contact exfiltration via Contact Picker API
Rather than asking victims to type or upload their contacts (which would be obviously suspicious), the site uses the standard Contact Picker API to show an OS-like dialog where users can select contacts to “share” for a security check. The selected contact details are then posted back to the attacker’s server. This is a textbook example of abusing a legitimate API for malicious data collection.
5. Location telemetry and device fingerprinting
Under the pretext of “verifying your identity from a trusted location,” the PWA requests geolocation data. Malwarebytes’ telemetry shows the site collecting precise metrics — latitude, longitude, altitude, heading, and speed — enabling near real-time tracking. The PWA also collects device fingerprinting details that make it easier for an operator to correlate a browser instance with specific accounts or networks.
6. Clipboard and one-time passcode harvesting
While the PWA window is open, scripts attempt to read the clipboard when the page gains focus or on visibility-change events. Attackers search for patterns that look like OTP codes, cryptocurrency wallet addresses, or other credentials. On browsers that support WebOTP (or other SMS/WebOTP bridges), the page can also attempt to intercept verification codes. This is a targeted technique to defeat SMS-based second-factor codes and grab data users might copy/paste when they think they’re completing a legitimate security flow.
7. WebSocket relay and HTTP proxy capability
One of the campaign’s most troubling capabilities is the use of a WebSocket relay to turn the victim’s browser into an HTTP proxy. The compromised PWA connects to a WebSocket relay controlled by the operator, which can then accept arbitrary HTTP requests and relay them through the browser using fetch/XHR. To outside services, the attacker’s traffic appears to originate from the victim’s IP and session context, allowing potential lateral movement into internal networks, port scanning of local hosts, and masquerading as the victim for additional attacks. Independent reporting and incident write-ups have confirmed the use of this proxying pattern.
8. Optional native escalation (Android APK)
In some user flows the site offers a companion Android APK — presented as a “critical security update” or “System Service.” If installed, this APK can register as a device administrator, request high-risk permissions (SMS, call logs, microphone, accessibility services), deploy a custom keyboard for keystroke logging, and persist across reboots. This transforms the incident from a browser compromise into a full device takeover on Android. Several technical write-ups that tracked the campaign identified package names and hashes for the APKs involved.
How Microsoft Edge and Windows are affected
Microsoft Edge is a Chromium-based browser and supports PWAs, service workers, the Contact Picker API (in supporting builds), WebOTP, and push notifications — the same platform features the attackers rely on. That means Edge users running recent releases (desktop or Android builds where Edge is present) can experience the same attack chain as Chrome users. Malwarebytes’ remediation guidance includes Edge-specific steps such as removing installed PWAs from edge://apps and unregistering service workers via edge://serviceworker-internals.
Bear in mind: this is
not a browser bug in Edge; it’s an abuse of browser features and user consent. That distinction is key to both detection and mitigation strategies.
Detection and immediate remediation (user-facing steps)
If you suspect you or your users have encountered this campaign, take these prioritized steps immediately.
- Uninstall the PWA
- Edge: go to edge://apps or the three-dot menu > Apps and remove any entry named Security Check or other unfamiliar web apps.
- Revoke push notification permissions for suspicious origins
- Edge: Settings > Cookies and site permissions > Notifications (or edge://settings/content/notifications) and remove any entries for google-prism[.]com or similar.
- Unregister service workers and clear site data
- Edge/Chrome: visit edge://serviceworker-internals or chrome://serviceworker-internals and unregister any workers tied to the malicious origin. Then clear site data for the origin to flush cached payload queues.
- Check for and remove suspicious Android APKs
- If an app named System Service or package com.device.sync is present and has Device Admin privileges, revoke admin access before uninstalling. Consider a factory reset if removal fails.
- Rotate credentials and 2FA tokens where appropriate
- If you copied an OTP or password while the PWA was active, assume it may have been harvested; revoke and reissue tokens and reset passwords.
- Run full scans with reputable endpoint/mobile security tools
- On Windows, run full AV/EDR scans; on Android, run reputable mobile scanners and consider a reset if native implants were installed.
These steps remove the most immediate persistence vectors and clean up data that may be queued for exfiltration. They are derived from Malwarebytes’ playbook and corroborated by analyst guidance reproduced in coverage across security outlets.
Enterprise guidance: triage, containment, and hunt
This campaign has strong operational implications for IT teams and SOCs because the WebSocket relay can make attacker-origin traffic look like internal traffic from a legitimate user. For enterprises:
- Detect and block the malicious domain(s) at the perimeter and DNS layer (google-prism[.]com and associated infrastructure).
- Hunt for unusual outbound WebSocket connections, especially to unknown hosts originating from browser processes.
- Query proxy and firewall logs for HTTP requests that match known IOCs and for source IPs that suddenly initiate internal host scans or requests with unusual headers.
- Isolate affected endpoints immediately and perform forensic capture of browser state (service worker registrations, installed PWAs list, notification permissions, and site data).
- Revoke tokens and sessions for accounts used on compromised endpoints, and force password resets or OAuth token re-issuance for sensitive accounts that may have been accessed.
A recommended incident response checklist produced by community responders includes unregistering service workers, clearing cached site data to remove the offline exfiltration queue, and reviewing browser sync to ensure stolen credentials were not propagated. These steps should be integrated into playbooks for SOCs that manage remote endpoints.
Why existing protections don’t fully stop this
- Browser security features like service workers and push were created for legitimate offline experiences and background tasks. They are inherently powerful and therefore attractive for abuse.
- SmartScreen and browser-safe-browsing lists can block known malicious domains, but these lists are reactive; new phishing domains and short-lived infrastructure often bypass reputation filters for a window of time.
- The attack requires user consent, which is always harder to police automatically. Security systems that rely solely on exploit detection or code-based heuristics miss consent-driven threats.
- Even when a PWA is uninstalled, service workers can persist if site data and registrations are not removed properly; push-based payloads queued on the server or stored offline can be flushed later, so incomplete cleanup is risky.
Practical hardening: steps that make exploitation harder
No single technology will eliminate consent-driven phishing, but layered defenses substantially reduce risk.
- Adopt stricter browser security policies in managed environments:
- Block PWA installations from untrusted sites via enterprise-managed browser policies where available.
- Restrict push notifications to allowlist-only domains for managed endpoints.
- Enforce strict Content Security Policy (CSP) and extension policies to reduce attack surface.
- Train users to treat unsolicited “security check” pop-ups as suspicious:
- Encourage users to access Google account security only via myaccount.google.com (or official apps) rather than acting on email or pop-up prompts.
- Monitor for unusual WebSocket and proxy-like behavior:
- Integrate detection rules into SIEM for fetch/XHR patterns over WebSocket relays and for internal port-scan signatures originating from user browser processes.
- Deploy endpoint detection that inspects installed PWAs and service worker registrations at scale:
- For managed Windows fleets, inventories of edge://apps or chrome://apps entries and service worker registrations can be automated for rapid alerting.
- Favor phishing-resistant MFA (security keys, FIDO2) over SMS and clipboard-reliant 2FA:
- The campaign’s success partially hinges on being able to intercept SMS/WebOTP flows and copied OTPs. Changing MFA posture to phishing-resistant tokens removes that vector.
Legal and privacy implications
This toolkit’s ability to turn a browser into a network proxy and to harvest location and contact data raises privacy and compliance concerns for organizations that handle regulated data. If an attacker uses a compromised browser as a pivot to access internal resources, the organization may have to consider breach notification, regulatory reporting, and forensic disclosure depending on the sensitivity of the accessed data and jurisdictional rules.
Security teams should treat browser-agent compromises with the same seriousness as endpoint malware incidents due to the potential for lateral movement and exfiltration.
Strengths, weaknesses, and the evolving threat model
Notable strengths of the attack (from attacker POV)
- Uses legitimate browser APIs — low friction for deployment and hard to mitigate with exploit-centric antivirus.
- Persists through service workers and push notifications — allows asynchronous command execution.
- Can escalate to an Android native implant for deeper access.
- Converts victim IP context into a convenient proxy for further attacks, enabling plausible deniability and internal network reconnaissance.
Practical weaknesses and mitigation opportunities
- Requires user interaction and consent at several steps; user training and UX cues can reduce successful conversions.
- Service workers and push permission lists are inspectable; managed IT can detect and revoke suspicious registrations centrally.
- Native APK escalation is optional; preventing users from sideloading and enforcing Play Protect/managed Play policies reduces the most severe outcomes.
What users should stop doing (short list)
- Don’t install apps or PWAs from unsolicited pop-ups or emails claiming to be a forced “security check.” Always access account security flows through your Google Account page or official app.
- Don’t grant notification permissions or device-level permissions to unfamiliar apps.
- Avoid copying confirmation codes into random web pages; prefer entering codes directly into the service requesting them, and shift to phishing-resistant authentication where possible.
Final thoughts and a call to adopt defensive UX
This campaign is a sharp reminder that the security model of the web — which balances power and user control — can be abused in creative ways. Attackers are increasingly combining legitimate browser features, social engineering, and optional native escalation to create multi-stage toolkits that are lightweight, scalable, and persistent without ever needing to exploit a browser bug.
For Windows and Edge users, the takeaway is not that Edge is “broken”; rather, the attack leverages
consent and convenience. Fixing that requires a mix of engineering changes (better UX cues when an origin is running outside the normal address bar), policy controls (managed push/installation allowlists), and human factors work (training and clearer, platform-enforced permission flows). Security vendors, browser teams, and enterprises must evolve detection and policy tooling to treat service worker registrations and PWA installations with the same suspicion as unknown native installers.
If you suspect exposure, follow the remediation checklist above without delay: remove the PWA, unregister the service worker, clear site data, revoke push permissions, scan the endpoint, and rotate affected credentials. Rapid action will limit the attacker’s window and prevent the background service worker from flushing any queued exfiltrated data once connectivity returns.
Confronted with attackers who weaponize trust, the best defense remains layered: technical controls, vigilant monitoring, and informed users acting as the last line of defense.
Source: Windows Central
This fake Google security page can take over your Edge browser in seconds