NTLMRelayX Multirelay fixes and behavioral changes #1741
Merged
Conversation
This file contains 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
* [MULTIRELAY][Default Behavior] The relay will cycle over its target list only once, this matches the behavior of the single relay mode * [MULTIRELAY] Added a flag to cycle over the target list any time a new connection is established, essentially relaying against each target in the list for every incoming connection * [MULTIRELAY] HTTP server will stop consuming targets after the first failed attempt, this matches the behavior of SMB server * Fixed issue in HTTP server when an unhandled exception occurs while trying to establish a connection with the target. Now it is recorded as a failed attempt.
…rget is now (internally) marked as "failed" * Bugfix: initclient-> unhandled return status of client.initconnection, now properly raises an exception when that call fails * Bugfix: enable-retries now works with smbserver
* [MULTIRELAY][Default Behavior] The relay will cycle over its target list only once, this matches the behavior of the single relay mode * [MULTIRELAY] Added a flag to cycle over the target list any time a new connection is established, essentially relaying against each target in the list for every incoming connection * [MULTIRELAY] HTTP server will stop consuming targets after the first failed attempt, this matches the behavior of SMB server * Fixed issue in HTTP server when an unhandled exception occurs while trying to establish a connection with the target. Now it is recorded as a failed attempt.
…rget is now (internally) marked as "failed" * Bugfix: initclient-> unhandled return status of client.initconnection, now properly raises an exception when that call fails * Bugfix: enable-retries now works with smbserver
* Set default value of keep-relaying flag to False
# Conflicts: # examples/ntlmrelayx.py # impacket/examples/ntlmrelayx/servers/httprelayserver.py # impacket/examples/ntlmrelayx/servers/smbrelayserver.py # impacket/examples/ntlmrelayx/utils/config.py
anadrianmanrique
added
bug
This was
linked to
issues
May 6, 2024
Closed
|
Excellent job! merging now |
This was referenced May 6, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 changeset addresses the issues reported in #1694
A new flag was introduced to ntlmrelayx
--keep-relayingwhich instructs the relay to keep cycling over its targets indefinitely.This means that whether or not a relay attempt was successful against its target, said target won't ever be discarded and future connections will be relayed to it.
Keep in mind that in multirelay mode, when relaying fails against a target, no further targets will be processed until the relay receives new connection.
An example with 3 targets (always successful, multirelay enabled):
3 Targets and (the second always fails, multirelay enbled):