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?
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.
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.
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.
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
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?
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.
After the malware exfiltrates the victim’s PII, the victim continues through the following web pages on the legitimate website without raising their suspicions.
Figure 7 — The malware’s WebView settings. Note the use of a constant user-agent of a Samsung device (SM-A205U).
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.
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.
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.
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.
|APK Hash (SHA256)
||Web(View) Inject malware
||BianLian aka Hydra
Scroll to view full table
Mobile Security Researcher, IBM
Mobile security researcher at IBM Security Trusteer group. Shahar is passionate about malware research, mobile security, reverse engineering and Android inte...