James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog.

Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials.

In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets Android and is replacing the classic overlay M.O. (Modus Operandi). These new attacks use the good-old web attack tactics with adjustments made for Android. IBM Trusteer has dubbed these attack tactics Mobile Web(View) attacks because the attack vector is the Android WebView component, and not the browser application (for reasons that will be explained in the following sections).

In this blog, two extremely effective attack techniques are discussed: Web(View) injection attack (based on web injects in the browser) and mobile cookie stealing.

What is a web injection attack?

A web injection attack is a technique used by malware to exfiltrate and manipulate the content of a website from the client side as it is being presented by the browser. During a web injection attack, the malware injects HTML or JavaScript code into the website by running code in the scope of the web browser process that is installed on the victim’s device.

In a web injection attack, what the victim sees in the browser might be different from what is intended by the web server. In addition, every private detail entered by the victim on the website is exposed to the malware.

For example, the JavaScript code that is injected by the malware can extract data from an HTML form that the user has filled in. Using this method, the malware can steal login credentials, credit card numbers, CVVs and so on. That data can then be sent to the command-and-control server (C2C) of the malware operator.

Another common example of a web injection attack is to manipulate the visuals of a website. This type of web injection attack can be used to insert new fields to steal additional personal identifiable information (also known as PII) that is not requested by the legitimate service or even to remove existing fields, which can prevent the user from seeing security warnings. This attack is also used by malware to perform on-device fraud (ODF) by changing the payee of a transaction initiated by the victim to the fraudster mule account.

Figure 1 — An example of injected JavaScript code. The injection creates a fake login form of an e-commerce company instead of the original content of the legitime website (left) versus the original HTML of the legitime website (right).

Figure 2 — The result of the injected JavaScript code: a fake login form of an e-commerce company (left) versus the original legitime website (right).

Due to all of these capabilities, the web injection technique is especially common among desktop financial malware, such as the Zeus Sphinx variant, IcedID and TrickBot.

Why are there no web injection attacks on mobile?

Although the use of web injection attacks has become the standard for desktop financial malware, this is not the case for mobile. Instead, financial malware on Android mostly uses the overlay technique, and more recently RAT techniques to steal victims’ credentials.

The reason web injection is not used in mobile is that on a non-rooted Android phone (and without using exploits), code injection to the browser application process (or to any other application on the device) is not possible. The Android operation system enforces these restrictions with the implementation of Android sandboxing.

Android Sandbox

In general, in Android OS, a distinct Linux user ID (UID) is assigned to each installed application. Android uses this UID to set up a kernel-level Application Sandbox. The kernel-enforced process isolation prevents applications from injecting code into each other, accessing each other’s files and resources, and manipulation of their code. Due to the sandbox protections, mobile malware cannot inject code into other browser applications such as Google Chrome and cannot inject code into the real banking application. As a result, Android malware cannot perform classic web injection attacks on Android.

Figure 3 — An example showing the UID of three processes running on a device: a banking application, a malware application, and the Chrome browser application.

Challenge accepted: Introducing the Web(View) inject attack

Android WebView

WebView is an embeddable browser inside an app that is used to load a URL. The WebView element is a part of the application it is running within; therefore, it is not protected by the Android Sandbox. In fact, Android allows an application to inject JavaScript code into its own WebView.

According to the malware analyzed by IBM Trusteer, to manipulate a banking website, the malware impersonates the banking application and runs a WebView that loads a legitimate URL of the bank. The malware injects JavaScript code that is required for the attack into its own WebView and uses that code to intercept text entered by the victim into the HTML fields such as the victim’s username and password.

The overall attack flow is shown in the following figure:

Figure 4 — Web(View) Inject attack flow.

*Smishing, also known as SMS-phishing, is a mobile text message containing a link to download malware or visit a malicious site via phishing.

How can malware inject its own code into a WebView element?

Introducing Android JavaScript interface

Android provides developers with an interface that allows them to bind JavaScript code into an Android app that uses a WebView. Android developers who build a web application using WebView can create interfaces between the JavaScript code and native Android code.

The application must know the exact names of the fields within the HTML of the legitimate site to use this technique. In turn, the JavaScript code must know the exact names of the Android functions within the interface to interact with them.

In the malware that Trusteer analyzed, the names of the Android JavaScript interface functions can be seen: “sendCerd,” “closeFrom,” and “sendBalance.” When the user enters their username and password, the malware extracts the values using the val() jQuery function and sends the information to the C2C. The script can get values from text fields in the HTML that the user filled in, including special fields with type=”Password”.

To mark potentially interesting targets, the attacker is specifically interested in the balance of the victim’s account. The code to retrieve the balance has a timeout of 3 seconds.

Figure 5 — The malware JavaScript code.

Figure 6 — The malware corresponding JavaScript interface from the Android side.

After the malware exfiltrates the victim’s PII, the victim continues through the following web pages on the legitimate website without raising their suspicions.

WebView settings

To inject the JavaScript code, the malware sets the WebView settings “setJavaScriptEnabled” and “setDomStorageEnabled” to “true”.

Figure 7 — The malware’s WebView settings. Note the use of a constant user-agent of a Samsung device (SM-A205U).

