VulnLab: Wutai (Part 1)

Today we are going to look at a medium red team lab, Wutai. For this we need the RTL VPN, which if you are on Pateron and payed for the middle payment then you will get 2 VPN files, one for the labs and one for red team labs. The red team labs are always running, and this one is running on the 172.16.20.0/24 network, with an interior network as we will see of 172.16.21.0/24.

We get a scope from Discord that states the following:

The Wutai Group has tasked you with performing a penetration test on its networks. This includes the Wutai Parent Company & its subsidiary Junon. Wutai is concerned about its security posture since a leak of domain usernames was found online on pastebin.

• https://pastebin.com/BBZkJGU1 KE37vTed5S

The goal of this test is to reach Enterprise Administrator in the wutai.vl domain. Wutai employs a small SOC but its blue team capabilities are still on a rather basic level. Wutai’s external systems can be reached through the Vulnlab VPN on the 172.16.20.0/24 network. Everything is in scope except the infrastructure (172.16.xx.1/172.16.xx.2).

First we will grab the username list that was found online from the pastebin, and cut the @ off each name:

cut -d '@' -f 1 users.txt > users1.txt
cat users1.txt| sed 's/^ *//g' > usernames.txt
rm -rf users.txt users1.txt

Starting off with a RustScan of the exterior network we see that there is a squid proxy port up and running on port 8080.

To be able to go through this port we need to change our /etc/proxychains4.conf file

Now that this is setup lets run netexec (newest crackmapexec) on a /23 network:

proxychains -q nxc smb 172.16.20.0/23

We find some addresses on the internal network:

Now lets figure out which one is the DC:

proxychains -q nmap -p 88 -iL internal.txt -Pn

The above breaks it down a little bit, but not quite enough, at least we know which servers are running Kerberos. However, 222, looks like it is in a different forest:

Now lets do a kerbrute to make sure that all those names are actually on the machines:

proxychains -q GetNPUsers.py work.junon.vl/ -no-pass -usersfile usernames.txt

We can let that run for a while and see the users are on the machine.

Now that we know that we cannot asrep roast lets try and bruteforce. This part I was stuck on, however, Summer2023 is the password you want to use.

proxychains -q nxc smb 172.16.21.200 -u usernames.txt -p Summer2023 --continue-on-success > brute.txt

This part is going to take a while, so don’t bring your fat ass to McDonald's and maybe do some burpees while you wait. As you can see I am outputting to a brute.txt file, which will allow me to grep for + afterwards to see if anyone was able to login with that password.

Now that we know we have some users, lets try some other passwords, such as Wutai2023 and Junon2023:

Now that we have some users, we can attempt to look at shares, bloodhound, lookupsid, if you were thinking SPNs good job, but there are not any and start to enumerate with a username and password, seeing what can we look at and get into. Also lets utilize something like crackeverything from github to see if these users can do anything else on the machines:

GitHub - overgrowncarrot1/CrackEverything6: Crack Everything for CrackMapExec version 6

Utilizing only a users file and only a passwords file we can test all the usernames and their different abilities with crackeverything:

proxychains -q CrackEverything.py -Z Shell! -F internal.txt -u brute_users.txt -p brute_passwords.txt -J 

Time for more burpees, this again is going to take a minute, but will drop everything we are able to do:

We will see at the bottom that we cannot do anything, however RDP doesn’t show Pwn3d! so we have have to actually look at it, it looks like we can RDP into different machines with all of the different users.

However, if you try to RDP in you will notice that you cannot. But, this is not the end of the world. Remember our first portscan that showed port 443 open on the external. Going there we see the following:

Looks like we may be able to login:

From here we login and click create a new session then see the following and try the same credentials:

Looks like we are logged in through a remote desktop, in here we can grab our first flags:

Looks like the external machine was hosting an internal machine:

From here I always like to check if I can write to inetpub:

And this shows that I can, so if we can get a aspx or asp shell on this, we could potentially become NT Authority due to permissions that most web servers have on Windows.

First we need to test pings and uploads:

Now we need to connect to the server utilizing FoxyProxy:

Ok, now we can grab an aspx reverse shell:

https://raw.githubusercontent.com/borjmz/aspx-reverse-shell/master/shell.aspx

Now lets upload that shell onto the machine and wait for a callback:

I wasn’t getting a callback, so I opened the file in notepad and changed the port to 8000 and the IP to 127.0.0.1, remember we also already loaded nc64.exe on the machine so we can now make a callback to ourselves.