jobs listing should show which implant a listener will stage

[justinsteven]

Is your feature request related to a problem? Please describe.

The jobs listing doesn't make it clear which jobs are doing what, particularly in terms of staging.

Describe the solution you'd like

It would help avoid confusion if the jobs listing showed information about which implant (if any) a listener will stage.

It would probably make the most sense to simply show the profile name of the implant being staged (if any).

But this has a similar potential pitfall also related to the Additional Information concern in #712. What should happen if a profile is created, then a stage-listener is created for it, then a profile is deleted? Perhaps a profile should not be allowed to be deleted while there are still things referencing it, such as stage-listeners and implants.

Mock-up:

[server] sliver > jobs

 ID   Name   Protocol   Port    Stage Profile
==== ====== ========== ====== ================
 1    http   tcp        4444
 2    http   tcp        4445     shellcode32
 3    http   tcp        4446     shellcode64

[server] sliver > profiles

 Profile Name   Implant Type   Platform        Command & Control            Debug   Format      Obfuscation   Limitations
============== ============== =============== ============================ ======= =========== ============= =============
 shellcode32    session        windows/386     [1] https://127.0.0.1:4444   false   SHELLCODE   enabled
 shellcode64    session        windows/amd64   [1] https://127.0.0.1:4444   false   SHELLCODE   enabled

Demo

Create a HTTP listener:

[server] sliver > http --lhost 127.0.0.1 --lport 4444

[*] Starting HTTP :4444 listener ...
[*] Successfully started job #1

[server] sliver > jobs

 ID   Name   Protocol   Port
==== ====== ========== ======
 1    http   tcp        4444

Do curl http://127.0.0.1:44444/a.woff and observe that you get 404 (expected)

Create profiles for x64 and x86 shellcode:

[server] sliver > profiles new -a amd64 --format shellcode --http 127.0.0.1:4444 shellcode64

[*] Saved new implant profile shellcode64

[server] sliver > profiles new -a x86 --format shellcode --http 127.0.0.1:4444 shellcode32

[*] Saved new implant profile shellcode32

[server] sliver > profiles

 Profile Name   Implant Type   Platform        Command & Control            Debug   Format      Obfuscation   Limitations
============== ============== =============== ============================ ======= =========== ============= =============
 shellcode32    session        windows/386     [1] https://127.0.0.1:4444   false   SHELLCODE   enabled
 shellcode64    session        windows/amd64   [1] https://127.0.0.1:4444   false   SHELLCODE   enabled

(Now that I see it laid out in a table like that, is it legal to have x86 and x64 or even different OS's phoning home to the exact same http/https/mtls/whatever listener for c2? I'm guessing it is, but I haven't tried it)

Create stage listeners for each profile:

[server] sliver > stage-listener -p shellcode32 -u http://127.0.0.1:4445

[*] No builds found for profile shellcode32, generating a new one
[*] Job 2 (http) started

[server] sliver > stage-listener -p shellcode64 -u http://127.0.0.1:4446

[*] No builds found for profile shellcode64, generating a new one
[*] Job 3 (http) started

List the jobs:

[server] sliver > jobs

 ID   Name   Protocol   Port
==== ====== ========== ======
 1    http   tcp        4444
 2    http   tcp        4445
 3    http   tcp        4446

It's unclear which listeners are staging payloads, and which ones.

http://127.0.0.1:4444/test.woff is still giving 404 (expected)

The other listeners are serving stages:

% curl -s http://127.0.0.1:4445/test.woff | xxd | head -n1
00000000: 4883 e4f0 4883 c408 e880 1d09 0180 1d09  H...H...........

% curl -s http://127.0.0.1:4446/test.woff | xxd | head -n1
00000000: 4883 e4f0 4883 c408 e880 e514 0180 e514  H...H...........

But it's not clear from the UI which one is which.

Describe alternatives you've considered

Workaround: Documenting separately which jobs are staging what

Alternative fix: Having stage-listeners return a listing similar to the jobs listing, showing where the stage listener is listening and which implant it's staging.