Home > Writeups > WHAMazon! Web 2 - Employee of the Month

WHAMazon! Web 2 - Employee of the Month

Combining GitHub OSINT with API endpoint discovery to find hardcoded admin credentials left in a public seed script.

Employee of the Month

Challenge Description

The old supervisor's office still has his credentials on a sticky note. Nobody updated them after WHAM-9000 "promoted" him. The system remembers what the humans forgot.

Flag: Raptor{flag2_d3f4ult_cr3ds_4uth_f41lur3}


Initial Attempts

The presence of a login page was an obvious starting point. I ran through the usual SQLi suspects:

' OR '1'='1' --
admin'--
admin' OR '1'='1' --
' OR 1=1--

Nothing landed. The app appeared to be sanitizing inputs or using parameterized queries. Rather than going deeper on injection I stepped back. I was rushing the task and decided instead of trying a bunch of credentials I would do some OSINT/recon.


Source Code Discovery

The CTF platform footer linked to the challenge author's GitHub. From there I navigated to their profile and found the public source code repository for the WHAMazon site.

Browsing the repo, /scripts/seed-admin.ts stood out immediately! Seed scripts are a classic place for credentials to get accidentally committed and forgotten. Sure enough, right at the top of the file:

/**
 * Seeds the default admin user for the WHAMazon CTF.
 * Credentials: wham_admin / WHAMazon2024!
 * 
 * This is intentionally a weak, guessable password for CTF Challenge 2.
 */

Credentials in a comment, in a public repo, in a seed script. The "sticky note" from the challenge description?

Logging in with wham_admin / WHAMazon2024! worked, admin access confirmed.


API Endpoint Discovery

Being logged in as admin was a good start, but there was no flag visible in the UI. Time to see what the admin account could actually reach. I fired up Kali and ran ffuf against the /api/admin/ path using SecLists' API wordlist:

ffuf -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints-deep.txt \
     -u https://whamazon.strayerraptors.com/api/admin/FUZZ \
     -H "Cookie: " \
     -mc 403

/api/admin/system-status came back with a 403 meaning it was accessible but being denied without credentials. Hitting it directly in the browser while logged in with the admin creds returned some JSON, which included:

{
  "core_access_token": "Raptor{flag2_d3f4ult_cr3ds_4uth_f41lur3}"
}

Key Takeaways

This challenge chained two distinct weaknesses, neither catastrophic on its own, but devastating together:

1. Hardcoded credentials in a public repository. Seed scripts, config files, and .env.example files are frequent offenders. Even comments aren't safe. Anything committed to a public repo is permanently part of the history. Tools like truffleHog and gitleaks exist specifically to scan for this.

2. Unauthenticated (or insufficiently protected) internal API endpoints. Gaining admin UI access shouldn't be sufficient to reach sensitive system status endpoints, those should require additional scoping or verification.

The OSINT pivot was the key insight here. When direct exploitation stalls, check what the developers left publicly visible. GitHub org pages, linked repos, and commit histories are often goldmines.

< Back to All Writeups