NTLM attacks are especially relevant to Active Directory environments. One of the most common attack scenarios is NTLM Relay, in which the attacker compromises one machine and then spreads laterally to other machines by using NTLM authentication directed at the compromised server. The best way to cope with NTLM vulnerabilities is basically not to use NTLM, but NTLMV2 is more secure.
http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx is worth a read to understand much of the background behind NTLM. But as good as that article is, it isn’t comprehensive. Referencing http://technet.microsoft.com/en-us/library/cc773178(v=WS.10).aspx (see section entitled “NTLM Referral Processing”) will help you understand how NTLM logons work across a trust. Note that this is why you won’t find any NTLMv1 logons on any domain controllers. You will find most NTLMv1 logon events on the member servers that allow NTLMv1–those member servers are the key and you should target them as the point of leverage to identify which clients are using NTLMv1.
Go to the GPO section Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options and find the policy Network Security: LAN Manager authentication level. You can also disable NTLMv1 through the registry.
|1||Client LMCompatibilityLevel configuration wasn’t compatible (e.g. XP default)||C|
|2||Member server has a LMCompatibilityLevel configuration that isn’t compatible. There are two scenarios here:||J -> C|
|3||Domain controller from a trusting domain has a LMCompatibilityLevel configuration that isn’t compatible (where the trusting DC is acting in the role of a client)||J -> C|
|4||Mac browser incompatibilities on old versions (Mac OS client + Safari)||A or M or P|
|5||Chrome (on Windows client) browser configuration needed||B or M|
|6||Firefox browser (on Windows client) with Windows Integrated webserver (in general, not specific to NTLMv1)||G or M|
|7||Firefox browser (on non-Windows client)||M or N or O or P or Q|
|8||Chrome browser (on non-Windows client)||M or N or O or P or Q|
|9||IIS webserver with Windows Integrated enabled (in specific, with “Negotiate,NTLM” enabled)||L or M or P or Q|
|10||POP or IMAP based email clients & Exchange that have “Simple Authentication and security layer” enabled||E|
|11||MacOS/Linux computers mounting SMB Share||H|
|12||IAS server & MS-CHAPv2 (which uses NTLMv1 by default)||F|
|13||Routing and Remote Access Service & MS-Chapv2 (which uses NTLMv1 by default)||D|
|14||Any client is trying to perform NTLMv2 authentication to Vista or Windows Server 2008 based service. Receives error: “STATUS_INVALID_PARAM”.||I|
|15||Copiers using Windows Integrated authentication (details lacking)||K|
Workarounds and Solutions
If you are using an old Mac device and can't upgrade, the MacOS Safari browser relies on an obscure Mac OS config setting in the nsmb.conf file http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man5/nsmb.conf.5.html
For step-by-step instructions: Enabling NTLMv2 on Mac OS-X
Internet Explorer(soon to be deprecated) and Chrome (on Windows) rely on the Intranet zone configuration (see Control Panel: Internet Options) to determine what type of authN it uses.
|C||Change the LMCompatibilityLevel value. Level 5 corresponds to “Send NTLMv2 response only. Refuse LM & NTLM.” and is the most desired state. Level 3 (“Send NTLMv2 response only”) is the minimum needed to continue to interact with the NETID DCs. How you go about setting the LMCompatibilityLevel depends on the existing configuration of the computer. |
Alternatively, to use the local security policy approach:
1) Use “Start->Run” and type in “gpedit.msc” in the “Run” dialog box. A “Group Policy” window will open.
c) Or alternatively, you can manually use the registry:
1) Open regedit.exe
2) Navigate to HKLM\System\CurrentControlSet\control\LSA. Click on LSA
3) If you don’t see LMCompatibilityLevel in the right window pane, then choose: Edit > New > REG_DWORD. Replace
|1, 2, 3|
|D||https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/lt2p-ipsec-ras-vpn-connections-fail describes how to force NTLMv2 in MS-Chapv2||13|
|E||Turn off “Simple Authentication and security layer” in the POP/IMAP based mail client.||10|
|F||Apply hotfix noted at https://support.microsoft.com/en-us/help/893318 if running the OS noted and/or set the |
registry value noted. https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/lt2p-ipsec-ras-vpn-connections-fail is a duplicative KB which notes the registry value.
NOTE: Upgrade the MacOS VPN client. This means that even if you apply the above workaround,
|G||For Firefox browsers (on Windows clients):|
Note: this setting is the successor to the deprecated
|H||Edit /etc/samba/smb.conf on the client, you should add the following to the “[globals]” section:client ntlmv2 auth = yes|
http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html is reference material on this configuration file.
If you are mounting a share, you’ll also need to modify the sudo command to explicitly specify the security level.
|I (i)||See hotfix at https://support.microsoft.com/en-US/help/957441.||14|
|J||Use this PowerShell script: Get-NtlmV1LogonEvents to determine if your domain controllers or member server is |
using NTLMv1, then C if needed. That powershell script assumes Windows Server 2008 or newer.
If your DCs or member servers are Windows Server 2003 R2 or earlier, the only way to identify NTLMv1 use is via
|K||There are some copiers whose default configuration doesn’t permit NTLMv2. In some cases these copiers need |
configuration, in others, they need a firmware upgrade to support NTLMv2.
For the Ricoh MP 6001, the firmware NIB needs to be at least 8.72. The Ricoh version can be seen on the
|L||According to two sources, IIS doesn’t actually negotiate the highest authentication protocol possible when used |
in combination with some combinations of Windows OS and browser–but instead negotiates the worst. We’ve
been unable to verify these claims due to the lack of detail in the claims. Those sources suggest one of two solutions.
Solution #1: This is caused by problem #1/4/5/6, so apply solutions C/A/B/G as appropriate to all clients.
Solution #2: Reconfigure IIS to “Negotiate” instead of “Negotiate,NTLM”.
Solution #3: https://docs.microsoft.com/en-US/troubleshoot/windows-server/windows-security/authentication-package-listed-as-ntlmv1-security-audit-event describes a scenario (scenario B as labeled in that article)
|M||Get Kerberos authentication working. If authentication is cross-domain, then you will need a forest trust |
(only 8 trusts of all trusts with NETID are not forest trusts). Kerberos authentication requires a valid SPN at
each of the stops in the authentication chain (the client, the member server and the DC). In most cases, the
SPN must resolve to the host it is for; the SPN can’t involve a DNS record that doesn’t exist or resolves
somewhere else. Kerberos authentication is time-sensitive, that is to say that all of the stops in the authentication
chain need to be within 5 minutes of each other. If a web browser is used, there is sometimes special configuration
required to get Kerberos working with it. For example, IE requires that the URL is listed in the intranet zone.
Workaround G is another example of this.
To get Kerberos working on a Linux computer, you might find http://technet.microsoft.com/en-us/magazine/2008.12.linux.aspx useful.
|N||Choose a browser that can do NTLMv2. To our knowledge, Safari on MacOS is the only non-Windows browser |
combination that supports NTLMv2. See workaround A.
Firefox doesn’t support NTLMv2 natively. On a Windows client, it relies on the Windows libraries to do NTLMv2.
Chrome doesn’t support NTLMv2 natively. On a Windows client, it relies on the Windows libraries to do NTLMv2.
Opera has never supported any NTLM protocol.
|O||There is an open-source “personal” NTLM proxy that includes NTLMv2 support for web authN that might be used |
as a workaround. See http://cntlm.sourceforge.net/.
If someone tries this out, we’d like to know so we know whether it’s a working workaround or just a theoretical one.
|P||If you have an IIS web server configured to do Windows Integrated authentication with non-Windows clients |
(see problems #7 & 8), an option is to remove Windows Integrated authentication and enable Basic Authentication.
If you do, make sure you require HTTPS, so passwords in transit have a secure channel. An alternative would
be to remove Windows Integrated and explore ADFS or Shibboleth authentication integration.
For more reading material on IIS authentication, see:
|4, 7, 8, 9|
|Q||If you have a web server (IIS or otherwise) configured to do Windows Integrated with non-Windows clients |
(see problems #7 & 8), your best bet may be to provide a 2nd website (with an alternate FQDN) on the same
web server pointing to the same content. This 2nd website would provide Forms or Basic Authentication.
You’d then tell customers with a browser that is incapable of doing Windows Integrated that the workaround
|4, 7, 8, 9|
|R||Null session behavior from win7/ws08r2 and beyond may be relevant: http://technet.microsoft.com/en-us/library/jj852275.aspx|
|S||Minimum session security setting may be important: http://technet.microsoft.com/en-us/library/cc736506(v=WS.10).aspx|