Hardening the Sliver C2 with both listeners HTTPS and mTLS when setting up the infrastructure. JARM hash isn't randomized by default. about sliver HOT 13 CLOSED

An easy way i use to check is just using strcmp's here's two default Sliver JARMs

from sliver.

So we'll typically stage primary payloads from different domains than those used for the C2 traffic, and give us the ability to limit access to those primary payloads either by IP address, number of downloads, time of date/etc.

However, in my experience if a human is tearing apart your infrastructure you're probably already in trouble hehe. It's better to implement techniques to bypass the automated detection that inform the humans something suspicious is going on.

from sliver.

Alright thanks for your time users I was planning to make a collab with Lsecqt for sliver c2 walkthrough part 2. Looks like there isn't much for me to say since all of my doubts are gone. I'll be back for more feedback if I got any.

from sliver.

I'd recommend putting your sliver server behind an HTTPS reverse proxy (apache, nginx, caddy, or whatever other technology you prefer) if you're worried about JARM signatures for the server.

How can I change this with openssl if possible?

You can't. The sliver-server binary creates its on certificate authorities on startup / when a cert needs to be generated. We don't support dynamically changing or configuring the TLS certificates settings currently. I believe @moloch-- looked at it at some point, but I'm not sure.

from sliver.

I figured that much for adding redirectors as the solution. I'm just wondering what's the point of --disable-randomized-jarm being there if it's not being used to randomize JARM hash. I just wondered if it's possible to rely without it. The only alternative I could think of using https listener to pass my own TLS certs and the JARM hash has changed. So it's just one way to do it.

Also what about the mTLS listener? Should I just use a redirector as you suggested? Or do you have plans how to change the JARM hash to circumvent it or what @moloch-- did look at the default certs to see if it's possible to change them?

from sliver.

The HTTPS listener JARM is randomized per-process due to the way the HTTPS servers are initialized, so stopping/starting the job will have the same JARM. Restarting the server process and listener will result in a new JARM.

The mTLS listener is not randomized as Go does not allow customizing cipher suites when using TLS 1.3, which we force in mTLS mode. The reasoning here is that Sliver relies upon mTLS for security and JARM randomization requires enabling as least some insecure cipher suites, as HTTP C2 uses its own encryption and doesn't rely on HTTPS we can safely randomize the JARM for HTTPS. The mTLS JARM will likely also collide with many other Go services, due to this behavior.

Also I'd point out that Rouge Sliver requires valid client certificates so in order to perform the attack you'd need:

1. Identify an mTLS endpoint on the internet as Sliver
2. Obtain a copy of an implant generated from that server
3. Extract client certificates from that implant, likely requiring in-memory extraction if obfuscation is enabled, so you'd have to run it in a sandbox or something too.
4. Execute Rouge Sliver with client certs

As this DoS technique can't be performed without per-server credentials we don't consider it to be an issue.

from sliver.

Also please note the two JARMs you listed are different

3fd21c20d00000021c43d21 c 21 c 43d41226dd5dfc615dd4a96265559485910
3fd21b20d00000021c43d21 b 21 b 43d41226dd5dfc615dd4a96265559485910

JARM hashes aren't like SHAs or anything they typically differ by only a few values.

from sliver.

I didn't notice that two characters which are hard to find. Alright one last question. It's about stage-listener. I've looked at this blog post https://www.whiteoaksecurity.com/blog/cobalt-strike-opsec related to shellcode compatibility.

What can I do to prevent from a threat hunter in a red team assessment from downloading the shellcode from the attacker's C2. But I read in the documentation of Bring Your Own Stager (BYOS) with a flag --prepend-size might be the cause of metasploit compatibility.

I'm writing notes for my project SCPA to harden the Sliver C2 so that anyone will take an OPSEC consideration during a red team assessment.

I wrote it in obsidian and there's still WIP.

from sliver.

So redirector is the answer to prevent it from happening?

from sliver.

Its one method of doing so yes, though there's many others out there!

from sliver.

Where can I find them?

from sliver.

The best is the one you invent yourself :) keep in mind stagers are just files like any other that get downloaded and executed. You can load a stager from anywhere or anything over any protocol that you can stash some data.

from sliver.

Cheers!

from sliver.