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)
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…
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
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
