sesh = silent exploitation shell | security engineering shell | super epic shell | stealth espionage shell | standalone execution shell | sexy encrypted shell
-
fully modular - enable/disable any feature at compile or runtime
-
total disregard foractive leveraging of established conventions -
does not touch disk without you knowing about it
-
read and write files without changing metadata
-
assume the identity of an already running process (or whatever you want it to be)
-
in-memory command history
-
embed arbitrary files in the binary for later use
-
configuration can be saved as a short string, which can be loaded with ease
-
built in enumeration scripts
-
spoof running time (may need root)
-
something like a cooler version of moonwalk
-
ignore SIGHUP (and/or other signals)
-
cool udp and tcp revshell capability, which when combined with the previous feature, means you can ssh (or whatever) to a target, run sesh, close ssh connection, and then reconnect via a more stealthy route (alla pwncat)
-
send random data to random (or not so random) ip addresses to cover communications
-
many useful tools built in, don't need to run binaries from disk, such as:
- cat, base64, zip, tar, netcat, nano, ls, find, grep, wget, su, env, chmod, chown, chgrp, getcap, setcap, etc
- (note that most of these will be replaced with cool rewrites, i.e. ls->exa, find->bfs, etc. will be kinda like busybox but more based.)
- might also just chuck python in there
-
run executables from memory, from network, or even local binaries with or without +x set
- not sure if I can do this, but optimally, given a binary in any of the above forms, you would be able to execute them with userland exec without overwriting the original sesh process, i.e imagine you are in a sesh session, and you run
silentexec /bin/ls
, this would read thels
binary, execute it with userland exec, show you the output, then return you to your sesh session, all without starting or stopping any processes at all! - ok I thought a bit more about the above idea, and I think I can basically (before sesh performs a userland exec) patch the target binary (in memory) in such a way that rather than exiting post-execution, it instead would itself perform a userland exec to get back to sesh. This would mean losing whatever state sesh was previously in though, which might be a problem, but I could probably save the state and restore it using a method similar to that used by CryoPID.
- alternatively perhaps I should basically somehow spin up a userland virtual machine sort of thing. I'll have to investigate that avenue.
- less cool version: through the use of memfd, like this
- not sure if I can do this, but optimally, given a binary in any of the above forms, you would be able to execute them with userland exec without overwriting the original sesh process, i.e imagine you are in a sesh session, and you run
-
ability to start a process as a child of some arbitrary process (cursed+hard), or maybe something like this to start the process inside another process without causing any issues with the original process
-
awesome backdooring using a project I haven't started writing yet, which involves infecting preexisting executables with a self-replicating security flaw (thanks Johnny!)
Warning
Written in Go!!!