sliver
sliver copied to clipboard
BishopFox
Customizing the implant binary
I would love to further extend sliver's implant build/compile process with custom code. I am thinking along the lines of CS artifact kit. I am not sure how much effort it would take to implement this in sliver, but I am 100% sure it would be a total game changer, as this is one of the main reasons for me to stay with CS when it comes to heavy duty evasion/obfuscation other than the default built-in sliver functionality.
In my opinion obfuscating with off-the-shelve tools is not sufficient for high-profile targets, where heavily customised payloads are the key. Maybe there's a way or workaround to get this done, but I have found non so far (other than manipulating the sliver source code which is not really portable as this had to be done for every modification on the implant payloads).
We've actually been thinking about how to implement this in a good way for a long time, and I think I have an approach in my head that I'm going to try to implement in the near-ish future.
Oh wow, that sounds awesome. I guess the only workaround would be generating implants/beacons in shellcode format and write your own encrypter/wrapper/bypasses around that. Not perfect, but better than nothing. Can't wait for this being implemented!
@dhauenstein for the moment did you give a look at pezor project https://github.com/phra/PEzor (a reference to pezor is present in sliver documentation)? A way to customize would be as you said to take the shellcode and put it in wrappers executing the shellcode. Pezor does this for you. If you want to automate things, you might introduce custom commands in the sliver-client, that will first get the shellcode, by contacting the sliver-server, and later calls pezor to pack the shellcode. Other packers are inceptor https://github.com/klezVirus/inceptor even if i'm afraid it runs only on windows.
Yea, i think the way I'm going to implement this is a general way to export the implant configuration to an external builder, the build can build anything then upload the binary back to the sliver server. This will allow for whole sale replacement of the default implant implementation. I'll probably make a stock external builder that just bulids the default implant, which should make it much easier to modify the implant code and have it interoperable with new/upstream server versions
So maybe it would be possible to let the sliver-server make an api call to the external builder. The api call is implemented as a rest API that is offered by the external builder. The external builder consumes the API call by returning an artifact to the server. I was thinking of implementing the external builder of like a microservice so that can be spawned also on a machine different from the sliver-server. For example in this way it might be possible to have the external builder running on windows machine and calling inceptor https://github.com/klezVirus/inceptor (that seems can work only on windows) and the team-server on a linux machine (or in a docker container). Maybe you already thought about more or less the same thing @moloch-- ?
Yeap, that's basically how I did it (see PR above) --though it uses the existing gRPC/mTLS API instead of REST. However, we can just implement REST in middleware if someone wants REST specifically.
Oh excellent! And thanks for last modifications to RportFwd variables, i didn't notice the inconsistent naming.
Super sweet! @MrAle98 I heard of PEzor, never used it tough. Can't wait for this PR to be merged, definitely a step in the right direction.
I am not sure how much effort it would take to implement this in sliver
A good amount. External builders are the easiest way forward in that direction, but will still require the end user to write a decent amount of code.
Yeah, I thought so, since the whole building has to be ported from Go binaries to native code, which I assume is a huge amount of work.
Writing lots of code myself (such as the bypassing routines and encryptors) is fine - I guess that's the price you pay for heavy customization. :)
The low level APIs are now in master but I'll create an basic builder too. We can turn any server binary into an external builder by creating a new cli entry point, which will make it possible to have a server offload compilations of certain builds to "external builders" on other platforms (e.g. have a linux server delegate builds to a macos device).
This improves mutli-platform builds for tricky targets and allows external binary implementations at the same time.