Update to Pentest Metasploit Plugin
I recently update my Metasploit Pentest Plugin . I added 2 new commands to the plugin and fixed issues when printing information as a table. The update are small ones.
Lets take a look at the changes for the plugin. We can start by loading the plugin in a Metasploit Framework session.
msf > load pentest ___ _ _ ___ _ _ | _ \___ _ _| |_ ___ __| |_ | _ \ |_ _ __ _(_)_ _ | _/ -_) ' \ _/ -_|_-< _| | _/ | || / _` | | ' \ |_| \___|_||_\__\___/__/\__| |_| |_|\_,_\__, |_|_||_| |___/ Version 1.5 Pentest plugin loaded. by Carlos Perez (carlos_perez[at]darkoperator.com) [*] Successfully loaded plugin: pentest msf >
The first update is so we can get a list of IP Addresses you can use for LHOST.
msf > get_lhost [*] Local host IP addresses: [+] 192.168.1.116
The code is very simple. It gets a list of IP addresses from the interfaces on the host and it filters out the loopback address for IPv4 and the IPv6 Link Local address.
def cmd_get_lhost(*args) opts = Rex::Parser::Arguments.new( "-h" => [ false, "Command help."] ) opts.parse(args) do |opt, idx, val| case opt when "-h" print_line("Command for listing local IP Addresses that can be used with LHOST.") print_line(opts.usage) return else print_line(opts.usage) return end end print_status("Local host IP addresses:") Socket.ip_address_list.each do |a| if !(a.ipv4_loopback?()|a.ipv6_linklocal?()|a.ipv6_loopback?()) print_good("\t#{a.ip_address}") end end print_line end
Those who have heard me talk in the podcast, listened to my presentation or taken any of my classes know I like proper tradecraft and a deep understanding of one tools. I added a command called check_footprint, the command will check you module for a list of API calls in post modules to check if the module may expose your action.
msf > check_footprint -h OPTIONS: -h Command Help. -m <opt> Module to check.
The -m option allows you to specify a post module or exploit persistence module, it supports tab complete for the full name of the module. Once specified it will check the module source code and it will let you know if uses API calls that may be logged by a defender. If you are under the context of a module you can run the command without specifying the module name and it will examine the current module you are under.
In the case that the module supports Shell type sessions it will warn you that all actions will be command line tools and actions may be logged.
The list of APIs is a simple one that can be extended. Here is the hashtable I use of APIs and the description of what possible negative footprint they will have on the target.
footprint_generators = { 'cmd_exec' => 'This module will create a process that can be logged.', '<client|session>.sys.process.execute' => 'This module will create a process that can be logged.', 'run_cmd' => 'This module will create a process that can be logged.', 'check_osql' => 'This module will create a osql.exe process that can be logged.', 'check_sqlcmd' => 'This module will create a sqlcmd.exe process that can be logged.', 'wmic_query' => 'This module will create a wmic.exe process that can be logged.', 'get_whoami' => 'This module will create a whoami.exe process that can be logged.', "service_create" => 'This module manipulates a service in a way that can be logged', "service_start" => 'This module manipulates a service in a way that can be logged', "service_change_config" => 'This module manipulates a service in a way that can be logged', "service_change_startup" => 'This module manipulates a service in a way that can be logged', "get_vss_device" => 'This module will create a wmic.exe process that can be logged.', "vss_list" => 'This module will create a wmic.exe process that can be logged.', "vss_get_ids" => 'This module will create a wmic.exe process that can be logged.', "vss_get_storage" => 'This module will create a wmic.exe process that can be logged.', "get_sc_details" => 'This module will create a wmic.exe process that can be logged.', "get_sc_param" => 'This module will create a wmic.exe process that can be logged.', "vss_get_storage_param" => 'This module will create a wmic.exe process that can be logged.', "vss_set_storage" => 'This module will create a wmic.exe process that can be logged.', "create_shadowcopy" => 'This module will create a wmic.exe process that can be logged.', "start_vss" => 'This module will create a wmic.exe process that can be logged.', "start_swprv" => 'This module manipulates a service in a way that can be logged', "execute_shellcode" => 'This module will create a thread that can be detected (Sysmon).', "is_in_admin_group" => 'This module will create a whoami.exe process that can be logged.', "upload_file" => 'This module uploads a file on to the target, AVs will examine the file and action may be logged if folder is audited.', "file_local_write" => 'This module writes to a file or may create one, action may be logged if folder is audited or examined by AV.', "write_file" => 'This module writes to a file or may create one, action may be logged if folder is audited or examined by AV.', "append_file" => 'This module writes to a file or may create one, action may be logged if folder is audited or examined by AV.', "rename_file" => 'This module renames a file or may create one, action may be logged if folder is audited or examined by AV.' }
I do plan on expanding the list and descriptions as time passes.
I hope you find these small changes also and that the check_footprint command makes you take in to consideration what actions modules are taking when executed that depending on the security posture of a target could get you detected if you are a Red Teamer. If you are in a Blue Team this may help you fine tune your detections and give you ideas of what behaviours to look for.