Direct SQL access is different from web SQL injection.
In the web chapter, the application is the entry point. In this chapter, we assume a database service is directly reachable or credentials have already been obtained through another path: config files, backups, environment variables, password reuse, shell access, Kerberoasting, SQL injection, or a previous host compromise.
The objective is to turn database access into impact.
Core Methodology
Use this order:
- Identify the database engine.
- Connect with the available authentication method.
- Determine the current login and execution context.
- Enumerate roles, grants, and dangerous privileges.
- Enumerate databases, schemas, tables, and sensitive data.
- Check file read/write primitives.
- Check command execution primitives.
- Check privilege escalation paths.
- Check lateral movement paths.
- Clean up lab artifacts and document detections/remediation.
The important question is not only "can we query data?"
The important question is:
What can this database identity make the server, client, domain, or filesystem do?
Engines Covered
| Engine | Main Attack Surface |
|---|---|
| MySQL | Grants, FILE privilege, secure_file_priv, local_infile, INTO OUTFILE, UDFs, plugin directory writes, webshell chains. |
| MSSQL | Windows auth, AD context, server roles, xp_cmdshell, OLE Automation, SQL Agent, CLR, external scripts, linked servers, impersonation, UNC coercion. |
Practical Mindset
Databases often sit at a privilege boundary:
- application user to database user
- database user to database admin
- database admin to operating system command execution
- database service account to domain identity
- one SQL server to linked SQL servers
- data read to credential reuse
Every query should answer one of these:
who are we?
what can we read?
what can we write?
what can we execute?
what can we impersonate?
where can we pivot?
what should be cleaned up?