Welcome to another Hack the Box exercise. In this blog post, I have documented how I owned the Environment machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs. You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment, and subscribe to my YouTube channel and also follow me on LinkedIn for more updates.
About the Machine
Environment is a medium-level Linux machine on HackTheBox that demonstrates...
The first step in owing the Environment machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:
This established a connection between my Kali Linux terminal and Hack the Box server. Once the connection was successful, I started the target machine and I was assigned an IP address 10.10.11.67. The next step was mapping the IP address to the domain name (environment.htb). To map the IP address to the domain environment.htb, I ran the following in the terminal:
It is important to map hostnames to IP addresses on your local machine (via /etc/hosts) for several reasons, especially in development, troubleshooting, and networking scenarios. Here's why it matters:
- Local Name Resolution Without DNS: The /etc/hosts file allows your system to resolve hostnames without querying a DNS server. It is useful when DNS is unavailable or misconfigured and when you're in an isolated or internal network.
- Testing and Development: You can point a domain (like myapp.local) to a local or test server (e.g., 127.0.0.1 or a staging IP). For example: 127.0.0.1 myapp.local This allows testing websites or apps locally using human-readable names.
- Security and Control: It can prevent connections to known malicious domains by redirecting them: 127.0.0.1 malicious-site.com
You control name resolution without relying on external DNS, reducing attack vectors.
Then I performed reconnaissance using Nmap to find all the open port and services associated with the target machine. Using the following command, I found all the services and port running at 10.10.11.67:
This command performs a version scan (-sV) and enables OS and service detection (-A) to get as much information as possible in one sweep.
The scan revealed two open ports:
- Port 22 (SSH) – Running OpenSSH 9.2p1 on Debian 12. While SSH is almost always present, it typically requires valid credentials or keys, so it’s not immediately exploitable. Still, it’s good to keep in mind for later in case I find a username/password combo.
- Port 80 (HTTP) – Hosting a web service powered by nginx 1.22.1. The server’s title is “Save the Environment | environment.htb”, which suggests a custom web application. Since web services often hide vulnerabilities in their logic or configurations, this becomes the primary point of interest.
Nmap’s OS fingerprinting identified the target as Linux (kernel range 4.15 – 5.19), confirming it’s running on a fairly modern environment. The traceroute output also shows the host is only two hops away, which is consistent with Hack The Box’s VPN setup.
At this stage, my biggest lead is the HTTP service, so the next step will be to dig into the web application and enumerate possible entry points.
I launched my browser and visited 10.10.11.67 and was redirected to http://environment.htb/ The website is a landing page with a hero banner "Our Environment Our Future" and a paragraph "Please help us in our journey of preserving the Earth's beautiful environment!" The website also contain the "About Us" section with flexbox containing "Our Mission", "Our Values", and "Get Involved" headers.
The site also includes a “Join Our Mailing List” subscription form at the bottom, which immediately caught my attention as a potential input vector for further testing. At this stage, the website looked like a static NGO-style landing page, but CTFs often hide functionality under the surface, so my next step was to begin enumerating directories and hidden content.
Since most CTF web challenges tuck away their juicy bits behind forgotten endpoints or misconfigured paths, I ran dirsearch against the target:
The scan returned a treasure trove of potential leads:
Interesting status codes:
- A lot of
403 Forbiddenresponses hinted at restricted resources such as/admin/.config,/bitrix/.settings,/mailer/.env, and/twitter/.env. The presence of.envfiles is particularly suspicious because they often contain sensitive configuration data like database credentials or API keys. Although access was blocked, their existence was enough to flag them for later exploitation attempts.
Valid endpoints (200 responses):
/favicon.icoand/robots.txt– Common files, but always worth checking./loginand/index.php/login/– These looked like an authentication portal, a clear pivot point for attacking the application./robots.txtwas especially small (24 bytes), so I made a mental note to inspect it—it might contain disallowed paths or development hints.
Redirects (301/302 responses):
/build→/build//storage→/storage//logout→ redirected back to/login, confirming the presence of a session-based authentication system.
Upload functionality:
/upload/returned a405 Method Not Allowed. This suggests that an upload handler exists but restricts certain request methods. File upload endpoints are notoriously dangerous and could lead to Remote Code Execution (RCE) if mishandled.
Overall, the biggest findings from enumeration were the login page and the upload endpoint. These stood out as the most promising footholds into the target application. The presence of forbidden .env files also hinted at a PHP/Laravel or similar framework under the hood.
The next logical step was to inspect /robots.txt and then test the login portal to see if it was vulnerable to weak credentials, SQL injection, or other bypass techniques.
x:
0 Comments