How i found exposed db creds on .gov site

Hello everyone,

I hope you all are having an amazing day. 😁

This is my first blog and the story of my first find. I am still new to this and learning every day so any feedback is appreciated… I will try to keep this short and simple — let’s get into it.

I chose a target, let’s call it freepalestine.com.

**Side note: This is a self-hosted program. I am no advocate for free labor but VDPs have less competition than BBPs, so I think this is the best option for me (might not be the same for you) to learn as a beginner without becoming too discouraged or unmotivated.

I started with subdomain enumeration using subfinder with the following options:

subfinder -d freepalestine.com -all -recursive > subs.txt-all uses all available data sources-recursive enables recursive enumeration for deeper scan (think subdomains of subdomains…)

** Important note: take the time to set up your API keys for subdomain enum and i promise, you will thank yourself in the future..

Next up is httpx-toolkit to get live urls with:

cat subs.txt | httpx-toolkit -status-code -td -cname -o subsalive.txt-status-code displays the status code of the site-td detects the technology used-cname displays host cname

I then started Nuclei using those live urls and running mostly default settings while I manually tested other things. After about an hour of no luck manual testing, I checked Nuclei and saw this on one of the subdomains:

wp-config.php.bak is the backup file of the wp-config.php file in a WordPress installation. It is a critical configuration file that contains important settings and information for your WordPress site.

I retrieved this file using wget and this is what we find:

Exposed DB credentials, authentication keys and salts. 😳

xmlrpc.php was also enabled on the subdomain and if you don’t know what that is go read this great article:

Knowing this, I used WPScan to retrieve any usernames for the login panel and it came back with 1 user. I then attempted to forge valid authentication cookies using the authentication keys and salts found in the backup file to potentially allow a login bypass to the site’s admin dashboard, but the bypass attempts were unsuccessful….

The database also appeared to be on an internal network, limiting the immediate impact of direct database exploitation. However, this does not mitigate the risk entirely, as internal attackers or anyone with access to the internal network could exploit the exposed credentials.

With all this information, I wrote up my findings, sent over the report, and the issue has since been mitigated.

Onto the next!

Thanks for reading. 😁