sliver
sliver copied to clipboard
BishopFox
Single instance only
We should implement some kind of mutex so only one instance of implant running at a time.
Seems like a good idea to me, you may run into situations where your persistence technique results in multiple executions of a payload based on user activity and it would probably be a good idea to limit the number of sessions that get created.
Makes sense. I'll play with CreateMutexA and see what's the most convenient way to integrate that. We'll probably need to modify the generate command to have a common mutex name per implant build (or we could use the implant name as a mutex name too).
Yea we'll want some way of doing this on MacOS and Linux too methinks. We'll want to consider if this gets enabled by default.
It may also be nice to have a scheme were we can limit execution n instances.
Looks like we have a Linux compatible sample here, need to see what's needed for unix / OS X to make it work too: https://github.com/shubhros/drunkendeluge/blob/master/semaphore/semaphore.go
Cool, let's make this per-generated-implant too, just randomize all the values.
Just a thought: should they be per-user on the host? So if you have an unprivileged sliver and then privesc, launch a 2nd sliver, it would be nice to not have this interfere.
@rkervella Now that each host has a UUID, You can replace old connections instead of duplicating them. Ex. If there is already a session with the same UID, GID and UUID then replace the old one. (As long as it's not in use)
@usiegl00 I'm not fond of this solution two reasons:
- we want to avoid the implant running multiple time on the same host, and that should be handled implant-side. Using mutexes / semaphores is what makes sense here.
- there's an edge case where the same host can have multiple UUIDs, which would make this solution unreliable for this case
Makes Sense.
UUIDs work well for persistence however, allowing the server to match based on UID in the edge cases.