It’s not every day you come across an issue that Microsoft deems worthy of a patch, especially when your day job is sifting through logs to try and find indicators of compromise. However, while testing some techniques to detect password scraping from memory, that’s the position we found ourselves in. The first thing we had to confirm was whether the issue was present on all of our Windows test servers as we were worried we had configured something in error on the server where the flaw was discovered. Once confirmed that we could reproduce the issue on multiple operating systems including a fully patch Windows Server 2016 environment we had the confidence to submit the issue to Microsoft.

Windows Credential Management

Microsoft has made many improvements over the last few years to how credentials are managed within Windows so that cracking open LSASS isn’t necessarily the guaranteed easiest way to get plaintext passwords.

We've seen improvements such as WDigest Authentication being off by default and the ability to configure Windows Defender Credential Guard & additional LSA protections. This has resulted in the use of other techniques to steal credentials, such as asking users or using a tool like Responder. Recent testing conducted by Seamless Intelligence discovered that under certain circumstances, passwords will be stored by Windows Credential Manager and left within LSASS as plaintext.

Why is this an issue?

Administrators may have a false sense of password security due to all the robust security features built into Windows Server 2016 that slightly hinder password dumping tools extract plaintext passwords. However, a single scheduled task may expose potentially sensitive credentials despite all the other safeguards.

When creating a scheduled task on a Windows Server an administrator can configure it to run with a Domain account and can explicitly set the task not to save the password. There are two configuration options which should stop passwords being saved in Credential Manager, but neither option worked with Windows Server 2012R2 or Windows Server 2016. These were;

• Task Scheduler has an option to “Do not store password”; however, our testing shows that this does not influence whether the password is stored within Credential Manager.


• Group Policy has a setting to stop storage of credentials for network authentication. Our testing shows that this is ineffective when configuring a scheduled task to use a Domain Account. It will stop the task being saved, but the password is still stored in LSASS. More information on this Group Policy setting can be found here - https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication

This is concerning for the following reasons;

• Scheduled Tasks are required to perform functions on a Windows server without needing someone to logon or perform them manually.
• If an administrator needs to save the password for Domain access it will be stored in LSASS in plaintext.
• If an administrator does not need the password it will still be saved even when Task Scheduler is told explicitly not to save it.
• Often the Service Accounts used for these tasks have a high level of privilege within the organisation.
• Administrators with the Group Policy set and who untick the “Store Password” box will be under a false impression regarding the security posture of their Windows servers.

Reproduce it for testing

The following steps should re-produce the issue in Windows Server 2012R2 and 2016

1. Set Group Policy “Network access: Do not allow storage of passwords and credentials for network authentication” to be “Enabled”
2. Edit the task to “Run whether user is logged on or not”
3. Change user to a domain service account
4. Ignore error (Error due to GP change above, does not allow task to be saved)
5. Credentials are now in Credential Manager
6. Run Mimikatz/SafetyKatz and password will be available in the plaintext.

What can we do?

With Microsoft releasing a patch, that's the best solution to this issue; however, there are some other things that can help reduce the impact of account misuse before patching can occur.

1. Review Use of Scheduled Tasks

   For the most common accounts used to run scheduled tasks, review what privilege level they have within the Domain. Use this list within your SIEM and look for activity that is abnormal for service accounts such as web activity, VPN logons or interactive logons to servers.

2. Review the Privilege Level

   For the most common accounts used to run scheduled tasks, review what privilege level they have within the Domain and look at reducing it where possible. BloodHoundAD is an excellent tool for reviewing this privilege as you can execute queries using either the group or the target account as the starting point. More information can be found here - https://github.com/BloodHoundAD/BloodHound

3. Patch

   With no concrete workarounds or mitigations the best course of action is to patch. More information on the security advisory can be found here - https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2019-0838