Pass­the­Hash Defense: Analysis of Strategies to Mitigate Weaknesses in Microsoft NTLM Authentication

Andrew Coates and Stephanie Sanders Department of Computer Science and Electrical Engineering

University of Maryland Baltimore County coates2, sschott1@umbc.edu

May 12, 2014 Abstract

Pass­the­hash is a network exploitation technique in which attackers authenticate to a remote server or workstation using a Windows NTLM or Lan Manager (LM) hash of a user’s password. This technique has been largely employed by hackers and red teams alike to expand access laterally in a target network. It has been a persistent weakness in Windows Domains since the late 1990’s, and past efforts to mitigate this weakness have proved largely ineffective. Our research evaluates the new solutions to the pass­the­hash problems introduced by Microsoft in their newest versions of the Windows operating system, Windows 8.1 and Windows Server 2012 R2. We have audited each implemented solution and commented on both the effectiveness as well as the technical feasibility of the proposed solutions. While these new technologies are novel and represent a step forward by Microsoft in securing domains and protecting credentials, we found that they failed to eliminate or patch the existing pass­the­hash vulnerability. Microsoft’s solutions can only be described as efforts to further protect credentials and slow down attackers. We found that Microsoft’s real problem lies in the fact that their authentication system uses non­salted, hashed credentials as authentication tokens on their network. Rather than using a Kerberos mechanism Microsoft has opted for non­expiring authentication tokens which represent real user data.

Other proposed pass­the­hash mitigations revolve around credential protection or flat out abandonment of NTLM authentication methods. These mitigations include TPM­based credential storage, hardware tokens, public/private key pairs, and even an elimination of the Single Sign On concept. Until Microsoft changes their underlying protocol, credential reuse, NTLM cracking, and illegitimate network authentication will plague corporate domains.

Keywords: Pass the Hash, PtH, NTLM hash, Windows authentication, credential security

1

Table of Contents 1. Motivation 2. Background

2.1 Windows Password Hashes 2.2 Microsoft Local Security Authority 2.3 Microsoft Domain Authentication Systems 2.4 Pass­the­Hash Within These Contexts

3. Previous Work 3.1 SANS’S Layered Solution 3.2 Microsoft ‘s Solution

4. Methods 4.1 Setting Up A Domain 4.2 New Windows Platform Technologies

4.2.1 LSA Protection 4.2.2 Restricted Remote Administration 4.2.3 Silos 4.2.4 Local Account

4.3 Pass­the­Hash Toolkits 4.3.1 Windows Credential Editor 4.3.2 Mimikatz

5. Results 5.1 LSA Protection 5.2 Restricted Remote Administration

6. Mitigation Proposals 6.1 TPM­Based Credential Storage 6.2 Hardware Tokens 6.3 Elimination of Single Sign On 6.4 Kerberos

7. Discussion 7.1 Windows 8.1 and Server 2012 Mitigations 7.2 Other Mitigation Proposals 7.3 Recommendations

8. Open Problems and Conclusion 9. References

2

1. Motivation Most of today’s network defenses rely on preventing malware from getting onto our systems,

but very few rely on minimizing the damage to our networks once this unauthorized access to a system is achieved. This is an incredible oversight. Once an attacker gains access to an end­user workstation, he can often take advantage of a technique called pass­the­hash to move freely around the network. Pass­the­hash takes advantage of a vulnerability in Windows authentication which allows an attacker to authenticate to remote servers using just a user name and password hash. It is a common technique which has historically given adversaries the ability to move laterally within a network. This makes network cleansing and mitigation techniques very difficult as legitimate user transactions become indistinguishable from the network transactions of malicious attackers on the network. Pass­the­hash is a serious problem in the cybersecurity world, as leaving this vulnerability unpatched provides hackers with unfettered access to our computer networks if they are able to trick just one user into downloading malware.

The pass­the­hash problem originates with Microsoft's implementation of Single Sign On (SSO), in which Windows attempts to improve user experience by eliminating the need for the user to repeatedly type in their user name and password when accessing network resources [2]. To implement SSO, Windows stores a user's password hash upon logon and later uses this to authenticate to network servers and shared resources. Upon gaining access to an end­user workstation, an attacker simply has to retrieve the user's password hash – which can be done using a number of publicly available tools – to begin compromising other network resources that user can access.

Figure 1: Microsoft Single Sign On, taken from Microsoft [6]

The pass­the­hash technique was introduced in 1997 by Paul Ashton, when he published an

