Lessons Learnt summary

Lab blue
Main goal Get hands into Metasploit, and exploit EternalBlue on Windows 7 machine
Pitfalls to avoid
  • The EternalBlue nmap script was not run, as not being part of -sC since it is a vuln script
  • The IP used by Metasploit was the LAN one (192.x.x.x) instead of the VPN one (10.x.x.x)
  • Shell2Meterpreter post exploit was either very slow (network?) or not highly reliable

The lab details


Like always, don't forget to do the reconnaissance on the system

With -sC you will have the default scripts run, not the vuln ones.
The EternalBlue script is a vuln one, so you will need to run it either specifically, or using broader --script vuln

To see that the device is vulnerable, the EternalBlue script must be run specifically

Or use the "vuln" group of scripts, which is not part of "default" (-sC)

EternalBlue exploit using Metasploit

From there, it's easy to start msfconsole and load the proper module for MS17-010

Set the RHOSTS option, which btw can be defined at run with run rhosts=10.x.x.x

You may look for payloads as suggested by the lab
The lab wants you to do that so you can give a look later on at how to move from regular shell to meterpreter shell

But that failed continuously

The next day (it was late enough, so I needed a break, hence the IP change) it was still failing

Then I noticed that LHOST was incorrect: Metasploit used the WLAN IP (192.x.x.x) instead of the VPN IP (10.x.x.x). Once properly set, the reverse shell popped in

When running a Metasploit exploit in the TryHackMe labs, don't forget to check the local host IP, as it may be the LAN one instead of the TryHackMe VPN one. I think I lost quite some time because of that…

Leverage from shell to meterpreter

Since lab made you change the default payload, you need to post-exploit to get a meterpreter shell

Easy to use, but don't forget to session ID to set (see sessions command)

Meterpreter will have much more commands than the regular shell, hence why we try to leverage to it

Likely than for the exploit itself, you'll need to check the LHOST value

The post exploit may be slow. Be patient. I wasn't. Hence why the terminal is a mess here!

You may setg LHOST 10.x.x.x so you don't have to define this option on every module: it will be globally set (hence the "g")

I'm not sure if it was the network or my lack of patience, but I ended up with several meterpreters and lots of them died (how sad!) afterward without being properly opened.

Trying the "non-opened" sessions (3rd here) will likely fail or hung. The 7th session here is the opened one, as we can see in the "Information" column, so I've used that in the end

The ps command now works and so does getpid, so we can see we already are in a process which is SYSTEM

Use migrate PID otherwise, or give a shot at other commands from help

Get passwords

hashdump now works, since the session is not stuck. I was running to try cracking it with hashcat, but, that laptop has no proper hardware for this…

I've run hashcat on another machine, but I then don't have the screenshots

Note that here, I was heading to generic (weak) passwords. I wouldn't have found the actual one from this. It is recommanded to use the rockyou.txt passwords from the seclists package

In the hashdump result, first hash is LM (empty here) and second is NTLM (our target password). We don't need to crack the first one using hashcat, just the second one, so that's faster.


You may gather the flags from the specified locations using the lab's hints…

… or you can be a greedy hoodie dragon and search for flags in the whole disk

If you're not "root" (SYSTEM), then such search might not return results, as you may not have access to the folder where the flag is. Also, this would fail if flag was named user.txt or root.txt