Feature Request: Catch Ctrl-Z When Inside Implant Shell

[jeffmcjunkin]

When running a shell inside a victim implant, the shell needs to cleanly exit before the operator can regain control of Sliver itself. In Metasploit, if a shell inside a meterpreter session stops being responsive, a Ctrl-Z can be caught by msfconsole and regain control of msfconsole itself, whether or not the child process on the target dies.

Requested Solution

Have Sliver hook Ctrl-Z (SIGTSTP), and give an option to operators to return control back to the Sliver console. Example from Metasploit:

meterpreter > shell
Process 30677 created.
Channel 1 created.
/bin/sh: 0: can't access tty; job control turned off
$ grep NeverGonnaGiveYouUp /dev/urandom
this input is ignored, as `grep` is still running...
^Z <-- actually pressing Ctrl-Z
Background channel 1? [y/N]  y
meterpreter > background
[*] Backgrounding session 1...
msf6 > 

Alternatives

I'm honestly unsure of another way to cleanly solve this potential problem.

Context

I brought this up on the BloodHoundGang Slack (inside #golang) and got some traction there. Greetz, as the kids said once.

[JayBeale]

+1

[lesnuages]

This is a tricky one. We have full pty support for platform that support it (so, mostly everything other than windows), and the host program (the one started by the shell command on the remote system) gets all user input, including signals.

It is really handy when you use an interactive program (say vim or whatever) in your bash session ran by shell and you want to use the the shell's support of SIGTSTP to put vim on background. You can currently do that with sliver.

Now, if we were to find a way to stop the signals at the client level, and catch SIGTSTP, we would break that feature.

I agree that sometimes it could be handy to have a meterpreter like channel feature, where you can jump back and forth between channels using SIGTSTP to go back to the console. That's just not currently the way the client implements the shell command, and it would kill this signal passing thing we currently have.

Now we could try to find a way to make both work, but I'd have to look more into the lib we're using for the fake terminal.

[lesnuages]

I guess we should look into a way to:

• catch the SIGSTP signal at the client level
• ask the operator whether they want it to be propagated to the implant
• send the signal if they chose yes, kill the shell session if they chose no

[lesnuages]

Also, a thing to consider: SIGTSTP does not seem to exists on Windows, so a Windows client won't have this feature.

[lesnuages]

By the way, for your specific example @jeffmcjunkin , the current behavior should work:

[server] sliver (TALL_TADPOLE) > shell

? This action is bad OPSEC, are you an adult? Yes
[*] Opening shell tunnel (EOF to exit) ...

[*] Started remote shell with pid 489

lesnuages@hawaii:/mnt/c/Users/lesnuages$ grep NeverGonnaGiveYouUp  /dev/urandom
^Z
[1]+  Stopped                 grep --color=auto NeverGonnaGiveYouUp  /dev/urandom
lesnuages@hawaii:/mnt/c/Users/lesnuages$ pkill grep
lesnuages@hawaii:/mnt/c/Users/lesnuages$ fg
grep --color=auto NeverGonnaGiveYouUp  /dev/urandom
Terminated
lesnuages@hawaii:/mnt/c/Users/lesnuages$ exit
exit
Shell exited

[server] sliver (TALL_TADPOLE) >

[jeffmcjunkin]

Thank you for the detailed response, @lesnuages. I may be in the minority, but I'd prefer the behavior you described here:

I guess we should look into a way to:

• catch the SIGSTP signal at the client level
• ask the operator whether they want it to be propagated to the implant
• send the signal if they chose yes, kill the shell session if they chose no

Failing that, I'd even rather have Sliver not allocate a pty (operators can do Python tricks or similar if need be) so the Sliver console can catch SIGSTP without repercussions. For Windows implants, as you said, there isn't SIGSTP, so this wouldn't lose functionality on a very common target.

That last option may put me firmly in the minority, though.

[Marshall-Hallenbeck]

Sliver could not allocate a pty and you could pass in a pty option when running shell, or vice versa (allocate one, and allow no-pty)

[moloch--]

That's already an option (shell has a --no-pty flag)