In penetration testing, we often encounter an MSSQL database. Usually, we will use an extended procedure like xp_cmdshell to perform privilege escalation or execute system commands. However, when xp_cmdshell is unused, what other methods can we leverage? We are publishing two blogs to introduce how to achieve post-penetration based on the exploit of MSSQL. This blog is Part One: Detect MSSQL service.

Detect MSSQL Service

To quickly find all the surviving MSSQL instances in the target Intranet, we conduct a large scan. However, since such scanning would be very “noisy,” it is likely to be detected by network traffic monitoring devices. We need a “stealthier” tool like the two introduced below. They are Windows-based and commonly used to identify MSSQL services quickly and quietly.

• Detectan MSSQL instance based on the working group:

The System.Data.SqlClient namespace provides a program-to-SQL Server’s .NET data. In the .NET framework 2.0, the SqlDataSourceEnumerator class is newly added to provide a mechanism for enumerating all available SQL Server instances in the local network.

  • Detect MSSQL instance in a Windows domain environment:

Query by SPN: SPN is the unique identifier of a service running on the server. Each service using Kerberos needs to register an SPN to initiate LDAP queries to the domain controller. This service is a part of normal Kerberos ticketing behavior. Therefore, the operation of querying an SPN is challenging to be detected by a monitoring system. Here we use the system’s native tools to query:

The above are the two commonly used methods for quickly detecting MSSQL services based on Windows native tools. Next, we will share with you the exploit of MSSQL-enable the target MSSQL xp_cmdshell.