exploit called “NT Pass the Hash with Modified SMB Client” to Bugtraq [9], but is still unpatched to this day. Despite the longevity of the vulnerability, our group found that the field of potential solutions was disturbingly slim and unscientific. Often the solutions proposed rely heavily upon careful network administration, and fail to degrade or deny an attacker the ability to move laterally within a network. Instead the solutions proposed by security researchers have focused on slowing an attacker by using

3

good security policies. What appeared to be lacking in the security community was a comprehensive examination and discussion of current and potential proposals to mitigate the pass­the­hash vulnerability in Windows domains.

The security community in general has invested a significant amount of time attempting to solve this problem but so far has been unable to stop this avenue of attack. Network administrators have attempted to thwart this technique with different network configurations, but these same configuration changes that make it difficult for hackers to get around a network can also make it more difficult for legitimate users. The pass­the­hash technique and possible solutions to thwart the technique have been discussed by many esteemed organizations and at many worldwide network security conferences, but the technique is still largely employed today. All previously proposed solutions rely on network reconfigurations and policy changes rather than successfully thwarting the pass­the­hash attack. We believe recent developments with researchers at the RSA Conference and by Microsoft warrant a fresh review of the strides made in network credential security. Specifically, Microsoft introduced new protections in Windows 8.1 and Server 2012 R2 to protect memory more thoroughly and to help isolate networks from would­be attackers. Our research audits the efforts of Microsoft to understand how these efforts truly affect the security of Windows domain systems. At this time no one else has attempted to an in­depth look at these new platform technologies. We also comment on the technical feasibility and efficacy of suggestions by the security community at large, as well as by our project sponsor, to help mitigate the pass­the­hash vulnerability. 2. Background

Understanding pass­the­hash vulnerabilities requires a thorough understanding of the Local Security Authority system as implemented by Microsoft, the domain authentication system, and general knowledge about cryptographic hashes. Each of these functional areas are described within this section. 2.1 Windows Password Hashes

To understand what we must defend against, we must first understand what credentials Windows stores, and where they are stored. Windows computes two different hashes for authentication ­ the Lan Manager (LM) hash and the NT hash. In versions of Windows prior to Vista, the LM hash is stored by default and is used for authentication [8]. The LM hash is known to be cryptographically weak and easy to crack. A LM hash requires a password to be a maximum of fourteen characters. When it is computed, all characters in the password are converted to uppercase, split into two seven­character chunks, encrypted separately, and then concatenated to form the LM hash.

4

Figure 2: Computing a LM Hash [17]

Converting all characters to uppercase decreases the key space, and encrypting the password into two separate chunks allows an attacker to brute force each chunk individually, contributing to the LM hash’s weakness. Given its limited keyspace and cryptographic weakness, the LM hash is not stored by default or used during authentication in any newer version of Windows. The NT hash is much stronger and is used in NTLM authentication, which is widely used today.

After computing these hashes, Microsoft stores them in a number of places, to include the Security Accounts Manager (SAM) database, the Credential Manager (CredMan) store, as Local Security Authority (LSA) Secrets in the registry, in the Domain Active Directory Database on domain controllers, and in the memory of the Local Security Authority Subsystem (LSASS) process [4]. 2.2 Microsoft Local Security Authority

The structure of the authentication process and security authority subsystem is built from three primary PE files. The Local Security Authority Subsystem Process, or LSASS.exe, is started with the Windows operating system and is responsible for managing security­related tasks. MSV1_0.dll is the PE file that contains the meat of security subsystem, including the majority of exported Local Security Authority (LSA) functions, such as LSALogonUser, LSAApLogonTerminated, and others used by the operating system during authentication. LSASRV.dll is the mature API which other processes following proper Microsoft protocols use to handle credentials and interact with the Local Security Authority subsystem. The final PE file involved in the LSA is WIN_LOGON.exe which handles initial attempts to log into a domain or standalone windows computer.

MSV1_0.dll contains the credential block of currently logged in sessions which have been registered through the LSALogonUser API call. This block is added to using LsaAddCredential, which decrypts the credential storage block list and adds a new credential, and then re­encrypts the block using the BCRYPT.dll exported by the Microsoft Operating System.

Credentials are stored according to the following structure which maintains network identification as well as hashed password data. These credentials are kept in a singularly linked list, and a credential session counter variable is used to keep track of the size of the list.

typedef struct UNICODE_STR ustr_domain;

5

