A Review of TryHackMe’s Throwback Lab

We will be reviewing my thoughts on Throwback, an Active Directory / Windows lab with multiple domains. I will also include my black box approach to going through the lab and how I think one should use the lab for learning.

The quick no BS Summary

Per TryHackMe, “Throwback is an Active Directory (AD) lab, that teaches the fundamentals and core concepts of attacking a Windows network”. They have sections on everything from phishing to AD enumeration, and some information about C2 frameworks.

Why I wanted to do the lab.

My reasoning for doing the lab was to improve my abilities when it comes to enumerating and finding footholds in AD environments, moving laterally in the environments and in the end compromising domains. Prior to completing this lab, I had completed the PWK (OSCP) Course, almost all the machines in their labs, and a ton of other boxes in proving grounds and Htb. I had also completed two other courses on Active Directory attacks and enumeration.

What I thought was good and not so good.

From a black box perspective, I enjoyed the lab. I thought it was mostly straight forward with a couple of side branches that I ended up not working on in the initial black box approach, but I went back and collected all the flags and went through all of the course material in the white box format. From an active directory attacks’ perspective, I thought the lab was limited and could have included more types of attacks to move from a domain user to the domain admin and then into controlling other domains.

Instead of more depth in the active directory area, it focused on enumerating to find hints about what one should be doing next, and stayed with the same general types of attacks like password spraying, dumping credentials / hashes, and then using pass the hash techniques to move laterally. There were some other attacks that you could find like kerberoasting, but you didn’t really need this to compromise the domain and it was more of a side quest.

Who should do the lab and how.

I would recommend the lab in general for someone who has done other courses, or has some experience and wants to use it as a test in your thinking process from a black box approach, but I wouldn’t recommend it as one’s first experience as a white box approach. It won’t hurt you to do it as a white box approach, but from my experience I found other materials I have done to be more thorough on the actual AD parts. To me it shined in making me work through and see where I might get stuck using previous knowledge effectively. It is also important to note that this was, from what I know, the first larger lab like this, done by Tryhackme, and so it was I believe a learning experience for those that built it as well.

Getting Started with the Black Box Approach

The introduction didn’t make it clear where to start, but I think the best approach is to treat it like a penetration test, where you know you have an assigned scope of addresses in the 10.200.x.0/24 range with VPN access. Everything inside that scope is free game to attack with the goal of compromising any domains present.

Locating the First Targets

Starting off the enumeration with NMAP to see what hosts were available. Once we have a list, we can use it to collect more information. There were 3 hosts that we can further enumerate 10.200.70.138, .219, and .232.

Using script and version scanning with NMAP for the 3, allows us to determine the operating system and services information for the hosts. Let’s take a look at what we found on each host and then give a quick summary of our thinking.

Host 10.200.70.138 – A PFSense Firewall

Review of the .138 host showed it had port 80 redirecting to port 443, and port 443 looked like it was a PFSense login page.

The login page verified that it was a PFSense device. Let’s move to the next device and after determining what all 3 hosts are, we can come back to this one.

Host 10.200.70.219 – A Windows IIS Server

This host showed up as a windows box running IIS, but also oddly has SSH running. It also provides us the domain name, we are dealing with “Throwback.local”.

IIS was running a company site for a security company “Throwback Hacks”. After we look at the last host, we will come back and dig into the website.

Host 10.200.70.232 – Web Mail

This was a linux host that also had port 80 open and was showing port 143 and 993 open for Dovecot.

Reviewing the web site gave us our first big break. The server is running web mail of some kind, and on top of that they were nice enough to provide credentials for guests. Presumably we are on an internal network, and given that they think it is safe to leave the guest credentials exposed.

A Summary after our initial look at each host

We haven’t went in depth on any host yet, but we can put together a quick summary of thoughts and what actions we want to take next.

PFSense

The PFSense firewall usually has brute force protection by default. We can review its log in page and try to determine a version, but there probably aren’t any unauthenticated vulnerabilities. Next, we will do a quick “password attack” with known default credentials. After that, we will take a quick look at exploitDB for any known vulnerabilities. If none of that turns anything up, we will move to the next host. If we turn anything up, we will note it and work through the other hosts.

