During the 7th Annual Saranac Lake Cybersecurity Conference, a student and I worked together to solve an easy Hack The Box challenge. The objective was to identify weaknesses in a web application and obtain the flag. What follows is a step-by-step account of how a handful of small misconfigurations — an exposed backup directory, a leaked filename, and a crackable password hash — chained together into a full administrative compromise.
Enumeration
Initial reconnaissance showed that only port 80 was open, indicating the web application itself was the primary — and likely only — attack surface. To map out hidden content, we ran Gobuster against the target using the DirBuster medium wordlist.
The scan surfaced four directories of interest:
| Path | Status | Note |
|---|---|---|
| /backups | 301 | Redirect — worth a closer look |
| /dashboard | 403 | Protected admin area |
| /login | 200 | Application login portal |
| /static | 301 | Static asset directory |
/dashboard returned a 403, confirming it was access-controlled. /login was reachable and appeared to be the app's authentication portal. The most interesting lead, however, was /backups — a directory name that has no business being reachable from the outside at all.
Inspecting the Login Page
Before chasing /backups blindly, we pulled the raw source of the login page to see what the application itself revealed.
Buried in the page markup was a direct reference to a SQL backup file. A filename like that, sitting in front-end HTML, is a strong signal that a database dump had been left somewhere web-accessible.
Retrieving the Database Backup
Combining the leaked filename with the /backups directory found during enumeration gave us a direct path to the file. We downloaded it without any authentication required.
Opening the dump revealed a full users table — including the administrator account and its hashed password.
.sql file handed us six user records and an administrator credential in one request.Password Recovery
The admin account's password was stored as a raw MD5 hash — no salt. We submitted it to CrackStation, which checks hashes against a large corpus of previously-cracked values.
The hash had already been broken and catalogued in public rainbow-table databases, so recovery was instant. That gave us a working administrator username and password.
Gaining Access
With valid administrator credentials in hand, we authenticated through the application's /login page. This unlocked the previously-403'd /dashboard area, where the challenge flag was waiting — completing the objective.
Key Findings
Three distinct, individually minor misconfigurations combined into a full compromise:
Publicly Accessible Backups
- Database backup stored in a web-reachable directory
- Dump contained full user records and password hashes
Weak Credential Protection
- Admin password hashed with unsalted MD5
- Hash already present in public crack databases
Information Disclosure
- Backup filename referenced directly in page source
- Turned a guessing game into a direct path to the file
Lessons Learned
- Store backup files outside the web root, never inside a publicly served directory.
- Restrict access to backup and administrative directories at the server or auth layer.
- Use strong, unique passwords for privileged accounts.
- Enforce password policies and require multi-factor authentication for admin access.
- Regularly audit web servers for exposed files and stray sensitive information.
- Monitor for leaked or previously-cracked credentials and force resets when found.
Conclusion
This challenge was an excellent demonstration of how seemingly small misconfigurations can lead to a complete compromise of a web application. Through enumeration, discovery of an exposed backup file, recovery of administrative credentials, and successful authentication, we obtained the flag and completed the exercise. It reinforced a simple lesson: secure backup management and credential hygiene aren't optional extras — they're the first line of defense.