Blue - TryHackMe — Devblog de Xenos

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
CTF files	💾 The files of this lab's writeup are available here

The lab details

Reconnaissance

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

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. That's 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.

Flags

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