IIS

On the IIS server we will go through the company site and pull out any useful information we can find, review the source and see if there might be a vulnerable framework being used, and depending on what we see we can check exploitDB again. There is also a chance the host has a file share, so we can check that before moving to the last host.

Web Mail

The Web Mail is really interesting since we probably have credentials to log in. We can review the source of the page, see if we can identify any version information, check for known exploits and then use the guest credentials to log in. Once we log in, we will likely find useful information.

A Deeper Look at Each Host

The PFSense Firewall

I went through the web page source code to see if I could identify the version number the firewall was running, but didn’t see anything indicating it. I also took a quick look for any known vulnerabilities with ExploitDB and found some RCE vulnerabilities depending on version, but they were authenticated. That left one option on our list, and that was try to log in.

I went to the documentation for the firewalls to get default credentials, and was able to log in. The devices use admin:pfsense for credentials.

After logging in, we took a look around the interface to see if anything stood out as exploitable.

In the interface of the device we find a diagnostics tab, that has a Command Prompt label.

When we check out the web interface for a command prompt, we find out we have the ability to upload files or run commands on the device. We checked what privilege level the command prompt was running as with “whoami”, and then tried a simple OpenBSD style reverse shell to see if we could get on the system.

The Command Prompt runs as root.

Here we are calling back to our host on port 443

If I think I will end up with multiple sessions, I like msf multi/handler for reverse shells. After our listener was set up and the command executed, we got our callback.

Reviewing the device we found a root flag and then found another flag hidden in the /var/log directory. There was also a login.log file here that had more useful information in it.

The file had a username and a password hash, that looked like it might be a NTLM hash.

Instead of cracking the hash myself I just used crackstation to see if the hash was already known. We ended up getting credentials for this user that might come in handy. If this had been a real user, I would have just cracked the hash on my local rig with hashcat. If we try Crackstation or another site and don’t have luck, we can always try to crack it with hashcat and a mutated word list to get credentials.

That was the last information we found, that was useful on the system, so we made a note of it and moved on to the next host.

The IIS Server

We are just going to look at the web site for now, and we will come back to this host and look at other options later.

Reviewing the website provided a couple pieces of information. The main page said that it was a security company that did red and blue team work, there was an Email address “hello@TBHSecurity.com”, a contact form we can use, and some key employee names.

We can make a note of these employees and might want to phish them in the future, or maybe do a password spray attack.

One more thing to think about with this site is the icons in the lower left corner for social media. We know the company name, and now have two separate domains, we know of the throwback.local and TBHSecurity.com. It isn’t shown here, but at this point I would also want to take a look at the company on social media and see if there was any useful information. In this case and a real case there probably is, but it isn’t required at this point to move forward.

After this host, we have the credential we found on the firewall, and we have some more usernames, and another domain name. We can check out the email host next, and after that, we can decide our best course of action.

The Web Mail Host

The Guest credentials that we found earlier work to log into the webmail. There is a single Email in the guest mailbox, indicating that the account is a shared account, and for use by guests who need email during their visit.

The best thing in the web mail is an address book, that looks like it has emails for a large number of users. One other note on the Email Addresses, they are all for the throwback.local domain. We know we saw another Email on the company website for the TBHSecurity.com domain.

For future use, I copied the email and username information out to a text file, and then reformatted it a bit so I would have an easy way to get usernames or emails if I needed them for a tool.

Here we are just showing how easy it is to format the text we saved.

Quick thoughts after our review of the 3 hosts

We have one set of credentials that we think belongs to the domain, usernames for key figures in the organization, and access to a domain email account that has an address book containing a large number of domain member addresses.

My first option I am going to take, is using the credentials for HumphreyW that we found, and seeing if we can gain access to either of the machines we haven’t accessed so far. If the credentials turn out to work, we will also try to collect more information with them (maybe domain shares, users, groups etc.).

