evil-winrm and socks proxy wont work

[githubee]

Describe the bug
Using sliver socks5 proxy and evil-winrm causes errors making it not usable. Using mtls transport

To Reproduce
Steps to reproduce the behavior:

1. socks5 add
2. proxychains evil-winrm
3. HTTP/NTLM/... errors

Sample error message:

Error: An error of type WinRM::WinRMHTTPTransportError happened, message is Bad HTTP response returned from server. Body(if present): (400).
Error: Exiting with code 1

Expected behavior
Should work. Workaround is to use portfwd

Screenshots
n/a

Desktop (please complete the following information):

• OS: Win10
• Version unknown

Additional context
Wireguard didnt work, so I dont know if mtls is the best transport option here.

When you say "⚠️ In-band SOCKS proxies can be a little unstable depending on protocol" - which protocol works best?

[moloch--]

I think this is due to improper handling of packet fragmentation in our socks5 implementation but it's very tricky to troubleshoot.

[githubee]

portfwd works flawlessly, no idea if this information is useful to you

[moloch--]

Yea the portfwd code we wrote from scratch, the socks5 is provided by a library (that we modified a little bit), suffice to say we just don't know the socks5 internal code as well.

[mrThe]

Hi there, can confirm that rdp wont work over socks. I'll try to investigate it in a few days, hope will find something.

upd: unfortunately don't have any time to do investigate, but ill keeping this in mind

[githubee]

maybe there is some managed code that could serve as a workaround? (running it using execute-assembly and portfwd)

[moloch--]

Yea for that i think we need to get around to implementing rportfwd (which honestly shouldn't be too hard) first.

[realalexandergeorgiev]

would be so good to have this.
bloodhound-python not working as well :(

[realalexandergeorgiev]

Found this, maybe its useful https://github.com/Acebond/ReverseSocks5

[Lcys]

When the data packet is too large, it will be split into multiple data packets, and when they arrive at the implant end, the order is inconsistent, causing some protocol interactions to fail