JPCERT/CC Eyes

In most of the targeted attack cases, often multiple computers get infected by malware, rather than just a single computer, and attackers continue compromising other computers across the network, including important servers. For this “lateral movement” purpose, password hash is often targeted. In order to enhance protection against such information theft, LSA Protection Mode for Windows 8.1 etc. and Credential Guard for Windows 10 Enterprise have been introduced. In this entry, we will examine the protection effect of these features and the points to consider in reserving the effect.

Overview of LSA Protection Mode

LSA (Local Security Authority) is a subsystem related to Windows security. It manages user rights information and stores password hash etc. in the memory. In OS including Windows 8.1 and others, LSA Protection Mode serves to protect such information from being stolen.

In order to enable LSA Protection Mode, users need to edit the registry as instructed in Technet Library [1] and reboot the OS. Please note that LSA plug-ins which are not compatible with LSA Protection Mode will not function after enabling the mode. Such plug-ins can be identified by using Audit Mode before changing the Protection Mode.

LSA Protection Mode was first introduced in Windows 8.1 and Windows Server 2012 R2. For Windows 10, which was released after that, Build 10240 could not be started up properly with Protection Mode. However, we confirmed that Build 10586 (Version 1511, November Update, TH2) was successfully started up under the mode.

Verification of LSA Protection Mode with Artifacts Used in Actual Attacks

We verified the effect of LSA Protection Mode by attempting hash dump using 4 types of artifacts which have functions to dump password hash. All the artifacts were used in actual attacks. Functions of each artifact are described in Table 1. Figure 1-6 shows the dump results for each artifact, and Table 2 shows the results under LSA Protection Mode.

We conducted the verification using Windows 10 Build 10586 and Windows 8.1, and confirmed that the same results were derived.

Under LSA Protection Mode, mimikatz and gsecdump observed an error as in Figure 2 and 4, and were unable to dump. On the other hand, when it is disabled, these two types of artifacts are able to dump logged-on domain user information as in Figure 1 and 3. Information of the domain user can be a hint to compromise other computers within the domain (e.g. pass-the-hash attack). LSA Protection Mode protects such domain user information from being stolen, and therefore it is expected to hinder lateral movement.

Figure 1: mimikatz (Protection Mode disabled)

Figure 2: mimikatz (Protection Mode enabled)

Figure 3: gsecdump (Protection Mode disabled)

Figure 4: gsecdump (Protection Mode enabled)

Figure 5: PwDump7

Figure 6: QuarksPwDump

As Figure 5 and 6 demonstrate, dumping with PwDump7 and QuarksPwDump is successful regardless of LSA Protection Mode since they dump information by reading disk devices or using registry API, instead of stealing information from LSA processes. However, the information that these two dump is local user information, not domain user. Note that the results here are derived solely from the commands/options in Table 1. (e.g. mimikatz also has a command to steal local user information just like QuarksPwDump etc.)

Overview of Credential Guard

For Windows 10 Enterprise, you can also use a further advanced system to protect LSA, “Credential Guard”. It is based on a protection environment isolated from the OS by virtualisation using hardware. Therefore, when Credential Guard is enabled, secret data and parts of LSA process that store the secret data are isolated from the OS and then protected [2] [3]. Comparison of LSA Protection Mode and Credential Guard is described in Table 3.

Credential Guard can be enabled in Group Policy Management Console. However, if Hyper-V Hypervisor is not enabled in advance, in some cases, Credential Guard may not be enabled until it is first enabled in the Console, and rebooted, and then rebooted again manually. Furthermore, Credential Guard does not function even if it looks enabled on Group Policy Management Console, in case the hardware requirements are not met or required functions are disabled by UEFI (BIOS) configurations. Whether Credential Guard is actually enabled can be checked by displaying system information [2].

Verification of Credential Guard with Artifacts Used in Actual Attacks

We conducted another verification test of hash dumping by using the same artifacts as in Table 1. The results of password hash for each artifact are shown in Table 4. The result outputs are shown in Figure 5-8.