When we finish with those credentials, we will try to get the domain password policy and see about a quick password spray that won’t lock any accounts. Depending on the results, we can circle back and try to use any new credentials.

Failing any progress there, we will resort to using the guest email account for a phishing attack.

Testing the HumphreyW user against .219 (Throwback-PROD)

Starting off we checked SSH login because it was showing an open port, then used crackmapexec to test SMB and WIMRM access. We saw that the credential was valid with SMB, but failed with both WINRM and SSH. For good measure, we also tried RDP, but didn’t gain access.

Since the credentials were good for SMB access, I went ahead and checked for any available shares with smbmap. We found that we had access to read the “Users” share.

One nice part about smbmap is, that we can use the -R switch to let it spider down through the directories we have access to, and make it easier to identify interesting files. When we did this we found that in the humphreyw users how directory, there was a .ssh directory with a keys and an authorized key file.

The key was downloaded, permissions were set to 600, and we tested log in with the SSH private key, but to our disappointment we couldn’t get logged in with the key. As a side note, after compromising this box it looked like the SSH configuration file was set up to only allow admin user keys that are stored in a different location.

Testing a Password Spray against the Web Mail

At this point our focus shifted to our options using the mail server. First we decided to create a list of users and credentials, so that we could test logging in with the known users. It is risky to run a significant password attack here, as we could risk locking out a number of accounts, so we take a list of 5 common passwords.

Carrying out the attack here requires a little more information and in order to get that we want to use a web proxy to intercept the requests when we submit credentials. I used Burp for this. Here we were forwarding to Burp (although somehow I didn’t screenshot it) and intercepted the request. I used a known bad username / password so I could also identify the error message we would set with hydra.

When we intercept the request, we get this information that shows us where we have to send the post request, and the payload that we need to use to send the login information.

Using hydra, we ended up with 5 credentials that showed as valid for the Web Mail. For good measure we tested the humphreyw credential, and found them to also be valid.

All of the Email accounts were reviewed for interesting information, but only a single user actually had any Email. (That isn’t 100% true, but the rest of the Emails on the system had been sent by other lab users who were trying to conduct a phishing attack.) The important Email indicated that there was a timekeep server on the throwback domain, and that password resets needed to be done. We didn’t have access to the server at this time, but based on the format it looked like we would be able to use this link to change any users password. Something to keep, in case we end up needing it.

The last thing before moving on from this was to take the new credentials we tried against the webmail, and give them a quick try against the .219 (Throwback-PROD) host. We used CME for the attack, and found one disabled account, but no luck with a valid login.

Without a lot of options left, it was time to move on to using the webmail accounts we had access to, to conduct a phishing attack and try to get access to someone’s system.

The Phishing Attack and Our Foothold

To set up the attack with needed to do 3 basic tasks. First, make a payload for the attack, set up our listener to get a callback, and last, send out the actual attack and hope for the best.

Generating the Payload

Generating a quick payload with msfvenom allows us to get something without much work, but in reality this isn’t going to work with systems running updated AV. With that said, there are a good number of articles around, that can show how to modify your payloads, if you really need to defeat basic AV.

Since we are using a Meterpreter payload, we are going to need to use the msf multi/handler to catch the callback. Under the multi/handler, we just need to set the correct payload, host, and port. At that point, we can run the handler and it will be ready when needed.

Now we just use the mail system, that we gained access to earlier, to send a quick mail, requesting that everyone use our attacked payload to install a security update due to a recent Microsoft vulnerability. With a little luck, we get someone to execute the payload. Of note here is that we made an executable payload and just labeled it update.exe, because everyone likes to execute stuff.

After a couple of minutes waiting, we got a callback from a host and started reviewing the access we had gained. We can see below gained access under the user BlaireJ.

Here, we dropped into a shell and started checking our privileges. It is cut off at the bottom, but just from checking, we can quickly see that we have administrator permissions and are not being restricted by UAC. I see this as OK, as a “Beginner” lab, or as labeled by THM “Intermediate”. They are not necessarily looking to test your ability to elevate privileges, to system or deal with a lot of AV avoidance, or to bypass UAC. (Although there were multiple hosts running AV including the one we landed on here.)

