NTLMRelayX SMB->LDAP ensure that negotiate request disables signing

[Meatballs1]

Having this commented out prevents LDAP NTLM relay from working..?

[asolino]

That is actually a good question @Meatballs1

Any take on this @dirkjanm?

[dirkjanm]

Yes that was one of my experiments to solve the SMB->LDAP relay problem which doesn't work because the signing flag is set.
The reason it is commented out is because it is pointless to modify the flags, flag modification will cause the authentication to fail since the signature will be invalid. So SMB->LDAP is still an unsolved problem.

[Meatballs1]

Well I uncommented it out and it worked for me..!

Without this I would get a connection in, relay it to the domain controller, I would get a bind success response, then doing a searchRequest the server would just ignore my request.

I couldn't understand why, then I looked in the bind request and saw that we were setting a session key, so the server expects future requests to be signed.

I only really noticed after doing a normal query with the LDAP3 NTLM auth to compare this doesn't bother with signing as far as I can tell - or not unless its required.

[dirkjanm]

Can't reproduce this, as soon as I uncomment it the auth starts failing.
Are you sure that when it worked you were not relaying from HTTP->LDAP? This doesn't have the signing bit set and thus the code doesn't change anything here.

[asolino]

Might the target OS be the factor changing behaviour here?

[Meatballs1]

Definitely smb DC set to not require signing. Client is an appliance, not windows client. Not sure if client requests signing - presumably not!

[Meatballs1]

If this is commented out, and a session key is sent in the ntlm bind request, the requests aren't signed by the ldap3 library anyway so you can't do any queries?

…

________________________________ From: Ben Campbell <[email protected]> Sent: Thursday, October 11, 2018 7:05:58 PM To: SecureAuthCorp/impacket; SecureAuthCorp/impacket Cc: Mention Subject: Re: [SecureAuthCorp/impacket] Dunno why this commented out (#500) Definitely smb DC set to not require signing. Client is an appliance, not windows client. Not sure if client requests signing - presumably not!

[dirkjanm]

Maybe the appliance SMB/NTLM stack does not use all the security options of NTLM that Windows does and thus the removal of the flag goes unnoticed.

[asolino]

Is uncommenting this line affecting any working scenario @dirkjanm?

[Meatballs1]

Couple of tested use cases (all using -smb2support)

NetLM/NTLM

1. Windows 10 client set to use LM or NTLM auth
2. The bind request ntlmssp_negotiate left at 1
3. The bind request ntlmssp_auth succeeds
4. Server doesn't respond to further requests (as they are not signed)

NetLM/NTLM

1. Windows 10 client set to use LM or NTLM auth
2. Changing the bind request ntlmssp_negotiate sign to 0
3. The bind request ntlmssp_auth still has signing set to 1 (forwarded without changes from the client)
4. Server (W2k8R2) doesnt care that there is a discrepancy between the negotiate and the auth flags
5. Requests to the server unsigned succeed.

Windows client doesn't care that the negotiate came back with sign disabled - still sends signing to the server.
Windows server seems to base whether signing is required based on the negotiate rather than the auth.
These messages have a MIC but the NTLM attribute 'flags' is not present so it isn't checked.

NetNTLMv2

1. Windows 10 client set to use NTLMv2 auth
2. The bind request ntlmssp_negotiate left at 1
3. The bind request ntlmssp_auth succeeds
4. Server doesn't respond to further requests (as they are not signed)

NetNTLMv2

1. Windows 10 client set to use NTLMv2 auth
2. Changing the bind request ntlmssp_negotiate sign to 0
3. The bind request ntlmssp_auth still has signing set to 1 (forwarded without changes from the client)
4. Server responds with Auth Failed Security Context Error

This would appear to be due to the MIC (sent in the auth message) failing. The MIC is a hash based on all of the messages. Don't think we can modify this to get this use case to suceed?

Appliance

1. Appliance sends NTLMv2 auth
2. The bind request ntlmssp_negotiate left at 1
3. The bind request ntlmssp_auth succeeds
4. Server doesn't respond to further requests (as they are not signed).

Appliance

1. Appliance sends NTLMv2 auth
2. Appliance has sign set to 1 in negotiate
3. Change the bind request ntlmssp_negotiate sign to 0
4. The appliance sends auth with signing set to 0.
5. Requests to the server unsigned succeed.

The appliance doesn't set a MIC nor the flags specifying whether a MIC should be present or not. The library probably doesn't support MICs. Therefore we can modify the negotiate flags to disable signing.

Appliance sees that negotiate says sign disabled, and sends auth request with signing disabled. (Windows doesn't do this)

In conclusion we think that SMB->LDAP works when:

Server doesn't require LDAP signing (this is rare as default domain controller policy is to enforce signing); and

1. NetLM/NTLMv1 is used on Windows clients; or
2. A third party library which doesn't support Message Integrity Checks (MIC)s is used; or
3. Old windows server (<2003) that doesn't support MIC (not tested)

[dirkjanm]

Nice research on the different scenarios! This does agree with my reading of the documentation, except for the MIC not being checked if NTLM (v1) is used, which is interesting.

The only downside I see to uncommenting this line is that it will generate failed authentications. We'd need to check if this locks out accounts, otherwise the only reason for not including it would be stealth.

[asolino]

Thanks for the research and comments.

I can live w/o being super stealthy but locking out account could be an issue. Can you please verify that?

[Meatballs1]

I would guess that a MIC failure doesn't cause a lockout as it should be the first thing checked and the message rejected before looking at the username? I wouldn't be too surprised if it doesn't even show up in event logs 🤣 Will have to spinup an env to check though...

[eladshamir]

I spent a bit of time investigating this issue as well.

NTLMv1 is irrelevant. If you get an NTLMv1 response, don't relay; just crack it (crack.sh).

As for NTLMv2, if you change any flag (or anything in any of the messages), the MIC won't be valid anymore. If you remove the MIC, you also need to remove the flag that indicates that the MIC is there, which will affect the NtProofStr and make the NTLM response invalid (it's sort of part of the salt).

As for recalculating the MIC, you'd need the NTLM hash to obtain the key, so that's either pointless or infeasible.

As far as I can see at this point, you can only relay from a client that doesn't support MIC (Win XP/2003 and prior), or a client that don't set the Sign or Seal flags. HTTP is one of them.

[n0skill]

Thank you all for your work ! It's helping me understand the mechanisms of ntlm which I didn't know before 😎

[omriman067]

I spent a bit of time investigating this issue as well.

NTLMv1 is irrelevant. If you get an NTLMv1 response, don't relay; just crack it (crack.sh).

As for NTLMv2, if you change any flag (or anything in any of the messages), the MIC won't be valid anymore. If you remove the MIC, you also need to remove the flag that indicates that the MIC is there, which will affect the NtProofStr and make the NTLM response invalid (it's sort of part of the salt).

As for recalculating the MIC, you'd need the NTLM hash to obtain the key, so that's either pointless or infeasible.

As far as I can see at this point, you can only relay from a client that doesn't support MIC (Win XP/2003 and prior), or a client that don't set the Sign or Seal flags. HTTP is one of them.

Thank you all for the awesome thread! I really learned a lot from reading here, especially considering my own results from experimenting with relayed credentials.
The one thing i still don't understand is this:
When relaying SMB->SMB I can see in that in both auth packets (the one from the client and the one sent to the victim) the MIC fields have the same value (and the relay is successful).
how could that be? does it mean that all 3 packets were passed untouched?
Thank you very much.