evil-winrm and socks proxy wont work
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:
- socks5 add
- proxychains evil-winrm
- 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?
I think this is due to improper handling of packet fragmentation in our socks5 implementation but it's very tricky to troubleshoot.
portfwd works flawlessly, no idea if this information is useful to you
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.
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
maybe there is some managed code that could serve as a workaround? (running it using execute-assembly and portfwd)
Yea for that i think we need to get around to implementing rportfwd (which honestly shouldn't be too hard) first.
would be so good to have this. bloodhound-python not working as well :(
Found this, maybe its useful https://github.com/Acebond/ReverseSocks5
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