Real-time collaboration for Jupyter Notebooks, Linux Terminals, LaTeX, VS Code, R IDE, and more,
all in one place.
Real-time collaboration for Jupyter Notebooks, Linux Terminals, LaTeX, VS Code, R IDE, and more,
all in one place.
Path: blob/master/docs/metasploit-framework.wiki/How-to-cleanup-after-module-execution.md
Views: 11766
On this page
Cleanup method
Metasploit has a handy cleanup
method that is always called when the module terminates, whether it is successful or not. This method can be overridden by any modules to add their own cleanup routines. For example, this might be useful to put some files back on the target after the module had deleted them. Another scenario would be to restore the settings in a web application that were modified by the exploit. This is the right place to clean things up.
Framework itself implements this method to disconnect connections, call the handler cleanup routines, etc. Some other mixins, such as the Msf::Exploit::FileDropper
(see the next section) or Msf::Exploit::Remote::Kerberos::Client
, override this method to add their own cleanup code. It is extremely important to always call super
in your cleanup
method to make sure Framework and any other mixins clean up themself properly.
Here is an example that restores a configuration file after being deleted by the module:
Here is another example of a cleanup
method that deletes a temporary Git repository:
FileDropper Mixin
In some exploitation scenarios such as local privilege escalation, command execution, write privilege attacks, SQL Injections, etc, it is very likely that you have to upload one or more malicious files in order to gain control of the target machine. Well, a smart attacker shouldn't leave anything behind, so if a module needs to drop something onto the file system, it's important to remove it right after the purpose is served. And that is why we created the FileDropper mixin.
The FileDropper mixin is a file manager that allows you to keep track of files, and then delete them when a session is created. To use it, first include the mixin:
Next, tell the FileDropper mixin where the file is going to be after a session is created by using the register_file_for_cleanup
method. Each file name should either be a full path or relative to the current working directory of the session. For example, if I want to upload a payload to the target machine's remote path: C:\Windows\System32\payload.exe
, then my statement can be:
If my session's current directory is already in C:\Windows\System32\
, then you can:
If you wish to register multiple files, you can also provide the file names as arguments:
Note that if your exploit module uses on_new_session
, you are actually overriding FileDropper's on_new_session
.