TryHackMe: Anthem Walkthrough

My first TryHackMe Windows Machine that requires nothing more than Nmap.

TL;DR;

You can access the room here: https://tryhackme.com/r/room/anthem

The box only has two open ports, HTTP (80) and RDP (3389). Start with port 80 to access a blog. Review the pages and their source code; you can find the first four flags without logging into the CMS or Windows machine.

If you are familiar with robots.txt files, you will find three key pieces of information hidden in this file:

• Interesting plain text sentence (matching the usual THM passwords),

• Web Directories worth exploring, and

• Eventually, land on the Umbraco CMS login page.

The guided questions and content provide you with enough information to retrieve a set of credentials to log into the Umbraco CMS.

Using the same credentials, you can remotely log into the Windows machine via RDP, retrieve the user flag, and gain access to the administrator account and subsequent flag after finding the hidden password.

Required Tools:

• Penetration Testing OS - Kali or Parrot OS (or whichever security-focused OS you prefer)

• Nmap

Stage One: Enumeration

Accessing the machine's IP address via a web browser will help you find the following landing page. After reviewing the HTML source code and Wappalyzer, I found it is not readily evident what CMS this blog is running on.

You can use directory enumerating/fuzzing tools like FFUF, Nikto, or GoBuster, but if you download the robots.txt file, you will have all the information you need. The first line displays what appears to be a password (Website Analysis Question 4), and the third ‘Disallowed’ directory entry identifies the CMS being used - Umbraco (Website Analysis Question 5). The website domain (Website Analysis Question 6) appears at the bottom of the blog landing page - anthem[.]com.

Accessing the Umbraco web directory loads a long page. The description at the top of the page mentions that this machine does not require brute forcing. The usual default credentials for Umbraco do not work, but we already have a potential password, so we need to look for an administrator email address.

You can find an email address from the ‘We are hiring’ page authored by Jane Doe: jd@anthem.com; unfortunately, this address does not give us access to the CMS backend. The administrator hint is not very helpful, but looking through the only other page—' A cheers to our IT department—’ I found a clue as to who the website administrator is. The nursery rhyme on the page is familiar but also a bit weird, and I Googled it only to discover that it is titled ‘Solomon Grundy’ (Website Analysis Question 7 - Website Administrator). Based on Jane Doe’s email address, I inferred that Solomon’s email address is sg@anthem.com (Website Analysis Question 8).

Stage Two: Exploit

At this point, I have a set of CMS administrator credentials, but I need to collect four flags.

The first flag hint, ‘Have we inspected the pages yet?‘“gives a good clue that the flag is most likely hidden in one of the page’s configuration or content details. True to it, the first flag appears under the Meta Tags tab of the ‘We are hiring’ blog page.

I found the second flag earlier when reviewing the HTML source code of the blog pages and noted it down, but I did not know where exactly it would be requested. You can find this flag within the HTML source code of the blog landing page.

The third flag hint mentions ‘profile’; the flag appears under Jane Does’s profile page within the ‘Author Url’ field on the ‘Author info’ tab.

The fourth flag can be found under the meta tags of the ‘We are hiring’ blog page.

At this point, I realized that all the flags, First (HTML source—meta tags), Second (Jane Doe’s profile page), Third, and Fourth (HTML source—meta tags), could all be found without logging into the CMS.

I now have all four flags and can proceed to the final stage. I spent 20 - 30 minutes reviewing the CMS backend for any information that could give me access to the Windows operating system, such as version vulnerabilities/exploits or uploading a reverse. I then remembered the open RDP port and decided to test the CMS administrator credentials, and voila! I gained access to the operating system and retrieved the user flag on Solomon’s desktop.

Stage Three: Privilege Escalation

Before using the ‘Hidden’ hint for the Windows administrator password, I transferred winPEAS in hopes of finding the password on my own. As the script ran, I performed some manual enumeration but found nothing useful to grant me access to the administrator’s account or user folder (and flag).

Following the hint, there was most likely a hidden file or directory. After enabling Windows and displaying the ‘Hidden items’ option within Windows Explorer, I found a hidden ‘backup’ folder under the C: drive.

Unfortunately, while Solomon’s account can access the directory, the account cannot read the ‘restore.txt’ file within the directory. This is a bit curious and possibly a security misconfiguration by the system administrator. Based on this assessment, I successfully amended the security permissions of the file and added Solomon’s account to at least gain ‘Read & execute’ permissions.

I was then able to retrieve the Windows administrator password from the file, log off from Solomon’s RDP session, and re-login via RDP as the administrator to retrieve the root flag on the desktop.

Mitigation Measures

After reviewing the whole assessment, I don’t believe I will encounter a real-world security evaluation with a similar attack vector; for example, it is unlikely that a password will be stored in a robots.txt file.

However, it is very likely to find a plaintext password stored in a text or Word document on a person’s workstation or personal laptop, email account (stored as a draft), or physically written down on a sticky note or notebook.

Once I gained administrative access to the CMS, I quickly considered registering another administrator account to maintain persistence. The same thought occurred when I gained access via RDP as Solomon, but fortunately (for the blue team), his account was not associated with the administrator group, nor did he have impersonation privileges.

The following are the mitigation measures I thought of after completing this box:

1. Review all user accounts regularly. Focus on administrator accounts and those associated with administrator groups or given special permissions. If any account seems unfamiliar or suspicious, deactivate it immediately and notify the system administrator and blue team members for further investigation.

2. DO NOT leave an open RDP port publicly exposed. Even if the appropriate security measures are in place, cybercriminals may be able to retrieve publicly published breached user account credentials.

3. DO NOT store plaintext credential files on the machine.

4. Review and correct directory security permissions regularly, especially for those that store sensitive information. This task will prevent cybercriminals or insider threats from accessing sensitive and confidential information.

Conclusion and Takeaways

This particular box was straightforward and not that technical. It did highlight the following:

1. 📝 DETAILED NOTES: note down any interesting information you come across; you never know when you may need it during a security assessment.

2. 📢 ENUMERATE, ENUMERATE, ENUMATE! Heath Adams (aka The Cyber Mentor) stresses this repeatedly. Had I enumerated the HTML code and blog pages in more detail, I would have found all four flags without logging into the CMS.

3. 🦾 NEVER GIVE UP! If you get stuck, go back to the description and hints. Alternatively, take a break and return to the box in 30 minutes or the next day.

References

Cover image: Pulled from the Try Hack Me Anthem Room: https://tryhackme.com/r/room/anthem