Be careful what you pwish for – Phishing in PWA applications

In this blogpost we discuss an uncommon type of phishing campaign targeting mobile users and analyze a case that we observed in the wild that targeted clients of a prominent Czech bank. This technique is noteworthy because it installs a phishing application from a third-party website without the user having to allow third-party app installation. For iOS users, such an action might break any “walled garden” assumptions about security. On Android, this could result in the silent installation of a special kind of APK, which on further inspection even appears to be installed from the Google Play store.

The phishing websites targeting iOS instruct victims to add a Progressive Web Application (PWA) to their home-screens, while on Android the PWA is installed after confirming custom pop-ups in the browser. At this point, on both operating systems, these phishing apps are largely indistinguishable from the real banking apps that they mimic. PWAs are essentially websites bundled into what feels like a standalone application, with this feeling being enhanced by the usage of native system prompts. PWAs, just like websites, are cross-platform, explaining how these PWA phishing campaigns can target both iOS and Android users.

This technique was first disclosed by CSIRT KNF in Poland in July 2023 and, in November 2023, observed in Czechia by ESET analysts working on the Brand Intelligence service. We also observed two cases of mobile campaigns against banks outside of Czechia: one case targeting the Hungarian OTP Bank and another targeting a Georgian bank.

Key points of the blogpost:

• Standard phishing delivery techniques were combined with a novel method of phishing; targeting Android and iOS users via PWAs, and on Android also WebAPKs.
• Insidiously, installing a PWA/WebAPK application does not warn the victim about installing a third-party application.
• On Android, these phishing WebAPKs even appear to have been installed from the Google Play store.
• Most of the observed applications targeted clients of Czech banks, but we also observed one phishing app that targeted a Hungarian bank and another targeting a Georgian bank.
• Based on the C&C servers utilized and backend infrastructure, we conclude that two different threat actors were operating the campaigns.
• Thanks to our discovery of operator panels on different domains, we were able to notify the victims’ banks in order to protect them.

Overview

ESET analysts discovered a series of phishing campaigns targeting mobile users that used three different URL delivery mechanisms (shown in Figure 1). These mechanisms include automated voice calls, SMS messages, and social media malvertising.

The voice call delivery is done via an automated call that warns the user about an out-of-date banking app and asks the user to select an option on the numerical keyboard. After pressing the correct button, a phishing URL is sent via SMS. This was reported in a tweet, by Michal Bláha.

Initial delivery by SMS was performed by sending messages indiscriminately to Czech phone numbers. The message sent included a phishing link and text to socially engineer victims into visiting the link.

Spreading via malicious ads was done by registering advertisements on Meta platforms like Instagram and Facebook. These ads included a call to action, like a limited offer for users who “download an update below”. This technique allows threat actors to specify the target audience by age, gender, etc. The advertisements would then appear in a victim’s social media feed.

After opening the URL delivered in the first stage, Android victims are presented with a high-quality phishing page imitating the official Google Play store page for the targeted banking application, or a copycat website for the application. These were two distinct campaigns. It is possible that the campaign utilizing Google Play visuals would modify itself based on the received User-Agent, to imitate Apple Store visuals. We did not observe this technique in analyzed cases.

From here victims are asked to install a “new version” of the banking application; an example of this can be seen in Figure 2. Depending on the campaign, clicking on the install/update button launches the installation of a malicious application from the website, directly on the victim’s phone, either in the form of a WebAPK (for Android users only), or as a PWA for iOS and Android users (if the campaign is not WebAPK based). This crucial installation step bypasses traditional browser warnings of “installing unknown apps”: this is the default behavior of Chrome’s WebAPK technology, which is abused by the attackers.

The process is a little different for iOS users, as an animated pop-up instructs victims how to add the phishing PWA to their home screen (see Figure 3). The pop-up copies the look of native iOS prompts. In the end, even iOS users are not warned about adding a potentially harmful app to their phone.

After installation, victims are prompted to submit their internet banking credentials to access their account via the new mobile banking app. All submitted information is sent to the attackers’ C&C servers.

Timeline

We discovered the first phishing-via-PWA case in early November 2023, and noticed the transition to WebAPKs in mid-November 2023. C&C servers that received information from phishing applications were first discovered in March 2024 (as can be seen in Figure 4), with data in them confirming that they were probably not operational earlier.

The only exception is the cryptomaker[.]info server, which we discovered in May 2024, but included activity from a campaign against a Georgian bank in February 2024.

Technical analysis

In this section we focus on the analysis of a campaign against a prominent Czech bank, utilizing WebAPK technology. We also briefly explain the underlying technology of progressive web applications (PWAs) and WebAPKs.

PWA and WebAPK applications

PWAs

The phishing campaign and method discussed in this post is possible only thanks to the technology of progressive web applications (PWAs). In short, PWAs are applications built using traditional web application technologies that can run on multiple platforms and devices. These apps are then installed on the mobile phone of the user after a pop-up installation prompt is automatically displayed, or the user manually selects the Install app option from a supported browser’s menu. The crucial step here is installation, which allows for the seamless usage of apps in a separate window and gives them the ability to be launched from the menu bar or home screen. After installation, PWAs on the home screen are distinguished by the logo of the user’s browser being superimposed on the PWA’s icon (Figure 5).

