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

[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.