SEC504 - Hacker Tools, Techniques, and Incident Handling

SQL Injection and Database Exfiltration with sqlmap

Solo, Lab

Print command sheet

Focus: Web Application Security

Level: SEC504

Date: Jul 2026

Artifacts: Sanitized manual probe and sqlmap output from the SEC504 web lab against support.falsimentis.com/kb

TL;DR

•A single quote in the search box returned a MariaDB 1064 error, confirming SQLi by hand
•sqlmap found only 'search' injectable (not 'entityid') via four techniques and enumerated the database
•--dump pulled 12 users with roles and password hashes; sqlmap cracked one inline to Password123

Skills demonstrated

Manual SQL injection confirmation (error-based)Automated exploitation with sqlmapParameter-level injectability testingDatabase enumeration ladder (--dbs, --tables, --dump)Inline hash cracking of dumped credentials

Note: Course-provided PCAPs and lab instructions are not shared. Only my own captures and sanitized notes are published.

Why this matters

SQL injection remains one of the highest-impact web findings because it exposes the entire database, credentials, roles, everything, and here a single quote in a search box was enough to confirm it. The detail that matters for reviews is that only one of two parameters was injectable: sqlmap tested both and told me which, which is why parameter-level testing beats assuming the whole endpoint is safe or unsafe. Parameterized queries would have closed this completely.

Context

This lab confirms a SQL injection by hand with a single quote, then uses sqlmap to characterize it and walk the enumeration ladder from databases to tables to a full table dump. It also shows sqlmap distinguishing an injectable parameter from a non-injectable one on the same URL, and cracking recovered password hashes inline.

Tools used

sqlmap 1.5.2curl / browserSlingshot Linux

Steps taken

1Confirm by hand

Appending a single quote to the search parameter (search=RAG') returned '1064, You have an error in your SQL syntax ... MariaDB' directly on the page. A one-character manual probe confirms the injection before sqlmap is ever launched, and tells you the backend is MySQL/MariaDB.

$ # /kb?entityid=3487&search=RAG'

A single quote breaks the query -> 1064 syntax error = confirmed SQLi

2Characterize with sqlmap

sqlmap tested both parameters. entityid was not injectable; search was, via boolean-based blind, error-based (FLOOR/EXTRACTVALUE), time-based blind (SLEEP), and a 3-column UNION query. It confirmed the backend as MySQL >= 5.0 (MariaDB fork) and stored the session so later runs resume instantly.

$ sqlmap -u "http://support.falsimentis.com/kb?entityid=3487&search=RAG"

sqlmap tests each parameter and reports which is injectable and how

3Enumerate databases

--dbs listed the available databases: information_schema (always present) and support (the application's). This is the top rung of the enumeration ladder.

$ sqlmap -u "..." --dbs

--dbslist databases; support is the app's

4Enumerate tables

-D support --tables listed chat, contact, kb, tickets, and users. The users table is the obvious next target for credential recovery.

$ sqlmap -u "..." -D support --tables

-D <db> --tableslist tables in the chosen database

5Dump the users table

-D support -T users --dump recovered 12 users with names, emails, usernames, roles (sme, admin, audit), and password hashes. sqlmap recognized the password column as hashes and cracked one inline, annotating it (Password123). Full credential and role disclosure from a single quote in a search box.

$ sqlmap -u "..." -D support -T users --dump

--dumpextract the table; sqlmap offers to crack recognized hashes

Key findings

A single quote in 'search' returned a MariaDB 1064 error (manual confirmation)

sqlmap found 'search' injectable via 4 techniques; 'entityid' was not injectable

Enumerated support DB tables: chat, contact, kb, tickets, users

--dump recovered 12 users with roles (sme/admin/audit) and password hashes

sqlmap cracked one hash inline to Password123

Outcome / Lessons learned

Confirmed a SQL injection by hand with a single quote, then used sqlmap to identify the one injectable parameter, enumerate the database, and dump 12 users with roles and password hashes, one of which cracked inline to Password123. A search box became full database and credential disclosure.

Use parameterized queries (prepared statements) everywhere, which closes this class of bug completely regardless of input. Apply least-privilege to the database account so the web app cannot read information_schema or unrelated tables. Store passwords with a slow salted hash (bcrypt/argon2), not the fast hashes seen here, and return generic error pages so a 1064 never reaches the client. Add WAF coverage and alerting for injection patterns, and test every parameter, since only one of two was vulnerable here.

Security controls relevant

Parameterized queries / prepared statements
Least-privilege database account
Slow salted password hashing (bcrypt/argon2)
Generic error handling (no SQL errors to the client)
Per-parameter injection testing and WAF coverage

What I took away from this

One character confirmed the whole finding. A single quote that produces a 1064 error tells you the input reaches the query unescaped and that the backend is MariaDB, before any automated tool runs. That manual step matters: it validates the vulnerability, guides sqlmap, and in a report it is far more convincing than 'the scanner said so.' Parameterized queries would make that single quote inert, which is the entire fix.

Parameter-level testing is the operational lesson. The endpoint had two parameters and only one was injectable; assuming the URL was uniformly safe or unsafe would have been wrong either way. sqlmap tested each and reported which, and that granularity is exactly how injection review has to work, because a single unparameterized parameter among many is all it takes to expose the whole database.