NTLM Hash Leaks: Ancient Microsoft Design Flaw(dylankatz.com)
dylankatz.com
NTLM Hash Leaks: Ancient Microsoft Design Flaw
https://dylankatz.com/NTLM-Hashes-Microsoft%27s-Ancient-Design-Flaw/
23 comments
NTLM was deprecated in 1999, when Windows 2000 came out. You have been supposed to use krb5 since then, and disabled the NTLM. Why is anything about NTLM still news? You have to specifically enable it on newest Windows platforms, because afaik it has been disabled by default for some 5+ years now.
> You have to specifically enable it on newest Windows platforms, because afaik it has been disabled by default for some 5+ years now.
No you don't have to specifically enable it, it's still enabled (by default).
Completely disabling NTLM on a network would be a large project and not even Microsoft recommend that because the security gains are relatively small.
(See microsoft.com/pth for their comprehensive credential security guidance)
No you don't have to specifically enable it, it's still enabled (by default).
Completely disabling NTLM on a network would be a large project and not even Microsoft recommend that because the security gains are relatively small.
(See microsoft.com/pth for their comprehensive credential security guidance)
By default, Kerberos will fail back to NTLM when:
* Authenticating against a pre-NT 4.0 server * Accessing a domain resource via IP * Accessing a resource on a non-domain member * Accessing a resource on a computer that does not support Kerberos (Windows 3.11, Windows 95, etc.)
It's trivial to force this downgrade on most domains.
* Authenticating against a pre-NT 4.0 server * Accessing a domain resource via IP * Accessing a resource on a non-domain member * Accessing a resource on a computer that does not support Kerberos (Windows 3.11, Windows 95, etc.)
It's trivial to force this downgrade on most domains.
That's not entirely accurate. Authentication in Windows can fall back to NTLM for a variety of reasons, including a malicious endpoint purposefully "downshifting" the version of NTLM it wants to use during a negotiation. There are tools to let you control the version of NTLM and group policy and what not...but that can break things that you have had for a long time.
Windows will do Kerberos by default and avoid NTLM in lots of situations, but it's hard to keep it from being used at all if that's your goal.
Windows will do Kerberos by default and avoid NTLM in lots of situations, but it's hard to keep it from being used at all if that's your goal.
I'll add to that - It is still very easy to hijack SMB connections and use it steal the NTLM hash in almost any network with Windows machines (Managed with a DC or not). Just go ahead and try [1] (Disclaimer - running responder.py without authorization might be considered as a crime and I do not take any responsibility for it. I encourage you to use it only if you understand what you are doing and you have full permission to do it).
[1] https://github.com/SpiderLabs/Responder
[1] https://github.com/SpiderLabs/Responder
That's why MS recommends that you use a separate forest for admins only these days. You only administer things with remote tools via a trust, you only enable admin perms as long as you absolutely need them, and you put admins in the protected users group so that they can only do Kerberos. It won't stop other peoples credos from getting stolen, but it makes complete ownership of the domain less likely. That being said if you have service accounts running as domain admin, or you have service accounts with "delegate to any service" perms...all bets are off.
Its so hard to get this right these days. I'm just recommending that people move all their clients to Azure AD join and put servers in resource forests.
NTLM has got to go and hardware/virtualization based security like device guard has to become the norm.
Its so hard to get this right these days. I'm just recommending that people move all their clients to Azure AD join and put servers in resource forests.
NTLM has got to go and hardware/virtualization based security like device guard has to become the norm.
because I know several "security" appliances where their http/https proxy only allows authentication via NTLM.
And SPA (Exchange) still uses NTLM.
And also Windows AD falls back to NTLM if krb is not available.
For a long time you couldn't setup a domain trust without NTLM.
Are you saying that if you disable NTLM, this hole is closed?
I.e. when Explorer processes an icon file with a URL, it will not pass an NTLM hash to a remote server?
What is "disable NTLM", exactly: what does/doesn't happen?
Does it mean that NTLM hashes don't exist any more and therefore can't be sent anywhere?
What is "disable NTLM", exactly: what does/doesn't happen?
Does it mean that NTLM hashes don't exist any more and therefore can't be sent anywhere?
Lots of places are still running Windows 2003 or 2000 and thus have critical infrastructure that uses NTLM.
Also, many, many places who do upgrade turn on legacy crap to interoperate and never turn them off. It's a lot of work to disable it, and the systems that still use it are usually old crap that isn't budgeted.
Also, many, many places who do upgrade turn on legacy crap to interoperate and never turn them off. It's a lot of work to disable it, and the systems that still use it are usually old crap that isn't budgeted.
I get the feeling that the author doesn't actually have much experience with production enterprise networks (where this issue occurs and is relevant).
It really isn't as simple as just flipping a switch and disabling NTLM:
> Microsoft made it very clear that they strongly recommended against disabling NTLM due to incompatibility issues. Instead, they created a system called NTLM Blocking, which requires users to edit their Windows security policies, track event logs, and whitelist applications that need access. This system, while effective if used correctly, is very complicated for normal users to configure and difficult to understand.
It is a complicated affair to fully get your network into 100% Kerberos mode. It will require prior auditing and fixing unless you want to suddenly break things in production (because this configuration is binary).
As a sysadmin myself, I can confidently say that most IT people (I really would say the majority) do not fully understand the authentication mechanisms on an AD network and how authentication happens in the background because Microsoft has actually succeeded in making it very transparent (except when things really break).
Many times Kerberos is not configured correctly in which case thanks to the NTLM fallback things still work and people will be none the wiser (which can be a bad thing precisely because people don't realize it). If you were to suddenly just disable that NTLM altogether, many things will suddenly just stop working.
Kerberos requires manual configuration in many cases (Service Principal Names) and its reliance on working DNS is absolute.
Some examples:
1) Need to connect to a system via IP address for whatever reason? Too bad, without NTLM it's impossible.
2) re: above, what if someone configured a connection string (database connection etc.) somewhere with an IP address? It won't be using Kerberos. Disable NTLM and the connection will just stop working.
3) Want to connect to a laptop that moves around often? Your dynamic DNS entries better be up to date. If the DNS name leads to a different device, you will get an authentication failure regardless of access because you're trying to authenticate with a Kerberos ticket for the wrong machine. See 1.
4) Set up a DNS CNAME (or anything that's not the server's actual hostname where configuration is mostly automatic)? Did you remember to add a Kerberos Service Principal Name for that name in AD? If not, you won't be using Kerberos with those names.
5) Set up a server service (SQL, IIS, etc.)? Is it running under the computer identity or a domain user account? That identity will need the proper Service Principal Name. Did you add one? If not, it won't be using Kerberos. Disable NTLM and the service will simply stop working.
6) Need to connect to a machine not on the domain? Need to connect to a machine on another domain with which you don't have an AD trust in place? You won't be using Kerberos.
To summarize, simply disabling NTLM willy-nilly on an enterprise network is going to be an RGE (resumé generating event).
It really isn't as simple as just flipping a switch and disabling NTLM:
> Microsoft made it very clear that they strongly recommended against disabling NTLM due to incompatibility issues. Instead, they created a system called NTLM Blocking, which requires users to edit their Windows security policies, track event logs, and whitelist applications that need access. This system, while effective if used correctly, is very complicated for normal users to configure and difficult to understand.
It is a complicated affair to fully get your network into 100% Kerberos mode. It will require prior auditing and fixing unless you want to suddenly break things in production (because this configuration is binary).
As a sysadmin myself, I can confidently say that most IT people (I really would say the majority) do not fully understand the authentication mechanisms on an AD network and how authentication happens in the background because Microsoft has actually succeeded in making it very transparent (except when things really break).
Many times Kerberos is not configured correctly in which case thanks to the NTLM fallback things still work and people will be none the wiser (which can be a bad thing precisely because people don't realize it). If you were to suddenly just disable that NTLM altogether, many things will suddenly just stop working.
Kerberos requires manual configuration in many cases (Service Principal Names) and its reliance on working DNS is absolute.
Some examples:
1) Need to connect to a system via IP address for whatever reason? Too bad, without NTLM it's impossible.
2) re: above, what if someone configured a connection string (database connection etc.) somewhere with an IP address? It won't be using Kerberos. Disable NTLM and the connection will just stop working.
3) Want to connect to a laptop that moves around often? Your dynamic DNS entries better be up to date. If the DNS name leads to a different device, you will get an authentication failure regardless of access because you're trying to authenticate with a Kerberos ticket for the wrong machine. See 1.
4) Set up a DNS CNAME (or anything that's not the server's actual hostname where configuration is mostly automatic)? Did you remember to add a Kerberos Service Principal Name for that name in AD? If not, you won't be using Kerberos with those names.
5) Set up a server service (SQL, IIS, etc.)? Is it running under the computer identity or a domain user account? That identity will need the proper Service Principal Name. Did you add one? If not, it won't be using Kerberos. Disable NTLM and the service will simply stop working.
6) Need to connect to a machine not on the domain? Need to connect to a machine on another domain with which you don't have an AD trust in place? You won't be using Kerberos.
To summarize, simply disabling NTLM willy-nilly on an enterprise network is going to be an RGE (resumé generating event).
[deleted]
>However, even when this attack is blocked over the internet, it is very rarely blocked over LAN, meaning it could be used as a method of pivoting within networks.
That's frightening, and I wonder if there are any exploits in the wild which do just that?
That's frightening, and I wonder if there are any exploits in the wild which do just that?
Most exploits don't actually need to be all that crafty. They just ask someone to click a link and run some javascript. Could someone use this to pivot in a network? Yes. Almost every large enterprise has bigger problems than this.
People need to be looking at the new model that they came up with for Windows 10 and Azure AD join if they want to stay on Windows clients. The traditional domain model makes the potential impact of breach far too widespread. Windows Server AD should be used as a server management technology with resources being in resource domains that are just big enough to manage things that are related as a unit. Everybody and everything in the same domain is an antipattern now a days because of credential theft techniques. Most places don't have the expertise to maintain AD. It's too complicated and the loss of a single domain admin cred means that you have to rebuild it if you want to get back to a trustworthy state.
Ehh. It's Friday and I want some cake.
Ehh. It's Friday and I want some cake.
Resource forests, if you want actual security boundaries. Domains aren't security boundaries.
Having said that, some good old fashioned network segmentation would be a "win", too. Default deny ACLs should be the norm, and hosts sshould only be able to communicate with hosts they actually need to, full stop. (The reactions I get from developers, however, are typically less than pleasant when they learn that environments I administer have such policies, however.)
Having said that, some good old fashioned network segmentation would be a "win", too. Default deny ACLs should be the norm, and hosts sshould only be able to communicate with hosts they actually need to, full stop. (The reactions I get from developers, however, are typically less than pleasant when they learn that environments I administer have such policies, however.)
True dat. I've gotten where I use forest and domain interchangeably even thought what you say is true. I only advise people build single forest single domains these days. Complex forest topologies are also a bad thing.
For packing that much information into a pleasantly readable paragraph? You deserve cake.
I don't know about exploits; it is a common trick used by pentesters.
I recall being at Defcon in the 90s listening to the cDc folks talking about this.
I recall being at Defcon in the 90s listening to the cDc folks talking about this.
I'm not sure what you mean - as stated in the article, and the linked blackhat presentation, this has been broken and exploited for 15 years:
https://github.com/rapid7/metasploit-framework/blob/master/m...
and/or:
https://github.com/rapid7/metasploit-framework/blob/master/d...
Getting a hash is rather simple, if you already have access to the lan, assuming you are able to redirect traffic or insert yourself between the target user and the network (say, false wifi ap):
https://shellgam3.com/2016/03/14/capturing-and-cracking-ntlm...
I'm generally not much of fan of firewalls (precisely because they by definition set up a "soft core" that's assumed to be safe) - but egress filtering of smb packets is unfortunately necessary if you have an winodws (and/or smb/cifs) clients on your network. I would much rather only run boxes that are "fit for the Internet" - but that's been rather difficult to do with windows for the past decades.
In fairness, Microsoft has made a number of improvements - but still not enough.
It would be nice if there was an easy way to set up the network so all clients used only kerberos5, and only sent credentials to kerberos principals in a trusted domain. As far as I know, there is no such easy way.
https://github.com/rapid7/metasploit-framework/blob/master/m...
and/or:
https://github.com/rapid7/metasploit-framework/blob/master/d...
Getting a hash is rather simple, if you already have access to the lan, assuming you are able to redirect traffic or insert yourself between the target user and the network (say, false wifi ap):
https://shellgam3.com/2016/03/14/capturing-and-cracking-ntlm...
I'm generally not much of fan of firewalls (precisely because they by definition set up a "soft core" that's assumed to be safe) - but egress filtering of smb packets is unfortunately necessary if you have an winodws (and/or smb/cifs) clients on your network. I would much rather only run boxes that are "fit for the Internet" - but that's been rather difficult to do with windows for the past decades.
In fairness, Microsoft has made a number of improvements - but still not enough.
It would be nice if there was an easy way to set up the network so all clients used only kerberos5, and only sent credentials to kerberos principals in a trusted domain. As far as I know, there is no such easy way.
Sure, NTLM relaying is standard pentest/attacker tooling and just this month Microsoft addressed two issues where NTLM vulnerabilities can lead to full domain compromise (in the worst case).
See: https://blog.preempt.com/new-ldap-rdp-relay-vulnerabilities-...
See: https://blog.preempt.com/new-ldap-rdp-relay-vulnerabilities-...
ntlm is still used every day in WiFi authentication. PEAP authentication is MS-CHAP over TLS over EAP. And the only way for non-MS products to authenticate to Active Directory is via Samba and ntlm.
Things would arguably be more secure if MS allowed for AD to export the password hashes to other systems. Querying for an NT hash via LDAP over TLS has essentially zero security problems. (Other than the NT hash itself)
Things would arguably be more secure if MS allowed for AD to export the password hashes to other systems. Querying for an NT hash via LDAP over TLS has essentially zero security problems. (Other than the NT hash itself)
Not sure what you mean about non-MS things using AD. sssd-ad is a fine client and uses kerberos, not NTLM.
You can take a clear-text password and authenticate it to AD via kerberos.
If you have MS-CHAP data, you can't convert it to something which will be accepted by kerberos. You MUST send it to AD as MS-CHAP data (i.e. ntlm), and then AD returns "pass / fail"
If you have MS-CHAP data, you can't convert it to something which will be accepted by kerberos. You MUST send it to AD as MS-CHAP data (i.e. ntlm), and then AD returns "pass / fail"