As Table 4 describes, the dump results are similar to the verification under LSA Protection Mode (Table 2). In Figure 7 and 8, which shows the dump results with mimikatz and gsecdump under Credential Guard, there was no error observed (unlike Figure 2 and 4 under LSA Protection Mode). However, this is due to the fact that the protection mechanism is different in LSA Protection Mode and Credential Guard as in Table 3, and it does not mean that the password hash is stolen.

Figure 7: mimikatz (Credential Guard)

Figure 8: gsecdump (Credential Guard)

Compare Figure 1 which shows the dump results of mimikatz without LSA protection and Figure 7 with Credential Guard, and similarly Figure 3 and 8 for gsecdump. Although the same password is configured for all the cases, you will realise that the password hash value is different and it derives an incorrect password hash value under Credential Guard (Figure 7 and 8). This means that the password hash is not stolen when Credential Guard is enabled.

Local password hash dump using PwDump7 and QuarksPwDump succeeds because it does not use LSA as an information source (as described in the Verification of LSA Protection Mode above), even under Credential Guard.

Point to Consider - 1

If you compare Figure 1 which shows the dump results of mimikatz without LSA protection and Figure 6 of QuarksPwDump with LSA protection, you will see that the password hash (NTLM) for “user1” in Figure 1 and “localuser1” in Figure 6 are identical. This means that these users share the same password, and actually “user1” is a domain user and “localuser1” is a local user. In mimikatz environment, domain users’ password hash can be protected by using LSA Protection Mode or Credential Guard. However, with QuarksPwDump, these two protection features are not effective against password hash dump of local users.

Even under LSA Protection Mode or Credential Guard, local users’ password hash can be stolen using PwDump7 or QuarksPwDump etc. in an environment where a domain user and a local user share the same password, and this raises the risks of the domain being compromised. Make sure to configure a different password for domain users and local users within the domain.

Point to Consider - 2

By using QuarksPwDump which is capable of dumping under LSA Protection Mode or Credential Guard, it is possible to dump domain logon information that was cached on the local disk as follows:

This cache is for usage on a laptop PC which is temporally offline from a domain. Neither LSA Protection Mode nor Credential Guard can protect the information in the cache from being stolen. Computers that are constantly connected to the domain do not require cache function, and in such case this function can be disabled. In order to disable cache, edit Group Policy [4] or registry [5].

If you disable cache, domain passwords cannot be found even with QuarksPwDump as shown in Figure 10.

Figure 10: QuarksPwDump –dhdc (Logon cache disabled)

If you cannot disable cache due to the network environment where the computer operates, it is better to configure stronger passwords (length, types of letters, hard to guess from dictionary). The cached password hash has a different format from data stolen from LSA, and it cannot be used for pass-the-hash attacks as is. However, some tools to crack the hash are already available, and it is possible to break weak and simple passwords.

Summary

We have verified that LSA Protection Mode and Credential Guard are one of the effective protection features against lateral movement in targeted attacks, by protecting domain password hash from being stolen. In order to enable the features, please make sure that your hardware and software meet the requirements and there is no impact on your driver or plug-ins. Also, it is important to check if your environment does not reduce the protection effect. We hope that these features help in constructing an even more secure Windows domain environment.

-Kenichi Imamatsu

(Translated by Yukako Uchida)

References

[1] Microsoft - Configuring Additional LSA Protection
     https://technet.microsoft.com/en-us/library/dn408187.aspx

[2] Microsoft - Protect derived domain credentials with Credential Guard
     https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard

[3] FFRI - Windows 10 Research report on effects of reducing security risks - Phase 1 (Japanese only)
     http://www.ffri.jp/assets/files/research/research_papers/windows10_security_ja.pdf

[4] Microsoft - Interactive logon: Number of previous logons to cache (in case domain controller is not available)
     https://technet.microsoft.com/en-us/library/mt629048(v=vs.85).aspx

[5] Microsoft - Cached domain logon information
     https://support.microsoft.com/en-us/kb/172931