Support Encrypted MSSQL Sessions

[zeroSteiner]

This enables sessions to MSSQL servers that require encryption. Currently, Metasploit can bruteforce MSSQL servers that offer/require encryption because our login method will proxy the traffic over an SSL socket using the old TDSSSLProxy class. The existing logic didn't support sessions though, so when a user wanted encryption (set SSL to true) or the server required it, Metasploit would fail to establish an interactive session or do anything after the login operation. Metasploit was effecitvely unable to communicate with the MSSQL server after the login operation when encryption was requried or enabled.

These changes add a new MsTds::Channel which leverages Rex's socket abstraction to facilitate the necessary encapsulation for the TLS negotiation. The TLS negotiation is more complex than other protocols because the frames used during the negotiation process have to be encapsulated within MS-TDS framing. Once TLS is established, the MS-TDS frames are within the tunnel. This encapsulation can be seen in the MsTds::Channel class #write and #_read_handler methods.

The MsTds::Channel has a couple of advantages over the old proxy class. The first is the channel object is now always used for the communication, there's no need to switch to writing to the proxy object or swap sockets instead when SSL is in use. The second is that it's using the new Rex::Proto::Tcp#starttls method which ensures that the TLS options are consistent with other usages in the framework.

Requires:

• Add a fiber-based relay manager rex-core#44
  • Needed for the fiber-backed IO-relay manager which allows the channel to operate with 1 relay thread instead of 2, also reduces the code because monitor_sock can be used with the callbacks
• Add the #starttls method for TCP sockets rex-socket#79
  • Adds the #starttls method

Closes #18745

Verification

• Test the new MsTds::Channel object
  • Setup an MSSQL server that requires encryption
  • Use the mssql_login module to authenticate to it and establish an interactive session
  • Test that you can relay to this same server that requires encryption
• Test pivoted TCP client channels work with Meterpreter
  • Establish a Meterpreter session (IIRC, all meterpreter support TCP client channels)
  • From the msfconsole prompt, not meterpreter, use the connect command and the -c argument to specify the session object, connect to a netcat listener
  • Test that IO works both ways from Meterpreter to the netcat listern and from the netcat listener to meterpreter
  • Test that the connection can be closed by both sides, just Ctrl+C from Metasploit, repeat the connection setup and terminate it from the netcat listener
    • This is a critical step that demonstrates the channel clean up logic is working as intended with the refactoring. Regardless of who closes the connection, the close operation should be propagated to the peer and fully processed to close the socket, exit the relay, close and cleanup the Meterpreter channel object, etc. This can also be tested for the MsTds::Channel by closing the connection from the MSSQL server using the KILL query verb just know that the KILL query can't be used to kill the connection that's making the query.
