Defending Against Pass-the-Hash Attacks

Pass-the-Hash Defenses

So what can be done to reduce the risk of PtH attacks? This section of the article summarizes the official Microsoft recommendations to decrease the risk of PtH attacks. Many mitigation controls are possible, but not all are equally easy to implement by all customers. Implement suggested mitigations only after careful consideration and testing.

Prevent attackers from gaining local administrator access

The real problem faced by victims of PtH attacks is that the attackers were able to gain access to privileged accounts in the first place. Password hashes must be stored in memory on computers in single-sign-on environments, so there is little an IT department can do to prevent an attacker with administrator or system permissions from stealing the hashes and other credentials entrusted to the local computer. In addition, the level of access that is required to steal password hashes from an active session would also allow attackers to capture logon credentials using other mechanisms, such as a keylogger. Therefore, even if PtH attack methods could be completely stopped, attackers could still accomplish the same outcomes through equally powerful means.

More than a decade ago, the MSRC formulated a set of computer security observations called Ten Immutable Laws of Security that covered a number of principles that apply to PtH attacks:

  • Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
  • Law #6: A computer is only as secure as the administrator is trustworthy.
  • Law #10: Technology is not a panacea.

The most powerful defense is to prevent attackers from taking advantage of users’ permission levels in the first place. If users aren’t local administrators, running an attacker’s trojan won’t automatically give the attacker the level of access required to do password hash dumps. Without privileged access, the attacker may still be able to gain access to the current user’s logged on account but they won’t be as easily able to capture and use other hashes.

To gain privileged access when an attacker only has the current user’s non-privileged access (called an escalation of privilege attack), the attacker would need to use an additional exploit that escalates their privilege. A fully updated computer makes escalation of privilege attacks more difficult to accomplish.

Enable User Account Control

Although requiring that users not belong to the local Administrators group on their computers, the ideal solution for user workstations is to have user accounts run without local administrator permissions. However, this requirement may be something that many customers are unwilling to undertake. The User Account Control (UAC) technology built into Windows 7 and other recent Windows releases can provide some benefits by providing an additional barrier that an attacker must overcome. When UAC is enabled, members of administrator groups run with standard permissions most of the time and must explicitly grant permission for a program or process (such as an attacker’s trojan) to run with administrator rights. This functionality can help prevent an attacker from gaining the necessary permission level to access the hashes stored in authentication databases.

Minimize the membership of privileged groups

Minimize the number and type of computers that members of privileged groups are allowed to log on to. For example:

  • Prevent members of the Domain Admins group from logging on to non-domain controllers.
  • Prevent local Administrators (and other local accounts with elevated permissions) from performing network logons.
  • Prevent elevated accounts from logging on to any computers except the ones they need.

Use role-based delegation

Instead of granting permanent privileged group membership to Administrator accounts, use a role-based delegation strategy to grant accounts the specific permissions that they require. The Delegation of Control Wizard in Active Directory Users and Computers provides hundreds of predefined tasks that can be delegated to individual user accounts or groups. Create role-based groups and assign one or more delegated tasks to each role, and use organizational units (OUs) to control the logical areas in which each delegated task can be performed.

For example, if level 1 help desk personnel need the ability to reset user passwords and modify user accounts, adding them to the Domain Admins group would create significant risk by giving them rights to perform hundreds of privileged tasks that their job doesn’t require them to do. Instead, assign them to a role-based group that can reset user passwords and modify user accounts for anyone in the domain. Similarly, you can create roles for server operators to administer only specific servers, and so on. By giving every account holder only the minimum permissions they need to perform their duties, you can significantly reduce the risk the organization faces from PtH and similar attacks.

See for Delegation of Control Wizard documentation that applies to recent versions of Windows Server, and see “Best Practices for Delegating Active Directory Administration,” available from the Microsoft Download Center, for a comprehensive overview of delegation in Active Directory (written for older versions of Windows Server, but containing much valuable information for anyone who is new to the concepts.)

Minimize the use of privileged user rights assignments

Privileged group membership is not always necessary to elevate users’ permissions. Microsoft considers the following permissions to be elevated:

  • Create token object (SeCreateTokenPrivilege)
  • Act as part of the operating system (SeTcbPrivilege)
  • Take ownership (SeTakeOwnershipPrivilege)
  • Back up files and directories (SeBackupPrivilege)
  • Restore files and directories (SeRestorePrivilege)
  • Debug programs (SeDebugPrivilege)
  • Impersonate client after authentication (SeImpersonate)
  • Modify object label (SeRelabelPrivilege)
  • Load and unload device drivers (SeLoadDriverPrivilege)

Any security principal account, even without belonging to a privileged group, can perform elevated tasks, up to and including gaining complete control of the domain or forest. Therefore, it’s considered a best practice to minimize the number of security principals who are granted permanent elevated permissions. Instead, use delegation as suggested earlier or grant elevated permissions only when needed.

Restrict logons to additional computers