UNICODE_STR ustr_username; BYTE NThash[16]; BYTE LMhash[16]; BYTE Udomain[MAX_DOMAIN_LEN]; BYTE Uuser[MAX_USERNAME_LEN]; CREDENTIAL_BLOCK;

The credentials which the attacker is interested in fall within this block, specifically the NT hash and LM hash portions of the struct. Microsoft uses these to represent a user on the network, and allows authentication based on these hashes. If an attacker can gain access to these credentials, any network resource which the legitimate user can access, the attacker may also access. This includes network shares, other physical machines, servers, and any other resource which uses the Windows Domain Authentication subsystem. 2.3 Microsoft Domain Authentication Systems

This system intuitively scales to Windows domains. When a user logs on to a domain, the same underlying mechanisms are activated. The difference is that the LogonUser.exe process handles all the Local Security API calls with respect to a remote SAM database rather than one stored locally on the computer. The SAM database is where credential information is stored long term. During a typical login procedure the LSA compares the credentials entered in the LSALogonUser API call to either a remote or local SAM database to ensure that the credentials entered are valid. From that point on the LSA functions almost exactly the same way regardless of the connection to a domain.

2.4 Pass­the­Hash Within These Contexts

Pass­the­hash and other credential theft techniques take one of two directions ­ they either break into the process space of LSASS.exe and call functions of the various DLLs to extract the credential data, or they read the PE file’s memory directly and extract the data that they need.

While these two techniques do not at first glance seem significantly distinguishable, they offer very distinct challenges when defending against attackers on the system. With the current design of the LSA subsystem it is virtually impossible to defend against attackers who are executing code within the same process space as LSASS.exe. Since legitimate Windows programs require the ability to receive parts of a credential block, attackers may always request using functions from MS1_0.dll the Windows credentials block they seek.

Most tool writers have found that operating within the process is less reliable than reading the process memory, and can often cause the process to crash. In the latest Windows environments this would surely mean that the operating system itself would crash, an undesirable outcome for an attacker. Nevertheless, as researchers we must recognize that mitigating the current techniques of a particular pass­the­hash tool does not leave the adversary without options.

6

3. Previous Work Other organizations have spent time attempting to understand the consequences of these

problems as the seriousness of the vulnerability has been made clear by various incidents. The SANS institute and Microsoft have both published papers regarding best practices for domain administrators to mitigate the pass­the­hash vulnerability. 3.1 SANS’s Layered Solution

The SANS institute suggests that, given their assessment of the technology in 2010, the best solution to the pass­the­hash problem given publicly available software was to properly configure systems to take advantage of good security practices. SANS particularly noted that domain administrators should only login to domain controllers with their administrator accounts, and that network administrators should enforce LUA (Least User Access), which ensures that users are not given rights above what their tasks require. The SANS institute also suggests that avoiding old authentication standards, turning off cached credentials, and disabling debug privileges on a system will allow users to mitigate the fundamental flaws with the Windows authentication system.

Our research is distinctly different from the solutions posed by the SANS institute. The SANS proposals are completely focused on lowering the surface of attack, while doing nothing to change the underlying vulnerability. This means that if the attacker uses an atypical attack vector, such as a privilege escalation, he may still be able to gain access to the LM hash. Our research focuses on the analysis of new Windows platform technologies introduced in Windows 8.1 and Server 2012 instead of focusing on the previously suggested network policy changes and good security practices as a way to thwart pass­the­hash attacks. 3.2 Microsoft's Solutions

Microsoft has previously acknowledged that the pass­the­hash problem lies in the Windows authentication subsystem and would require a significant redesign to mitigate properly [4]. Microsoft suggests a number of potential mitigations, however they recognized that these mitigations are lacking and as of 2012 were actively seeking new ways to deal with this vulnerability.

The mitigation techniques put forth by Microsoft suggested taking steps similar to those suggested by SANS. The suggested mitigation techniques included restricting privileges of domain accounts and protecting the few accounts that need domain administrator privileges. Microsoft also suggested restricting inbound traffic on the network using firewalls, and removing standard users from local administrator groups. Knowledgeable individuals quickly recognize that the suggestions made by Microsoft are typical good security practices and built around avoiding network compromise, rather than avoiding specific pass­the­hash attacks.

The only mitigation technique mentioned by Microsoft which falls outside of basic security practices is the suggestion to disable the NTLM protocols entirely. However this too fails to properly protect the network as the substitute for network authentication becomes Kerberos, and Kerberos authentication has its own credential theft problems.

7

