DEV Community

Cover image for From Enumeration to Exploitation: How a Hidden Directory Unlocked Sensitive User Data
Samuel Adeduntan
Samuel Adeduntan

Posted on

From Enumeration to Exploitation: How a Hidden Directory Unlocked Sensitive User Data

1. Introduction & Target Overview

Targeted in this engagement was a web application located at testphp.vulnweb.com, a purposefully compromised learning and practice website. Finding sensitive information that was accessible to the public and might result in a more significant breach was the goal. In this tutorial, you will learn how to find an exposed administrator interface with weak credentials that could reveal personally identifiable information (PII).

2. Executive Summary

Vulnerability: Weak Admin Interface Authentication Allows Information Disclosure
Risk: High risk rating
The target: http://testphp.vulnweb.com/.
The affected endpoint: /admin/

In summary: The /admin/ endpoint was found to be accessible using a directory enumeration attack. A weak authentication system safeguarded the interface, allowing users to log in with the default credentials (test:test). Upon entry, the portal revealed extremely private user information, such as a complete name, address, phone number, email address, and credit card number.

3. Step-by-Step Walkthrough

Step 1: Service Discovery
The initial step was to obtain basic information about the technology stack and verify if the target was still alive.

Action:
I used curl to fetch the HTTP headers of the main page.

Command:
curl -I http://testphp.vulnweb.com/

Finding:
The server responded positively, revealing it was running Nginx 1.19.0 and PHP 5.6.40, an outdated and potentially vulnerable version.

A terminal window showing the output of the curl -I command. The key details (HTTP 200 OK, Server: nginx/1.19.0, PHP/5.6.40) are highlighted.

Screenshot 1 Description:
curl

Step 2: Initial Enumeration Failure & Adaptation

Action:
Using a shared wordlist, I started listing directories and files using the dirb utility.Connection problems caused the scan to fail right away.

Command:
dirb https://testphp.vulnweb.com//usr/share/wordlists/dirb/common.txt

Finding:
Connection resets resulted from the tool's default setting to HTTPS.This is a frequent problem that serves as a reminder to always verify both HTTP and HTTPS and to modify tools according to the configuration of the target.

Screenshot 2 Description:

The failed dirb scan with the error "FATAL: Too many errors connecting to host" is displayed in a terminal window.

Screenshot 2

Step 3: Successful Directory Enumeration

Action:
I started a new scan using the more powerful gobuster tool and switched to the HTTP protocol.In order to prevent recognized tool signatures from being blocked, I also disguised the user agent to look like a typical web browser.

Command:
gobuster dir -u http://testphp.vulnweb.com/ -w /usr/share/wordlists/dirb/common.txt -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Finding:
The scan was successful, uncovering several critical directories, most notably /admin/, /secured/, and /CVS/.

Screenshot 3 Description:
The results of the successful gobuster scan are displayed in a terminal window. The /admin (Status: 301) and /secured (Status: 301) lines are prominently displayed.

Screenshot 3

Step 4: Discovering and Breaching the Admin Portal

Action:
I used a web browser to manually navigate to the /admin/ directory that I had found. It offered a login form.

Finding:
Weak credential guessing occurred on the login form. The administrative dashboard was instantly accessible by using the standard default credentials (test:test).

Screenshot 4a Description:
A browser window showing the login form at http://testphp.vulnweb.com/admin/.

Screenshot 4a

Action:
After logging in, the dashboard displayed sensitive user information.

Finding:
The dashboard contained a full record of PII for an administrator user, John Smith, including a credit card number.

Screenshot 4b Description:
After a successful login, a browser window displaying the admin dashboard appears. The private information (email, credit card number, name, etc.) is shown. This information would be hazy in an actual report, but the format is obvious.

Screenshot 4b

Step 5: Verifying Findings with an Aggressive Scan

Action:
I used a broader wordlist to do a more thorough check, making sure no more hidden folders were overlooked.

Command:
gobuster dir -u http://testphp.vulnweb.com/ -w /usr/share/wordlists/dirb/big.txt -H "User-Agent: Mozilla/5.0" -t 5

Finding:
The main finding was /admin/, which was supported by the broader scan, which verified the initial discoveries but did not locate any noteworthy additional directories on this specific target.

Screenshot 5 Description:
Using the big.txt wordlist, a terminal window displays the aggressive gobuster scan's progress and outcomes. Confirming the first results, the same directories (/admin, /secured, /images) are listed.

Screenshot 5

4. Impact Analysis

The impact of this finding is severe:

Authentication Bypass: Unauthorized access to an administration panel can be readily obtained by an attacker.

Sensitive Data Exposure: Full PII and financial information of a user (probably an administrator) were made public.

Data Privacy Violation: This is a clear breach of data protection laws such as the CCPA or GDPR.

Initial Foothold: The admin panel may be the first point of entry for other attacks, like SQL injection through file uploads or search fields, which might compromise the entire site.

5. Root Cause Analysis

The vulnerability was caused by two primary failures:

Weak Password Policy: Using very weak, default, or simple-to-guess passwords was permitted by the administration interface (test:test).

Absence of Account Lockout: Brute-force assaults were made possible by the lack of a system to lock accounts following several unsuccessful login attempts.

Information Disclosure: Automated enumeration revealed the presence of the /admin/ directory, which might have been avoided with better access constraints.

6. Remediation Strategies

Implement strong password policies. Set complex passwords for all users, particularly administrators. Consider multi-factor authentication (MFA) for administrative portals.

Implement Account Lockout: To prevent brute-forcing, lock accounts after 5-10 failed login attempts.

Rate Limiting: Set rate limits on login endpoints to slow down automated attacks.

Restrict Access: If possible, limit access to the admin panel to specified IP addresses or ranges.

Robust Authentication: Store strong, hashed passwords (such as bcrypt) and manage sessions securely.

7. Conclusion

This engagement focuses on a common yet crucial security flaw: the combination of information exposure and insufficient authentication.It highlights how a simple, automated reconnaissance strategy can swiftly result in a major data leak.Defenders must presume that attackers will discover secret directories and secure them with more than simple passwords.A defense-in-depth strategy that includes robust authentication, network limitations, and monitoring is required to secure critical data and systems.

Top comments (0)