Man-in-the-Browser via Chrome Extension
PreviousLateral Movement over headless RDP with SharpRDPNextShadowMove: Lateral Movement by Duplicating Existing Sockets
Last updated
Last updated
This is a quick lab to familiarize with a CursedChrome Chrome extension, which at a high level works in the following way:
CursedChrome extension is added to Chrome on a compromised computer;
Compromised computer's Chrome connects back to an attacker controlled CursedChrome C2 server. Comromised computer's Chrome now acts as a proxy into the compromised network;
Attacker can now proxy web requests through the compromised computer's Chrome and reach any internal web application that the compromised user/computer can access.
The beauty of this technique is in the fact that the attacker's web requests leverage cookies stored in the compromised Chrome browser, which means that if a compromised user is logged on to some web application the attacker is interested in, the attacker no longer requires to authenticate to that application in order to access it as their HTTP request will re-use the existing cookies from the compromised Chrome and will be let in without being asked to provide credentials.
The extension author visualizes the whole process like so:
Below is a list of systems involved in this lab:
18.130.61.92 - CursedChrome C2 server;
10.0.0.7 - attacker computer WS01;
x.x.x.x - compromised computer in some other network outside the WS01 computer's network.
On the CursedChrome C2 server, pull the CusedChrome git repo, enter it and spin up the CursedChrome server using docker-compose with the following commands:
After running the above docker-compose, you should see the below screen:
Save the username and password for later as these will be required when connecting to the CursedChrome C2 web console:
Additionally, note that the CursedChrome's web console is listening on 127.0.0.1:8118 and HTTP proxy on 127.0.0.1:8080 - we will need these later, when setting up local SSH tunnels, so that we can access these services from the attacking machine WS01.
On a compromised computer, we need to install the CursedChrome implant.
It's up to you how you will do it, but for the demo purposes, I simply enabled Developer mode and clicked Load unpacked and pointed it to the .\extension folder from the CursedChrome's repo. The extension is now installed:
On the attacker machine, let's set up a couple of local SSH tunnels.
In order to access the CursedChrome's C2 web console via http://localhost:1111, we need the following SSH tunnel to the CursedChrome's C2 server:
In order to proxy our HTTP traffic through the CursedChrome's C2 web proxy, using FoxyProxy, we need the following tunnel:
Once we have the tunnels setup, we can try accesing the web console by navigating to http://localhost:1111 and if everything works, you should see a login panel:
Enter the admin credentials you got after setting up the CursedChrome server using docker-compose and you should now be logged on to the panel, where you will see a bot / compromised computer's CursedChrome extension calling back to the CursedChrome C2:
Note the username and password of the bot as you will need it when configuring FoxyProxy.
Important Do not forget to export the Proxy CA certificate (see the big download button below the connected bots panel) and install it to FireFox as this is required for the technique to work.
Now we're ready to setup the FoxyProxy (FireFox extension).
Proxy IP and port should be 127.0.0.1:2222 (remember, we set up a local SSH tunnel for this earlier) and username/password should be those seen in the "Connected bots" panel in the CursedChrome's C2 web console:
Configure FireFox to use the FoxyProxy you just set up and you are ready to access some internal web application on a compromised computer's network, that otherwise would not be accessible to you.
With all the setup completed, the below image shows how I'm able to access a Bitbucket on behalf of a compromised user Mantvydas without knowing their credentials on a network that is outside of the attacking VM WS01:
