The PWA that installs like a native app — and the push channel that phishes you after

What happened

ESET Research documented phishing campaigns that abuse Progressive Web Apps and their Android form, WebAPKs, to install fake banking apps. Unlike a normal sideload, "installing a WebAPK does not produce any of the 'installation from an untrusted source' warnings" — the app installs even when third-party installs are disabled. The result looks identical to the real bank app on the home screen (no browser chrome), and its details misleadingly read "App details in store" as if it came from Google Play. Victims arrive via malvertising, SMS, and robocalls, land on a copycat store page, tap Install, and a credential-harvesting app appears with no warning. Campaigns targeted Czech, Hungarian, and Georgian bank customers.

Separately, Matrix Push C2 shows the second half of the PWA threat: once a site is granted push-notification permission (via lures like "Click Allow to play video"), attackers push spoofed, OS-styled notifications impersonating brands like MetaMask, PayPal, and Netflix. These fire even when the browser is idle or in the background, "outside the page," and are hard to trace back to the source — a persistent channel for phishing and malware delivery.

Root cause

This is insecure design and interface spoofing (CWE-451). The WebAPK install path was built for convenience — frictionless, native-looking installs — and in doing so removed the exact "untrusted source" signal users are trained to rely on. Push notifications were designed as a persistent, app-independent channel; granted once, they become an attacker-controlled megaphone at the OS level. Nothing is "broken" in the code sense — the platform behaves as designed. The missing invariant is user-verifiable provenance and trust: nothing in the UI reliably tells the user this app/notification is not who it claims to be.

How it would have been caught

Threat-modeling the install and notification flows from the attacker's view — "can a lookalike install without a warning?" and "can a granted push channel impersonate a bank?" — surfaces both. A brand-protection check that drives the real install flow and asserts a spoofed page cannot produce a warningless banking-app install exercises the reproduction end to end.

How to prevent it

• Users: only install PWAs from the genuine site or store; deny push permission by default and audit which sites can notify you; distrust urgent notifications that ask for credentials.
• Sites/defenders: monitor for lookalike domains and copycat install pages; harden the real app with phishing-resistant auth (passkeys) so harvested passwords are worthless.
• Platforms: preserve a clear provenance indicator on installed web apps and OS notifications so origin is user-verifiable.

The Breachwire test (red → green)

Drive the phishing flow in a real browser: reach the copycat page, install the WebAPK, and confirm it lands on the home screen with no untrusted-source warning and no origin indicator (and that a granted push channel can render a bank-branded notification) — the RED proof of spoofable provenance. Apply the controls — passkey auth that defeats credential capture, push denied/audited, lookalike-domain takedown — then confirm harvested credentials do not authenticate and the spoofed notification channel is blocked.