Apply exploits to RHOSTS instead of RHOST

[timothyleung]

I think it will be great to have a module that can accomplish this in a generic way.
For example, the options that the module should take are:

1. GenericExploit
2. RHOSTS

I am thinking about extending either Auxiliary class or Exploit class to accomplish this. It will be great if you can give me some ideas on what do you think on this issue.

The difficulties here is different exploits have different options. We will create a new_module with a module called generic_exploit. Then user can do the following:

1. use new_module/generic_exploit
   • UI manual will pop up with two options (GenericExploit and RHOSTS)
   • user type in set GenericExploit exploit/windows/smb/psexec
   • RHOSTS 192.168.0.0-250
     We will need a new command here to call the extended class. Let say we create a new command called extend.
2. User will then type extend

• And the usual UI for exploit/windows/smb/psexec will pop up with RHOSTS instead of RHOST, our extended module will override this behaviour when extend command is being called.
• Then if user type run, it will execute the run from the extended module.
• The run in the extended module is basically the same but it will go through all the IPs in RHOSTS instead
  for i in ips:
  super.run() // this is calling the exploit chosen by user and run by calling super

I reckon this is feasible and does not require a huge amount of effort. I am not sure about adding a new command to metasploit is a good idea or not. So I am happy to hear your opinion.

Thanks.

[wchen-r7]

I like this idea, I've always wanted it too. However, this would be a challenge for the current architecture considering the handler is meant to receive only one type of payload by default.

For example, if you have a multi-platform exploit that targets Windows and Linux, and that a cross-platform payload isn't an option, your exploit would only work one of those platforms.

Also, some modules may require the user to tweak the settings based on the target or platform they're attacking.

There might be other challenges I haven't thought of, I think @egypt is good candidate to bring in this conversation.

[bcook-r7]

@wchen-r7 we are working on an actual 'Multi' handler for Meterpreter payloads - see the work that @OJ is currently engaged in.

I do believe that, even if we didn't have that, that this feature would still be useful much of the time.

[wchen-r7]

@bcook-r7 Did you guys want to add the RHOSTS feature within the scope too? Or separate?

[timothyleung]

Im thinking about using some OOP design. I will have a look at it and suggest some solutions.

[egypt]

As @wchen-r7 alluded to, this would require a major architectural change. The handler is not the only problem. Payload settings and TARGET are also dependent on the victim and many exploits cannot know which target to select.

If the handler problem is solved, it may be possible for something like this to work for some exploits, or even classes of exploits, but I don't think it's possible to generically work for all exploits.

[0xIslamTaha]

is there any update on this issue?

is there any way to set rhosts and loop over them trying to exploit or not?

[busterb]

one-liner RC script that does what you want for now:

<ruby> framework.db.hosts.each do |host| {self.run_single("set RHOST #{host}"); self.run_single("exploit");}</ruby>