Attack with WebView2 applications

Man

Professional
Messages
3,075
Reaction score
612
Points
113
We explore WebView2 apps and how they can be used to steal credentials and cookies.

Introduction​

According to Microsoft, “Microsoft Edge WebView2 control lets you embed web technologies (HTML, CSS, and JavaScript) into your own applications”. Essentially, WebView2 technology can be used to create an executable file that can interact with web applications in a similar way to a browser. This is intended to enhance desktop applications and give them additional capabilities to interact with web applications. The image below is an example of WebView2 being used in a legitimate Microsoft Office application.

a1a5501a-6093-45a8-b739-b4b7736c7b6d.png


The main advantage of using WebView2 for attackers is the rich functionality it provides when phishing credentials and sessions. In this post, I discuss and show how attackers can create WebView2 applications and use them for multiple purposes. My code uses a modified version of Microsoft's WebView2 sample repository. The research was difficult and time-consuming, as I had to read a lot of documentation and do a lot of debugging to understand the inner workings of WebView2.

JavaScript implementation​

Using the built-in WebView2 feature, JavaScript can be easily injected into any website. This means that you can load a target website and inject malicious JavaScript (such as a keylogger).

JavaScript Keylogger Example​

In the example below, I use a custom WebView2 application that is loaded login.microsoftonline.com with an embedded JavaScript keylogger.

706d3b3c-f582-4690-ac4e-a4a4664a981e.png


The image below shows a keylogger successfully reading keystrokes.

047a4788-c208-4323-8f51-9b2382a34098.png


Bypass 2FA​

WebView2 also provides built-in cookie extraction functionality. This allows an attacker to extract cookies after the user has authenticated on a legitimate website. This method eliminates the need to run Evilginx2 or modlishki, but the obvious trade-off is that the user must execute the binary and authenticate.

Chrome cookie theft​

WebView2 can be used to steal all available cookies of the current user. This has been successfully tested in Chrome.

WebView2 allows you to launch with an existing user data folder (UDF) instead of creating a new one. The UDF contains all the passwords, sessions, bookmarks, etc. Chrome's UDF is located at C:\Users\<username>\AppData\Local\Google\Chrome\User Data. We can simply tell WebView2 to launch an instance using this profile, and on startup, extract all the cookies and pass them to the attacker's server.

A small snag​

The only catch is that WebView2 looks for a folder named EBWebView instead User Data (not sure why). Make a copy of User Data the folder and rename it to EBWebView.

256947d2-24cc-4ffb-ae22-cf0eaf9e3ff5.png


Retrieve all cookies​

The image below shows how I was able to load my Chrome UDF and extract all the cookies. This functionality is not implemented in the code uploaded to my GitHub repository, but it is easy to implement and the GitHub README explains what needs to be changed to make this functionality work.

08bee8b3-aa02-4e9f-8174-99bdb68ca696.png


Application demo​

I have uploaded code for an O365 WebView2 app that is loaded www.office.com/login on runtime and upon successful user authentication, base64 encoded cookies www.office.com are sent to the attacker via an HTTP GET request.

Run the demo version​

The demo below shows the execution of the WebView2 binary.

5f6c2fa1-78c2-4203-9e95-d0c41ab0c458.png


Demonstration of use​

The Telegram channel's post itself shows how the user will interact with the application and how an attacker can log in using stolen cookies.

Download the files themselves​

Feel free to use it in your future projects or modify it as needed. The instructions at explain everything in case you want to modify it for another use case.

Download project files https://disk.yandex.ru/d/BKKmwGGE8ipKGw

Final thoughts​

There are pros and cons to this method. The obvious tradeoff is that the binary must be executed on the host machine, and the user must enter credentials into the application. One might ask, if the application must be run, why not just execute shellcode and gain remote access? Sure, you can. But depending on someone's needs, they may need something beyond remote access, such as executing JavaScript on the target website.

You can extend the functionality of the existing WebView2 application to also gain remote access. However, the binary currently only uses legitimate functions provided by Microsoft. This will likely make it difficult for security solutions to detect.
 
Top