use exploit/windows/smb/ms17_010_psexec
set RHOSTS 10.11.1.0/24
run
(not only for this exploit)
How'd you do it?
set THREADS 10Since the new metasploit version allows to set RHOSTS (not only RHOST) I'd like to run all exploits concurrently on multiple hosts (not only for this exploit).
the exploit is run for one host at a time
Framework Version: 5.0.0-dev
ArchLinux
At a guess, this could probably be achieved by borrowing some code from:
def check_multiple(hosts) from lib/msf/ui/console/module_command_dispatcher.rb
And adding to:
def cmd_exploit(*args) in lib/msf/ui/console/command_dispatcher/exploit.rb.
This is a good idea, and also a bulk of work.
Actually, I have tried to achieve this, it's a challenge, however. Not same as the auxiliary scan modules, just run it with thread pool or some other concurrent library, there are some phases during the exploit module running, such as generate the payload, start the handler and execute the code to exploit. For now, the rhosts option is parsed and executed one by one, simple and dirty.
In my opinion, to achieve this goal perfectly, we have to refactor the core library function in exploit module. Here is the procedure:
First of all, just generate the payload once for each module, instead of doing it against every target with the same module. Then start the local handler for one time as the previous step do, or start a lot of handlers if the payload is a kind of bind_* or others. That depends on the type of payload. At last, we execute the main exploit code. That's a basic procedure in my brain, I did not describe some other stuff in detail.
I am not a good coder and know little about design patten, I am afraid that I would mess up the beauty of Metasploit framework. It's better that some employee in R7 to do it, but if others are not interested in this, I would do it when I am free.
Thanks for your suggestion.
I explicitly left out threads support because not all handlers can support multiple connections in parallel for the purpose of determining success or failure with exploit modules. Also some big refactoring of the threading methods would be nice as @Green-m pointed out, to avoid duplicating even more of the delicate threaded bits. Will have to think about it in May perhaps.
Most helpful comment
This is a good idea, and also a bulk of work.
Actually, I have tried to achieve this, it's a challenge, however. Not same as the
auxiliaryscan modules, just run it with thread pool or some other concurrent library, there are some phases during theexploitmodule running, such as generate the payload, start the handler and execute the code to exploit. For now, therhostsoption is parsed and executed one by one, simple and dirty.In my opinion, to achieve this goal perfectly, we have to refactor the core library function in
exploitmodule. Here is the procedure:First of all, just generate the payload once for each module, instead of doing it against every target with the same module. Then start the local handler for one time as the previous step do, or start a lot of handlers if the payload is a kind of
bind_*or others. That depends on the type of payload. At last, we execute the main exploit code. That's a basic procedure in my brain, I did not describe some other stuff in detail.I am not a good coder and know little about design patten, I am afraid that I would mess up the beauty of
Metasploit framework. It's better that some employee in R7 to do it, but if others are not interested in this, I would do it when I am free.Thanks for your suggestion.