NHAS / reverse_ssh

SSH based reverse shell
BSD 3-Clause "New" or "Revised" License
947 stars 134 forks source link

Add shellcode generation for client both for windows x86 and x64 and linux #128

Closed Cr7pt0nic closed 1 year ago

Cr7pt0nic commented 1 year ago

I just want to add a suggestion for adding an option that allows the user to generate x86/x64 shellcode for windows or linux

NHAS commented 1 year ago

Hi there,

Not sure what you mean by this, reverse ssh is quite large in size (even with upx) so the shellcode would be several megabytes which isn't particularly useful for any exploitation I know of.

As it currently stands reverse ssh is solidly a post exploitation tool that enables more advanced "management" of targets. Rather than your first tool through the door.

If you define what youre looking to accomplish a bit more I might be able to help, but for now this will probably be marked as won't fix sorry!

Cr7pt0nic commented 1 year ago

Well for post exploitation it would be nice to add the ability to generate the shellcode or possibly allow the user to invoke shellcode stored from an external address from a hosted webserver hosting the binary shellcode instead of taking the raw hexadecimal shellcode data and having to input it into another executable. So during runtime it could grab the shellcode from the external address and execute it into memory without storing the shellcode to disk. I don't know that was just an idea that I had from seeing another github repository with the same idea. Of course this isn't utilizing shellcode but instead using AES encryption but I thought it might be a good idea to do the same with shellcode as well but I just wanted to give my input on something that might be useful in the future.

https://github.com/TheD1rkMtr/FilelessPELoader

Cr7pt0nic commented 1 year ago

Oh also I have another issue. When generating a windows x64 compiled client I am able to setup the RSSH_HOMESERVER but when generating the client and running it. It doesn't connect back to the server but when adding the -d arguments it works for connecting back to the server. But the RSSH_HOMESERVER argument during compiling should've made it so that the executable during runtime would connect back to the server without providing an argument. This is the command I used

GOOS=windows GOARCH=amd64 RSSH_HOMESERVER=172.26.122.47:4200 make client
NHAS commented 1 year ago

So. In further review of your request, and the provided example this already exists in RSSH.

The RSSH server can generate and provide portal executables via http and the link command in the server console. This lets you pull an RSSH client binary and from there its up to you to load it into memory however you wish.

If you're asking for me to implement something like the loader stage that would connect back to the RSSH server and pull said binary thats out of scope of this project.

NHAS commented 1 year ago

As for your issue. I cannot replicate this. I have used your exact command line and can see the value is injected into the binary and when running with --foreground can see the client connects