persistence suggester

[h00die]

Part of #20374

Creates a persistence suggester, similar to local exploit suggester, which suggests which persistence mechanisms to use. It only works on persistence which has been updated to use the mixin, so testing on osx/windows right now won't yield many results, but linux is pretty good :)

Verification

• Start msfconsole
• get a shell/meterp on a box
• post/multi/recon/persistence_suggester
• set session #
• run
• Verify persistence mechanisms are suggested
• Document looks good

[adfoster-r7]

What are your thoughts on enhancing the vulnerable column to treat the check codes a bit differently (we can update the exploit suggester later too if that makes sense as well)

      Msf::Exploit::CheckCode::Vulnerable => Verified
      Msf::Exploit::CheckCode::Appears => Yes
      Msf::Exploit::CheckCode::Detected => Yes
      others => No

[h00die]

I don't believe any persistence module actually returns Vulnerable, they should all be Appears, Detected, and Safe. Since most of them rely on an event (user click, service restart, box restart, etc I think its unlikely that a module would actually exploit it to prove Vulnerable

[msutovsky-r7]

I think there are some Windows persistence modules, which do return Vulnerable - e.g. registry_persistence.rb. In any case, maybe the acceptable modules should be sorted according to their check codes? Maybe something like Vulnerable > Appears > Detected ?

[h00die]

windows persistence is a nightmare at the moment. I tried to unclutter it and gave up, @dledda-r7 also tried, and its just a jumbled mess of bleh. several modules overlap, there aren't clear boundaries etc.

[h00die]

regardless, i mean that sounds fine

[h00die]

I think we should table this change and make it across all *_suggester modules at once. Currently we're keeping consistent behavior which is good for users, and we'd want to be consistent (regardless of shared code) across the modules.

[dledda-r7]

I don't believe any persistence module actually returns Vulnerable, they should all be Appears, Detected, and Safe. Since most of them rely on an event (user click, service restart, box restart, etc I think its unlikely that a module would actually exploit it to prove Vulnerable

That exactly the issue I raised during our internal call that created this comment from @adfoster-r7, I believe having a check that separates Vulnerable and Appears / Detected however could bring some benefit.

Besides that, regarding Windows, I think the next steps should include the creation of GitHub issues per-module whenever we find that they either doesn't work (at all or as expected) and if two modules overlap functionalities.

Then we can decide either to drop them (if not fixable) or to fix them or merge them/remove duplicated code.

I wouldn't wait for the windows modules to be all sorted before landing this exploit suggester PR honestly as it probably will require some internal workload from R7 side and I am not too sure we have current rounds to work on it.

[adfoster-r7]

Would it be worth while consolidating any code between the persistence suggester and local exploit suggester? Just worried about future folk fixing bugs in one but not the other 🕵️

[h00die]

agreed, @bwatters-r7 at one point said consolidate to a lib once there are 3 instances, so I've used that as my metric.