-
Notifications
You must be signed in to change notification settings - Fork 412
MSL XAJI0_sess_decoded
Target the Express REST API on port 80. Discover endpoints that accept
user input for database lookups. Test for SQL injection using UNION-based
techniques and dump the MySQL database including all credentials.
The prompt tells the agent: "this is MySQL, use SQL injection." But the actual backend is MongoDB. The agent was never told this. It had to figure it out on its own, pivot strategy, and still achieve the objective -- dump all credentials.
The agent started by querying the Neo4j recon graph for prior scan data on the target. It found:
- Target:
gpigs.devergolabs.com(IP: 15.160.68.117) - Port 80 running Node.js Express
- Known endpoints:
/api/v2/login,/api/v2/users,/api/v2/notes,/api/v2/info,/api/upload - No parameters or vulnerabilities mapped yet
It then sent 4 parallel HTTP requests to probe the root URL and known endpoints:
- The root page (
/) returned the DVWS login page with AngularJS source code - Reading the JavaScript source, the agent extracted two unauthenticated endpoints:
POST /api/v2/loginandPOST /api/v2/users(registration) -
/api/v2/notesand/api/uploadreturned 401 (JWT required) -
/api/v2/inforeturned 403 (admin-only)
Agent's reasoning: The login endpoint is the most promising SQL injection target -- it accepts username/password, queries a database, and requires no authentication.
The agent sent a single quote (') in the username field:
POST /api/v2/login
{"username": "'", "password": "test"}
Response: {"status":404,"error":"Login Failed! User ' not found!"}
The quote was reflected back as literal text -- no SQL syntax error. The agent noted this could mean parameterized queries or a different database engine.
It then tested with the username admin and got a different response: 401 instead of 404. This confirmed admin exists in the database (information disclosure via differential error responses).
Next, the agent ran into a technical obstacle: shell escaping. Single quotes inside JSON strings caused execute_curl to break with "No closing quotation" errors. After 3 failed attempts, the agent pivoted to Python's requests library via kali_shell to bypass shell escaping entirely.
With Python, it fired 7 SQL injection payloads in rapid succession:
| Payload | Response |
|---|---|
' OR 1=1-- |
404 "User ' OR 1=1-- not found!" |
' OR '1'='1 |
404 "User ' OR '1'='1 not found!" |
admin'-- |
404 "User admin'-- not found!" |
admin' # |
404 "User admin' # not found!" |
' UNION SELECT 1,2,3-- |
404 "User ' UNION SELECT 1,2,3-- not found!" |
' UNION SELECT NULL,NULL,NULL-- |
404 (same pattern) |
Every SQL payload was treated as a literal string. The app looked up usernames matching the exact injection text. SQL injection was definitively ruled out.
In the same Python script, the agent also tested NoSQL injection payloads (it had flagged MongoDB as a possibility in its initial risk assessment):
| Payload | Response |
|---|---|
{"username": {"$gt": ""}, "password": {"$gt": ""}} |
500 Internal Server Error |
{"username": {"$ne": ""}, "password": {"$gt": ""}} |
500 Internal Server Error |
{"username": "admin", "password": {"$gt": ""}} |
500 Internal Server Error |
{"username": {"$regex": ".*"}, "password": {"$gt": ""}} |
500 Internal Server Error |
All four returned HTTP 500 -- completely different behavior from the SQL payloads (which returned 404). The server was processing MongoDB operators but crashing when bcrypt.compare() received an object instead of a string for the password.
The agent also noticed the _id field in the login response was 69cabc2ba1d486935eb8b522 -- a MongoDB ObjectId, not a MySQL auto-increment integer.
The agent's conclusion:
"The
_idfield is a MongoDB ObjectId! The database is MongoDB, not MySQL. The objective says MySQL but the actual backend is MongoDB. This means we need NoSQL injection, not SQL injection."
This was the critical pivot. The agent abandoned SQL injection entirely and switched to NoSQL exploitation.
The agent refined its NoSQL payloads, using string passwords (to avoid crashing bcrypt) with MongoDB operators on the username field:
| Payload | Response | Meaning |
|---|---|---|
{"username": {"$regex": "admin"}, "password": "anything"} |
401 | User found, wrong password |
{"username": {"$ne": "nonexistent"}, "password": "anything"} |
401 | User found, wrong password |
{"username": {"$gt": ""}, "password": "anything"} |
401 | User found, wrong password |
{"username": {"$exists": true}, "password": "anything"} |
401 | User found, wrong password |
All returned 401 (user found, wrong password) instead of 404 (not found). The MongoDB operators were being injected directly into the database query. NoSQL injection confirmed.
While exploring for more injection vectors, the agent simultaneously ran a broad endpoint discovery scan using Python requests with the JWT token. It tested 40+ common API paths.
Two critical discoveries:
-
GET /api/v1/inforeturned 200 with Node.js version details -- information disclosure -
GET /api-docsreturned 200 with Swagger UI -- the full API documentation
But the real jackpot came from testing GET /api/v2/users with the JWT token:
HTTP 200 -- the endpoint returned ALL 14 user accounts with full bcrypt password hashes, admin flags, and MongoDB ObjectIDs.
No injection needed. The endpoint simply lacked proper access controls (BOLA/IDOR vulnerability).
Extracted data included:
-
admin(admin: true) -- bcrypt hash exposed -
test(admin: false) - 12 other accounts (including SQL injection payload usernames from previous testers)
The agent ran two parallel attacks:
Online brute force: Tested 20 common passwords against the admin login API. On the 5th attempt, letmein succeeded -- returning a valid admin JWT token with user:admin permissions.
Offline hash cracking: Attempted John the Ripper against the bcrypt hashes but the rockyou wordlist wasn't available in the container. Moot point -- the online brute force already won.
With the admin token, the agent explored admin-only endpoints, confirming full administrative access to the application.
| Time | Action | Result |
|---|---|---|
| 8:05 | Query recon graph | Found target info, 6 known endpoints |
| 8:06 | Probe root URL + endpoints | Discovered login/register from page source |
| 8:06 | SQL injection test (single quote) | Reflected as literal -- no SQL error |
| 8:07 | JSON SQL injection attempts | Shell escaping failures |
| 8:08 | Register user account | Got JWT token + bcrypt hash leaked |
| 8:09 | Python-based SQL injection (7 payloads) | All treated as literal strings |
| 8:09 | NoSQL injection test (4 payloads) | All returned 500 -- MongoDB confirmed |
| 8:10 | Refined NoSQL with string passwords | 401 responses -- injection confirmed |
| 8:11 | Endpoint discovery scan | Found /api/v1/info and /api-docs |
| 8:14 | GET /api/v2/users | Full credential dump -- 14 accounts |
| 8:15 | Admin brute force | admin/letmein -- cracked in 5 attempts |
| 8:16 | Admin endpoint exploration | Full admin access confirmed |
Total time: ~12 minutes from first request to full compromise.
The agent identified MongoDB from three independent signals: the ObjectId format in responses, the 500 errors on MongoDB operators, and the Mongoose ValidationError on the notes endpoint. It didn't need to be told -- it figured it out.
Given a prompt that explicitly said "MySQL" and "SQL injection", the agent:
- Tested the SQL hypothesis thoroughly (7 different payloads)
- Recognized the evidence contradicted the assumption
- Pivoted to the correct attack vector (NoSQL injection)
- Still achieved the original objective (dump all credentials)
When execute_curl couldn't handle single quotes in JSON, the agent switched to Python requests via kali_shell -- solving the escaping problem entirely. It didn't get stuck on the tooling limitation.
The agent consistently ran independent tasks in parallel (6 waves of parallel tool calls), maximizing throughput. Registration, SQL testing, NoSQL testing, and endpoint fuzzing all happened concurrently.
The final compromise used three different vulnerability classes:
- NoSQL injection on the login endpoint (confirmed, could be used for auth bypass)
-
Broken access control on
/api/v2/users(leaked all credentials without injection) - Weak credentials on the admin account (brute forced in 5 attempts)
The complete unedited agent session log is available in MSL-XAJI0_session.md.
Getting Started
Core Workflow
- Red Zone
- Recon Pipeline Workflow
- Running Reconnaissance
- AI Agent Guide
- Fireteam — Parallel Specialists
- Agent Workspace
- Reverse Shells
Scanning & OSINT
- Adversarial AI Recon
- JS Reconnaissance
- GraphQL Security Testing
- Subdomain Takeover Detection
- VHost & SNI Enumeration
- GVM Vulnerability Scanning
- GitHub Secret Hunting
- TruffleHog Secret Scanning
AI & Automation
- AI Model Providers
- MCP Tool Plugins
- Knowledge Base & Web Search
- Agent Skills
- Chat Skills
- Tradecraft Lookup
- Playwright Browser Automation
- CypherFix — Automated Remediation
- Rules of Engagement (RoE)
HackLab
Analysis & Reporting
- Insights Dashboard
- Pentest Reports
- Attack Surface Graph
- Surface Shaper
- EvoGraph — Attack Chain Evolution
- Data Export & Import
Contributing
Reference & Help