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/documentation/modules/post/multi/recon/local_exploit_suggester.md
Views: 11786
The Local Exploit Suggester is a post-exploitation module that you can use to check a system for local vulnerabilities. It performs local exploit checks; it does not actually run any exploits, which is useful because this means you to scan a system without being intrusive. In addition to being stealthy, it's a time saver. You don't have to manually search for local exploits that will work; it'll show you which exploits the target is vulnerable to based on the system's platform and architecture.
The Local Exploit Suggester is available for Python, PHP, Mettle, Java and Windows Meterpreter.
Vulnerable Application
To use the Local Exploit Suggester:
You must have an open Meterpreter or shell session.
Verification Steps
Please see the Overview section.
Options
You can set the following options for the Local Exploit Suggester:
SHOWDESCRIPTION - Set this option to true to see more details about each exploit.
ValidateArch - This option lets us toggle whether or not a mismatch in session and module architecture should be validated or ignored.
ValidatePlatform - This option lets us toggle whether or not a mismatch in session and module platform should be validated or ignored.
ValidateMeterpreterCommands - This option lets us toggle whether or not Meterpreter commands that are missing from the current Meterpreter implementation should be validated or ignored.
Colors - Similar to the option used for
HttpTrace. This lets us change the colors used to show valid, invalid and ignored options or incompatibilities. Unsetting this option results in no colored output.
Scenarios
When the Local Exploit Suggester runs, it displays a list of local exploits that the target may be vulnerable to, and it tells the user the likelihood of exploitation.
It also tells the user why the check methods for some exploits did not complete successfully, allowing for easier debugging.
Furthermore, with the Verbose option turned on, a table is printed showing modules that were not considered as valid for the current session, and gives reasons as to why.
The following terms are used to help you understand how vulnerable a target is to a particular exploit:
Vulnerable - Indicates that the target is vulnerable.
Appears - Indicates that the target may be vulnerable based on the file version, but the vulnerable code has not been tested.
Detected - Indicates that the target has the file, but it cannot be determined whether or not the target is vulnerable.
Table Output
Valid Modules
This table is shown by default, and shows which exploits have had their check methods executed, and provides information on the returned result.
Below is an example of how this table could look:
When output to a terminal window with the Colors datastore option set, the table rows are highlighted appropriately based on the Check Result.
Incompatible Modules
This table is hidden behind the Verbose toggle.
It provides a list of modules that did not have their check method executed, and provides information as to why a module is not compatible with the current session.
Below is an example of how this table could look:
Note: In the table above, the session architecture is reported as x64. However, it is not considered as 'incompatible' as the ValidateArch=false option was used.
When the above is output to a terminal, the incompatibilities for a specific module (e.g. architecture or platform mismatch) are output in a different color if enabled with the Color datastore option.