Microsoft recently re­addressed the pass­the­hash issue with their presentation at the RSA Conference in 2014 [6]. In this presentation, Microsoft addressed using new Windows platform technologies available in Windows Server 2012 R2 and Windows 8.1 to mitigate the pass­the­hash vulnerability. First, Microsoft addresses two new account groups that have been added ­ “Local Account” and “Local Account and Member of Administrators Group.” Microsoft claims that these groups are useful for restricting access, and can be used to stop pass­the­hash attacks. Next, Microsoft discusses some domain account mitigations, such as a new protected users security group for Active Directory, designed to better protect and manage domain credentials. Microsoft also discusses the new LSASS process protection, which intends to block the attempts of existing pass­the­hash tools to gain access to the memory of LSASS and dump the LM and NT hash. Microsoft then discusses the new Restricted Administration mode for Remote Desktop connections, which allows an administrator to log in to a workstation remotely without passing their credentials to the remote workstation. Finally, Microsoft touches on their new Authentication Policies and Silos, which enable the isolation of users or network resources.

As these pass­the­hash mitigation techniques have been newly introduced with Windows 8.1 and Windows Server 2012 R2, they have not yet been fully evaluated. Our research intends to serve as a comprehensive evaluation of each new Windows platform technology and determine its effectiveness at thwarting pass­the­hash attacks. 4. Methods

We determined our research methodologies by each of the proposed solutions we examined. We recreated solutions which had been implemented by Microsoft or industry partners in our own testing domain and evaluated their effectiveness at stopping pass­the­hash attacks using the Mimikatz pass­the­hash toolkit. Proposed solutions, however, required that we examine the potential impacts of the solution since we are not able to test actual implementations. 4.1 Setting Up A Domain

The first step in preparing our test environment was to properly configure a Windows 2012 Server as a domain controller and add a Windows 8.1 workstation to the domain. Domain configuration consisted of installing a Windows 2012 standard server, then installing the Active Directory Domain Services role using the Server Manager program within Server 2012.

8

Figure 3: Active Directory Installation

After installing the Active Directory Domain Services role, the user must configure the domain instantiation. In our case we created a new “forest” called Virtual.Local which would house our test domain. Our configuration is dramatically simple, and consists of a single virtual domain controller linked to several virtual Windows 8.1 workstations. Prior to testing our domain consisted of several users.

Figure 4: Adding Users

We also needed to install DNS services in order to handle domain names locally, including but not limited to the domain with which client computers will authenticate. All client computers in the

9

domain had to be added to the domain, first by pointing their primary DNS to the domain controller and then adding by the computer to the domain itself.

Figure 5: Joining the Domain

4.2 New Windows Platform Technologies

Our testing focused specifically on the new Windows platform technologies introduced with Windows 8.1 and Windows Server 2012 R2. We set up a test environment for each new technology, and evaluated the effectiveness of each at defending against pass­the­hash attacks. 4.2.1 LSA Protection

In Windows 8.1 and Server 2012 R2, users have the option to make LSASS.exe a protected process. Enabling LSA protection requires all plugins loaded into LSASS to have a valid Microsoft signature. The idea behind this is to block existing pass­the­hash toolkits from injecting into the LSASS process to dump password hashes. However, this is only enabled by default in Windows 8.1 RT; it is not enabled in Windows 8.1 or 2012 by default. To enable process protections, a user must edit the registry key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and set the value of the key to RunAsPPL=1, then restart the computer [11].

10

Figure 6: Running as Protected LSASS.exe

4.2.2 Restricted Remote Administration

Restricted remote administration allows an administrator to establish a remote desktop protocol (RDP) connection to a remote system without sending their credentials to that system. In theory, this is an improvement over typical RDP, in which an administrator’s credentials would be sent to and stored by an end user system. Sending credentials to an end user system through an RDP login potentially exposes those administrator credentials to infected end­user systems and enables attackers to use them to expand laterally within a target network. Restricted remote administration mode results in better protection of administrator credentials since they will no longer be exposed to end user workstations through RDP. 4.2.3 Silos

Authentication policy silos are a new feature of Windows Server 2012 R2 which enable a network administrator to isolate users and systems into their own containers. The idea behind authentication policy silos is to create restrictive subsections of network users and workstations to prevent credential misuse. In essence, authentication policy silos restrict where a user can log in from, so that even if an attacker does acquire an administrator’s password hash, he will be unable to use it unless coming from an administrator’s workstation. Authentication policy silos are created via the Active Directory Administration Center in Windows Server 2012 R2 [12]. Since authentication policy silos

