Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Term1N8 opened this issue Jan 5, 2024 · 10 comments
Closed

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

Term1N8 opened this issue Jan 5, 2024 · 10 comments
Assignees
Labels
medium Medium priority item waiting for response Further information is needed from people who opened the issue or pull request

Comments

@Term1N8
Copy link

Term1N8 commented Jan 5, 2024

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.

@PocketDC
Copy link

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

@Term1N8
Copy link
Author

Term1N8 commented Jan 11, 2024

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
Copy link

Zamanry commented Jan 17, 2024

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

@anadrianmanrique anadrianmanrique added the medium Medium priority item label Jan 18, 2024
@mbb5546
Copy link

mbb5546 commented May 23, 2024

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
Copy link
Collaborator

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

@gabrielg5 gabrielg5 added the waiting for response Further information is needed from people who opened the issue or pull request label Aug 6, 2024
@kopfjager007
Copy link

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
Copy link
Collaborator

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
Copy link

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
Copy link

J005 commented Aug 13, 2024

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
Copy link
Collaborator

Closed after #1789

thank you all

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
medium Medium priority item waiting for response Further information is needed from people who opened the issue or pull request
Projects
None yet
Development

No branches or pull requests

8 participants