Gemhide Sliver: Making C2 Look Like Anything You Need - Timothy Makram Ghatas

Uh hi everyone, my name is Tim. I work at Bishop Fox and I'm one of the developers working on Sliver. Uh this is a very improvised talk so please bear with me. Uh the slides were only made yesterday but uh let's talk a bit about Sliver. So, Sliver is uh one of the uh well-known C2 uh platform used by red teams. Uh specifically, it's uh the type of tool that you'd use uh in a security assessment that requires stealth where you need to evade detections, try to stay under the radar, and uh slowly move your way across uh your targets environment. Let's talk a bit about an assessment I had a while ago. uh as we typically do

in these, we started with looking at their external parameter uh searching for vulnerabilities and anything that could allow us uh to gain an entry point into our targets network. And lucky for us, after a while, we found an RC. And it wasn't just an RC. It was an RC as the root user on some random web server. After a bit of enumeration on that host, we quickly noticed there was actually no EDR running on there. And even better, looking at the network interfaces, it seemed to have some way to pivot to the on-remise environment. At this point, this is really uh the perfect scenario for us. We have a pivot point. We can quickly deploy some implant on there and

use it to start targeting uh our client's internal network. Basically, uh jackpot. However, after a couple hours, uh we lost access. All our beacons were all our beacons died and we're no longer able to reach into the environment at all. So, as we typically do in these scenarios, we started doing some investigation trying to find out what actually happened. We talked with our clients and as far as we could tell, the domain was good. Our implants weren't causing any uh alerts in their or in their logs or anything like that. We just couldn't figure out what had happened. It turned out later on the client had actually caught it through the network traffic for a very simple

reason. they've had been compromised with sliver before. So they wrote some customized detections and got us caught. Pretty pretty dumb scenario. So at that point in time I started taking a look at uh how SL actually uh handled its HTTP traffic uh to see if I could maybe improve on that. And so to give you a quick description, this is uh the situation scenario 1.5 when you generate your implants, you have a single uh C2 configuration where you define extensions for the different operations that uh your implant is going to do and a bunch of URLs, a bunch of paths and uh your implant will just generate your traffic on the fly. Uh and you end up

with URLs that look essentially like this. The extensions always have to stay the same. uh and the rest is just procedurally generated based on the uh configuration that you provided. The configuration is going to be the same across all implants for that uh sliver host which means that over time uh you're going to see a lot of requests uh going to uh JS. Why? Because that is the one used for poll requests. Essentially, every time the implant is looking whether there's a new activity to to run, it's going to call ajs uh URL which ends up generating a lot of very predictable uh network traffic. And so, uh the other thing that you have is by

default you have this uh little URL parameter. This is actually an encoder ID. So it's used to determine uh what method the implant used to hide uh the data it's exchanging with its backend server. In this particular case for example it's using an English language uh encoder which is essentially data encoded in the lengths of the different words that you're seeing around the screen. It can also do PGs and a few other things. But the problem is you always have the single ID. So if you start adding all of this up together, you start getting to a situation where it's actually possible to write uh some detections for this particular network traffic. And so I spent uh the last 6

months essentially trying to address these problems uh allowing more flexibility in the unplant by uh removing the need for specific extensions uh making sure that the content type actually matches the request. Like if you look at this here, we're calling it JS file, but this is actually random English or it could be a picture or anything else. And finally, also removing the need for that encoder ID allowing to hide it in other places like for example in cookies or uh inside the URL instead of a random parameter. So what you're seeing here is uh the latest release as of uh Thursday uh where I've implemented a lot of these fixes. And essentially uh what you'll see here is

first of all uh we actually allow having multiple uh C2 profiles now. So you're no longer tied to one specific type of traffic, but rather you have the ability to switch between as many as you want. Uh you can have

you you here we go you can have uh as many extensions as you want and the implant will just randomly pivot between all of these and for each extension uh you will have specific types of encoder that are specified which allow you to tie uh the right content type to the right network traffic request and kind of avoid that small uh discrepancy there. And so essentially when you generate your implant, you now just specify whichever C2 profile you wanted to use. Uh and once it starts running, we'll have a look at the logs here. You can see that it now uh no longer has that URL parameter because in this particular case, it's hiding it inside

of the URL. It's randomly switching extensions as it goes on. uh which makes it a lot more difficult to fingerprint using the methods that the client had used in that assessment I mentioned earlier. So uh this is it for my talk. Sorry it's pretty short. Uh we have a website with our documentation and this is an open source project. So if you want to contribute or learn more about the tool uh here you go.

Hello. Thanks for your talk. It was short but great. Uh question for you. Have you had do do you have the ability or have you considered to do like malleable C2 profiles and and using like CDNs to you know kind of blend in with traffic with like Azure um domains and other like legitimate domains like like for example Cobbot Strike would do. >> Um so we actually do use uh these domains but this isn't something that we've included in the tool itself. It's more uh automation that we build on top of this. Um as far as malleable C2 profiles, uh this is another ongoing project uh that we're working on, but it is not currently

included in sliver itself.