11

force authentication via the Kerberos protocol, they are outside the scope of our testing. 4.2.4 Local Account

In Windows 8.1 and Server 2012, Microsoft provides a way to better restrict local accounts from being used laterally across a network. This is accomplished through the creation of two new security identifiers ­ “Local account” and “Local account and member of the Administrators group.” By default, Windows 8.1 places each local account into these groups [13]. To prevent pass­the­hash attacks using these accounts, a network administrator must simply deny network logons from these identifiers [14]. 4.3 Pass­The­Hash Toolkits

There are many publicly available pass­the­hash toolkits, and several retrieve credentials in different ways. The two primary toolkits which have been incorporated into penetration testing frameworks such as Metasploit are Mimikatz and Windows Credential Editor. For the purposes of our testing we used Mimikatz, precisely because the retrieval process for these two toolkits is identical. 4.3.1 Windows Credential Editor

The Windows Credential Editor (WCE) toolkit functions by dumping credentials from memory and does not need to be injected into LSASS.exe to function [5]. To do this the WCE toolkit gains SE_DEBUG privileges for the LSASS.exe process on the victim’s computer. Using these privileges WCE copies the loaded PE file in memory and extract’s specific sections of the LSASS.exe process. The program then decrypts the authentication blocks using microsoft’s BCRYPT.dll and a key extracted from process memory. The authentication blocks contain all of the relevant user authentication data. 4.3.2 Mimikatz

Mimikatz also recovers credentials from memory. It works almost equivalently to Windows Credential Editor. This tool used to inject itself into the LSASS.exe process and interact directly with the process rather than read memory. However, the latest versions have been modified to use the same passive strategy as WCE. Mimikatz has expanded functionality to pull http credential data and other stored credentials from memory [18]. It is because Mimikatz seemed to capitalize on all weakness in the authentication subsystem that we choose this tool kit for our experiments. 5. Results

We collected results of testing cutting edge Microsoft platform technologies designed to stop credential theft by modern pass­the­hash toolkits. We were specifically able to successfully test the LSA protections and restricted remote admininstration protections. In both of these cases, we found that credentials in memory were hidden from potential attackers.

12

5.1 LSA Protection Once LSA process protection is enabled, our group found that modern credential extraction

tools are unable to break into the LSASS.exe process and read memory. When attempting to use Mimikatz to extract credentials, we received an error message. However, these programs are all using user level API calls and user level permissions. If an adversary is operating within kernel space, no block of memory is safe from the adversary.

Figure 7: Testing LSA Process Protection

Our group also considered the possibility that an attacker could simply modify the registry key corresponding to LSA process protection back. We attempted this; however Microsoft thought of this as well, and once LSA is made a protected process, the process protections cannot be removed.

Implementing process protection is a step forward in making credential theft harder for attackers, however it does not change the pass­the­hash vulnerability. If a user has extracted proper

13

credentials from any system on the domain then he may still use those credentials to authenticate services on the Windows 8.1 machine or anywhere else. Process protection only aims to make credentials more difficult to obtain from a Windows machine. 5.2 Restricted Remote Administration

Restricted remote administration is not used by default but can be specified as an argument to

the RDP binary, MSTSC.exe, by specifying “mstsc /remoteAdmin” the via command line.

Figure 8: Using Restricted Remote Administration

When using restricted remote administration, a malicious actor can still execute pass­the­hash toolkits to retrieve local account password hashes for user accounts who have logged in to that machine. However, the credentials associated with the remote log on cannot be retrieved.

14

Figure 9: Attacking Remote Admin

The section of the Mimikatz execution most relevant section to our experiment has been placed

below.

Authentication Id : 0 ; 204438 (00000000:00031e96) Session : RemoteInteractive from 2 User Name : Administrator Domain : VIRTUAL SID : S­1­5­21­534258492­3024196616­1093290638­500

msv : [00000003] Primary * Username : PTH­LAB$ * Domain : VIRTUAL * LM : 00000000000000000000000000000000 * NTLM : 8efca7d38e046e6f87d017821744baf1 * SHA1 : 2d359d114016dcfeb2441155fe1b7dc46efce94b tspkg : wdigest : * Username : PTH­LAB$ * Domain : VIRTUAL * Password : (null) livessp :

15

kerberos : * Username : PTH­LAB$ * Domain : VIRTUAL.LOCAL * Password : (null) ssp : credman :

The credential dump for the remote session, displayed above, has details which are not