PWAs also have the advantage of a single codebase across multiple platforms, which now may also use modern browser APIs and even native code, thanks to WebAssembly. Progressive web apps may also be used offline, thanks to service workers (see Figure 6). These workers act as a sort of proxy system, retrieving data from the local cache if no internet connection is available.

All the application behavior is defined in a single file called the manifest. This is a standardized file that defines the logo, name, web application scope, sources, and service worker script of the application, as well as the launcher type. Here the threat actor can define the app as standalone, which results in the PWA behaving like a regular mobile app.

PWAs may also be assigned as default handlers for certain file formats, but only as an experimental feature, which is not supported on mobile browsers. This could result in threat actors writing malicious applications that register as a default handler for, as an example, all .docx documents, and so a simple yet powerful espionage app could be created. However, even without that feature, access to browser APIs gives PWAs the right to request access to microphone, geolocation, camera, and all other supported browser functions, meaning that spyware PWAs could be on the radar.

WebAPKs

WebAPKs could be considered an upgraded version of progressive web apps, as the Chrome browser generates a native Android application from a PWA : in other words, an APK. These WebAPKs look like regular native apps, as their icons lack the browser logo (see Figure 7). In the PWA/WebAPK phishing scheme, this is used to trick users into believing that the installed phishing app is their legitimate banking application. The generation of WebAPKs is currently only supported by Google Chrome.

Furthermore, installing a WebAPK does not produce any of the “installation from an untrusted source” warnings, such as the example seen in Figure 8, that users are commonly trained to look for. The app will even be installed if installation from third-party sources is not allowed.

Phishing flow

As mentioned in our overview of the monitored campaigns, multiple types of delivery mechanisms were used. In the case of the phishing campaign against the prominent Czech bank, the whole flow started with a phishing link being spread by multiple malicious ads on Facebook (see Figure 9). These advertisements were registered in bulk, often five or six at a time, with each registration at a separate time. The threat actor used specially created Meta accounts and possibly compromised accounts.

The malicious ads included a mix of the bank’s official mascot (blue chameleon), as well as the bank’s logos and text that either promised a financial reward upon installing the app or warned users that a critical update had been rolled out.

In the example case, a limited-time offer of a financial reward was used to entice victims into visiting the malicious link. After visiting the link, users were prompted with a convincing, albeit fake, Google Play page (Figure 10). This is the site from which the phishing WebAPK is downloaded.

The site checks for the usage of a mobile client via the User-Agent HTTP header. If the victim is indeed on a mobile device, the “Install” button prompts the victim for installation via a pop-up. If the User-Agent header is for a desktop, the install button does nothing. The prompt also imitates Google Play animations, further enhancing the believability of this campaign (Figure 11).

The demonstrated campaign clearly targets Android users, thanks to the Google Play visual and animations. Other campaigns (that we observed and that were publicly reported) targeted users of both iOS (Figure 12) and Android systems. These sites utilized the visual of a well-known application on the landing page and prompted victims for the installation of a new version. Android users were led to install a WebAPK, and iOS users to PWAs.

After installation, the phishing PWA/WebAPK is added to the user’s home screen, and opening it leads to a phishing login page, directly in the application (Figure 13).

On top of all the previously mentioned hurdles for a regular user, the application’s info tab also states that the app was downloaded from the Google Play store, which is the default behavior (Figure 14). This applies to all WebAPK apps.

The phishing application and phishing URL discussed in this post were reported to ČSOB. The phishing applications have never been available on the Google Play store.

C&C infrastructure

Based on the fact that the campaigns used two distinct C&C infrastructures, we have determined that two separate groups were operating the PWA/WebAPK phishing campaigns against Czech and other banks.

One group used a Telegram bot to log all entered information into a Telegram group chat via the official Telegram API, and another used a traditional C&C server with an administrative panel. The second group is responsible for the campaign covered in our blogpost on the NGate Android malware.

Telegram bots

All stolen login information was logged via a backend server, which then sent the user’s entered banking login data into a Telegram group chat. HTTP calls to send messages to the threat actor’s group chat were made via the official Telegram API. This is not a new technique and is used in various phishing kits.

After loading the phishing page of the PWA, a stack trace is displayed on top of the screen (see Figure 15). The stack trace includes information about the Telegram API and bot token used, and was visible even on the login screen.

Based on this, we identified that the threat actor logged all data into a Telegram group chat. We reported all sensitive information of compromised bank clients to the relevant banks.

C&C servers

During analysis of one of the installed PWAs, we noticed that entered victim data was sent to a different backend server. Upon inspection of the contacted C&C server, we uncovered an operator panel (Figure 16) that included sensitive information of victims, currently active phishing URLs, and a full history of visiting victims.

The threat actors did not stay put, and after the first C&C domain was deactivated (hide-me[.]online) they continued to establish more domains and even prepared a completely new malicious campaign, operated from the same panel. The second campaign is analyzed in our research on the NGate Android malware.