Wprowadzenie do problemu / definicja luki
Na początku marca 2026 r. opisano kampanię phishingową podszywającą się pod „Google Account security page”, która zamiast klasycznej fałszywej strony logowania wykorzystuje Progressive Web App (PWA) – web-aplikację instalowaną z poziomu przeglądarki. Po instalacji PWA uruchamia się w osobnym oknie bez paska adresu, co znacząco utrudnia użytkownikowi ocenę, czy to na pewno Google. Atak nie wymaga exploita: bazuje na socjotechnice i legalnych funkcjach przeglądarek (powiadomienia, service worker, wybrane API).
W skrócie
- Kampania używa domeny google-prism[.]com i udaje „kontrolę bezpieczeństwa” Google.
- PWA wyłudza uprawnienia (m.in. powiadomienia, kontakty, lokalizację, schowek) i próbuje przechwytywać kody OTP z SMS przez WebOTP API (tam, gdzie wspierane).
- Najgroźniejszy element: WebSocket relay, który pozwala operatorowi kierować żądania HTTP „przez przeglądarkę ofiary” (proxy), oraz funkcje skanowania portów w sieci lokalnej.
- Dla części ofiar kampania oferuje też kompaniona na Androida (APK) podszytego pod „krytyczną aktualizację”, z bardzo szerokimi uprawnieniami (m.in. SMS, Accessibility, przechwytywanie powiadomień).
Kontekst / historia / powiązania
PWAs są coraz częściej nadużywane w phishingu, bo łączą „webową łatwość dystrybucji” z „aplikacyjnym” UX (ikonka na ekranie, osobne okno, brak paska adresu, powiadomienia). To trend opisywany przez zespoły analityczne i instytucje rządowe: użytkownik widzi coś, co wygląda jak natywna aplikacja, a w praktyce to strona z trwałymi mechanizmami (np. service worker).
Warto też zauważyć, iż nadużycia PWA były już wcześniej obserwowane w kampaniach podszywających się pod aplikacje bankowe na urządzeniach mobilnych – ten sam „wektor instalacji bez sklepu” utrudnia filtrowanie zagrożeń.
Analiza techniczna / szczegóły luki
1) „Security check” jako czterostopniowy lejek uprawnień
Atak zaczyna się od strony udającej alert bezpieczeństwa. Ofiara jest prowadzona krok po kroku:
- instalacja PWA (znika pasek adresu),
- zgoda na powiadomienia web push,
- udostępnienie kontaktów (w opisywanym przypadku przez Contact Picker API),
- udostępnienie lokalizacji GPS,
- oraz (w tle / dodatkowo) dostęp do schowka.
2) Dwa „silniki” kampanii: skrypt strony i service worker
Kluczowa różnica względem zwykłego phishingu:
- Page script działa, gdy PWA jest otwarta (np. odczyt schowka przy zdarzeniach focus/visibility).
- Service worker zostaje zarejestrowany i może obsługiwać powiadomienia, zadania w tle oraz kolejkę eksfiltracji danych choćby po „zamknięciu okna”.
W analizie opisano m.in. kolejkowanie danych w mechanizmach przeglądarki (np. Cache API) i ich dosyłanie po odzyskaniu łączności (Background Sync / Periodic Background Sync – zależnie od wsparcia w danym Chromium).
3) Kradzież OTP i dane „około-tożsamościowe”
Narzędzie ma polować na:
- kody OTP (w tym próby przechwycenia SMS-owych kodów przez WebOTP API na wspieranych przeglądarkach),
- zawartość schowka (np. jednorazowe kody kopiowane przez użytkownika, a także adresy portfeli kryptowalut),
- dane urządzenia (fingerprinting),
- kontakty i lokalizację.
4) „Browser RAT”: proxy przez ofiarę i skan sieci wewnętrznej
Najbardziej alarmujący element to WebSocket relay: operator może kazać przeglądarce ofiary wykonywać żądania HTTP (dowolna metoda/headers/body), a potem odebrać pełną odpowiedź. To w praktyce „proxy przez użytkownika”:
- obchodzenie kontroli opartych o IP,
- „wejście” do zasobów osiągalnych tylko z sieci ofiary (np. firmowej),
- ukrywanie źródła ruchu (wygląda jak ruch ofiary).
Dodatkowo opisano skanowanie portów hostów w podsieci lokalnej (typowo 80/443/8080), co może służyć rozpoznaniu usług w LAN.
5) Opcjonalny komponent Android (APK)
Jeśli ofiara „włączy wszystko”, dostaje także APK (w analizie: pakiet com.device.sync, nazwa widoczna jako „System Service”), które:
- prosi o dziesiątki uprawnień (SMS, połączenia, mikrofon, kontakty),
- wykorzystuje Accessibility i przechwytywanie powiadomień (potencjalnie także 2FA),
- ma mechanizmy utrzymania (device admin, autostart/boot receiver, alarmy).
Praktyczne konsekwencje / ryzyko
- Przejęcie kont: wyłudzenie loginu/hasła + przechwycenie OTP znacząco zwiększa szanse na skuteczne logowanie, zwłaszcza przy 2FA przez SMS lub kody jednorazowe „przepisywane”/kopiowane.
- Ryzyko dla firm: tryb proxy i skanowanie LAN mogą stać się wstępem do rozpoznania zasobów wewnętrznych, a następnie ataków na aplikacje dostępne tylko z intranetu.
- Trwałość kompromitacji: zamknięcie karty nie wystarcza – service worker + powiadomienia pozwalają „reaktywować” interakcję i ułatwić kolejne etapy eksfiltracji.
- Eskalacja na Androidzie: jeżeli zainstalowano APK, konsekwencje mogą wykraczać poza przeglądarkę (przechwytywanie klawiatury, powiadomień, działania Accessibility).
Rekomendacje operacyjne / co zrobić teraz
Dla użytkowników (szybka checklista)
- Nie instaluj „Security Check” z pop-upu i nie przyznawaj powiadomień stronom, których nie rozpoznajesz. Google nie wymaga instalacji PWA/APK do „weryfikacji bezpieczeństwa” – narzędzia są w panelu konta.
- Jeśli podejrzewasz infekcję:
- usuń zainstalowaną PWA (Chrome/Edge: lista zainstalowanych aplikacji),
- cofnij zgody na powiadomienia dla podejrzanych domen,
- wyrejestruj service worker dla złośliwego origin,
- zmień hasła i przejrzyj aktywne sesje. (Kroki usuwania są opisane przez Malwarebytes).
- Na Androidzie: sprawdź, czy nie ma aplikacji typu „System Service” / pakietu com.device.sync i czy nie ma uprawnień administratora urządzenia; w razie problemów z usunięciem rozważ reset (wg zaleceń analizy).
Dla zespołów IT/SOC (wdrożenia „na dziś”)
- Zablokuj instalację PWA i/lub web push politykami przeglądarki tam, gdzie to możliwe (szczególnie na stacjach firmowych i urządzeniach uprzywilejowanych).
- Wymuś phishing-resistant MFA (np. FIDO2/passkeys) dla kont krytycznych; dokumenty rządowe dot. AiTM podkreślają, iż same kody/OTP są podatne na przechwycenie w nowoczesnych kampaniach phishingowych.
- Telemetria:
- monitoruj anomalie: nagłe zgody na powiadomienia, instalacje PWA, nietypowe rejestracje service workerów,
- alertuj na nietypowy ruch WebSocket/HTTP z przeglądarek do rzadkich domen,
- rozważ DNS/URL filtering pod kątem nowych domen udających brand.
- Edukacja: pokaż pracownikom przykład „aplikacji bez paska adresu” i wyjaśnij, iż brak paska adresu ≠ zaufanie (to cecha PWA).
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- Klasyczny phishing zwykle kończy się na kradzieży hasła/OTP na stronie. Tutaj mamy „browser RAT”: trwałe komponenty (service worker), kanał powiadomień i funkcje proxy/skanowania sieci.
- W porównaniu do wcześniejszych kampanii PWA podszywających się pod banki, ten przypadek mocno stawia na uprawnienia przeglądarkowe + telemetrię urządzenia (kontakty, GPS, schowek) i „operacyjne” możliwości C2 przez WebSocket.
Podsumowanie / najważniejsze wnioski
Ta kampania jest dobrym przykładem, jak legalne funkcje nowoczesnych przeglądarek mogą zostać złożone w pełnoprawny łańcuch ataku bez wykorzystywania podatności. PWA pozwala atakującym „opakować” phishing w formę aplikacji, service worker daje trwałość, powiadomienia – kanał sterowania, a WebSocket relay – możliwość nadużyć w sieci ofiary.
Jeśli masz wdrożone MFA oparte o kody (SMS/OTP), potraktuj ten przypadek jako kolejny argument za przejściem na phishing-resistant MFA oraz za twardszym zarządzaniem uprawnieniami przeglądarki (push/PWA) na urządzeniach służbowych.
Źródła / bibliografia
- BleepingComputer – opis kampanii i wysokopoziomowe IoC (m.in. domena google-prism[.]com, WebOTP, proxy). (BleepingComputer)
- Malwarebytes – analiza techniczna „browser RAT”, service worker, WebSocket relay, Contact Picker API, GPS, kolejki eksfiltracji, Android APK. (Malwarebytes)
- NCSC New Zealand – obserwacje trendu nadużyć PWA w phishingu. (NCSC NZ)
- Canadian Centre for Cyber Security – wytyczne dot. zagrożeń AiTM i potrzeby phishing-resistant MFA. (Canadian Centre for Cyber Security)
- BleepingComputer (2024) – wcześniejsze kampanie PWA podszywające się pod aplikacje (kontekst trendu). (BleepingComputer)
