RFC: establish a separate module category for persistence modules

[bcoles]

Summary

We have a lot of modules to establish persistence (and will likely gain more: #16791 #19359).

# find modules/ -name *persist*
modules/exploits/unix/local/at_persistence.rb
modules/exploits/osx/local/persistence.rb
modules/exploits/windows/local/persistence.rb
modules/exploits/windows/local/persistence_image_exec_options.rb
modules/exploits/windows/local/registry_persistence.rb
modules/exploits/windows/local/s4u_persistence.rb
modules/exploits/windows/local/persistence_service.rb
modules/exploits/windows/local/ps_persist.rb
modules/exploits/windows/local/vss_persistence.rb
modules/exploits/windows/local/wmi_persistence.rb
modules/exploits/linux/local/apt_package_manager_persistence.rb
modules/exploits/linux/local/autostart_persistence.rb
modules/exploits/linux/local/rc_local_persistence.rb
modules/exploits/linux/local/service_persistence.rb
modules/exploits/linux/local/motd_persistence.rb
modules/exploits/linux/local/bash_profile_persistence.rb
modules/exploits/linux/local/cron_persistence.rb
modules/exploits/linux/local/yum_package_manager_persistence.rb
modules/exploits/multi/misc/persistent_hpca_radexec_exec.rb
modules/post/windows/manage/persistence_exe.rb
modules/post/windows/manage/sshkey_persistence.rb
modules/post/linux/manage/sshkey_persistence.rb

Although the modules are consistently named *_persistence*, the categorization is inconsistent - sometimes as post/<platform>/manage/, but usually within the exploit/<platform>/local/ directory.

Almost all of these modules establish persistence by creating a new session at an unknown time in the future. These are not exploits - they are post-exploitation modules more akin to management post modules.

Persistence modules were previously classified as local exploit modules as traditionally any module which could result in a new session was considered to be an "exploit" module; however, this old practice has been repeatedly undermined and the definition is no longer useful. For example:

• Evasion modules return a session
  • these modules are not classified as exploits, but they effectively operate the same as file format exploits (like exploit/<platform>/file/ modules) and return a session
• Management post modules return a session
  • modules/post/multi/manage/shell_to_meterpreter.rb returns a session
  • modules/post/windows/manage/persistence_exe.rb returns a session (There is an open issue to convert this module to an exploit module #18053)

Is it useful to separate persistence modules into a separate category/subdirectory?

Basic example

• Move persistence modules to modules/post/<platform>/persistence/ ?
• Move persistence modules to modules/exploits/<platform>/persistence/ ?
• Move persistence modules to modules/persistence/<platform>/? (with a new Msf::Persistence class?)

Motivation

Although there is no real harm in leaving persistence modules in the local exploit category, the typical use case for persistence modules is sufficiently different to exploit modules that a separate category may be desirable to eliminate ambiguity.

Once segregated, exploit/<platform>/local exploits will be local exploits only:

• Persistence modules can be more easily found should the operator wish to maintain persistence on a host.
• Privesc modules can be more easily found should the operator wish to elevate privileges on a host.
• Persistence modules will not be selected and tested using the Local Exploit Suggester module, which is intended for local exploitation (ie, privilege escalation).

Additionally, as most exploit modules within Framework return a session immediately, where as persistence modules return zero or more sessions at an unknown time in the future, segregation may be beneficial to facilitate intuitive handler workflows. For example, persistence modules could be configured with default module options to launch backgrounded long-running session handlers.

[h00die]

agree with this.

[jvoisin]

I think modules/persistence/<platform>/ makes the most sense.