An attacker with sufficient permissions can use stolen hashes to move from computer to computer in an organization. You can mitigate this risk by using various methods to restrict logons, as shown in Figure 62.

Figure 62. Mitigating PtH attacks by restricting logons


Local Accounts

Domain Accounts

Restricting the logon rights for privileged accounts stored in the local SAM:

  • Denying network logon

  • Denying RDP logon


Randomizing the passwords for built-in accounts in the local SAM


Disabling the local accounts


Granting permissions to workstation administrators only on a temporary basis


Use isolated management computers

One of the greatest risks in any environment occurs when privileged accounts log on to computers that are not under complete control of the privileged account, especially computers that have access to Internet browsing or email. Every time a privileged account logs on to a high-risk computer, it increases the chances that the privileged accounts credentials will be stolen.

To reduce risk, privileged accounts should only be used to log on to highly secure, dedicated management workstations. These computers (sometimes known as jump boxes or trusted computers) should not be used for any other purpose, and should not be able to access the Internet; if Internet access is needed, it should be limited to a few defined websites. Such a management computer can be used to safely run privileged processes, or to run other processes against remote computers that are less susceptible to PtH attacks (discussed later in this section). Many organizations use virtual machines as management computers, resetting them after each and every logout. Access to management computers should be monitored and audited.

Reboot computers after logging on using privileged credentials

Most of the time, password hashes are removed from memory after an active logon session is terminated. However, password hash removal depends on the involved applications and processes, and some malfunctioning applications may not remove the hashes. Therefore, it is possible for password hashes to remain after the privileged user has logged out. It is also common for privileged users to end remote sessions without logging out, thereby leaving the active session open. Whenever possible, privileged users should reboot computers after they accomplish their tasks to ensure that password hashes do not remain in memory for attackers to access. Rebooting may not be possible on highly used production computers, but it should be done whenever possible.

Minimize elevated remote interactive network logins

One of the most common administrative methods is to use Remote Desktop or Terminal Services to log on to a computer to administer it. Because these types of logons are interactive, the password hashes of the logged on user are kept in memory for at least the duration of the session. Therefore, administrators should minimize the use of remote, interactive logons (as well as batch and service logons, which have the same issues).

Instead, use other, non-interactive methods of administration, including the ones in the following list.

  • MMC snap-ins. Administrators can use Microsoft Management Console (MMC) snap-ins to perform operations on remote computers as they would locally, without leaving password hashes on the target computer for attackers to steal.
  • Windows PowerShell. Using PowerShell (without CredSSP) is an excellent way to administer targeted computers without leaving password hashes in memory. Many tasks can be completely accomplished using PowerShell cmdlets.
  • Other tools. Many other remote management tools can be used to administer computers remotely without using a full interactive session. For example, the PsExec tool, available for download from the Windows Sysinternals site at, can be used to perform remote administrative tasks. Although it is theoretically possible for an attacker to steal the logon credentials or token while the task is operating, the credentials or token are removed from memory when the task finishes and exits.

Minimize password reuse

Password reuse across multiple computers creates some of the greatest risk from PtH attacks. Many customers use scripts and third-party tools to either ensure that no password is reused over multiple computers (for example, by requiring a different password for every local Administrator account on each computer), or to require one-time passwords (OTP) or password changes after every session. Any OTP hashes that might be stolen by an attacker cannot be used to create future active sessions, which minimizes the attacker’s ability to access other computers. (Note, however, that many third-party OTP management tools use privileged accounts to reset passwords, which can themselves become vulnerable to attack.)

Scan for and eliminate PtH tools

Most antimalware scanners detect many common PtH tools. Make sure your antimalware scanner is configured to detect hacking tools, and to look specifically for the presence of PtH-related software.

Create separate security zones

PtH attacks often compromise all the password hashes in an entire domain or forest. If you are worried about one successful PtH campaign in a weakly secured domain leading to a compromise of a more strongly secured domain, consider creating a separate forest. Forests are security boundaries in Active Directory. Having separate forests reduces the potential spread of a single PtH attack campaign. Maintaining separate forests can impose additional administrative costs and responsibilities, but the additional overhead may be justified in some scenarios.

Check for leftover password hashes in memory

Although no currently supported Microsoft software products leave password hashes in memory after the conclusion of an interactive session, some older or third-party tools might. If you are concerned about this problem, use existing tools to look for password hashes in memory after the active sessions have ended. The LogonSessions tool, available for download from the Windows Sysinternals site at, lists the currently active logon sessions on a computer, which can help you locate problem software that leaves hashes in memory.


Successful PtH attacks can create a significant degree of risk in any environment. Although they require privileged access to begin the attacks, they can allow an attacker to gain a large amount of control over a domain or forest if administrative practices are not adapted to thwart attacks. Following the guidelines presented in this section can help you mitigate the risk your organization faces from PtH attacks and minimize any potential resulting damage.

Top of page Top of Page

Managing Risk


United States Change All Microsoft Sites



Was the information in this article helpful?