← All walkthroughs

SQL injection to remote code execution

A SQL injection flaw exposes the database, then the database's own features — command execution or file write — are leveraged into a shell on the server.

Web application with a SQL back end Intermediate WebSQL injectionExecution
Authorized testing only. This is a conceptual, defensive-aware walkthrough that maps an attack path to MITRE ATT&CK, detection and mitigation, and links to references for the detail. It is not a copy-paste playbook. Use it only against systems you own or are explicitly permitted to test.

Scenario

An authorized web application test. You have found a parameter vulnerable to SQL injection. The objective is to show how a data-layer flaw escalates from information disclosure to code execution on the host.

Practice this path: OWASP WSTG · MITRE ATT&CK
  1. 1

    Initial Access / Discovery

    Confirm and characterise the injection

    T1190 Exploit Public-Facing Application

    Verify the injection point and determine the DBMS, privileges and whether stacked queries are allowed — this decides which escalation paths are even possible.

    Detection

    SQL errors, UNION patterns and tautologies in query logs and WAF alerts flag injection attempts.

    Mitigation

    Use parameterised queries/prepared statements, least-privilege DB accounts, and a WAF as defence in depth.

    References sqlinjection · sqlmap
  2. 2

    Collection

    Demonstrate data exposure

    T1213 Data from Information Repositories

    Read a limited, agreed sample from the database (schema, a few rows) to prove impact — never bulk-exfiltrating real customer data.

    Detection

    Unusual high-volume reads, access to tables the app never touches, and information_schema queries are visible in DB audit logs.

    Mitigation

    Database activity monitoring, query allow-listing, and encryption of sensitive columns at rest.

    References sqlinjection
  3. 3

    Execution

    Turn database access into command execution

    T1059 Command and Scripting Interpreter

    Where the DB account permits it, use the database's own features — such as command-execution procedures, user-defined functions, or writing a file to a web-served directory — to run code on the host. Report each capability as a privilege finding.

    Detection

    The database process spawning a shell, or new files appearing in web roots, are high-fidelity host alerts.

    Mitigation

    Disable dangerous DB features (e.g. command-shell procedures), run the DB as a low-privileged service account, and make web roots non-writable by the DB.

    References command-injection · sqlmap
  4. 4

    Persistence

    Establish a foothold

    T1505.003 Server Software Component: Web Shell

    If a file write to a web-accessible path is possible, demonstrate a minimal web shell to confirm code execution, then document and remove it as part of clean-up.

    Detection

    New executable files in web directories and web requests to unknown endpoints are detectable with file-integrity monitoring and web logs.

    Mitigation

    File-integrity monitoring on web roots, disallow script execution in upload/writable paths, and review for unexpected files.

    References reverse-shell · pivoting-tunneling

Key takeaways

  • SQL injection is not only a data-disclosure bug — with a privileged DB account it becomes code execution.
  • Parameterised queries stop the injection; a least-privilege DB account limits how far it can go if one slips through.
  • Disable command-execution DB features and keep web roots unwritable so data access cannot become a shell.