Ntlmrelayx doesn't relay or log connections when -tf is used

[Term1N8]

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 <IP HERE> connections are received/logged as normal. Tried using a targets file generated by netexec (new crackmapexec), as well as manually.

[PocketDC]

Same problem here, -tf gives me nothing but individual targets (from the same file) will

[Term1N8]

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.

[Zamanry]

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

[mbb5546]

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.

[gabrielg5]

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

[kopfjager007]

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

[gabrielg5]

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.

[kopfjager007]

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.

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!

[J005]

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

The --no-multirelay flag resolves the issue for me, Thanks @gabrielg5

[gabrielg5]

Closed after #1789

thank you all