Potentially useful Metsploit modules to run from/besides meterpreter:

  • post/windows/gather/checkvm — try to determine if we’re in a VM
  • post/multi/recon/local_exploit_suggester — find possible privilege escalation exploits (can be slow/unreliably on 64-bit architectures)
  • post/windows/gather/enum_shares — enumerate shares
  • auxiliary/scanner/smb/smb_enumusers_domain — enumerate SMB domain users (requires existing admin credentials)
  • post/windows/gather/hashdump — same as the hashdump command, but pushes the hashes into the Metasploit DB
  • post/windows/gather/smart_hashdump GETSYSTEM=FALSE — same as the hashdump command, but pushes the hashes into the Metasploit DB and ignores system accounts
  • auxiliary/analyze/crack_windows — sic John the Ripper or Hashcat on NTLM hashes stored in the Metasploit DB
  • post/windows/manage/enable_rdp — enable RDP access (requires admin privileges)
  • post/multi/manage/autoroute — manipulate target routing for pivoting
  • auxiliary/server/socks_proxy — start a SOCKS proxy
  • exploit/windows/local/persistence — sets up a persistent connection (you probably want to set STARTUP SYSTEM)… without a password!

NOTE

It is generally more useful to background meterpreter and then run these commands through the Metasploit console, as within meterpreter they need to have all options specified on the “run” command line (in the console you can access help, actually see what the options are, etc.).

There seem to be a lot of options for the post/multi/manage/autoroute and auxiliary/server/socks_proxy modules, but I don’t see a way to access them from meterpreter (it looks like to get help you need to background meterpreter and use the console).

The advantage of setting up a SOCKS proxy on the target is that you can then use proxychains to route through the target; this can allow you to pivot more deeply into the network that you’re attacking. (You probably want to create a custom proxychains.conf file to do this. Fortunately, /etc/proxychains.conf is well documented.)