Add support for Ruby SMB Client to be compatible with Msf::Exploit::Remote::SMB::RelayServer #20967
Merged
cdelafuente-r7 merged 11 commits intorapid7:masterfrom Mar 24, 2026
Conversation
adfoster-r7
reviewed
Feb 12, 2026
jheysel-r7
changed the title
Moved gss handling to separate func as per TODO Remove debug output
jheysel-r7
force-pushed
the
fix/lib/smb_relay_ruby_client_support
branch
from
656b38b to
fe9f498
Compare
|
Thanks for your pull request! As part of our landing process, we manually verify that all modules work as expected. We've added the |
|
Additional test pipeline started ⌛ |
|
Slice summary:
Note: build results only accessible to maintainers. |
Contributor
cdelafuente-r7
left a comment
cdelafuente-r7
left a comment
There was a problem hiding this comment.
Thanks @jheysel-r7 for these updates. I tested it and it works great using one or two relay targets with the RubySMB client. I just left a few comments and questions.
One issue I found with a very specific use case is when you create a SMB session from the client, while it's being relayed by a second instance of msfconcole. The resulting SMB session ends up to be unusable.
msf auxiliary(scanner/smb/smb_login) > run verbose=true rhosts=192.168.22.1 smbuser=smbuser smbpass=123456 CreateSession=true
[*] 192.168.22.1:445 - 192.168.22.1:445 - Starting SMB login bruteforce
[+] 192.168.22.1:445 - 192.168.22.1:445 - Success: '.\smbuser:123456'
[!] 192.168.22.1:445 - No active DB -- Credential data will not be saved!
[*] SMB session 2 opened (192.168.22.129:38481 -> 192.168.22.1:445) at 2026-03-19 13:17:42 +0100
[*] 192.168.22.1:445 - Scanned 1 of 1 hosts (100% complete)
[*] 192.168.22.1:445 - Bruteforce completed, 1 credential was successful.
[*] 192.168.22.1:445 - 1 SMB session was opened successfully.
[*] Auxiliary module execution completed
msf auxiliary(scanner/smb/smb_login) > sessions
Active sessions
===============
Id Name Type Information Connection
-- ---- ---- ----------- ----------
2 smb SMB smbuser @ 192.168.22.1:445 192.168.22.129:38481 -> 192.168.22.1:445 (192.168.22.1)
msf auxiliary(scanner/smb/smb_login) > use scanner/smb/smb_enumshares
[*] New in Metasploit 6.4 - This module can target a SESSION or an RHOST
msf auxiliary(scanner/smb/smb_enumshares) > run verbose=true rhosts=192.168.22.1 session=2
[*] Using existing session 2
[*] Error: 192.168.22.1: RubySMB::Error::CommunicationError Socket read returned nil
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
I believe this is not something a user would do often, and doing so would inevitably result in a failure, but I just wanted to call it out.
Contributor
Author
|
Thanks for the review @cdelafuente-r7! Much appreciated. I thought I had seen that unusable SMB session issue before as well. After ensuring all the necessary registry keys were set appropriately to allow for SMB relaying, doing more testing to ensure the PSEXEC action was working, I wasn't able to reproduce the broken SMB session. The following output was triggered by relaying auth from a separate msfconsole window using smb_login: smb_relay CREATE_SMB_SESSION working
The following output highlights the only changes I have on the branch are pulling in the ruby_smb changes: |
Contributor
|
Oh! I'm sorry I think I was not clear. I was talking about the session created by the client running In this example, the client ( It is certainly an edge case that is not worth fixing, unless it is an easy fix, but I don't think so. |
cdelafuente-r7
moved this from In Progress
to Waiting on Contributor
in Metasploit Kanban
Contributor
Author
Oh okay, right my apologies. I thought that was to be expected (although maybe it's not!). Whenever I would relay successfully from The metasploit-framework/modules/auxiliary/scanner/smb/smb_login.rb Lines 317 to 332 in c49a376 I think this would require some extra verification that it might not be worth subjecting every SMB session to for this edge case - although let me know what you think! |
|
Additional test pipeline started ⌛ |
Contributor
|
Thank you for the last updates. I agree, it is not worth updating the original code for this. everything looks good to me. I tested with two relay targets and successfully got two sessions using another instance of |
|
Additional test pipeline started ⌛ |
|
Slice summary:
Note: build results only accessible to maintainers. |
|
Slice summary:
Note: build results only accessible to maintainers. |
cdelafuente-r7
approved these changes
Mar 24, 2026
github-project-automation
Bot
moved this from Waiting on Contributor
to In Progress
in Metasploit Kanban
Contributor
Release NotesThis fix an issue that prevents successful authentication relay from Ruby SMB Client and |
This was referenced Mar 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes the following issues:
Ruby SMB Client is incompatible with Msf::Exploit::Remote::SMB::RelayServer.
In order to relay NTLM authentication from a Ruby SMB client properly the NTLMSSP messages must first be unwrapped from their GSSAPI wrapping. The Window's
net usedoes not wrap it's NTLM message and is partially why Metasploit'ssmb_relayhas only worked withnet use- until now!smbclient is not compatible with Msf::Exploit::Remote::SMB::RelayServer
Not all smbclients respond with a reauthentication attempt to the error code
STATUS_NETWORK_SESSION_EXPIREDwhich our smb_relay server depended upon until now. This fixes the smb_relay server so that if only oneRHOSTis specified, NTLM authentication is immediately forwarded. This allowssmbclientand others to be compatible the smb_relay when only specifying one target.Due to do the large number of PRs and the fact that both of these fixes require the related fix in ruby_smb I figured I'd combine them.
Requirements
This fix requires changes from ruby_smb. Be sure to pull in those changes and reference your local copy of
ruby_smbin yourGemfileprior to testing:Testing
(The relay server out will be continued below)
msfconsoleand run thesmb_loginmodule sending the authentication request to your relay serverjobs -K, set only one RHOST and verify auth can be successfully relayed to one target bysmbclient(or any client that doesn't support resending an authentication to the session expired smb status code )Trigger the relay like so:
And verify it works: