Hi all!
New to HTB and to the world of cyber security. I have been doing plenty of research on metasploit and all that good stuff. Felt confident enough to begin testing what ive learnt on HTB. I started with the ‘Lame’ machine, but to no avail sadly. I did some recon and found that the super simple exploit for vsftp 234 and decided to start this on metasploit. I set up the options correctly and fired away! Was gutted when it came back that a session could not be created. it attempted to make a session then asks for USER 331 password, before then explaining exploit completed but no session created.
I have no idea what im doing wrong here? I checked the walk through after and it seems they did the same thing but with success?
Any help or advice would be greatly appreciated !
With Metasploit, a failed session is often down to some common issues:
- incorrect IP address for the LHOST (remember it needs to be your HTB one, not your normal network one)
- incorrect payload
- local security controls (firewall or AV)
- something no longer working.
The last one is really common with older boxes. Components are often being updated/modified and exploitation is literally doing something which isn’t supposed to be done. This means that what worked in (say) 2017 version of MSF, might no longer work in the 2020 versions.
I dont have a good answer though, because it could be many things. If you can share some more details it might be easier to help.
I have done Lame like month or two ago and I couldn’t manage to exploit vsftp too. Either with metasploit(various versions and payloads) and “manually” but there is another way (another service) to get in the box. But as TazWake said, there maybe other reasons to this.
Thanks for your comments guys really helps me out.
I am going to work on what you have advised tonight, will update on this thread if any of the above works!
Much appreciated again
Thanks for you help!
Managed to own the Legacy machine.
I had my LHOST badly configured.
stoked on my first root own!
Am i the only one who attacked it through 3632 that was open? I looked through several walkthroughs afterwards and there was no mention of this port anywhere., (including the pics of their nmap scans)
Type your comment> @NetIceGear said:
Am i the only one who attacked it through 3632 that was open? I looked through several walkthroughs afterwards and there was no mention of this port anywhere., (including the pics of their nmap scans)
Я тоже нашел этот порт и атаковал через него.
Type your comment> @NetIceGear said:
Am i the only one who attacked it through 3632 that was open? I looked through several walkthroughs afterwards and there was no mention of this port anywhere., (including the pics of their nmap scans)
Hey, I attacked the same port but was not able to priv esc.
I dont recall ever seeing that port open.
Type your comment> @TazWake said:
I dont recall ever seeing that port open.
I was very surprised by it myself (actually I’m glad @Rjmoscow saw it too, and I wasn’t the only user this happened to), especially given that it isdistccd that’s running on that port.
The distccd exploit was brutally simple (the metasploit module dates back to 2002), but this was because of what the distcc daemon actually exposes. Seeing the port open and the vulnerability exposed sort of made sense in terms of it being the first machine of the first clickable track on the tracks page.
However, after NOT seeing it mentioned in any of the write-ups (especially the nmap scans) suggests that distccd happened to be running on this machine only because someone started it , as distccd can actually be started as user, and allowed clients configured with the --allow option.
Note: distccd is a compiler that lets you “share” unused processing power of a machine thats inside of a cluster .