Understanding the Windows Credential Leak Flaw and How to Prevent It
By
Lawrence Abrams
- August 5, 2016
- 12:48 PM
- 34
This week there has been a lot of news about a flaw in Windows that could be used by web sites to easily gain access to a visitor’s Windows login name and password. When I tested this flaw it was downright scary. Using a test site for this flaw, the site was able to get my test Microsoft Account login name and the hash of its password in a few seconds. Then it took the site less than 30 seconds to crack the password! What is even scarier, is that this flaw is not new and was discovered in March 1997!
Test shows my account info and Password
Yes. I changed the password already.
News about this flaw was recently reported again by VPN company Perfect Private and by ValdikSS, who is affiliated with the Russian VPN service ProtoVPN. They have both set up test sites that demonstrate this flaw so that visitors can determine if they are affected and should change their passwords. I have no idea what information they keep from these tests, so I would change your password if they are able to detect your info. The web sites that can be used to test whether you are vulnerable to this flaw can be found here:
http://msleak.perfect-privacy.com/ (Perfect Privacy’s Test Page)
http://witch.valdikss.org.ru/ (ValdikSS’s Test Page)
While in the past this flaw was serious, it has become downright dangerous now that more and more people are using Windows 10 and logging into Windows with a Microsoft Account. With the use of Microsoft Accounts, credentials that can be used on the Internet are now more readily exposed through this flaw. Furthermore, since so many users use the same credentials on their Microsoft account as they do on other services, a hacker could potentially gain access to many other sites that a victim uses. This means that a victim’s email accounts, bank accounts, government accounts, business accounts, etc could become compromised.
This bug works by somehow getting a user to open a remote SMB network share to access a file, When you connect to a SMB share, Windows automatically sends your user name and your hashed password to try to automatically login into the share. The problem is that this happens even when the share is located off of your network or over the Internet. See the problem now?
Essentially, all an attacker has to do is create a web page that contains a link to an image hosted on a SMB server under their control. They can then monitor the server for credentials being passed to it and then run password cracking programs on the exposed password hashes. As many people use extremely weak passwords, these programs can crack the passwords incredibly fast. When I say fast, I mean cracking a weak password in 4 seconds.
Cracking Password
Unfortunately, Microsoft has not released an advisory regarding this flaw. When I, and other sites, have reached out to Microsoft, we all received the same token response.
<a href=”https://us-ads.openx.net/w/1.0/rc?cs=fiInstance_101900_0_3257706_iframe&cb=83d3d088dc&c.zoneid=fiInstance_101900_0_3257706&r0=https://cdn.firstimpression.io/delivery/ck.php?oaparams=2__bannerid=9534__zoneid=101900__cb=83d3d088dc__oadest=” ><img src=”https://us-ads.openx.net/w/1.0/ai?auid=538508260&cs=fiInstance_101900_0_3257706_iframe&cb=83d3d088dc” border=”0″ alt=””></a>
We’re aware of this information gathering technique, which was previously described in a paper in 2015. Microsoft released guidance to help protect customers and if needed, we’ll take additional steps.
– a Microsoft spokesperson
Unfortunately, to mitigate this flaw, there is not a lot of good info out there. Microsoft didn’t really offer anything useful that I could get to work and Perfect Private advises you to stay away from Microsoft Edge and Internet Explorer. I knew there was a better way, so I dug around and found a few methods that prevented this information from being disclosed.
Preventing Edge and Internet Explorer from disclosing your Login Information
Below is a technique that a user can use to prevent Windows and applications from disclosing login credentials to remote servers. To prevent any application in Windows from disclosing your credentials, you need to configure certain Windows policies that disable outgoing NTLM traffic to remote servers. For Windows Home users, these policies will need to be configured via the registry. Windows Pro and greater users can configure the policies via the Group Policy editor.
If you enable this policy, no NTLM traffic will be sent to remote servers and this may cause issues in an enterprise or corporate environment. To resolve these issues you can configure another policy that allows you to add excepts to this restriction. More information can be found in the sections below.
Update 8/7/16: Updated the mitigation information to include registry keys that Home users can use to enable the policies below.
Use the Windows Registry to prevent NTLM Credentials from being sent to Remote Servers:
If you are using Windows Home then you do not have access to the Group Policy Editor to add the necessary Windows policies. Instead you will need to add them via the Windows Registry. Those those who do not wish to use the Windows Registry Editor, I have created a Registry file that can be used to disable NTML Credentials from being sent to remote servers here. If you need to add server exceptions, you will need to follow the instructions below.
To do this, open the Windows Registry Editor by start the C:\Windows\regedit.exe program. Then navigate to the following path HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0 as shown below.
MSV1_0 Registry Key
Now right click on the MSV1_0 key as shown above and select New and then DWORD (32-bit) Value. A new value will be created and Windows will prompt you to name it as shown below.
Name New Value
Please enter RestrictSendingNTLMTraffic and then press the enter key on your keyboard to finish naming it. You should now see a new registry value called RestrictSendingNTLMTraffic under the MSV1_0 key. Now double-click on the RestrictSendingNTLMTraffic value and you will be shown a dialog asking you to enter data for this value.
Edit RestrictSendingNTLMTraffic Value
In the Value data: field enter 2, which stands for Deny All, and then press the OK button. Windows will no longer send NTML traffic to remote servers. If you perform another credential leak test, it should state that are no longer vulnerable.
Not Vulnerable
You can now close the Windows Registry Editor and use your computer as normal.
If you need to allow certain remote servers to receive NTLM traffic from this computer, you will need to create another registry key. Using the previous instructions, you can create a new value located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0\ called ClientAllowedNTLMServers. When creating this value, create it as a Multi-String Value, or REG_MULTI_SZ.
When you double-click on this value to enter its data, you will see a box where you can add text. In this box you should add the names of servers, each on their own line, that you wish to allow NTLM traffic to be sent to.
Use the Group Policy Editor to prevent NTLM Credentials from being sent to Remote Servers:
In order to prevent Microsoft Edge and Internet Explorer from leaking your account credentials, you need to enable a particular policy on the computer called Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers. This policy will prevent Windows from sending credentials to remote servers when accessing a SMB share. Though I tested this on my computer with absolutely no problems, this could cause issues in a corporate environment. Therefore, please perform tests before putting this change into production. There is another policy that I will describe below that should allow you to white list certain servers so that credentials are sent as normal.
To enable this policy, you should open the Group Policy Editor and navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers as shown below.
Restrict NTML Outgoing Policy
To enable this policy, double-click on the Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers and configure it to Deny all as shown below. You can also select Audit All to generate Windows event logs that show what remote servers you are sending credentials. This can be used to create a whitelist in the other policy described later in the article.
Restrict Outgoing NTLM Traffic
Now that you have restricted outgoing NTML traffic, Windows will no longer send your NTLM credentials to remote shares. You can test this, by going to one of the credential leak test sites described earlier in the article. It should now say the computer is not vulnerable.
Test showing that you are no longer Vulnerable
For those who need to send credentials to a remote server, you can add certain servers to a whitelist through the To enable this policy, you should open the Group Policy Editor and navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication as shown below.
Add remote server exceptions for NTLM authentication Policu
To enable this policy, double-click on the Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication and add the servers that you wish to whitelist. This will allow the credentials to be sent to these servers as normal.
Add Exceptions for Outgoing NTLM Traffic
Your computer will now be protected from the NTML Credentials Leak, while at the same time being able to use remote SMB servers as needed.
Disabled Internet Windows Authentication in Internet Explorer
ORIGINAL POST: https://www.bleepingcomputer.com/news/security/understanding-the-windows-credential-leak-flaw-and-how-to-prevent-it/
_______________________________________________________
Configuring server exceptions to allow NTLM
Published: November 29, 2012
Updated: November 21, 2012
Applies To: Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012
This topic describes the reasons for and how to configure two security policies introduced in Windows Server 2008 R2 and Windows 7 that permit NTLM authentication on servers that you identify.
You might have instances in your organization where you want to restrict the usage of NTLM to all but a few servers. Two security policy settings are used to list those exceptions where NTLM is allowed: one for client access to remote servers and one policy for access to servers in a domain. Both security policy settings are dependent upon the correct configuration of other settings, as explained below.
Caution
Setting the policy Network Security: Restrict NTLM: NTLM authentication in this domain or Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers without performing an impact assessment first might cause service outage for those applications and users still using NTLM authentication. For additional information, see Assessing NTLM usage.
In this topic
- Add remote server exceptions for NTLM authentication
- Add server exceptions for NTLM authentication in this domain
- Additional resources
Add remote server exceptions for NTLM authentication
This policy setting allows you to create an exception list of remote servers to which clients are allowed to use NTLM authentication if the Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers policy setting is configured.
To add remote server exceptions for NTLM authentication
-
On the remote server, use the Group Policy Management Console (gpmc.msc) to configure Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers to Deny all outgoing NTLM traffic to remote servers. If you do not configure this policy setting, no exceptions will be applied.
-
On the remote server, use the Group Policy Management Console (gpmc.msc) to open the security policy Restrict NTLM: Add remote server exceptions located under the Computer Configuration/Security Settings/Security Options node.
-
List the server names and click OK.
The naming format for servers on this exception list is the fully qualified domain name (FQDN) or NetBIOS server name used by the calling application listed one per line. A single asterisk (*) can be used at the beginning or end of the string as a wild card character.
-
Reevaluate NTLM usage by viewing the NTLM authentication events in the NTLM/Operational log by using Event Viewer. Add or remove server names from the exception list to adjust.
Add server exceptions for NTLM authentication in this domain
This policy setting allows you to create an exception list of servers in this domain to which clients are allowed to use NTLM pass-through authentication if the Network Security: Restrict NTLM: NTLM authentication in this domain policy setting is configured.
To add server exceptions for NTLM authentication in this domain
-
On the domain controller, use the Group Policy Management Console (gpmc.msc) to configure Network Security: Restrict NTLM: NTLM authentication in this domain to any option other than Allow domain logon related NTLM traffic and NTLM traffic to servers in this domain. If you do not configure this policy setting, no exceptions will be applied.
-
On the domain controller, use the Group Policy Management Console (gpmc.msc) to open the security policy Restrict NTLM: Add server exceptions for NTLM authentication in this domain located under the Computer Configuration/Security Settings/Security Options node.
-
List the server names and click OK.
The naming format for servers on this exception list is the FQDN or NetBIOS server name used by the calling application listed one per line. A single asterisk (*) can be used at the beginning or end of the string as a wild card character.
-
Reevaluate NTLM usage by viewing the NTLM authentication events in the Analytic log of Event Viewer. To adjust, add or remove server names from the exception list.
- Network Security: Restrict NTLM: NTLM authentication in this domain
- Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers
- Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication
- Network security: Restrict NTLM: Add server exceptions in this domain
See Also
Concepts
ORIGINAL POST: https://technet.microsoft.com/en-us/library/jj865685(v=ws.10).aspx
_________________________________________________________
Viewing events for assessing NTLM usage
Published: November 29, 2012
Updated: November 21, 2012
Applies To: Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012
This topic describes what events are recorded in the NTLM/Operational log when the Restrict NTLM audit or restrict settings are enforced.
In this topic
Finding NTLM version information
You can determine if the NTLM audit information in the event log pertains to NTLM v1 or NTLM v2, and which computer has preserved or downgraded the strength of the NTLM authentication. The Restrict NTLM audit and blocking policies have the same effect on both versions of NTLM so this investigation is optional.
Tip
For alternate ways to locate NTLM version and LM usage information, see Purging Old NT Security Protocols.
How to find version information
-
Open Event Viewer on the target computer.
-
Under Windows Logs, select the Security log.
-
For the list of security events, visually inspect the log to verify that Logon events are recorded.
-
To search the list of events in the log, use Find with the phrase “Authentication Package.”
Note When searching the list of events on non-English versions of the Windows operating systems, adapt search terminology as appropriate.
-
For each event located, on the General tab, view the Authentication Package information under Detailed Authentication Information. If the package is NTLM, then the Package Name will state the version.
The following example shows the authentication package as “NTLM” and the Package Name as “NTLM V1.”
The events file is security.evtx. The name and path of the log can be found on the properties page of each individual log.
Detailed Authentication Information:Logon Process: NtLmSspAuthentication Package: NTLMTransited Services: -Package Name (NTLM only): NTLM V1Key Length: 128
The authentication information fields provide detailed information about this specific logon request.
- The LUID (not shown) is a unique logon identifier that can be used to correlate this event with a KDC event.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
How to analyze the NTLM audit events
The key to implementing an NTLM blocking strategy is that you must be systematic and methodical. Analysis, depending on the complexity of your deployment, could span months. Your goal is to find applications that do not need to use NTLM and either update them or reconfigure them where possible. Some applications will be too costly to reconfigure, and you will need to determine an exception strategy where you allow NTLM on specific servers.
Expect to find the following applications using NTLM even if they theoretically support Kerberos:
- Applications that allow various security configurations and providers.
- Applications that have not been correctly configured with service principal names (SPNs).
- Applications that use IP addresses instead of DNS names, due to misconfiguration or vendor documentation.
- Applications with a legacy code base can have NTLM-only portions.
There are two methodologies for auditing applications: those that do not use server message block (SMB) protocol and those that do. You can determine SMB usage during your NTLM usage investigation by noting the PID event element when reviewing events on servers or domain controllers. If SMB is used, the authentication communication originates from kernel mode, which translates to a PID indicating the SYSTEM process. The following sections describe how to analyze both.
Auditing for applications that do not communicate over SMB
Applications that directly implement NTLM and use a protocol/transport other than SMB are generally easy to analyze. By enabling auditing, most NTLM usage will be quickly apparent. A key event element to note is PID. For non-SMB authentication traffic, this element will represent the process of the application that is sending the request. For information about all the available NTLM events, see Using event collection systems for assessing authentication usage.
Configurations
- Settings enabled on all servers and clients: Network Security: Restrict NTLM: Audit Incoming NTLM Traffic
- Settings enabled on all servers and clients: Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers set to Audit all.
- Setting enabled on the domain controller: Network Security: Restrict NTLM: Audit NTLM authentication in this domain.
- Event collection or investigation of Event 8004 (Source: NTLM) on the domain controller.
Analysis
What to look for in Event 8004 on the domain controller:
- Logged – The date and time of the event.
- Secure Channel name – The name of the member server the client computer connected to for the transitive logon. It is on this server you will investigate Event 8003.
- User name – The account name.
- Domain name – The domain name.
- Workstation name – The computer to which the user name is associated for this event.
A DC event (Event 8004) might not transpire because a local user account could be connected to a file server and that would require NTLM.
What to look for in Event 8003 on the member server identified in the 8004 event as “Secure Channel name”:
- Logged – The date and time of the event which should match or be close to that recorded in Event 8004.
- User name – The account name.
- Domain name – The domain name.
- Workstation name – The computer to which the user name is associated for this event.
- PID – Process identifier. If the local processing came in through Kernel mode (PID 4 is SYSTEM) you will need to examine Event 8001 on the client computer identified as “Workstation name”.
What to look for in Event 8001 on the client computer identified in the 8004 or 8003 event as “Workstation”:
- Logged – The date and time of the event, which should match or be close to that recorded in Event 8004 or Event 8003.
- Target server – This element contains the name or IP address of server intended to receive the NTLM request. If not in NetBIOS or FQDN format, then Kerberos will not be used.
- Supplied user – This will match the user account name element in Event 8003 or Event 8004.
- Supplied domain – This will match the Domain name element in Event 8003 or Event 8004.
- Name of client process – The name of the application or service that made the request.
- User identity of client process – Lists the user’s credentials that are being supplied to log on from that application (Name of client process). This might be different than the Supplied user name.
Working from the domain controller, you can investigate each usage of NTLM by computer, process, and user. You can identify if users are connecting to the IP address of web servers and not using the NetBIOS name or fully qualified domain name that would have allowed Kerberos to work. You can detect the credential level each application uses and if that is different than the user’s account. All of this information can be used to identify behaviors and misconfigurations that will cause NTLM to be used.
To understand ways to restrict NTLM as discovered from this investigation, see Possible actions in this topic.
Auditing for applications that do communicate over SMB
Applications that use a protocol/transport like SMB (through the redirector that handles connections) are more difficult to analyze. This is because all communication, often to Named Pipes, is through kernel mode. When auditing these types of applications, the only process ID (PID) that will appear is 4, which equates to SYSTEM. By enabling auditing you will be able to locate the computers. Then, by examining those computers under Process Monitor, the actual calling application will be revealed.
Configurations
- Settings enabled on all servers and clients: Network Security: Restrict NTLM: Audit Incoming NTLM Traffic. This will allow Event ID 8001 to be logged on client computers.
- Settings enabled on all servers: Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers set to Audit all. This will allow Event ID 8002 and 8003 to be logged on remote and member servers.
- Setting enabled on the domain controller: Network Security: Restrict NTLM: Audit NTLM authentication in this domain. This will allow Event ID 8004 to be logged on the domain controller.
- Install and configure your process monitoring software required for the following Analysis step.
Analysis
The analysis of the NTLM logs begins on the domain controller (or remote server) to identify the exact NTLM authentication request and the client computer computer making it. However, because some calling applications hide the process identifier (PID) in the SMB package, you will have to use additional evaluation tools to discover the calling applications PID. The Microsoft Process Monitor can be used to filter out superfluous traffic and focus on the client computer’s sending time stamps and the server’s receiving time stamps, and then correlate that to the actual application. For more information, download Process Monitor.
Important
Verify that you have downloaded the latest version of Process Monitor before using it.
For more information about using Process Monitor and restricting NTLM usage, see NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7.
What to look for in Event 8004 on the domain controller:
- Logged – The date and time of the event.
- Secure Channel name – The name of the member server the client computer connected to for the transitive logon. It is on this server you will investigate Event 8003.
- User name – The account name.
- Domain name – The domain name.
- Workstation name – The computer to which the user name is associated for this event.
A DC event (Event 8004) might not transpire because a local user account could be connected to a file server and that would require NTLM.
What to look for in Event 8003 on the member server identified in the 8004 event as “Secure Channel name”:
- Logged – The date and time of the event, which should match or be close to that recorded in Event 8004.
- User name – The account name.
- Domain name – The domain name.
- Workstation name – The computer to which the user name is associated for this event.
- PID – Process identifier. If the local processing came in through Kernel mode (PID 4 is SYSTEM), you will need to examine Event 8001 on the client computer identified in Event 8003 as “Workstation name.”
What to look for in Event 8001 on the client computer identified in the 8004 or 8003 event as “Workstation”:
- Logged – The date and time of the event, which should match or be close to that recorded in Event 8004 or Event 8003.
- Target server – This element contains the name or IP address of the server intended to receive the NTLM request. If not in NetBIOS or FQDN format, then Kerberos will not be used.
- Supplied user – This will match the user account name element in Event 8003 or Event 8004.
- Supplied domain – This will match the Domain name element in Event 8003 or Event 8004.
- Name of client process – The name of the application or service tells you what made the request.
- User identity of client process – Lists the user’s credentials that are being supplied to log on from that application (Name of client process). This might be different than the Supplied user name.
The PID of client process indicates that the client’s process is hidden in the SMB protocol because the actual caller for authentication is the redirector, which runs in the kernel. Therefore, to discover the client computer’s calling process, you will need to investigate the process activity using a tool such as Process Monitor. The following steps will guide you through what to look for.
- On the computer sending NTLM credentials (Event ID 8001 element “Computer”), install the process monitoring software.
- Filter the process scope on the monitor to the path of the remote server logging the 8003 events (which would be the Event ID 8003 element “Computer”) to both the computer name and the IP address. Consider running the monitor in background mode to collect a substantial sampling of data for later analysis.
Note
To allow the process monitor to run, you might need to elevate credentials of the user during this investigation phase.
- When you examine the monitor’s output from the client computer, compare it to the Event ID 8003 event element (which is the time stamp) logged on the server. The user, path, and authentication identifiers will correspond to audit events on the server and, consequently, identify the calling application.
The information from these events shows you the following information:
- The NTLM authentication requests within the named domain would be blocked if Network Security: Restrict NTLM: NTLM authentication in this domain is set to any of the Deny options on the domain controller.
- The NTLM authentication requests domain accounts managed by a single member server would be blocked if Network security: Restrict NTLM: Incoming NTLM traffic is set to “Deny all domain accounts” on a member server.
If you want to allow NTLM authentication requests in the named domain, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Disabled on the domain controller.
If you want to allow NTLM authentication requests to specific servers in the named domain, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Deny for domain servers or Deny domain accounts to domain servers, and then set the security policy Network Security: Restrict NTLM: Add server exceptions in this domain to define a list of servers in the named domain to which clients are allowed to use NTLM authentication.
If you want to restrict NTLM authentication requests to other servers running Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7, use the policy Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers, and select Deny all.
If you want to restrict specific client computers from using NTLM, use the policy Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers and select the Deny all.
See Also
Concepts
ORIGINAL POST: https://technet.microsoft.com/en-us/library/jj865682(v=ws.10).aspx
_____________________________________________________
NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7
★★★★★
★★★★
★★★
★★
★
October 8, 2009May 21, 2016 by NedPyle [MSFT]
![Avatar of NedPyle [MSFT]](data:image/jpg;base64,/9j/4AAQSkZJRgABAQEAtAC0AAD/2wBDAA0JCgsKCA0LCgsODg0PEyAVExISEyccHhcgLikxMC4pLSwzOko+MzZGNywtQFdBRkxOUlNSMj5aYVpQYEpRUk//2wBDAQ4ODhMREyYVFSZPNS01T09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0//wAARCAAsACsDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDz+2Ie4iQgnLAHJrr5QuAqpgt0O3FbPhfwhFp0pu55POnAKqNuAvYmrWvaeYZbS4LZTJTnjHcfyNRJNLQ0hZyVzEjslWIZX9KzZoEtL+ORVCxyHa46D611rCFLf5iq+5NZYtorq+gilUPFI+3261hC6Z1VLSViv9niPYfnR9lh/wAmrWu+ERAHk04sCORExyD9DXFtKVYq2VYHBB7V0nEev28yoNmQGJJ69aj1uFrrTWVV3MmGCjvjt+Wa42O7uo2UmZyFOQM8CuhtNSupooysYBf1546U21bUFvoZsbxKpXbuUYwMfnWhpFv9q1WKRUxFb/M3t6D86sT6GtzIssc/lO3Mg2jGfbFaljaxaakcCSZMvUseWPc4rGMdTeVVONkXJUDE7gD7GuO1Lw7ZT380rQplzk127HC9egrFnkkMzFQCM+tb2MLnCyybe4A7k9q3dBlEaoJiPKLZU5wQPc1XWygmsIxIuc4z75qPUbRNNuI7a3kkMeP4myazm9S4JWszqGiiu4VXznAJ+WRD+H0qe4kiS6tBMynB+Qsea5ZJpY5I/LkZMAthTgHH/wCurGsWsd/Pp9zNuDxKCoU4HXNEXdBKDTsdjM2EOeBXF6rryWupTQFM7COR9BV7U9XvYbN2SUZA4JUVxlzK89w8srbnY5J9a0jK5EouO5//2Q==)
NedPyle [MSFT]
Microsoft Corporation
}
MSFT
126,362 Points 16 4 5
Recent Achievements
Forums Replies II About Me Busy Bee New Gallery Rater
// 10 Comments
Ned here again. Windows 7 and Windows Server 2008 R2 introduce a long sought feature known as NTLM blocking. This prevents NTLM from being used for authentication. IT works in both a send or receive mode, and allows you to create exceptions.
There’s currently very little documentation on this new capability, so I am going to get the ball rolling and talk about some techniques you can use to start evaluating if NTLM blocking will work for your network. Through the use of auditing techniques and application analysis, it is possible to correctly outline all NTLM use in an environment. This is a critical phase to complete before attempting to block NTLM – if you just start blocking arbitrarily you will likely have applications that stop working. Don’t say I didn’t warn you.
NTLM auditing and analysis recommendations
The key to rolling out NTLM blocking is that you must be systematic and take your time. I fully expect an NTLM blocking deployment to take at least 6 months of testing and analysis in a complex environment with hundreds of applications and thousands of computers. You may find applications that you had no idea were using NTLM, and they will need to be updated or reconfigured – that can really stretch out the timelines. Some elderly applications may simply use legacy code and will always require NTLM – this may cause you to abandon the blocking effort, or force you to come up with an exception strategy.
Below are some guidelines for your auditing and analysis phase:
- Deploy all three types of NTLM auditing (See Enabling NTLM Auditing below).
- Deploy the auditing in a test environment as long as all applications have been inventoried and there is no reasonable possibility of users running unknown applications in production.
- Deploy auditing in the production environment if not all applications can be inventoried.
- Deploy the incoming and outgoing auditing policies to all servers and computers. Deploy the domain auditing on DC’s only; it will have no effect on member computers.
- NTLM blocking in environments that have Vista/2008/XP/2003 or older OS’s is not recommended. NTLM cannot be blocked on them directly and auditing/remote exceptions will be very difficult.
- Come up with an audit event collection strategy. This may include third parties, Event Subscriptions, or other methods. The key is to make sure that the events are not lost. Make sure the NTLM audit event logs are increased to a large enough size that they do not constantly wrap.
- It is easier to monitor NTLM auditing on servers than clients – clients can be used for detailed analysis after server behaviors start becoming apparent.
Expect to find a large number of applications using NTLM even if they theoretically support Kerberos:
- Applications that allow various security configurations and providers (such as IIS or OCS)
- Applications that have not been correctly configured with Service Principal Names (such as SQL or SharePoint)
- Applications that use IP addresses instead of DNS names, due to misconfiguration or vendor documentation.
- Applications with a legacy code base can have NTLM-only portions (i.e. they were originally written to work with Windows NT)
When you find these applications, contact your vendor for further support. If a Microsoft application, contact that support specialty. The Directory Services team does not know your applications!
Enabling NTLM Auditing
There are three security policies introduced in Win7/R2 that support auditing NTLM. When accessed through GPMC.MSC and you edit a policy, they are stored in:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options
To enable the deepest level of auditing, including both workgroup and domain authentication attempts that use NTLM, set:
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit All Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts
Note: Configure “Audit NTLM authentication in this domain” on DC’s only. Configure “Outgoing NTLM traffic to remote servers” and “Audit Incoming NTLM Traffic” on all computers.
NTLM audit events are written out to this event log path:
Event Viewer (Local)\Applications And Services Logs\Microsoft\Windows\NTLM\Operational
Auditing for applications that do not communicate over SMB
Applications that directly implement NTLM and use a protocol/transport other than SMB are generally easy to analyze. By enabling auditing most NTLM usage will be quickly apparent.
Example walkthrough:
1. Settings “Audit Incoming NTLM Traffic” and “Outgoing NTLM traffic to remote servers” are enabled on all servers and clients. “Audit NTLM authentication in this domain” is enabled on the DC’s.
2. Testers and users are evaluating various applications in the environment.
3. 8004 events are being seen on the DC’s – examination of DC 2008r2-f-01 shows:
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-Security-Netlogon
Date: 9/25/2009 10:47:36 AM
Event ID: 8004
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 2008r2-f-01.contoso.com
Description:
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
Secure Channel name: 2008R2-F-04
User name: roberg
Domain name: CONTOSO
Workstation name: 7-X64-01
Secure Channel type: 2
3. Note the important information here – the time, user, domain, transitive logon, and originating workstation are all listed. User RoberG in the Contoso domain used NTLM to connect from his client 7-x64-01 to his server 2008r2-f-04 on Sept 25th at 10:47:36 AM.
Also note that a DC event is not guaranteed – for example a local user account could be connected to a file server and that would require NTLM.
4. 8003 events are being seen on the member servers – examination of server 2008r2-f-04 shows:
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-NTLM
Date: 9/25/2009 10:47:36 AM
Event ID: 8003
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 2008r2-f-04.contoso.com
Description:
NTLM server blocked in the domain audit: Audit NTLM authentication in this domain
User: roberg
Domain: CONTOSO
Workstation: 7-X64-01
PID: 4
Process:
Logon type: 3
InProc: true
Mechanism: (NULL)
Note how on the member server you have the 8003 event at the same time for the same user from the same client as in Step 3. You cannot see the Process ID though as – in this particular instance – the local processing came in through Kernel mode (PID 4 is SYSTEM). This means you will need to examine the client.
5. 8001 events are logged on the clients that were seen in steps 3 and 4 and show the final important details:
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-NTLM
Date: 9/25/2009 10:47:36 AM
Event ID: 8001
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 7-x64-01.contoso.com
Description:
NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked.
Target server: HTTP/10.70.0.106
Supplied user: roberg
Supplied domain: CONTOSO
PID of client process: 3416
Name of client process: C:\Program Files (x86)\Internet Explorer\iexplore.exe
LUID of client process: 0x384a35
User identity of client process: Administrator
Domain name of user identity of client process: CONTOSO
Mechanism OID: (NULL)
Note how the actual problem is now clear – users are connecting to the IP address of web servers, not the NetBIOS name or fully qualified domain name that would have allowed Kerberos to work. Furthermore you can see they were using Internet Explorer, so you know the application. Finally you can see that the user running the application is different from the credentials being supplied to logons from that application. All of this information will be helpful info in identifying behaviors and misconfigurations that will cause NTLM to be used.
Auditing for applications that do communicate over SMB
Applications that use a protocol/transport like SMB (via the redirector) are more difficult to analyze. This is because all communication – often to Named Pipes – is through kernel mode. When auditing these types of applications the only process ID (PID) that will appear is 4 – i.e. SYSTEM. By enabling auditing you will be able to locate the computers. Then by examining those computers under Process Monitor, the actual calling application will become visible.
Example walkthrough:
1. Settings “Audit Incoming NTLM Traffic” and “Outgoing NTLM traffic to remote servers” are enabled on all servers and clients. “Audit NTLM authentication in this domain” is enabled on the DC’s.
2. Testers and users are evaluating various applications in the environment.
3. 8004 events are being seen on the DC’s – examination of DC 2008r2-f-01 shows:
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-Security-Netlogon
Date: 9/30/2009 5:13:21 PM
Event ID: 8004
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 2008r2-f-01.contoso.com
Description:
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
Secure Channel name: 2008R2-F-04
User name: Administrator
Domain name: CONTOSO
Workstation name: 7-X64-01
Secure Channel type: 2
Note the important information here – the time, user, domain, transitive logon, and originating workstation are all listed. User Administrator in the Contoso domain used NTLM to connect from his client 7-x64-01 to his server 2008r2-f-04 on Sept 30th at 5:13:21 PM.
Also note that a DC event is not guaranteed – for example a local user account could be connected to that would require NTLM.
4. 8003 events are being seen on the member servers – examination of server 2008r2-f-04 shows:
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-NTLM
Date: 9/30/2009 5:13:21 PM
Event ID: 8003
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 2008r2-f-04.contoso.com
Description:
NTLM server blocked in the domain audit: Audit NTLM authentication in this domain
User: Administrator
Domain: CONTOSO
Workstation: 7-X64-01
PID: 4
Process:
Logon type: 3
InProc: true
Mechanism: (NULL)Note how on the member server you have the 8003 event at the same time for the same user from the same client as in Step 3. You cannot see the Process ID though as the local processing in this case came in through Kernel mode (PID 4 is SYSTEM). This means you will need to examine the client.
5. 8001 events are logged on the clients that were seen in steps 3 and 4 and show the final important details.
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-NTLM
Date: 9/30/2009 5:13:21 PM
Event ID: 8001
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 7-X64-01.contoso.com
Description:
NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked.
Target server: cifs/10.70.0.106
Supplied user: (NULL)
Supplied domain: (NULL)
PID of client process: 4
Name of client process:
LUID of client process: 0x14e5b2
User identity of client process: Administrator
Domain name of user identity of client process: CONTOSO
Mechanism OID: (NULL)Examining the client shows us that SMB (CFS) is being used, but the process is still 4 for SYSTEM. This is because any application authenticating while using SMB as a transport is going through the client redirector in kernel mode. The actual calling application is opaque to the auditing, because the actual caller for authentication is the redirector, which runs in the kernel. So you will need to dig deeper with Process Monitor.
6. Install Process Monitor on the computer that is sending NTLM credentials through SMB (in this case, 7-X64-01.contoso.com). Process monitor can be downloaded from http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx.
7. Set a filter in Process Monitor for the Path to start with the remote server throwing 8003 events. Make sure to set the filter for both the computername and the IP address. This will require giving the user of that computer Admin rights temporarily, during this analysis phase. Alternatively, this could be done through boot logging so that PM is always running silently in the background (note: filtering does not apply with boot logging, so ensure you have plenty of free disk space in that case).
Path \ begins with \ <server name> \ Include Path \ begins with \ <server IP address> \ Include
Example:
8. Wait for the issue to reproduce through user application use.
9. Examine the Process Monitor log output and compare the time stamps to when the 8003 events occurred. Applications that call into SMB will (hopefully) be easily discernable in the log data.
For example:
Explorer.EXE 2300 FileSystemControl \\10.70.0.106\IPC$ Explorer.EXE 2300 FileSystemControl \\10.70.0.106\IPC$ Explorer.EXE 2300 CloseFile \\10.70.0.106\IPC$ Explorer.EXE 2300 QueryOpen \\10.70.0.106\SharedData\ Explorer.EXE 2300 CreateFile \\10.70.0.106\SharedData\ Explorer.EXE 2300 QueryBasicInformationFile \\10.70.0.106\SharedData\ Explorer.EXE 2300 QueryBasicInformationFile \\10.70.0.106\SharedData\ Explorer.EXE 2300 CloseFile \\10.70.0.106\SharedData\
By modifying the Process Monitor column headers, you can also correlate the time, user, and authentication ID’s seen in the 8001 events:
Note how the time, user, path, and authentication ID all line up with the previous NTLM audit events. Explorer is the calling application. Further investigation and interview of the end user determines that they are mapping drives by IP address, forcing the use of NTLM.
More Information and the Big Finish
For the current NTLM Restriction doc on TechNet, see:
For future docs on TechNet (no ETA on release date, so don’t ask me):
Update 2/23//2012: He’s dead, Jim…
NTLM blocking does not totally turn off NTLM on a computer. After all, a local logon uses NTLM. So if you are at home and log on with your computername\user account, the logon will work even if NTLM is disabled fully through group policy. Your Windows 7 client does not run a local KDC after all…
NTLM blocking is no joke. I didn’t bother to discuss how you actually disable NTLM here because you’re not ready to do it yet. NTLM blocking can be a résumé generating event!
– Ned “seriously, just audit for now” Pyle