312-50 Question 337
Single answer▪ Attack Database ConnectivityDuring an authorized internal assessment, you discover a legacy web application that connects to a Microsoft SQL Server backend. The application uses a low-privileged database account, but the database server has the SQL Server Browser service enabled and listens on the default port. You successfully authenticate to the database using exposed credentials found in a configuration file. Your goal is to determine whether the database connectivity can be abused to achieve remote command execution on the underlying Windows host without relying on a vulnerability in the web application itself. Which action is the most appropriate next step?
- A
Use the SQL Server connection to check whether xp_cmdshell can be enabled or is already enabled, and if your database context has sufficient privileges to execute OS commands
- B
Exploit the SQL Server Browser service directly to obtain a remote shell because it is designed to execute administrative requests remotely
- C
Assume that successful database authentication automatically provides SYSTEM-level access on the Windows host and proceed with privilege escalation
- D
Capture the SQL Server traffic and decrypt TDS packets to force the server to reveal the sa password in plaintext
Show answer and explanation
Correct answer: A
Explanation
This question focuses on abusing database connectivity rather than exploiting the web application itself. In real assessments, once an ethical hacker gains valid DB credentials, the next step is to determine what those credentials allow within the database engine and whether that access can be pivoted into host-level execution. For Microsoft SQL Server, xp_cmdshell is a well-known extended stored procedure that can execute OS commands, but Microsoft documents that it is disabled by default and should be enabled only when necessary. Testing whether it is enabled, and whether the current principal has privileges such as sysadmin, is therefore a realistic and exam-relevant next action. SQL Server Browser, by contrast, supports instance discovery and does not itself provide command execution. Likewise, successful DB authentication does not imply OS-level control, and packet capture is not the proper next move when the objective is to assess abuse paths from authenticated DB access. Relevant references include Microsoft documentation on xp_cmdshell, server configuration via sp_configure, and SQL Server security best practices regarding least privilege and separation of database and operating system permissions.
- A. Correct.
Correct. In a CEH-style attack-database-connectivity scenario, once valid SQL Server credentials are obtained, the practical next step is to evaluate whether database features can be abused for host-level command execution. On Microsoft SQL Server, xp_cmdshell is the classic mechanism to run operating system commands, but it is disabled by default on modern versions and typically requires high privileges such as sysadmin to enable or use. Verifying whether it is enabled and whether the current login has the required privileges is a realistic and technically correct way to assess abuse of database connectivity.
- B. Incorrect.
Incorrect. SQL Server Browser helps clients discover SQL Server instances and ports, especially for named instances, but it is not a remote command execution interface. A common misconception is that because Browser exposes instance information over the network, it can be directly abused to execute commands. In reality, it is an enumeration aid, not a shell mechanism.
- C. Incorrect.
Incorrect. Database authentication does not automatically grant operating system access, much less SYSTEM-level access. The database account's permissions are separate from Windows privileges, although some database features may bridge that boundary if misconfigured. This option reflects a dangerous misunderstanding of trust boundaries between application, database, and host layers.
- D. Incorrect.
Incorrect. TDS is the Tabular Data Stream protocol used by SQL Server, but decrypting captured traffic is not a valid method for forcing disclosure of the sa password. If encryption is enabled, passive decryption is not feasible without keys; if encryption is not enabled, plaintext credentials might be observed only under certain authentication methods and circumstances. More importantly, this does not represent the most appropriate next step after already obtaining valid credentials and wanting to test abuse of database connectivity for code execution.