312-50 Question 336
Single answer▪ Attack Database ConnectivityDuring an authorized internal assessment, you discover a legacy web application that connects to a Microsoft SQL Server using an ODBC DSN stored on the web server. The application itself does not appear vulnerable to SQL injection, but you obtain low-privilege access to the web server and find the DSN configuration references a SQL login used by the application. You want to verify whether the database connectivity can be abused to expand access without modifying application code or attacking the SQL Server over the network directly. Which action is the MOST appropriate next step?
- A
Use the recovered DSN details to authenticate to SQL Server with an ODBC client from the compromised host and enumerate the database privileges of the application account
- B
Change the DSN to point to a different database server and observe whether the application sends plaintext credentials during login
- C
Assume the DSN password is hashed and attempt offline cracking before trying any database connection
- D
Exploit the SQL Server by sending SMB relay traffic to TCP 1433 from a separate workstation to capture the service account credentials
Show answer and explanation
Correct answer: A
Explanation
This question focuses on a common real-world CEH scenario: abusing database connectivity through credentials or configuration artifacts stored on an application server rather than through direct SQL injection. In Windows environments, ODBC DSNs and application configuration files may store or reference connection information for SQL Server, Oracle, MySQL, or other databases. A sound next step in an authorized engagement is to use those recovered details from the compromised host to authenticate with an appropriate client and enumerate privileges, such as accessible databases, roles, and potentially dangerous rights. This follows the principle of validating exposure with the least disruptive method available. Relevant best practices from Microsoft SQL Server security guidance emphasize least privilege for service and application accounts, because an overprivileged application login can turn host compromise into database compromise. Similarly, secure development guidance generally recommends protecting secrets in configuration, limiting DSN use where possible, and avoiding embedded high-privilege database credentials. The key applied lesson is that database connectivity itself can be the attack path when connection details are exposed, even if the application is not vulnerable to SQL injection.
- A. Correct.
Correct. If the DSN contains usable connection details, the most appropriate next step is to test database connectivity from the compromised host using the same context the application relies on, then enumerate what the application account can actually do. This is a practical and controlled way to assess whether database connectivity can be abused through weak credential storage or overprivileged service accounts. In a CEH-style scenario, this aligns with attacking database connectivity by leveraging stored connection information such as ODBC DSNs, connection strings, or application configuration files to authenticate and assess access.
- B. Incorrect.
Incorrect. Changing the DSN on a production-like application host is intrusive and can disrupt the application. It also does not represent the safest or most direct way to validate abuse of existing database connectivity. Additionally, SQL Server authentication over standard connections is not something you would test by redirecting a live application to another host unless explicitly authorized for an invasive test plan.
- C. Incorrect.
Incorrect. DSN credentials used by applications are often recoverable in usable form or otherwise retrievable through system configuration or application context; assuming they must first be cracked is the misconception. The more appropriate first step is to validate whether the recovered details already permit authentication. Attempting offline cracking before testing the actual connection adds unnecessary effort and may not apply at all.
- D. Incorrect.
Incorrect. This option mixes unrelated attack concepts. TCP 1433 is SQL Server's default port, but SMB relay is a separate protocol abuse technique and is not a normal or direct method for validating abuse of database connectivity from recovered ODBC settings. It also ignores the scenario's constraint that the tester should not attack the SQL Server over the network directly from another system.