-Used only nessessary pointers needed for exploit to work removing junk/filler chars
-Repaced ROP chain with generic from msvcrt (even though original was beautiful and smaller, uses hardcoded pointers for leave instructions)
-Cannot use ropdb since 4 byte junk char during generation may result in InvalidByteSequenceError during UTF conversion
-It's been some years since my last pull request...so I might be a bit rusty to new Metasploit standards (please forgive me!)
Because we are not able to get our hands on the hardware for testing,
and that this module may trigger a backtrace if the UDP server isn't
Moxa, we force check to make sure that doesn't happen.
This is not a bug, but a feature which gives users with the correct
permissions the ability to take over a host running Octopus Deploy.
During an automated deployment initiated by this module, a powershell
based payload is executed in the context of the Octopus Deploy server,
which is running as either Local System or a custom domain account.
This is done by creating a release that contains a single script step
that is run on the Octopus Deploy server. The said script step is
deleted after the deployment is started. Though the script step will
not be visible in the Octopus Deploy UI, it will remain in the server's
database (with lot's of other interesting data).
Options for authenticating with the Octopus Deploy server include
username and password combination or an api key. Accounts are handled
by Octopus Deploy (stored in database) or Active Directory.
More information about Octopus Deploy:
https://octopus.com
While it offers a better OOBE, don't set a default LHOST. Force the user
to think about what they're setting it to. Also, RequiredCmd is largely
unnecessary and difficult to determine ahead of time unless the target
is a virtual appliance or something else "shipped."