Exploit completed, but no session was created

I have tried 4 different retired HTB challenges and have been trying to familiarise myself with all of the processes and tools and have come so close to completing them, but with 3 of them I get an error message after running ‘metasploit’.

The reverse TCP loads, each time, the script runs, but then I get to the end and get the dreaded line:

‘Exploit completed, but no session was created’

I have trawled Google and all I can see is maybe you’re not connecting to the right port, but when I ping the port I get a positive result. I am sure I am missing something tiny. Can anyone offer any help please.

Thanks

There’s a few basic things that it could be;
Make sure that your LHOST/SRVHOST is set to your vpn’s local address, or tun0:
If this isn’t set, most modules will use your default interface’s(usually eth0 or wlan0) local ip as the value.
You can get the IP with the ‘ifconfig’ command, if you’re using a kali virtual machine then and are connected to the HTB vpn then when you run the command you should see ‘lo’, ‘eth0’, and ‘tun0’. You want to use the inet value under tun0. Usually 10.10.. on HTB. Most modules support supplying just ‘tun0’ or whatever your vpn’s interface is labeled as.

Another thing could be your firewall. Check and see if UFW or whatever your firewall of choice is running, either stop it with ‘systemctl stop insert_firewall_here’ or set a rule that allows inbound connections on the port you’re trying to get a session on.

One other thing, some exploits have a tendency to mess up boxes, it’s entirely possible that whatever box you’re trying to get access to is foobar; So try resetting it.

Hopefully this helps :slight_smile:

which boxes or chall ?

@Laine thanks very much I will try those as soon as I can and let you know

@peek Blue and Lame both have the same issues

yeah very unstable machines, run many times your exploit, and reset.

Hey @albinomonkey,
Sounds like you are mixing up using staged and stageless payloads and listeners maybe.

Read this. ??

wrong post lol sorry

Type your comment> @Laine said:

There’s a few basic things that it could be;
Make sure that your LHOST/SRVHOST is set to your vpn’s local address, or tun0:
If this isn’t set, most modules will use your default interface’s(usually eth0 or wlan0) local ip as the value.
You can get the IP with the ‘ifconfig’ command, if you’re using a kali virtual machine then and are connected to the HTB vpn then when you run the command you should see ‘lo’, ‘eth0’, and ‘tun0’. You want to use the inet value under tun0. Usually 10.10.. on HTB. Most modules support supplying just ‘tun0’ or whatever your vpn’s interface is labeled as.

Another thing could be your firewall. Check and see if UFW or whatever your firewall of choice is running, either stop it with ‘systemctl stop insert_firewall_here’ or set a rule that allows inbound connections on the port you’re trying to get a session on.

One other thing, some exploits have a tendency to mess up boxes, it’s entirely possible that whatever box you’re trying to get access to is foobar; So try resetting it.

Hopefully this helps :slight_smile:

Thank you very much … it’s working :slight_smile:

Having the same issues here as well, and getting stuck on trouble shooting now. Wonder if anyone has suggestions.

Have tried on both Lame and Legacy.

Ran an nmap and returned the correct expected ports on both of these boxes. I can even access Lame file share with anonymous credentials.

But, I then find the correct exploit for either box; Dont want to go spoiling it for everyone, so wont post exactly what exploit, but I 100% have the correct one for each box and an updated metasploit-framework. And much the same for Lame; found the correct exploit, checked multiple sources, are the ports open etc.

Set the RHOST to either 10.10.10.3 or 4 depending on machine. LPORT is defaulted to 4444 but have tried various others suggested online. Auto payload, but have tired running various payloads. And each time I get “Exploit completed, but no shell was created”.

I have tried restarting machines, been through that 3-4 times for both Lame and Legacy.

I am running on VMware Workstation, Kali Linux version 2020.2 on a wifi connection. Firewall is set to default within Windows Defender.

If someone could suggest something I would be grateful.

I ran into this problem just now on Lame as well and was able to figure it out. My guess is the actual exploit itself has changed since the walkthroughs were written, or else maybe my metasploit somehow was different.

Anyway, it appears the exploit did not have a payload specified, or else maybe had a generic payload specified. I did some Googling and found how to select and specify a payload using (withing metasploit) “show payloads”. This will list the payloads which are compatible with your selected exploit. Then I just tried a few until I found one which worked. Note that you may need to define certain additional options once you’ve selected a payload, such as LHOST and LPORT. Just type “options” after choosing your payload and it should show what you need to define.

Hope this helps.

Type your comment> @peek said:

yeah very unstable machines, run many times your exploit, and reset.

The last probably 10-15 machines I did, never had one doing what you describe.
The machines can be slower at times, but haven’t experienced any instability or loss of shells. I love privesc, so sometimes I spend days on a box turning it inside out. Can’t recall one connection dropping from htb’s end. Maybe I was lucky, but considering the time I can spend in a shell, that’s a whole lot of luck in one place.

@albinomonkey if you have trouble getting outgoing connections, check with simple commands first that you know for sure you can reach your machine.

nc -nvlp 80 on attacker side and wget http://<my_ip>
or curl on the target side for example.
I haven’t came across an easy or medium box I think that blocked or limited outgoing connections.

Check your commands: simple stuff will trip you up the most, like forgetting to url encode, or just having a character wrong, not understanding your tunnel-ip.

If we think rationally: people have drawn first blood on the machines, a handful of people are rooting retired machines every day… but the conclusion would be that all 4 machines are broke?
I’ll bet my money that the commands are using are wrong or not suited for the setting in which you use them.

As a sidenote: my advice would be to stay away from meterpreter… Never understood what people see in it: when it work, it’s handy, but it’s so known that you hardly ever can use it in normal situations. I’d take a basic shell that works 99% of the times over any tool that doesn’t work half the times all day.

@gnothiseauton said:

Type your comment> @peek said:

yeah very unstable machines, run many times your exploit, and reset.

The last probably 10-15 machines I did, never had one doing what you describe.
The machines can be slower at times, but haven’t experienced any instability or loss of shells.

In defence of what @peek has put here, when he wrote it (Feb 2019), there were a fair few unstable boxes around - and a lot where the creators were, erm, mischievous with the box…

But certainly in the last six to twelve months I’ve never had a problem with any box - other than my own stupidity.

Which leads me to this:

Check your commands: simple stuff will trip you up the most, like forgetting to url encode, or just having a character wrong, not understanding your tunnel-ip.

I 100% agree.

If we think rationally: people have drawn first blood on the machines, a handful of people are rooting retired machines every day… but the conclusion would be that all 4 machines are broke?

Very, very good point here. I’ve been working boxes, on the same VPN as people, who’ve been complaining about instability while the box has looked perfect to me. ServMon was a good example of this.

I’ll bet my money that the commands are using are wrong or not suited for the setting in which you use them.

As a sidenote: my advice would be to stay away from meterpreter… Never understood what people see in it: when it work, it’s handy, but it’s so known that you hardly ever can use it in normal situations. I’d take a basic shell that works 99% of the times over any tool that doesn’t work half the times all day.

Also, agree.