Search results for:
By: Shiran Grinberg
How hackers use browser vulnerabilities to invisibly manipulate secure connections
In our last article, we’ve demonstrated how attackers may evade detection when establishing C&C and data exfiltration channels by using ICMP Tunneling to obfuscate traffic.
But how is data collected in the first place? Naturally Data Collection techniques (MITRE TA0009: Collection[1]) are as diverse and abundant as they come, but some common examples may be:
In this article, we’ll show one common technique adversaries use to collect user data and even manipulate it to their advantage. In a nutshell, it’s a form of a Man-in-the-Middle attack that focuses on web browsers as the attack vector.
The rest of the introduction discusses Man-in-the-Middle attacks and web browsers.
This is part of an extensive series of guides about Network Attacks
When employing a man-in-the-middle attack, adversaries position themselves between two machines or network devices, in such a way that allows them to intercept and manipulate the traffic between both parties.
Usually this will be achieved by spoofing and relaying techniques: the adversary will falsely identify as an existing network host or service, tricking clients into accessing his machine instead of the actual service. Then, all requests from the client to the attacker will be relayed to the actual service, and all responses from the service will be relayed back to the client. The attacker now has free reign to intercept and manipulate the data-stream to his advantage.
As we all know, web browsers are software application used to access and browse the World Wide Web. They are used on many different devices, and had a clientele of 4.3 billion people in 2019, according to Internet World Stats[6].
As technology advanced and the world wide web gained prominence, more and more information became accessible through web browsers. Furthermore, larger amounts of personal, exploitable data were now accessible online, as services migrated to web-based environments. From email clients and cloud storage services to banking and government – clients can now use their web browsers to wire funds, manage financial assets, receive and send emails, access personal medical information and much more.
Moreover, a similar process is noticeable in Enterprise environments – as many intranet services, such as knowledge management systems, file servers, DBs etc. now offer web interfaces for users.
Accordingly, new security measures were implemented to protect personal data. Today, it is not uncommon to see websites that support HTTPS, security token mechanisms, and multi-factor and out-of-band authentication. Additionally, an ever-growing arsenal of technologies are available to protect the services themselves from malware, injections, cross-site scripting (XSS) and more.
Essentially, nowadays copious amounts of exploitable data are available through the world wide web. Yet collecting it, either by interception or false authentication, is harder than ever due to advancing security solutions. Queue Man-in-the-Browser.
In a Man-in-the-Browser attack (MITRE T1185: Man-in-the-Browser[7]), adversaries will exploit vulnerabilities in a victim’s web browser to gain partial or full control over it. Controlling the browser, the attacker is now a man-in-the-middle between the graphical content shown to the victim and the requested servers – and can use this position to intercept and manipulate both parties as he wishes.
However – and here is the genius of this technique – as this is a client-side MITM attack, it is very hard to distinguish legitimate client behavior from the attacker’s injected malicious activity. Essentially, an adversary may “inherit” the victim’s security context, rendering himself almost invisible.
Consider the following example: a victim is trying to transfer funds online. He makes sure the website is legitimate and that the connection is secure, authenticates using his username, password and ID number, fills a CAPTCHA form, and even verifies the login attempt on his mobile device, as the website implements out-of-band authentication. At last, he fills in the relevant form and hits Enter. The web browser will now render the user’s actions into an HTTP POST request to the server, including the input form data. Except, maliciously controlled by an adversary, the browser sends two POST requests – the original, and one designed to transfer funds to himself.
Man-in-the-Browser malware usually serve as trojan horses that run inside a specific process. In most modern web browsers, that means a specific tab (as each tab runs on a separate process). As the victim browses the internet, the malware will be hooked to these tabs. Three common attack vectors are:
In this demonstration we will use BeEF (Browser Exploitation Framework), an open-source pen-testing tool. It is somewhat similar to Metasploit, in that it is a modular exploit framework – but for web browsers.
BeEF hooks on to web browser instances, enabling adversaries to launch its expansive set of command modules inside a browser’s security context. In addition, it boasts a graphical user interface that streamlines the attack process significantly.
The server runs on a Linux machine but clients are not really OS-dependent. That is because BeEF relies on JavaScript code injection as its initial hook.
Figure 1: Demonstration network diagram
First, the BeEF server should be initiated on the attacking machine. No additional parameters are mandatory:
Figure 2: Starting the BeEF server. Notice the web UI and JS hook, marked in red.
The framework’s Web UI is now available at http://127.0.0.1:3000/ui/panel, as highlighted above. The location of the malicious JavaScript code is also indicated. Here’s the UI’s authentication page.
Figure 3: BeEF web UI login page.
And after logging in:
Figure 4: BeEF web UI control panel.
Now that the server-side is up and running, we will need to hook our victim’s browser by injecting the malicious JavaScript code.
Several attack vectors can be used to inject the code, amongst which are MITM, reflected/stored XSS execution and social engineering. But as JavaScript injection is a complex topic and to keep this demonstration focused, we’ll be using BeEF’s basic demo page that is already injected with the malicious code.
Here you can see our victim accessing the demo page on his Windows machine through Microsoft Edge:
Figure 5: The victims accesses a web page injected with the BeEF hook.
And over on the server side, a new client is shown:
Figure 6: Victim’s hooked browser seen in control panel alongisde various details (to the right).
Now that the browser is hooked, we can use BeEF’s simple interface and comprehensive list of modules to exploit our victim.
Alongside the basic data shown on the hooked browser’s main screen (see previous figure), many modules are available to fingerprint the victim and establish persistence, among which are:
Figure 7: “Fingerprint Browser” command module, with its results in the right-most pane.
Figure 8: “Detect Antivirus” command module, with its results in the right-most pane.
After assuring persistence and fingerprinting the victim, adversaries may start to collect personal victim data with the following modules (and various others):
Figure 9: “Spider Eye” module showing the victim’s hooked browser tab (marked in red).
Figure 10: “Detect Social Networks” command module, with its description and parameters in the right-most pane.
Adversaries may exploit man-in-the-browser attacks to forge requests on behalf of the victim, in the security context of the hooked browser. The victim “does all the heavy lifting” by authenticating to a certain service, say an Enterprise’s cloud storage, and the attacker swoops in at the last moment, sending a request to the storage server to delete all files.
This is accomplished by tunneling the attacker’s desired requests to the hooked browser session over BeEF’s communication channel, thus mimicking a reverse HTTP proxy. The hooked browser session in the proxy’s exit point.
First, the desired hooked session must be set as the proxy server:
Figure 11: Using the hooked browser as a proxy.
Now requests can be forged through the control interface under Proxy -> Forge Request:
Figure 12: Forging HTTP requests through BeEF’s control panel.
Alternatively, a different web browser can be set to use the proxy server, allowing the attacker to visually hijack the victim’s browser. To demonstrate this, we set up a dummy website with a simple logon page. Here it is on the victim’s machine: 
Figure 13: Victim logging in to a secure service.
On the BeEF server, we set up a proxy as shown above, and configured Firefox to use it. Now, when we access the DVWA website, we are not prompted with the login screen – because we’re browsing in the victim’s security context:
Figure 14: On the attacking machine, the attacker accesses the secure service without authentication, using the hooked browser as a proxy exit point.
Man-in-the-browser attacks are client-based and very hard to detect from a network traffic perspective. Moreover, no new processes are created and sometimes the malicious code will live entirely “off the land”.
Some approaches to detection and prevention may be:
Let’s get started
Ready to extend visibility, threat detection and response?
Prefer a one-on-one demo? Click here
By clicking next I consent to the use of my personal data by Cynet in accordance with Cynet's Privacy Policy and by its partners
