Once you've selected an exploit and a payload and set all the necessary options, running the exploit is the easiest part of the process. The exploit command takes all the settings you already made and tries out the exploit. If the target computer is vulnerable to the selected exploit and you set all the options appropriately, you will soon be rewarded with a remote shell, a VNC window, or whatever the output of your chosen payload happens to be. Here's some sample output from a successful exploitation of a remote Windows machine using the ms03_026_dcom exploit and the windows/vncinject/bind_tcp payload:
msf exploit(ms03_026_dcom) > exploit
[*] Started bind handler
[*] Trying target Windows NT SP3-6a/2000/XP/2003 Universal...
[*] Binding to 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57:0.0@ncacn_ip_tcp:yakima[135]
[*] Transmitting intermediate stager for over-sized stage...(89 bytes)
[*] Bound to 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57:0.0@ncacn_ip_tcp:yakima[135] ...
[*] Sending exploit ...
[*] Sending stage (2834 bytes)
[*] Sleeping before handling stage...
[*] Uploading DLL (340049 bytes)...
[*] Upload completed.
[*] Starting local TCP relay on 127.0.0.1:5900...
[*] Local TCP relay started.
[*] The DCERPC service did not reply to our request
[*] VNC Server session 2 opened (10.150.9.46:56861 -> 10.157.6.231:4444)As the exploit runs, it displays (usually) useful debugging information to the console. The final message printed informs us the exploit was successful and a local VNC relay is waiting for our VNC client to connect. By pointing our VNC client to port 5900 on our local IP address (127.0.0.1), we see the login screen of the remote Windows machine as shown in Figure 7-4.
Sometimes (in fact quite often if you don't do your homework in advance) the exploit fails. Sometimes the exploit process will hang for minutes and eventually timeout. Other times you'll get a failure message back immediately. Here's an example of a failed attempt to use the ms05_017_msmq exploit:
msf exploit(ms05_017_msmq) >exploit[*] Started bind handler [*] Trying target Windows 2000 ALL / Windows XP SP0-SP1 (English)... [*] Binding to fdb3a030-065f-11d1-bb9b-00a024ea5525:1.0@ncacn_ip_tcp:yakima[2103] ... [*] Bound to fdb3a030-065f-11d1-bb9b-00a024ea5525:1.0@ncacn_ip_tcp:yakima[2103] ... [*] Sending exploit ...[-] Exploit failed: DCERPC FAULT => nca_s_fault_ndr
There are many reasons why an exploit can fail. A few possibilities and potential solutions are:
- The target computer isn't vulnerable to the exploit due to a patch, its configuration, etc.
Unless you can somehow convince the owner of the target computer to reconfigure the vulnerable software or remove the patch they've applied, you're out of luck using this particular Metasploit exploit. Try picking a different exploit or a different target.
- The target computer isn't running the software you're trying to exploit
As with the above cause of failure, unless you can trick the computer's owner into installing the vulnerable software, you'll have to try something else. The good news is that Metasploit has dozens of exploits to pick from.
- A firewall is blocking access to the network port you're connecting to
Some exploits can work over multiple ports. For example, some SMB vulnerabilities can be triggered via ports 139, 445, or 1025+. There's a chance the firewall is blocking some, but not all, of the potential ports—so trying a different port might work. If you're using a browser exploit and the user is connecting back to you, you can select any port you want and cherry-pick a port that is most likely to be allowed through the firewall policy.
- A host or network IPS is detecting and stopping the exploit
It can be hard to determine whether an IPS is blocking your attack, but if you suspect one is present, you can play with the Metasploit evasion options (see Sample Evasion Output) to try to trick the IPS into letting your attack through.
- The payload variant you've selected is failing for some reason
Sometimes certain exploit/payload/target combinations simply don't work, even though by all rights they should. Despite the fact that Metasploit makes exploitation look easy, it's actually quite complex, and sometimes things just don't work. If you're reasonably sure your exploit should be working, try different payloads and payload variants. One of them may work where others fail.
- One of the options necessary for the exploit has an improper value
Some exploits and payloads provide a large number of options to set; while Metasploit attempts to fill in sensible default values, there's no guarantee that they're appropriate to your environment. Try setting various options to alternate values that make sense based on your understanding of the situation. This is yet another reason that performing thorough reconnaissance (see Chapter 2) prior to exploitation is a good idea.
- The target computer is technically vulnerable but is currently in a state that prevents exploitation
Some vulnerabilities can be triggered over and over again reliably, but others can only be triggered once before a reboot is required to return things to a vulnerable state. Even "reliable" vulnerabilities can eventually start to fail as exploit after exploit leaves the process in a more and more damaged state. If you end up in this situation, you can either wait for the computer's owner to reboot the machine or try to force a reboot using some form of DoS attack.
- The target computer is behind a NAT device
It is very common for computers on the Internet to connect through a NAT device (see Chapter 13). In this case, while the target computer will be able to make connections to your IP addresses, you will likely be unable to establish your own connection to it. In this case, you should make sure you're using a
reverseorfind_tagpayload variant; otherwise, the exploit will almost certainly fail.