representative of the domain administrator’s actual credentials. The domain administrator for our test network was using the password “drowssap1~”. When processed to be used for local security authority credentials this password corresponds to the NTLM hash of CB9C2812FB09F6D8B53FDB315B9D5094. This is entirely different than the credentials which were extracted from the remote machine. This means that while credential reuse has not been eliminated during restricted administration sessions, the restricted user’s accounts are never stored on the remote machine. Given this evidence one must assume that this technique is successful at blocking malicious users from stealing credentials of users who are using restricted remote administration on Windows domains.

Unfortunately, the operating systems which support restricted remote administration are only Windows Server 2012 R2 and Windows 8.1. Since almost all corporate networks have not yet completely upgraded to the latest Windows operating systems, the impact of this particular change is not enormous at this time. However, it is a step in the right direction for better protecting administrator credentials on domain assets. 6. Mitigation Proposals

We found that proposals for mitigating against the pass­the­hash vulnerability from the entirety of the security community were of various levels of academic worth when compared to the current NTLM authentication system. A relevant factor to each of these proposals is a predicted rate of adoption by industries using active directory networks.

6.1 TPM­Based Credential Storage

Other mitigation techniques and proposals revolve around unimplemented solutions. In particular, AIS was interested in the potential efficacy and effectiveness of a Trusted Platform Module (TPM)­based solution to the NTLM credential problem. It’s clear from an analysis of NTLM and the TPM specifications that TPM technology is not a strong fit for the established NTLM authentication protocol.

The poor fit of TPM as a solution for protecting credentials is due to the lack of a proper root of trust in a modern environment, as well as the functionality exposed by the TPM to the operating system. The original premise of our research was based on a heavily contested software environment, even one where the adversary has access to the most trusted permission level. The problem this creates

16

for a TPM solution is that adversaries will have access to the same TPM functionality as legitimate software. TPM functionality includes the ability to reset the TPM [21] and rebuild PCR registers which are used to ensure that the system is in a verifiably trusted state [21]. Without these features of the TPM, any attempts to store keys or seal keys becomes useless, as an attacker can force the TPM into a state where it allows encryption keys to be unsealed. Furthermore attackers may find that attacking the TPM is completely unnecessary to obtain the NTLM hashes or credential information, as there already exist functions which decrypt credential data to use it for network authentication. Attackers have already used these legitimate functions to force the Local Security Authority to dynamically decrypt credential data and hand it to an attacker.

These challenges could potentially be overcome by building a tiered system which hashes executable code segments prior to loading them into memory to ensure that they were valid at load time. However, building a tiered system such as this would require a significant redesign of almost the entire operating system and still would likely house significant runtime flaws allowing the execution of arbitrary code. Return oriented programming could be one avenue which could allow users to use pieces of legitimate code to subvert parts of such a system.

Considering the significant investment required to redesign operating systems around TPMs, and the potential pitfalls and inflexibility of a redesigned system, TPM­based solutions do not seem promising in the near term to solve the problem of pass­the­hash vulnerabilities. 6.2 Hardware Tokens

Hardware tokens for the purpose of single sign on are perhaps the most appealing proposal we considered. Using this method, credentials are never cached in memory and instead are only read from the hardware authentication system when required. Removing credentials from memory entirely would ensure that no pass­the­hash toolkit could extract those credentials. However, there still could be a pathway for a malicious user to extract data from the physical token, especially in the case of static hardware tokens. The cost of the technology is high for this solution, but the results are very effective.

This potential vulnerability of hardware based systems is analogous to an attacker’s potential use of the TPM­exported functions in order to subvert security on the system. It is important to note that for an attacker to have any chance at stealing the credentials of the user, the physical token must be present. 6.3 Elimination of Single Sign On

The elimination of single sign on seems to be the most intuitive solution to the pass­the­hash problem. Removing cached credentials from Windows workstations would ensure that even in the event that an attacker gained remote code execution on an end­user workstation, credential theft could not occur. On a Windows domain this would have to be implemented such that every time a network resource was used, the domain user would be forced to re­enter his authentication credentials.

Modern critics of the pass­the­hash vulnerabilities often discuss this solution as significant in theory however in practice likely a non starter [19]. The workflow costs, such as the many logins to do

17

normal network navigation, are not worth the benefits in security to implement this type of protection, especially from a Microsoft perspective. Single sign on is the model that Microsoft domains were built around; expecting them to do away with this idea is unrealistic. 6.4 Kerberos