• Optionally test PostgreSQL encryption connections work (they were switched to the new #starttls method)
• Optionally test WebSockets still work with the refactoring, credentials are available to make this easy, just reach out

[zeroSteiner]

This was removed because the #close method is no longer replaced with something that'd close the channel. The original logic was prone to creating recursion loops during development and would send a close command back to Meterpreter when Meterpreter initiated the close operation.

The new implementation should simply things by always closing the channel from the channel object level instead of the rsock. Now when a channel is closed by Meterpreter, the #dio_close_handler will simply close and cleanup the channel locally without echoing the command back to Meterpreter.

When the channel is closed by Metasploit Framework, it's either closed by lsock.close which causes an EOF to be read in the Relay Manager which will dispatch to the on_exit callback, which by default calls #close_write. Alternatively, the channel object can be closed directly, but there's no longer a loop as everything is notified.

[zeroSteiner]

I started work on a test module for testing socket channels (TCP client, TCP server and UDP). It's a WIP, but can be used for testing here: https://github.com/zeroSteiner/metasploit-framework/blob/feat/mod/socket-channel-tests/test/modules/post/test/socket_channels.rb

I think it probably makes sense to keep it in a separate branch and PR it on its own especially if there are pre-existing issues and inconsistencies.

Preview

msf post(test/socket_channels) > rerun
[*] Reloading module...
[*] Running against session 2
[*] Session type is meterpreter and platform is linux
[*] Running TCP client channel tests...
[+] Receives data from the peer
[+] Sends data to the peer
[+] Propagates close events to the peer
[+] Propagates close events from the peer
[*] Running UDP client channel tests...
[+] Receives data from the peer
[+] Sends data to the peer
[*] Passed: 6; Failed: 0; Skipped: 0
[*] Post module execution completed
msf post(test/socket_channels) >

[zeroSteiner]

I managed to rebase this after the socket channel tests were landed. This should be unblocked and ready for review now.

[zeroSteiner]

Now this has been rebased again to include the relaying code. The combo here enables relaying NTLM to servers that require TLS connections.

[jheysel-r7]

Great work @zeroSteiner. Everything is working as expected.

Thanks for pushing changes to the Gemfiles to make for easy testing 🙏

Testing

MSSQL encrypted authentication working:

msf auxiliary(scanner/mssql/mssql_login) > run
[*] 172.16.199.131:1433   - MSSQL - Starting authentication scanner.
[*] 172.16.199.131:1433   - TDS Encryption enabled
[!] No active DB -- Credential data will not be saved!
[+] 172.16.199.131:1433   - Login Successful: KERBEROS\Administrator:N0tpassword!
[*] 172.16.199.131:1433   - Scanned 1 of 1 hosts (100% complete)
[*] 172.16.199.131:1433   - Bruteforce completed, 1 credential was successful.
[*] 172.16.199.131:1433   - You can open an MSSQL session with these credentials and CreateSession set to true
[*] Auxiliary module execution completed

Encrypted SMB to MSSQL relay working:

msf auxiliary(server/relay/smb_to_mssql) > set rhosts 172.16.199.131
rhosts => 172.16.199.131
msf auxiliary(server/relay/smb_to_mssql) > run
[*] Auxiliary module running as background job 0.
msf auxiliary(server/relay/smb_to_mssql) >
[*] SMB Server is running. Listening on 0.0.0.0:445
[*] Server started.
[*] New request from 172.16.199.200
[*] Received request for \Administrator
[*] Relaying to next target mssql://172.16.199.131:1433
[*] TLS encryption has been enabled based on server response.
[+] Identity: \Administrator - Successfully authenticated against relay target mssql://172.16.199.131:1433
[SMB] NTLMv1-SSP Client     : 172.16.199.131
[SMB] NTLMv1-SSP Username   : \Administrator
[SMB] NTLMv1-SSP Hash       : Administrator:::59ebf02d1dc00f5b00000000000000000000000000000000:d63ca2db774f8cdfff351d142ad023e890ad6b124f02261a:82d8300f1243a3c4

[+] Relay succeeded
[*] MSSQL session 1 opened (172.16.199.1:51281 -> 172.16.199.131:1433) at 2025-12-02 09:57:40 -0800
[*] Received request for \Administrator
[*] Identity: \Administrator - All targets relayed to
[*] New request from 172.16.199.200
[*] Received request for KERBEROS\Administrator
[*] Relaying to next target mssql://172.16.199.131:1433
[*] TLS encryption has been enabled based on server response.
[+] Identity: KERBEROS\Administrator - Successfully authenticated against relay target mssql://172.16.199.131:1433
[SMB] NTLMv1-SSP Client     : 172.16.199.131
[SMB] NTLMv1-SSP Username   : KERBEROS\Administrator
[SMB] NTLMv1-SSP Hash       : Administrator::KERBEROS:27b938bb1e684cf700000000000000000000000000000000:9503699648f3bdc2b9d69919134a2682016f56d2e8295f85:4c197f51b006836a

[+] Relay succeeded
[*] MSSQL session 2 opened (172.16.199.1:51298 -> 172.16.199.131:1433) at 2025-12-02 09:57:42 -0800
[*] Received request for KERBEROS\Administrator
[*] Identity: KERBEROS\Administrator - All targets relayed to

Pivoted TCP client channel I/O works in both directions.
Both have the ability to close the connection:

PosgreSQL over SSL working:

msf auxiliary(scanner/postgres/postgres_login) > set createsession true
createsession => true
msf auxiliary(scanner/postgres/postgres_login) > set ssl true
ssl => true
msf auxiliary(scanner/postgres/postgres_login) > run
[!] 172.16.199.136:5432   - No active DB -- Credential data will not be saved!
[+] 172.16.199.136:5432   - 172.16.199.136:5432 - Login Successful: msfuser:testpass@msfdb
[*] PostgreSQL session 8 opened (172.16.199.1:52048 -> 172.16.199.136:5432) at 2025-12-02 11:31:40 -0800
[*] 172.16.199.136:5432   - Scanned 1 of 1 hosts (100% complete)
[*] 172.16.199.136:5432   - Bruteforce completed, 1 credential was successful.
[*] 172.16.199.136:5432   - 1 Postgres session was opened successfully.
[*] Auxiliary module execution completed

[jheysel-r7]

Release Notes

This enables sessions to MSSQL servers that require encryption. These changes add a new MsTds::Channel which leverages Rex's socket abstraction to facilitate the necessary encapsulation for the TLS negotiation.