Real Findings: Exposed Backup Files #1

During routine reconnaissance, a GET request to a predictable configuration backup path returned a 200 OK response containing a plaintext PHP configuration file. The exposed file contained full production database credentials, including the database name, username, password, host endpoint, and port. No exploitation of a software vulnerability was required. The server simply served the backup file as static content.

This article covers the discovery method, the exposed data, the associated risk, and remediation steps.

Discovery

The target was a web application running a common CMS (Drupal). These platforms store database connection details in a configuration file typically located at:

/sites/default/settings.php

During testing, a request was made to the same path with a common backup extension appended:

/sites/default/settings.bak

The server responded with 200 OK and returned the contents of the file as plain text. This behavior indicates that the web server was not configured to deny access to files with the .bak extension. The file was treated as a static resource rather than a script, and its contents were returned to the client without any access control.

Exposed Data

The response contained a PHP array defining the database connection configuration. The following fields were exposed in plaintext:

database → Production database name
username → Database user account
password → Plaintext password for that account
host → AWS RDS endpoint
port → Database port (3306)
driver → Database type (MySQL)

database → Production database name
username → Database user account
password → Plaintext password for that account
host → AWS RDS endpoint
port → Database port (3306)
driver → Database type (MySQL)

Why This Is Critical

The exposed credentials provide direct access to the production database. An attacker does not need to exploit any vulnerability in the application itself. The credentials can be used from any external host to:

Connect directly to the database
Dump all tables including user data and PII
Extract password hashes for offline cracking
Modify or delete records
Potentially pivot to other internal services

This is a full compromise achieved through a single unauthenticated HTTP request.

Root Cause

Backup files are created during routine maintenance, configuration changes or troubleshooting. Common naming conventions include settings.php.bak, settings.php.old, settings.php, settings.bak, etc.

When these files are left in the web root and the server is not configured to block them, they become publicly accessible. Automated scanners routinely check for these extensions across millions of domains. If the file exists, it will be found.

Remediation

1. Remove backup files from the web root

Backup copies of configuration files should never reside in a publicly accessible directory. Store them outside the document root or use version control instead of manual file copies.

2. Block sensitive file extensions at the server level

Nginx:

location ~* \.(bak|old|orig|save|swp|swo|txt|log|sql|inc)$ {
    deny all;
    return 404;
}

location ~* \.(bak|old|orig|save|swp|swo|txt|log|sql|inc)$ {
    deny all;
    return 404;
}

Apache:

<FilesMatch "\.(bak|old|orig|save|swp|swo|txt|log|sql|inc)$">
    Require all denied
</FilesMatch>

<FilesMatch "\.(bak|old|orig|save|swp|swo|txt|log|sql|inc)$">
    Require all denied
</FilesMatch>

3. Rotate exposed credentials

Any credential that has been exposed in a publicly accessible file must be considered compromised. Rotate the database password immediately and verify that no unauthorized access occurred.

4. Use environment variables or a secrets manager

Avoid hardcoding credentials in files that may be copied or backed up. Use environment variables or a dedicated secrets management solution (e.g., AWS Secrets Manager, HashiCorp Vault, or similar).

5. Add backup file checks to your deployment pipeline

Include a step in your CI/CD pipeline that scans the web root for common backup file patterns before deployment. This prevents accidental exposure before it reaches production.

Key Takeaways

A single misconfigured file extension can expose an entire database.
Backup files are a common and easily overlooked attack surface.
Server-level deny rules for sensitive extensions are a basic but essential hardening step.
Credential rotation is mandatory after any exposure and even if no breach is detected.

Note to the readers: The specific host, database name, username, and password shown in the original screenshot have been intentionally omitted from this article to protect the affected organization. The purpose of this post is educational and to highlight the importance of server hygiene.

Contents