Kerberos authentication is touted by Microsoft as being more secure and more efficient than NTLM authentication [20]. Kerberos works by issuing tickets to be used for authentication rather than authenticating with actual user data. Kerberos tickets also expire after a configurable length of time, so even though they too are vulnerable to theft, they at least only provide an attacker with access to network resources for a limited amount of time.

Kerberos tickets also offer an additional advantage because the tickets granted do not relate to login credentials. While NTLM hashes are often cracked to extract plain text credential information, Kerberos would be immune to this. Which means credential data doesn’t need to be stored in memory or sent over network connections other than the initial login.

Similar to NTLM kerberos is extensively targeted for the purposes of obtaining network credentials. Mimikatz and Windows Credential editor already by default attempt to extract a TGT (ticket granting ticket) allowing malicious users access to the same systems a legitimate use would.

7. Discussion

This section concludes our analysis of the various pass­the­hash mitigations and comments on those which seem most promising. We also provide recommendations to both protocol writers for network authentication as well as the information technology industry in general. 7.1 Windows 8.1 and Server 2012 Solutions

Overall, our group found that while the strides taken by Microsoft to harden domains against pass­the­hash are a step forward in credential security, none of these new platform technologies actually attempt to patch the pass­the­hash vulnerability. Further, we find it concerning that for many of these new technologies to be used they must be enabled or specified by network administrators.

LSA protection is a novel idea that attempts to make it harder for the average script kiddie to obtain password hashes using traditional pass­the­hash toolkits. However, it is not enabled by default but rather requires a network administrator to modify a registry key to enable it. For this to be effective, network administrators must be aware of the existence of process protection in newer versions of Windows and take steps to implement it. Further, there is no way to enable LSA protection through a user interface, so enabling process protection becomes even more of a burden on network administrators and may not be trivial for average users who rely on user interfaces to perform most tasks.

Restricted remote administration is a step forward in protecting administrator credentials from being exposed on other potentially compromised workstations within a network. However, it must be specified as a command line argument to RDP. However, many network administrators and users

18

initiate a RDP connection by double clicking the Remote Desktop Connection executable in Windows rather than via command line, and the restricted remote administration option can only be specified via command line. Further, Portcullis Labs recently published research suggesting that restricted remote administration introduces a new vulnerability, allowing an attacker to authenticate via RDP using a password hash rather than a plaintext password [16]. It is questionable as to whether an attacker will be able to obtain an administrator’s password hash if restricted remote administration is enabled; however, it is necessary to note that the introduction of this capability weakens the RDP protocol in that it no longer requires authentication using a plaintext password but can now accept a password hash.

Last, we find it notable to mention that all of these mitigations require a network to be using the latest versions of the Windows operating system, Windows 8.1 and Server 2012. However, many organizations will not upgrade to the latest operating system right away due to the cost and effort required. These features have not been back­ported to older versions of the Windows operating system, so while they may represent a forward stride in credential protection, many organizations will not feel the benefits of these new platform technologies for a number of years until all of their systems have been upgraded. 7.2 Recommendations

Our group recommends using the new Windows platform technologies if you are using the latest versions of the Windows operating system, as these platform technologies do represent a stride forward in credential protection. We also recommend network administrators limit the use of domain administrator credentials, and use the principle of least privilege when granting user account permissions in a domain environment. Long term recommendations include moving away from NTLM authentication if possible, in favor of Kerberos authentication or hardware authentication tokens without static keys. 8. Open Problems and Conclusion

Overall, the new platform technologies introduced by Microsoft in the latest versions of their operating system attempt to reduce the exposure of credentials in memory.

19

Figure 10: A picture of credential data in memory, taken from Microsoft [6]

By making it harder for attackers to obtain password hashes, Microsoft makes harder ­ but

does not eliminate or patch against ­ pass­the­hash attacks. The only way to patch against these attacks is to completely rethink the way Microsoft does authentication. Until Microsoft does this, the best they can hope to do is to limit the exposure of password hashes and make these attacks harder for attackers to perform. However, though these new platform technologies may slow an attacker down momentarily, they will not stop a persistent attacker as they do not address the underlying pass­the­hash vulnerability.

20

