This lab was super enjoyable. I really liked the challenge and free-reign we had over how to approach this lab, and I felt like I knew the next steps based off of the things that we had done in previous labs. I did have a lot of trouble initially with the syntax of the SQLi exploit, and it took me a while to get that working because I kept making silly syntax mistakes and wondering why it wasn't working. I also had a lot of trouble with the password cracking, as I tried to use hashcat initially to crack the hash and got a false positive, which really confused me when the credentials didn't work. It did not help that I was also using the wrong username for a lot of the lab, as the word admin was not actually the administrator name nor is it ever in Windows environments.

• Target IP Address:
  • Using an nslookup on gloin.shire.org, which was the only information we were given on this target box, I was able to see the local IP address of the target box. To do this, I needed to specify the target DNS server though. The full command was nslookup gloin.shire.org 10.0.5.22 The IP address of the box is 10.0.5.31.
• Open Ports:
  • Now that I know the target IP of the box, I can perform an NMAP port scan to see the open ports, and the available services. Potentially, I can even gleam information about the operating system as well as the kernel release it's running. After doing so, I discovered that the target is running ports/services 22, 443, and 3389. That means this box has SSH, HTTPS, and RDP enabled respectively. Since this was an OS scan, we were also able to see that this box is running a build of Windows.
• Discovered Vulnerability:
  • Since HTTPS is enabled, I visited https://10.0.5.31 and was redirected to some sort of online entrance exam website. There is some text related to an enterance exam, as well as a text entry box for a reference code, with a login button below it. Using Kali Linux's tool searchsploit, I got a few different results: 'Multiple' SQL injection, Account Takeover, SQLi Authentication Bypass, and Unauthenticated Admin Creation. I wasn't really sure how to manipulate anything with most of the exploits, but since we had experience with SQL injection, I went ahead with that one. Going to https://exploitdb.com/exploits/50398 gave me a URL exploit to try, which was https://10.0.5.31/entrance_exam/take_exam.php?id=%27+UNION+SELECT+1,username||%27;%27||password,3,4,5,6,7+FROM+admin_list;. When I did this, it dumped some info as well as a start exam button. Looks like a hash or encoding of some sort. I ran a hashcat with hashcat -m 0 <hash> /usr/share/wordlists/rockyou.txt to see if I could get anything, and I got 2 candidates: Moritz16, and Moorehead. The ExploitDB entry for this exploit also has a url to try in order to get the admin user as well, so I used the link https://10.0.5.31/entrance_exam/admin/view_enrollee.php?id=1'+UNION+SELECT+1,2,3,4,5,6,password,username,9,10,11,12,13,14,15+FROM+admin_list;
• How I achieved a foothold:
  • Now that I had some credentials to play around with and I knew SSH was open, I started there. This part took me FOREVER because I could not seem to get any creds to work. After doing a lot of research, I found the rather obvious solution that ended up being admin was not actually what the administrator is called. On Windows machines, the admin user is called Administrator by default. However, I still could not log in. After using these passwords and neither of them worked, I decided to try other solutions to verify the hashes cracked properly. Using CrackStation, I got the password Moria2Featon6, and was able to log in using this one.
• How I achieved root:
  • See above. I was able to crack the hash of the admin password from the SQLi exploit on ExploitDB and got the username after bashing my head against a brick wall for a little while.
• User flag:
  • I was a bit confused at first because all I could see was the root flag, so I went up a directory to the Users folder and saw there was a gloin account, so I assumed this is probably what I needed. I navigated here, and found the flag.
• Root flag:
  • Since I am SSH'd into the root account, I was able to cat the root flag immediately as it was in my working directory.
• How to mitigate this vulnerability:
  • As this is an SQLi vulnerability, I think the most effective way to prevent against this attack in the future would be either input sanitization or input validation. Making sure that only certain parameters can be passed is important, as well as preventing text input in the URL from being passed as code is crucial in preventing access to sensitive SQL-related data in a website.