-
-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to run as a windows service #70
Comments
Whats missing seems to be the start command |
Oh. Alright ill tweak that and test it |
For some additional info, rssh can install itself as a service, and I have used it there. So Im not sure what the issue is here. |
The issue is described in the original comment, where you are hijacking an existing service to assume its identity. That is, for example, you have write access over a binary or a binary's location used by a service that isn't presently running or you can stop and start. You replace the binary then start the service - at present this will fail with the message in the prior screenshot. |
Hm, thanks. I think it may be due to this: golang/go#44921 As I cant spot anything that would make rssh unable to communicate as a service otherwise |
Hmm okay. Ill do some testing - see if it functions properly with a low privilege service |
Please try with the unstable branch, I've just bumped the modules |
It can still be stopped by killing the client from the rssh catcher interface. I'm fine to close this issue, ta. |
Ah yes, actually thats a bug funny enough. The break statement is breaking the switch rather than the outer for loop |
This change is now on unstable |
In a few 'engagements' I have needed to replace a windows service binary to hijack the account running the service. reverse_ssh golang clients compiled for windows do not respond to the start/status requests made by the windows service system, so do not start properly and are quickly killed.
To get around this, I have built basic .NET windows service projects that simply call the reverse_ssh binary on start, but this is a bit annoying.
The x/sys golang library suports creating windows services - this issue proposes that this functionality be built into the windows client build so that the windows client can serve both as a standalone executable and a windows service as needed - there is a .IsWindowsService method in this library that should be able to change the operating mode based on context
The text was updated successfully, but these errors were encountered: