Can't spawn Shell and can't install Armory on Win mTLS

[mgeeky]

Describe the bug Cannot install armory seatbelt as well as cannot enter interactive shell session while operating on mTLS implant.

To Reproduce Steps to reproduce the behavior:

1. Spawn windows sliver implant (mTLS)
2. Run armory
3. Run armory install seatbelt
4. See error
5. Run shell
6. Client binary hangs, no further output produced, had to CTRL+C to kill it.

Expected behavior Wanted to spawn interactive shell and wanted to install armory.

Desktop (please complete the following information):

sliver (win1) > info

        Session ID: 49e437b8-fd6c-4d55-b596-64d89cb34762
              Name: win1
          Hostname: foohost
              UUID: 47aeca5a-05e6-7022-c012-7e0ed3ac2ccc
          Username: CONTOSO\foouser
               UID: S-1-5-21-123456789-123456789-123456789-123456
               GID: S-1-5-21-123456789-123456789-123456789-513
               PID: 18476
                OS: windows
           Version: 10 build 19042 x86_64
              Arch: amd64
         Active C2: mtls://attacker.com:8888
    Remote Address: 1.2.3.4:3367
         Proxy URL:
Reconnect Interval: 1m0s

Additional context

sliver (win1) > armory install seatbelt

[!]
Failed to install file: empty file \Seatbelt.exe
[!] Failed to install alias 'seatbelt': failed to install alias
sliver (win1) > armory update

[*] All aliases up to date!
[*] All extensions up to date!

sliver (win1) > armory install rubeus

[!]
Failed to install file: empty file \Rubeus.exe
[!] Failed to install alias 'rubeus': failed to install alias
sliver (win1) >

Spawning shell resulted in CTRL+C and client process killing due to no interaction:

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

[*] Started remote shell with pid 19672


whoami

Shell exited

Any ideas how to proceed here?

[moloch--]

I think the armory is a path handling bug, tbh we don't test the windows client as well as the others. The shell issue looks like it may be separate bug, are you using the Windows Terminal / a terminal that supports PTYs?

[mgeeky]

Yes, I'm using windows terminal.

So, any idea what to do about that armory case?

[moloch--]

We'll probably have to patch the armory installation code, looks like it's something related to Windows' relative paths not behaving like Unix-like paths. WSL+Linux client should work as an interim quick fix.

The code is implemented using cross platform filepath but Windows usually still finds a way to break.

[mgeeky]

Also, I didn't open the bug report for this, but there are plenty of issues around handling of backslashes - where for instance:

generate c:\test\sample1.exe

will produce:

ctestsample1.exe

Other affected commands are execute-assembly, upload and so on - it's a global problem really.

[moloch--]

You will need to use \\ for backslashes, this isn't a bug but the way our shell interpreter works.

[mgeeky]

I'd consider this as an UX annoyance. Is there anything that can be done about it?

[moloch--]

Not really without switching the entire shell repl library we use (this is used to encoding lots of things), we are working on a GUI that will be out ... when it's ready, which of course won't have this behavior.

[827Dream]

same problem

[jamesgol]

I think I just ran into the can't spawn shell bug when I installed a windows vm to test another patch on.

Server is running linux, implant is windows8. My implant is in debug mode, the shell pops but on the open terminal on the windows box that is showing the debug.

I could type exit on the shell visible in the implant and control is returned back on the server. I can take some screenshots later if that would help at all.

This is the first time I've tried an implant on windows so I'm not sure if it works on other versions at all.

Here's the implant log:

2022/09/07 20:57:38 sliver.go:223: [recv] tunHandler 20
2022/09/07 20:57:38 shell_windows.go:71: [shell] [C:\Windows\System32\WindowsPow
erShell\v1.0\powershell.exe -NoExit -Command [Console]::OutputEncoding=[Text.UTF
8Encoding]::UTF8]
2022/09/07 20:57:38 shell_handler.go:82: [shell] Process spawned!
2022/09/07 20:57:38 shell_handler.go:159: [shell] Started shell with tunnel ID 6
12065781856809678
2022/09/07 20:57:38 shell_handler.go:132: [shell] tWriter: {0xc000057c20 0xc0000
54240} outErr: &{0xc0000bc780}
2022/09/07 20:57:38 shell_handler.go:132: [shell] tWriter: {0xc000057c20 0xc0000
54240} outErr: &{0xc0000bc280}

At this point the shell was opened on the implant and I manually typed exit after a bit. and the log continues:

2022/09/07 20:57:56 shell_handler.go:107: [shell] Closing tunnel request 6120657
81856809678 (shell wait error). Err: exec: Wait was already called
2022/09/07 20:57:56 shell_handler.go:107: [shell] Closing tunnel request 6120657
81856809678 (process terminated). Err: <nil>
2022/09/07 20:57:56 sliver.go:223: [recv] tunHandler 22
2022/09/07 20:57:56 sliver.go:223: [recv] tunHandler 22
2022/09/07 20:57:56 data_handler.go:46: [tunnel] Cache tunnel 612065781856809678
 (seq: 1)
2022/09/07 20:57:56 data_handler.go:46: [tunnel] Cache tunnel 612065781856809678
 (seq: 0)
2022/09/07 20:57:56 data_handler.go:58: [tunnel] Write 54 bytes to tunnel 612065

[moloch--]

I wonder if its something to do with the version of powershell?

[jamesgol]

I wonder if its something to do with the version of powershell?

I have no idea, I'm not a windows user. I only spun up the VM to test that other PR against, figured I'd play around with the windows implant a bit once I had it up and running.

[maxlandon]

Solved in new release, there was a problem in the client assets code that would not correctly consider paths on Windows.