Add an SMB to MSSQL NTLM Relay module

[zeroSteiner]

This adds a new NTLM relay module for relaying from SMB to MSSQL servers. On success, an MSSQL session will be opened to allow the user to run arbitrary queries and some modules.

The authentication code in the existing MSSQL client module was pretty dense and not readily reusable. This also refactors that to break down the different authentication mechanisms into their own methods. Some structures were migrated to BinData, which is the current way of doing binary protocols in Metasploit. Moving these structures into bindata reduces the code to create what is now the MsTdsLogin7 structure from 4 different places (3 login methods and now the relay). The USE_WINDOWS_AUTHENT option has been removed because it's redundant with the new Mssql::Auth option which is more explicit. Specs are included for the bindata structures, showing that they can be constructed and parsed.

There's still an issue which predates this work where if the target MSSQL server requires encryption, the session creation will fail after authentication. This is tracked in #18745.

Verification

• Install MSSQL Server on a Domain Joined host. Ensure that Windows Authentication mode is enabled.
• Start msfconsole, and use the module.
• Set RHOSTS to target the MSSQL server.
• On another host, use net use to trigger an authentication attempt to metasploit that can be relayed to the target.

Demo

[*] Auxiliary module running as background job 0.
[*] SMB Server is running. Listening on 0.0.0.0:445
[*] Server started.
msf auxiliary(server/relay/smb_to_mssql) > 
[*] New request from 192.168.159.10
[*] Received request for MSFLAB\smcintyre
[*] Relaying to next target mssql://192.168.159.166:1433
[+] Identity: MSFLAB\smcintyre - Successfully authenticated against relay target mssql://192.168.159.166:1433
[+] Relay succeeded
[*] MSSQL session 1 opened (192.168.159.128:35967 -> 192.168.159.166:1433) at 2025-10-21 09:33:19 -0400
[*] Received request for MSFLAB\smcintyre
[*] Identity: MSFLAB\smcintyre - All targets relayed to
[*] New request from 192.168.159.10
[*] Received request for MSFLAB\smcintyre
[*] Identity: MSFLAB\smcintyre - All targets relayed to
[*] Received request for MSFLAB\smcintyre
[*] Identity: MSFLAB\smcintyre - All targets relayed to
msf auxiliary(server/relay/smb_to_mssql) > sessions -i -1
[*] Starting interaction with 1...
mssql @ 192.168.159.166:1433 (master) > query 'SELECT @@version'
Response
========
    #  NULL
    -  ----
    0  Microsoft SQL Server 2019 (RTM-GDR) (KB5065223) - 15.0.2145.1 (X64) 
    Aug 13 2025 11:31:46 
    Copyright (C) 2019 Microsoft Corporation
    Standard Edition (64-bit) on Windows Server 2025 Standard 10.0 <X64> (Build 26100: ) (Hypervisor)
mssql @ 192.168.159.166:1433 (master) > 

[jvoisin]

Suggested change

	Proxies no A proxy chain of format type:host:port[,type:host:port][...]. Supported proxies: sapni, socks4, http, socks5, socks5
	Proxies no A proxy chain of format type:host:port[,type:host:port][...]. Supported proxy types: sapni, socks4, http, socks5, socks5

[zeroSteiner]

These seemed very wrong. At least on the database server I freshly installed, there is no MSSQL database. Using this as the default value meant that authentication was failing unless I explicitly cleared it. If the credentials are correct but a database is specified and it doesn't exist, authentication will fail.

Also the default username that's created when the database is installed is sa not MSSQL.