Initially, I was going to set up a service with msf to callback, if the connection was lost, or the PC was rebooted. I found, when I tried, it failed to provide a callback. So, the lesson here is, enumerate the security controls before trying. I had wrongly assumed, because the system didn’t stop my initial shell, that it wasn’t using AV. It was. This is easily verified by checking with PowerShell from our established session.

I went ahead and used the Meterpreter built in ability to dump hashes, and then went about looking for the root and user flags that each box in the lab has. I also collected basic information on the host.

Without throwing up 100 screenshots, we found out the host was Throwback-ws01 (a web server) at IP 10.200.70.222, and we hadn’t been able to reach this host from our attacker machine. Because it was a new level of access into the network, I also checked the ARP table, and found another host we hadn’t seen before the 10.200.70.117. This other host ended up being a domain controller.

A quick note about attacking deeper into the network

In this case I didn’t do it, but since we were running Meterpreter, and running MSF, we have the ability to just set up routes over the session, and then use this host as a proxy to attack deeper into the network. In this case I decided to take another path and use a dynamic SSH proxy.

If we have system level access and meterpreter, we can just dump hashes from the box.

Here are the hashes we got off the system.

As a general principal, everything we do is like a closed loop process. Each time we make progress and get information, we circle back to previous steps to see if the new information has provided something we need to move forward.

Returning to the .219 host Throwback-PROD

With the new information from the web server, I went back to the original host we had looked at before, to see if we would gain any new access there, and be able to collect more information.

Using Crackmapexec is a quick and easy way to test credentials or hashes, to see if we have local administrator rights. If we test a hash with smb and get the (Pwn3d!) flag, we know we have local admin access, and can try to get a shell with PsExec. We can also change the smb option to winrm and test the credentials against winrm as well. In this case, we had access to both.

Since we have winrm access, it makes sense to just connect that way with evil-winrm.

A script on the box is supposed to teach people to listen to the network.

The really interesting thing on this box is a python script, that is being used to connect to hosts in the VPN address range. If you were to do packet captures, or run responder on your attack box connected to the VPN for a few minutes, you would get a connection from the host. This allows you to capture a hash that provides a login to this machine.

I didn’t really care for that and thought it would be more useful to have someone connect to a windows machine, and have permissions to run the Inveigh tool (or packet capture) from the machine to pull off this type of attack.

We had local administrator permissions on this box as well, and direct connectivity, so I used the lsassy module from CME to remotely dump credentials for later use.

As we can see above, we actually got a clear text set of credentials dumped in addition to a number more hashes.

Using a Dynamic Proxy with SSH to Attack the DC

The .219 and the .222 hosts that we now had control of, both have access to the .117 host that we discovered to be a domain controller. Using the credentials we had already discovered, and taking advantage of the hosts in the lab running SSH, we collected some basic information from the DC.

Here, we just simply connect with the dynamic proxy option over SSH.

Not shown, we needed to modify our proxychains config file, to use port 1090 as a socks proxy.

Using the proxy we set up the DC, sees our traffic coming from the .219 host, and we are able to use a domain member credentials to dump a complete domain user list. Not only that, we come across another flag in a user password description.

Another thing I want to do early on is check for SPNs, as these can be Kerberoasted, and might provide additional paths for lateral movement.

Impacket tools provide a wealth of options for attacking domains directly from a Linux box.

With the proxy we can check for SPNs directly with the DC from our attacker machine. And find that there is an SPN.

If there is an SPN, we can use the same impacket tool to get a ticket, and then crack it offline. If the password is weak, we can get a password and possibly use the privileges to move laterally, or interact with the service.

Running the ticket through hashcat with a good wordlist should result in a password if we are lucky, and in this case it does. I didn’t end up actually using the cracked password to take over the domain, but there is a side path that I found wasn’t needed, that goes through this, and includes exploiting the timekeeper server. If anyone take a more direct approach to compromising the domain, it is worth while to go back through the white box approach, and make sure you compromise the timekeeper server. You need hashes from there to get your certificate of completion anyway.

