Ntlmrelayx doesn't relay or log connections when -tf is used
Term1N8 opened this issue · 10 comments
Configuration
impacket version: v0.11.0
Python version: 3.8.10
Target OS: Ubuntu 20.04.6
Command: ntlmrelayx.py -tf hosts.txt -smb2support -debug -of hashes.txt
Result: no connections are logged, no debug activity, and hashes are logged in hashes.txt. When replacing -tf with -t connections are received/logged as normal. Tried using a targets file generated by netexec (new crackmapexec), as well as manually.
Same problem here, -tf gives me nothing but individual targets (from the same file) will
The problem above occurred when installing via pipx. When using the ntlmrelayx.py file in the examples dir, a different issue happens where every connection says "connection will be relayed after re-authentication". Works fine with -t "host", as soon as I switch to -tf list.txt it breaks.
My team had multiple unique hosts within a file and we had successful execution of ntlmrelay. Python 3.9 on Kali Linux. We installed Impacket via apt-get. Impacket v0.10.0
Also having these issues, I Installed impacket by cloning the project and then configuring a venv with virtualenv. From within the venv I ran the setup.py script.
Running ntlmrelayx with the -tf flag seems broken and when relaying authentication the following message is received over and over again
[*] Received connection from ACME/User123 at Computerabc, connection will be relayed after re-authentication
Pivoting to using the -t flag works as normal. -tf seems to be working incorrectly.
Hey hello,
Going through the ticket to understand this scenario and relate with latest changes in ntlmrelayx. It seems to be related with the multi-relay feature (#767).
Multi-relay is enabled when using -tf and disabled when using -t by default. That's why you faced different behaviors when defining targets one way or the other.
Multirelay leverages client's ability to reauthenticate after triggering a first authentication request. So, if client does not honour this condition, no connection will end up being relayed (We Love Relaying Credentials: A Technical Guide to Relaying Credentials Everywhere (secureauth.com))
A couple months ago we merged a PR (#1602) that added a log message when first connection attempt was received in the relay server; letting users know that an authentication was performed - even if, by how the client behaves, it is not relayed afterwards -
That's the behavior change @mbb5546 comments about; that's the log message that was added.
Multi-relay capabilities can be disabled with the flag --no-multirelay (#1128). Useful, among others, in scenarios like these you are facing now
I seem to also be experiencing this issue, but only when running with both -tf and -w flags. I have a targets file of about 30 hosts and got relay from low-priv users. Once each host had a single relay session, no more sessions are created when other connections for other users come in. Usually I'll get a session on each target for each user (where applicable), but not when running with both -tf and -w. I had a domain admin relay come in and since all targets seemed to have one relay session, it just spits out "connection will be relayed after re-authentication" (numerous times)... so i'm not getting relay with a high-priv user, or any subsequent users, unless I re-run ntlmrelayx and omit the -w flag. If i omit the -w flag I get relay for each user and each host (where applicable) and don't see the log/error "connection will be relayed after re-authentication".
Impacket version: impacket 0.12.0.dev1+20240731.132353.0f64d63
Installed via: pipx install git+https://github.com/fortra/impacket
Python version: 3.10.12
OS: Ubuntu Server 20.04 x64
Hi @kopfjager007,
That seems like another issue. Will try to replay what you mention in my lab related to the -w flag.
In the meantime, have you tried with the newly added --keep-relaying flag? We added it a couple weeks ago in the context of #1741
I guess it will come in handy in your scenario as you need to keep considering targets despite having a relayed connection
Let us know how that goes.
Hi @kopfjager007, That seems like another issue. Will try to replay what you mention in my lab related to the
-wflag.In the meantime, have you tried with the newly added
--keep-relayingflag? We added it a couple weeks ago in the context of #1741 I guess it will come in handy in your scenario as you need to keep considering targets despite having a relayed connectionLet us know how that goes.
Thanks for the reply @gabrielg5! I saw the new flag --keep-relaying after (naturally...) I posted the previous comment. Using --keep-relaying performs as expected and "solves" my issue. Although the real issue for me turns out to be me not reading, so I'll just go sit in the corner for a while for that :). Thanks again!
Hey hello,
Going through the ticket to understand this scenario and relate with latest changes in ntlmrelayx. It seems to be related with the multi-relay feature (#767).
Multi-relay is enabled when using
-tfand disabled when using-tby default. That's why you faced different behaviors when defining targets one way or the other.Multirelay leverages client's ability to reauthenticate after triggering a first authentication request. So, if client does not honour this condition, no connection will end up being relayed (We Love Relaying Credentials: A Technical Guide to Relaying Credentials Everywhere (secureauth.com))
A couple months ago we merged a PR (#1602) that added a log message when first connection attempt was received in the relay server; letting users know that an authentication was performed - even if, by how the client behaves, it is not relayed afterwards - That's the behavior change @mbb5546 comments about; that's the log message that was added.
Multi-relay capabilities can be disabled with the flag
--no-multirelay(#1128). Useful, among others, in scenarios like these you are facing now
The --no-multirelay flag resolves the issue for me, Thanks @gabrielg5