Skip to Content.
Sympa Menu

ad-assurance - [AD-Assurance] Microsoft TwC "Pass-the-Hash" document

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

[AD-Assurance] Microsoft TwC "Pass-the-Hash" document

Chronological Thread 
  • From: "Capehart,Jeffrey D" <>
  • To: "" <>
  • Subject: [AD-Assurance] Microsoft TwC "Pass-the-Hash" document
  • Date: Wed, 29 May 2013 20:55:59 +0000
  • Accept-language: en-US
  • Authentication-results:; dkim=neutral (message not signed) header.i=none



I had seen that document, but apparently I only shared it internally.  My suggestion at the time was to do a quick review to see how many of the Active Directory Domain Service DC’s are currently following techniques listed in the mitigations 1, 2, or 3 below.


For future development of Community Documentation, a checklist based on these techniques would be useful in evaluating the security of the credential store beyond the minimum requirements in Silver.  Techniques could be used as compensating controls for criteria that may need an alternative means if the configuration recommendation cannot or will not be met (approved algorithms, not using Bitlocker, for example.)  In this case, since Microsoft has specific recommendations, perhaps these techniques (and a checklist!) would be relevant to AD-DS and not just some generic password store.




The Microsoft Trustworthy Computing (TwC) initiative produced this 78 page that includes a number of techniques to be used to protect the credential store.


Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques
Explore Pass-the-Hash (PtH) attacks against Windows operating systems, learn how the attack is performed, and get recommended mitigations for PtH attacks and similar credential theft attacks.


In particular:  “The PtH technique allows an attacker who has compromised a single computer to gain access to connected computers, including domain controllers and other servers storing sensitive information. For this reason, mitigating the risk of PtH attacks and other similar credential theft attacks can significantly improve the security posture of an Active Directory environment. The PtH attack is one specific type of credential theft and reuse attack. While this document focuses on Windows operating systems, other operating systems are vulnerable to similar credential theft and reuse attacks.”



Mitigation 1: Restrict and protect high privileged domain accounts

Main objective: This mitigation restricts the ability of administrators to inadvertently expose privileged credentials to higher risk computers.

How: Completing the following tasks is required to successfully implement this mitigation:

• Restrict domain administrator accounts and other privileged accounts from authenticating to lower trust servers and workstations.

• Provide admins with accounts to perform administrative duties that are separate from their normal user accounts.

• Assign dedicated workstations for administrative tasks.

• Mark privileged accounts as “sensitive and cannot be delegated” in Active Directory.

• Do not configure services or schedule tasks to use privileged domain accounts on lower trust systems, such as user workstations.


Mitigation 2: Restrict and protect local accounts with administrative privileges

Main objective: This mitigation restricts the ability of attackers to use local administrator accounts or their equivalents for lateral movement PtH attacks.

How: Completing one or a combination of the following tasks is required to successfully implement this mitigation on all computers in the organization:

1. Enforce the restrictions available in Windows Vista and newer that prevent local accounts from being used for remote administration.

2. Explicitly deny network and Remote Desktop logon rights for all local administrative accounts.

3. Create unique passwords for accounts with local administrative privileges.


Mitigation 3: Restrict inbound traffic using the Windows Firewall

One of the most important prerequisites for an attacker to conduct lateral movement or privilege escalation is to be able to contact other computers on the network.

Main objective: This mitigation restricts attackers from initiating lateral movement from a compromised workstation by blocking inbound connections on all workstations with the local Windows Firewall.

How: This mitigation restricts all inbound connections to all workstations except for those with expected traffic originating from trusted sources, such as helpdesk, workstations, security compliance scanners, and management servers.



Do not allow browsing the Internet with highly privileged accounts

Internet activities, such as browsing the Internet and reading email, are inherently high risk activities because they process content accessed from the Internet that is potentially malicious or dangerous. If user accounts with administrative rights are used to perform these activities, a potential compromise on the computer or application can lead to immediate attacker control of those administrative rights. For these reasons, we recommend separating administrative rights from Internet access where possible by doing the following:

• Remove standard users from the local Administrators group.

• Configure outbound proxies to deny Internet access to privileged accounts.

• Ensure administrative accounts do not have email accounts or mailboxes associated with them.


Additional recommendations

·         Use remote management tools that do not place reusable credentials on a remote computer’s memory

·         Avoid logons to less secure computers that are more likely to be compromised

·         Update applications and operating systems

·         Limit the number and use of privileged domain accounts

·         Secure and manage domain controllers

·         Remove LM hashes

·         Disable the NTLM protocol

·         Reboot workstations and servers





Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

  • [AD-Assurance] Microsoft TwC "Pass-the-Hash" document, Capehart,Jeffrey D, 05/29/2013

Archive powered by MHonArc 2.6.16.

Top of Page