Attacking the DC and Getting Domain Admin Access

We had user accounts now that could be used to pull domain information from the DC. We used this to gather more information on security controls. CME was used to pull the domain password lockout policy. It shows that even if we attacked with more passwords, we wouldn’t get locked out. This, combined with having a list of all domain users we collected previously using CME, made another quick password spray a good bet.

Using the list of all domain users and the 5 passwords we tried earlier, we ended up with one more hit for the user jeffersd.

RDP Access to the DC, and identifying the path to get administrator access

The new account was used to pull some more information with CME, and also provided us with RDP access to the DC. From the attack host we were able to use xfreerdp over the SSH proxy through host .219 to get access.

Once on the Domain Controller with jeffersd, we found that the user didn’t have local admin rights, but we did come across a saved document in the users documents directory. This was a message from the System Admin at the company. It reminded people not to use domain admin credentials on backup servers. The thing that really stands out here is we know about a backup user from dumping the domain users, and backup permissions can be very risky to hand out. Privileges to complete backups can allow privilege escalation, or in this case compromise of the domain.

Normally by this point I would have just dumped all relevant domain information using a bloodhound collector and used the pretty graphs to determine what I should do. In this case I wanted to actually practice some enumeration I had learned in a recent course, so I started reviewing the ACLs for the backup user.

PowerView can be obfuscated easily and used to collect a wealth of information.

PowerView can be very useful if something like bloodhound isn’t available. Here we set up a python web server to host PowerView, and imported it into our Powershell session with iex. We can then use the Get-DomainObjectACL with the users sid, and pull down all the associated rules. As we suspected, the backup user account had permissions, that would allow a dcsync to be completed.

With the backup user credentials and the proxy connection, we dumped the hashes for the entire domain with Impackets SecretsDump. At this point, we had hashes for every user in the domain.

The downside to this was that the built in administrator account was disabled, so we had to locate some other user that was a domain admin. PowerView also helps here. It has a function that can recursively look at groups to determine who has access to the domain admins group. MercerH ended up being a domain admin.

With control of the MercerH account, we had successfully taken over the initial Throwback.local domain. This isn’t the end of the lab as there are actually two more domains to take control of.

I won’t be going through how we get from the Throwback domain to the Corporate domain, and then from Corporate to the TBHSecurity domain. If you make it this far and know how to use built in AD tools, PowerView, or Bloodhound finding your way to the Corporate domain isn’t hard. Once there, you will be able to find some breadcrumbs that lead you to the last domain.

Final Thoughts

Learn basic skills before starting here

I would recommend people to do other learning before doing this lab. There are good options on Htb, and the PWK / OSCP has a pretty good (although too short) section on AD attacks. Once you are more familiar with the principles, get lab time on this lab and try to go through it blind, and see what you come up with.

Good word lists are the hardest part for me

I would think most beginners would get stuck (especially coming up with word lists). You also wouldn’t know to do LLMNR or NBT-NS attacks over the VPN with Responder, because it normally wouldn’t work. But when you have been stuck for a while, look at the coursework and take a small hint just to get you over the sticking point and go from there.

Try to have multiple options for every attack.

One thing I find useful is to set limitationd, or use techniques I might not normally do. As an example, I used an SSH proxy, because the system .219 had SSH running, but what if it didn’t? I can proxy with msf, upload a chisel binary, or use an RDP session and “Over Pass The Hash. Instead of passing the hash from our attacker box, we use an RDP session to the .219 host. Then use mimikatz to do “Over Pass The Hash” attacks, and covert a captured NTLM hash into a kerberos ticket. This allows us to move to the DC directly from the compromised host, using a legitimate sysinternals PsExec tool, and kerberos, instead of NTLM authentication.

The most important thing is, after you finish the lab and print off your certificate, take advantage of the lab time you have left to experiment. Understand the why behind the attack, and if you think the attack won’t work in the real world, ask yourself what you would do to make it work. This is what a real attacker would do. Then look at your own AD environment and understand how you are defending against those attacks to make sure your customers are less vulnerable.