8. References [1] APTISS. (2008). Trusted Platform Module TPM Fundamental [Powerpoint Slides]. Retrieved from http://www.cs.unh.edu/~it666/reading_list/Hardware/ tpm_fundamentals.pdf [2] Duckwall, Skip, and Chris Campbell. (2013). Hello My Name Is Microsoft and I Have A Credential Problem [White Paper]. Retrieved from https://media.blackhat.com/us­13/ US­13­Duckwall­Pass­the­Hash­WP.pdf [3] Gurgens, Sigrid and Carsten Rudolph, Dirk Scheuermann, Marion Atts, Rainer Plaga. (n.d.). Security evaluation of scenarios based on the TCG’s TPM Specification [White paper]. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download? doi=10.1.1.218.5679&rep=rep1&type=pdf [4] Microsoft Corporation. (2012). Mitigating Pass­the­Hash (PtH) Attacks and Other Credential Theft Techniques[White paper]. Retrieved from http://www.microsoft.com/en­us/download/details.aspx?id=36036 [5] Ochoa, Hernan. (2011). WCE Internals [Powerpoint slides]. Retrieved from http://www.ampliasecurity.com/research/WCE_Internals_RootedCon2011_ampliasecurity.pdf [6] Russinovich, Mark and Nathan Ide. (2014). Pass­the­Hash: How Attackers Spread and How to Stop Them [Powerpoint slides]. Retrieved from http://www.rsaconference.com/writable/presentations/file_upload/hta­w03­pass­the­hash­how­attackers­spread­and­how­to­stop­them.pdf [7] SANS Institute. (2009). Why Crack When You Can Pass the Hash? [White Paper]. Retrieved from http://www.sans.org/reading­room/whitepapers/testing/crack­pass ­hash­33219?show=crack­pass­hash­33219&cat=testing [8] SANS Institute. (2010). Pass­the­hash attacks: Tools and Mitigation [White paper]. Retrieved from http://www.sans.org/reading­room/whitepapers/testing/ pass­the­hash­attacks­tools­mitigation­33283 [9] SecurityFocus. (1997). NT "Pass the Hash" with Modified SMB Client Vulnerability. Retrieved from http://www.securityfocus.com/bid/233/info [10] Segall, Ariel. (n.d.). Using the TPM: Data Protection and Storage [Powerpoint slides].

21

Retrieved from http://opensecuritytraining.info/IntroToTrustedComputing_ files/Day2­2­data­storage.pdf [11] Microsoft. (2013). Configuring Additional LSA Protection. Retrieved from http://technet.microsoft.com/en­us/library/dn408187.aspx [12] Microsoft. (2013). Authentication Policies and Authentication Policy Silos.Retrieved from http://technet.microsoft.com/en­us/library/dn486813.aspx [13] National Security Agency. (2013). Reducing the Effectiveness of Pass­the­Hash. Retrieved from http://www.nsa.gov/ia/_files/app/Reducing_the_Effectiveness_of_ Pass­the­Hash.pdf [14] A Hacker News. (2013). Windows 8.1 Stops Pass­the­Hash Attacks. Retrieved from http://ahackernews.com/hacker­news/2013/windows­8­1­stops­pass­hash­attacks/ [15] Microsoft. (2013). Pass the Hash and Other Credential Theft and Reuse: Mitigating the Risk of Lateral Movement and Privilege Escalation [Powerpoint slides]. Retrieved from https://media.blackhat.com/us­13/us­13­Jungles­Pass­the­Hash­and­Other­ Credential­Theft­and­Reuse­Mitigating­the­risk­of­Lateral­Movement­and­Privilege­Escalation.pdf [16] Portcullis Labs. (2013). New “Restricted Admin” Feature of RDP 8.1 Allows Pass the Hash. Retrieved from https://labs.portcullis.co.uk/blog/new­restricted­admin­ feature­of­rdp­8­1­allows­pass­the­hash/ [17] Johannson, Jesper. (2006). Security Watch: The Most Misunderstood Windows Security Setting of All Time [Article]. Retrieved from http://technet.microsoft.com/en­us/ magazine/2006.08.securitywatch.aspx [18] Security Tube. (2012). Grabbing Windows Passwords in Plain Text. [Video]. Retrieved from http://www.securitytube.net/video/5601 [19] Campbell, Chris and Skip Duckwall. (n.d.) Still Passing the Hash 15 Years Later. [Blog]. Retrieved from http://passing­the­hash.blogspot.com/ [20] Microsoft. (2003). What is Kerberos Authentication? Retrieved from http://technet.microsoft.com/en­us/library/cc780469(v=ws.10).aspx [21] University of Texas Austin. (2013). Cloaking Malware with the Trusted Platform Module.

22

Retrieved from https://www.usenix.org/legacy/event/sec11/tech/full_papers/Dunn.pdf

23