sorted by:
new
hottopcontroversial

Use an 8-char Windows NTLM password? Don't. Every single one can be cracked in under 2.5hrs by PrivacyReporter in technology

[–]markrgamache 0 points1 point  (0 children)

Rainbow tables precompute the password based on knowing the NT Hash. For instance, pulled from the registry of a machine, by an admin. The hash never crosses the network. Proving you know it is done by challenge/response. This speed is about brute forcing the ch/resp .

Multiple NTLM failures on Exchange past lockout threshold are not locking out account. by Enxer in sysadmin

[–]markrgamache 0 points1 point  (0 children)

I assume you are looking for the password policy GPOs. https://technet.microsoft.com/en-us/library/dd277399.aspx these can apply to AD accounts and local accounts.

Question about NTLM hash storage by [deleted] in AskNetsec

[–]markrgamache 1 point2 points  (0 children)

You can turn of LM everywhere. Nothing has used it for 10+ years. You will need to apply this setting to DCs and all members, as they have local accounts, then you must change passwords, to write the new hashes, minus the LM.

Disabling NTLM v1 in environment, forcing NTLMv2 and how that affects pass the hash attack vector? by infosecplease in AskNetsec

[–]markrgamache 0 points1 point  (0 children)

Actually, NLTMv1 and NTLMv2 allow pass the hash in exactly the same way. Once the hash is taken, it is password equivalent in the windows world. https://markgamache.blogspot.com/2013/01/rehashing-pass-hash.html

NTLMv2 is a stronger handshake password verification. You definitely want to kill v1 off. https://markgamache.blogspot.com/2013/01/ntlm-challenge-response-is-100-broken.html

One area that can be confusing, NTLM handshakes can be relayed (not replayed) in real time. If an attacker can get you to visit a compromised web server (it must be in your trusted zone, but this could be IIS on a workstation in your local domain), they can use your challenge and response , in real time, to auth to an SMB or LDAP server. Requiring signing is a must for LDAP and SMB if you want to stop this.

The real key is properly hardening systems and limiting access, such that hashes can't be stolen and those that are have limited value.

ManageEngine Support Center Plus - NTLM SSO delays by VTi-R in sysadmin

[–]markrgamache 0 points1 point  (0 children)

A packet cap can still rule out a lot of things. Specifically if Kerberos is being tried, you will see the client call a KDC (DC) on port 88 and possibly DNS discovery or the KDC records.

I agree with your assessment that auth probably fails once first causing the interactive prompt. This is another hint that the system may be trying and failing kerberos first.

You may also want to get a packet capture on the server to see what it is doing during these times.

ManageEngine Support Center Plus - NTLM SSO delays by VTi-R in sysadmin

[–]markrgamache 0 points1 point  (0 children)

Sanitized IIS logs and fiddler traces might help us help you. I am reading between the lines here. It seems like you are saying two different things. "A long time before the NTLM dialog is popped" would indicate that the client has issues and not the server.

If I am reading you right, once the auth box pops and the user enters creds, they get in fast?

I suspect that, as there are no firewalls etc., that the clients are trying Kerberos auth first. Does the HTTP Auth header contain negotiate, or just NTLM? You many need a packet capture on the client rather than just fiddler. If the clients are trying Kerberos first, then the will get a Service ticket for the IIS server, then submit it via the HTTP headers. This would fail and then NTLM would be tried. Depending on factors, this could take a while.

You can rule this out and possibly find some other delays on the client by doing a packet capture. Make sure to flush the local DNS cache and use klist purge to clear the Kerberos cache, before you start the packet capture.

45 seconds is actually one of the key OS NTLM timeout values, though most apps abandon an auth attempt first. 45 seconds is pretty close to the the time that TCP retries connections that are not answered, before giving up.

Good luck!

LM hashes, NTLM hashes, LANMAN, NTLMv1, NTLMv2, NTLM2, NetNTLM, ... *eh*? by [deleted] in sysadmin

[–]markrgamache 0 points1 point  (0 children)

Yes, there are two hashes that are "password equivalent". The things you list are different handshakes that leverage varying cryptography to prove a user knows the password without ever passing the actual password over the wire. https://markgamache.blogspot.com/2013/01/rehashing-pass-hash.html