Injecting JavaScript

After setting up the Android JavaScript and the WebView, the malware can inject the JavaScript code into its own WebView with the loadUrl() function. In the malware analyzed by Trusteer, the JavaScript was Base64 encoded. Looking at the source of the injected page, the injection code is not human readable; however, since it is only Base64 encoded, it can be easily decoded.

Figure 8 — The malware’s Base64 encoded JavaScript injected code.

Web(View) attack versus overlay attack

In this attack dubbed Web(View) Injection by IBM Security Trusteer, the malware loads a legitime URL of the bank rather than a fake activity or a fake phishing site. In an overlay attack, the malware shows the victim a fake overlay screen mimicking the bank’s login page on top of the real banking app.

One advantage of the Web(View) Inject method is that the malware doesn’t need to change the design of the overlay screen every time the bank changes its UI since it is injecting straight into the legitimate banking site.

Another advantage is that this attack requires fewer permissions than an overlay attack, which usually requires at least the “android.permission.SYSTEM_ALERT_WINDOW” permission. In fact, Web(View) attack requires only the “android.permission.INTERNET” permission to be declared in the manifest. This permission is extremely common and therefore much less suspicious.

This is not the first time mobile malware has used the Web(View) inject technique, but this is the first time that IBM Trusteer researchers have identified it being used by mobile financial malware.

Web(View) Injection is not the only web attack technique IBM Trusteer detected that financial malware used in Android.

The next attack discussed in this blog is a Mobile Cookie Stealing attack that, much like the Web(View) Injection attack, targets the Android WebView component.

What is a cookie stealing attack?

Cookies are strings of text and numbers that websites store in the browser to save the login state or track the user’s activity on the website.

Cookies are used as session identifiers. Various websites including banks and cryptocurrency sites use cookies as session identifiers for their login pages. If a fraudster steals a cookie from the browser after the user logged in, the fraudster might be able to use the cookie to steal the victim’s session (as long as the cookie hasn’t expired) without even having to know the victim’s credentials.

This attack has recently gained popularity among financial mobile malware, such as SOVA’s remake malware MailBot, FluBot, SharkBot, and Hydra, the newer version of BianLian.

Who stole the cookie from the Android jar?

As stated in the Android Sandbox section, an Android application cannot manipulate the browser application directly and, as a result, can’t steal cookies from it without the victim’s knowledge. However, cookie stealing can be done from its own WebView.

BianLian is a piece of financial malware that has overlay capabilities as well as RAT capabilities. IBM Trusteer researchers have analyzed the BianLian malware, aka Hydra, and here BianLian’s implementation of the cookie stealing attack is unpacked. The overall attack flow is shown in the following figure:

Figure 9 — Cookie stealing attack flow

The malware creates an instance of CookieManager and then the “getCookie()” method is used with the legitimate URL loaded to get the cookie.

Figure 10 — BianLian’s cookie theft function.

BianLian steals cookies from e-mail, social networking and financial applications, using the real application’s URLs:

Figure 11 — BianLian’s cookie theft configuration list.

BianLian detects when the user opens one of the targeted apps using the accessibility service. It then overlays the legitimate application with its own WebView loaded with the real login URL of the targeted application. This way, from the victim’s perspective, everything seems to be as expected. However, any interaction the victim has from this point on is with the malware screen and not the actual application.

The malware WebView has the “setMixedContentMode” property set to load content from any other origin, even if that origin is insecure. It also has the “setCacheMode” property set to load no cache, which means loading from the network.

The malware then waits for the user to log in to the service. It makes sure the victim is successfully logged into their account by checking the loaded URL with the “onPageFinished” method and then grabs the session cookie using the Cookie manager.

Once it steals the cookie, BianLian sends the cookie to its C2C (at the time of writing, the malware sends requests to the server unencrypted via HTTP). Finally, the fraudster uses the stolen cookie to hijack the victim’s session.

Fewer permissions, fewer suspicions

Similar to the Web(View) injection attack, the cookie stealing attack requires only the “android.permission.INTERNET” permission.

Note that even if the website uses HTTPS, the malware can still intercept the cookie value with the described technique.

Conclusion

Although it took more than a decade, web attack techniques have finally made their move to mobile. In this blog, we have detailed two such attack techniques translated from PC to Android in the form of WebView abuse attacks: the Web(View) injection attack and Mobile Cookie grabbing.

Every Android application is exposed to these attacks because malware can use a WebView to load any service URL that has an online login page and inject it with its own JavaScript, which effectively gains full control of the website (from the client perspective).

The biggest risk from the Web(View) Inject attack is the fact this attack might allow an attacker to perform ODF, where transactions are initiated from the same device that the victim uses daily. This is a known M.O. used by PC financial malware, where the attacker replaces the payee of each money transaction with their own account. The fraudulent transaction is initiated by the victim from the legitimate device, making it look less suspicious.

Because this technique requires only a few permissions and is relatively easy to implement for anyone familiar with Web attack in PC, IBM Trusteer expects WebView attacks in Android to be seen more frequently in financial malware in the future.

Malware IOCs