Do not allow storage of passwords and credentials for network authentication impact

Do not allow storage of passwords and credentials for network authentication impact

We use Azure AD joined devices deployed with Endpoint Manager. Our development servers running in another domain environment. But credential manager stores the already expired domain credentials. I want to disable this using this local policy: Network access: Do not allow storage of passwords ... for network authentication.

Can't find the CSP option for this. Can somebody help me to disable this setting with a Configuration profile?

Do not allow storage of passwords and credentials for network authentication impact

level 1

Just validating, if you manually disable this, does it address the issue?

How does the issue manifest itself and when do you run into it?

(Note that I'm not questioning that this is happening, just looking for more info.)

level 2

Good question, not sure if it helps. Was willing to deploy this to a test laptop. I will test it first tomorrow. Will update you if this works. I think to deploy this with MEM policy I need to run a powershell script.

level 1

Did you figure out how to set that via Intune?

level 2

I would like to know as well - did you end up needing to do PowerShell?

A recent Crowdstrike blog post talked about how attackers were targeting a specific industry.  What caught my eye was how they ensured that they were able to steal the credentials in the firm: “Five minutes after gaining access to the host …, the adversary modified the registry to implement a widely known procedure that enables credentials to be stored in clear text within memory, facilitating credential theft:

reg add hklm\system\currentcontrolset\control\securityproviders\wdigest /v UseLogonCredential /t REG_DWORD /d 1 /F

Last year I wrote about how to prevent the use of WDigest credential theft. Clearly, not everyone has learned the lesson. Attackers use old attacks because they still work—and work well. What can you do to ensure that you aren’t this easy to attack?

Know what you are protecting

I find that if I understand what I’m trying to protect, I can devise better ways to protect it. Understanding how the authentication process works and why certain processes are better starts with understanding the password authentication process in general. Steve Syfuhs, a developer on Microsoft’s Azure Active Directory team, wrote an excellent post on what happens when you enter your password in Windows. (For more information on similar topics, check out his post on how single sign-on works and on how Azure AD sign-on works.)

I urge you to review two excellent posts on the topic of credential harvesting from Reliaquest: Credential Dumping Part 1: A Closer Look at Vulnerabilities with Windows Authentication and Credential Management and Credential Dumping Part 2: How to Mitigate Windows Credential Stealing. They will help you understand how attackers can gain access and how you can protect against it.

Some of the best protections you can have on the Microsoft platform are not included in Windows 10 Professional. Many features might appear to work in Professional, but only upon testing and investigation will you confirm that the protections work only with Windows 10 Enterprise—for example, Credential Guard, Microsoft’s virtualization-based feature that protects passwords or other credentials. As noted in the Credential Dumping Part 2 post, “When Credential Guard is used, instead of storing credential secrets in the LSA memory space, the LSA process will communicate with an isolated LSA process which will store the secrets. This new isolated LSA process is protected by virtualization and is not accessible to the rest of the operating system. The virtualization is handled by a hypervisor.”

If you attempt to enable the Credential Guard setting on the Professional version, Defender may say it’s enabled, but the setting does not protect you. Only with Enterprise or Education versions does the setting protect you from attacks that use tools like mimikatz.

Even without Window 10 Enterprise or Education, you can take steps make you less susceptible to credential stealing.

Set WDigest to 0

I urge you again to set WDigest setting to “0” to block the ability to store plaintext passwords. First, push out the registry key located at:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest

If the UseLogonCredential value is set to “0”, WDigest will not store credentials in memory. By setting the value of “0”, you’ll ensure that you can monitor the registry for changes. Should an attacker attempt to change the value, you can be flagged when this is attempted.

Set LSASS in protected mode

The next setting you can do if you only have Windows 10 Professional is configure Local Security Authority Subsystem Service (LSASS) in protected mode. LSASS is a process in Microsoft Windows operating systems that is responsible for enforcing the security policy on the system. It writes to the Windows Security log and verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens.

To do so use the guidance and using regedit and navigate to:

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Then set the value of the registry key to: “RunAsPPL”=dword:00000001.

Reboot your computer to enable the setting.

From a functionality concern, every time you adjust a default setting in Windows, you must review the potential impact to your line-of-business applications. If a third-party authentication application is using LSASS, the functionality could break if it does not adhere to the following mandates regarding signature verification.

First, protected mode requires any process loaded into LSA to have a digital signature by Microsoft. Any unsigned or invalidly signed program will not be able to load within LSA. Drivers must be signed with the WHQL Certification. If they are not signed, it must be signed using the file signing service for LSA. Finally, the application must adhere to the Microsoft Security Development Lifecycle process guidance. Review any third-party authentication platforms or applications to ensure that they will not be impacted by this setting.

Set cached credentials settings

One setting that may be difficult to do in this era of work from home and VPN usage is to limit cached credentials. In Windows systems, the cached credentials for the last 10 domain users are stored within the registry at HKEY_LOCAL_MACHINE\SECURITY\Cache. Follow these steps to adjust that setting:

  • Go to “Local Security Policy”
  • Go to “Local Policies”
  • Go to “Security Options”
  • Go to “Interactive Logon: Number of previous logons to cache (in case domain controller is not available)”

You may wish to set this setting to “0” or “low” for on-premises assets that do not move from the network. You may not want to change this setting for client workstations.

Adjust Credential Manager

Credential Manager is another location holding network passwords that attackers can access using tools such as Credentialsfileview. You can disable password saving by following these steps:

  • Go to “Computer Configuration”
  • Go to “Windows Settings”
  • Go to “Security Settings”
  • Go to “Local Policies”
  • Go to “Security Options”
  • Go to “Network Access: Do not allow storage of passwords and credentials for network authentication”

Adjusting this setting means that you block yet another low hanging fruit that attackers can use to gain more access to your system.

Copyright © 2020 IDG Communications, Inc.