Mitigating Pass-the-Hash Attacks and Other Credential Theft Techniques

Summary:

This document appears to be focused on cybersecurity policies and procedures within an organization, particularly concerning network security and user account management, including detailed steps for configuring local privileged accounts and restricting inbound traffic on workstations using Remote Desktop Services and Windows Firewall. Below is a summary of the key points from this text: ### User Rights Assignment and Account Policies To ensure that all local accounts are denied network logons to mitigate password hash theft (PtH) attacks, follow these steps with an account in the Domain Admins group: 1. **Disable Guest Account**: - Ensure the guest account is disabled on workstations. 2. **Limit Local Admin Rights**: - Assign local administrative rights only to essential personnel and ensure that no other users have direct local administrator privileges. 3. **Implement Strong Password Policies**: - Enforce strong password policies including complexity requirements, minimum length, expiration, and history retention. 4. **Use Microsoft Account or Domain Accounts**: - Encourage the use of Microsoft accounts or domain accounts for easier management and security. ### Inbound Firewall Rules Configuration Using Group Policy Objects (GPOs) To configure inbound firewall rules on workstations, follow these steps: 1. **Enable Windows Firewall Inbound Policy**: - Open Group Policy Management Console > Computer Configuration > Security Settings > Windows Firewall with Advanced Security. Enable the firewall and set inbound connections to block except for specific exceptions. 2. **Configure Inbound Exception for Remote Management Hosts**: - Create a custom inbound rule allowing connections from remote management hosts, defining scope based on these hosts and selecting appropriate profiles. 3. **Deploy the GPO**: - Link the GPO to workstation OUs and test applications and systems to ensure compatibility with new firewall settings. ### Pass-the-Hash (PtH) Attack Mitigation The document addresses PtH attacks, emphasizing that Windows OS is a common target but other operating systems can be affected. The recommended mitigation strategies include: 1. **Use of Unique Passwords**: - Ensure unique passwords for local accounts to minimize the risk if hashes are stolen. 2. **Disable NTLM EPM (Extensible Authentication Protocol) and Credential Guard**: - These features can help prevent PtH attacks by disabling certain authentication protocols used in these attacks. ### Conclusion This document provides a detailed guide on how to configure local privileged accounts, restrict inbound traffic using GPOs, and mitigate the risk of Pass-the-Hash (PtH) attacks within an organization. The steps outlined are designed to enhance network security by controlling inbound traffic through carefully configured firewall rules and enforcing robust account management policies.

Details:

This document provides information on how to mitigate Pass-the-Hash (PtH) attacks and other credential theft techniques. PtH attacks involve using pre-obtained valid user credentials, typically in the form of a hash value, to authenticate as that user on another machine within the same network. The document outlines several mitigations strategies for organizations to reduce the risk of such attacks: 1. Restrict and protect high privileged domain accounts by limiting their use and ensuring they are not used excessively or without proper authorization. 2. Protect local accounts with administrative privileges by restricting access and monitoring activities closely related to PtH attacks. 3. Use remote management tools that do not store reusable credentials on the remote computer, as this can be exploited in a PtH attack. 4. Implement strict network security measures such as configuring the Windows Firewall to restrict inbound traffic. 5. Update applications, operating systems, and other software regularly to patch vulnerabilities that could be exploited for credential theft. 6. Remove LM hashes from user accounts to make PtH attacks more difficult. 7. Other potential mitigations include disabling NTLM authentication protocol, ensuring administrative users do not have email accounts, restricting the use of standard users in the local Administrators group, and configuring outbound proxies to deny Internet access to privileged accounts. 8. The document emphasizes that organizations should continuously evaluate their security posture and adjust strategies as necessary based on emerging threats and best practices. This document discusses various security measures and strategies to mitigate Pass-the-Hash (PtH) attacks in Windows environments. PtH is a type of cyberattack where an attacker steals valid logon credentials from one computer and uses them to access other computers on the network without needing the actual password. The document outlines specific tasks for administrators to restrict and protect local accounts, implement multifactor authentication, and configure security protocols such as Kerberos and Windows authentication. The first mitigation step involves separating administrative accounts from user accounts, creating dedicated workstations for admins, restricting logon access, disabling account delegation, enforcing unique passwords for local privileged accounts, and setting up strict firewall rules using Group Policy Objects (GPOs). These measures aim to minimize the risk of PtH attacks by limiting the potential exposure of high-privileged domain accounts. The document also includes a step-by-step guide in Appendix A detailing how to implement these mitigation strategies effectively. It provides detailed instructions and considerations for each task, such as separating administrative and user accounts, creating specific workstation hosts for admins, restricting access based on logon types, enforcing local account restrictions, and setting up the Windows Firewall with GPOs. The document concludes by emphasizing that implementing strong security practices through these tasks can significantly reduce the risk of successful PtH attacks in a Windows environment. The article discusses a technique where an attacker must first gain local administrative access on a computer within an organization to steal credentials from the disk and memory. This level of privilege enables the attacker not only to obtain password hashes but also any other stored credentials. To achieve this, the attacker can exploit built-in local administrator accounts, domain accounts with membership in the local administrators group, or another local account capable of installing drivers, applications, and executing applications that interact directly with the hard disk or volatile memory. Once the attacker has obtained local administrative access, they can use it to compromise connected computers including domain controllers and other servers storing sensitive information. This type of attack, known as Pass-the-Hash (PtH), is a specific form of credential theft and reuse attack that poses significant risks in Active Directory environments. The PtH technique exploits the same flexibility of single sign-on authentication mechanisms, which require computers to maintain copies of user's authentication credentials for seamless access to network resources. The article highlights how attackers can use multiple tools and techniques to perform a Pass-the-Hash attack, some of which are easily available from the Internet. It also mentions that these attacks can affect any operating system and are not limited to Windows systems, posing threats to other platforms as well. The PtH attack leverages SSO mechanisms for seamless authentication but takes advantage of weaknesses in credential management to gain unauthorized access. A successful PtH attack could lead to the compromise of privileged administrative accounts within an Active Directory environment, such as those belonging to Domain Admins or Enterprise Admins groups. To mitigate these risks, organizations are advised to evaluate and implement mitigations for PtH attacks and similar credential theft attacks, including educating decision-makers and administrative staff on business risk management. The article concludes by recommending the deployment of specific mitigations against Pass-the-Hash attacks as outlined in this document, which aim to significantly minimize the risks associated with these types of attacks within an organization's security posture. This summary outlines a process where an attacker gains unauthorized access to privileged areas of volatile memory and file systems on at least one computer. The attacker then attempts to increase access to other computers on the network by stealing user credentials and using them to gain access across networks. A password hash is discussed as a direct, one-way mathematical derivation of a password that changes only with user changes; it can be used as an authenticator or stored for single sign-on (SSO). After stealing authentication credentials, the attacker gains control over the affected account and can steal any other stored credentials such as those for local, domain, service, and computer accounts. To reuse stolen password hashes on another host, the attacker must meet certain requirements including network connectivity to the remote computer and valid credentials for logon. With administrative access, an attacker can steal credentials from various storage locations including the Security Accounts Manager (SAM) database, Local Security Authority Subsystem (LSASS) process memory, Domain Active Directory Database on domain controllers only, and the Credential Manager (CredMan) store. The summary emphasizes the difficulty in distinguishing malicious activity using stolen credentials from authorized activity when system and event logging is enabled. A Pass-the-Hash (PtH) attack is a type of cyberattack where an attacker gains unauthorized access to systems by using existing valid user credentials, specifically targeting password hashes. The process involves several key steps: 1. Initial Compromise: An attacker exploits a vulnerability or tricks users into running malicious software to gain local administrative access on a compromised computer. They then extract the SAM database (a Windows system file storing all user account information) containing the NTLM password hash, which is used for authentication. This hash can be read from memory if necessary. 2. Lateral Movement: The attacker replaces the current session's logon credentials with the stolen hashes and uses them to access other systems on the network through built-in Windows commands or tools like psexec. These tools allow attackers to bypass security restrictions by impersonating legitimate users, gaining access to additional resources without needing to crack passwords or intercept traffic. 3. Escalation: The attacker continues to move laterally across the network until they can gain access with a privileged domain account. This process is crucial for an effective PtH attack and demonstrates how quickly unauthorized access can be achieved within an organization's infrastructure, highlighting the importance of strong password policies and regular security updates. In summary, this type of attack capitalizes on stolen password hashes to bypass traditional authentication mechanisms and gain access to more systems in a network. To mitigate such risks, organizations should implement strict password policies, enforce proper account termination for unnecessary high privileged accounts, ensure all systems are up-to-date with security patches, and limit the use of administrative privileges. Figure 2 illustrates advanced stages of a Pass-The-Hash (PtH) attack where an attacker uses compromised credentials to gain higher privileges and move laterally within a network, eventually aiming for privileged domain administrator accounts. These attacks involve several steps including compromising local administrative accounts, escalating privileges on servers, and potentially accessing the entire Active Directory forest if successful. Mitigation strategies include restricting local administrative access from standard users, limiting credential reuse through Single Sign-On mechanisms, and improving encryption methods to protect stored credentials. Microsoft is actively researching enhancements to Windows operating systems to better secure against these attacks but notes that addressing PtH attacks requires a multi-faceted approach rather than a single fix or update. The document outlines several recommended mitigations for preventing privilege-based (PtH) attacks, which include restricting highly privileged domain accounts and local accounts with administrative privileges. These recommendations are designed to reduce the risk of attackers compromising credentials by ensuring that such accounts are used only on secured systems required for administration tasks. Additional steps involve configuring outbound proxies to deny Internet access to privileged accounts, ensuring administrative accounts do not have email accounts, using remote management tools without leaving reusable credentials on a computer's memory, and updating applications and operating systems. The document also highlights the effectiveness of these mitigations in terms of effort required (effort level), their impact on privilege escalation (lateral movement), and their applicability to PtH attacks and credential theft. It provides specific guidance for implementing each mitigation, such as restricting domain administrator accounts from authenticating to lower trust servers or workstations, assigning dedicated administrative workstations, marking privileged accounts in Active Directory, and configuring services or tasks without using them on less secure systems. The document advises that while these mitigations should have minimal negative impact on most organizations, it is crucial to test the implementation of each mitigation before deploying them in a production environment. It emphasizes the importance of developing rollback plans to minimize daily operations impacts and highlights that these recommendations are not a substitute for securing computers against attackers but rather add an extra layer of defense-in-depth protection. In summary, this document provides actionable steps to enhance security by limiting access to privileged accounts in both domain and local contexts, thereby reducing the risk associated with PtH attacks and related threats. The mitigations are presented as part of a broader strategy aimed at improving system security through various layers of defense. The text discusses several mitigation strategies to protect computers against privilege escalation (PtH) attacks, which involve attackers using local administrator accounts or their equivalents to gain access to other systems and steal credentials. **Mitigation 2: Restrict and Protect Local Accounts with Administrative Privileges**

• **Objective**: To restrict the ability of attackers to use local administrator accounts for lateral movement in PtH attacks.

• **How**: Implement several tasks including enforcing restrictions in Windows Vista and newer versions, denying network and Remote Desktop logon rights to local administrative accounts, and creating unique passwords for such accounts.

• **Outcome**: Prevents an attacker from using obtained credentials for further network access after compromising a computer.

**Mitigation 3: Restrict Inbound Traffic Using the Windows Firewall**

• **Objective**: To limit attackers' ability to initiate lateral movement from compromised workstations by blocking inbound connections on all workstations with local Windows Firewall enabled.

• **How**: Configuring the firewall to allow only expected traffic from trusted sources while denying access to other networks.

• **Outcome**: Stops attackers from using stolen credentials to connect to other networked computers.

**Additional Recommendations**

• **Do not allow browsing the Internet with highly privileged accounts**: Suggestions include removing standard users from the local Administrators group, configuring outbound proxies to deny Internet access to privileged accounts, and ensuring administrative accounts are not associated with email accounts or mailboxes.

• **Remove standard users from the local Administrators group**: This practice increases resistance against PtH attacks by making it harder for an attacker to gain elevated privileges before stealing credentials.

These strategies aim to enhance overall network security by limiting the effectiveness of PtH attacks and other credential theft methods, even in different domain configurations. This summary highlights several methods for mitigating Privilege-Theft (PtH) attacks, focusing on the management of high-privileged domain accounts within an organization's network. The strategies include employing User Account Control (UAC), restricting administrative rights through technical tools such as deployment processes and configuring outbound proxies, ensuring that privileged accounts are not linked to email accounts, using remote management tools securely, avoiding logons to less secure systems, regularly updating applications and operating systems, and minimizing the number of members in privileged groups. These measures aim to protect user credentials from theft by attackers through various avenues such as phishing or malware attacks targeting weak points in network security configurations. To enhance security against pass-the-hash (PtH) attacks, it is recommended to follow several steps. Firstly, restrict and protect high privileged domain accounts by implementing measures such as disabling LAN Manager (LM) hashes in the local SAM and Active Directory databases. This can be enforced through Group Policy settings that are enabled by default from Windows Vista and Server 2008 onwards but should be confirmed for older domains. Ensure all users change their passwords periodically to avoid storing LM hash values, which could potentially be used by attackers. Another important measure is securing domain controllers by ensuring they do not run unnecessary software, are promptly updated, and configured with appropriate security settings. Additionally, consider the management tools and services that manage these domain controllers and their administrators as equally important for overall security. The use of Microsoft Security Compliance Manager (SCM) tool can help distribute recommended configurations for domain controller setups. Lastly, while disabling the NTLM protocol may offer added security benefits against PtH attacks, it is not a practical recommendation due to its complexity in implementation and potential impact on other systems and services. Organizations should focus more on updating their software and ensuring all users' passwords are changed frequently to eliminate LM hashes from storage. Testing compatibility issues before making major changes is advisable for organizations considering these steps. This text discusses various methods for enhancing network security, including the use of multifactor authentication like smartcards, considerations for jump servers, and rebooting workstations. It emphasizes the importance of implementing robust security measures such as Kerberos and NTLM protocols to prevent credential theft attacks. The text also highlights that while some mitigation strategies have been suggested, such as restricting access through jump servers or rebooting systems, they do not directly address the issue of stolen credentials from logons. Finally, it provides additional technical information on how trust levels can impact these security threats and encourages a layered approach to securing networks against credential theft. The principle under discussion has several important implications regarding trust levels and computer security. One such implication is that if an administrator logs on to a lower-trust computer using higher-administrative credentials, they effectively grant themselves privilege escalation. This means that by logging into a standard workstation with Domain Admins group credentials, the admin trusts the security of their domain to that specific machine. Another key point is the principle's assertion about trust levels and security gains from connecting lower-trust computers to higher-trust ones. It states that gaining security by accessing a higher-trust computer from a lower-trust one is not possible, as it could lead to compromised credentials if keystrokes are intercepted or passwords are stolen through other means. The discussion also covers various methods attackers can use to steal plaintext passwords and password hashes, including keystroke loggers, brute force attacks, man-in-the-middle attacks (such as NTLM Relay), and exploiting weaknesses in the LSASS subsystem on compromised machines. These tactics pose significant threats by potentially allowing attackers to access credentials and carry out further malicious activities like lateral movement or privilege escalation. Additionally, the text highlights other forms of attack techniques not detailed earlier, such as social engineering attacks from compromised computers which can lead to phishing scams targeting users and stealing privileged credentials. Physical access to a computer's hardware is also crucial for attackers to steal password hashes stored in local databases or network traffic interception. Lastly, the mention of Kerberos Pass the Ticket attacks refers to another method attackers might use to exploit security systems, similar to pass-the-hash (PtH) attacks but specific to Kerberos environments. This attack type involves using stolen tickets to access resources without revealing user passwords, thus evading traditional detection methods. Overall, these implications and discussed tactics highlight the importance of maintaining strong trust models and robust cybersecurity practices within organizations to protect against sophisticated credential theft and reuse attacks. A type of credential theft and reuse attack involves obtaining local administrative access to capture stored Ticket Granting Tickets (TGTs) from a compromised system, which are then used in a Kerberos protocol attack. TGTs and their associated session keys form reusable credentials that can be reused until they expire, typically within 10 hours but with the potential to renew for up to 7 days if renewed before expiration. Smartcard-based authentication requires users to insert their smart cards and enter their PINs when the TGT has expired, while automatic renewal using the same credentials can occur in Single Sign-On (SSO) scenarios without user intervention. Kerberos attacks are less common than those on NTLM but pose a risk if local administrative access is compromised. A key difference between the reuse value of NT hashes used in NTLM and TGTs is that password hashes can be reused until a user changes their password, whereas TGTs expire within hours. While Kerberos authentication is also vulnerable to similar attacks, it may not displace pass-the-hash (PtH) attacks unless NTLM becomes unavailable. Delegation in Kerberos authentication presents a risk if sensitive domain accounts are trusted for delegation; an attacker can exploit this trust by converting inbound service tickets into reusable TGTs. This risk can be mitigated by setting the "Account is sensitive and cannot be delegated" attribute on privileged accounts, or using constrained delegation to limit which accounts can be impersonated by certain services. Windows operating systems support various authentication protocols and credential types, with Kerberos being the default and preferred protocol for domain authentication in most current versions. NTLM uses a challenge-response method based on NT hashes and supports multiple versions including NTLMv2, NTLM, and LM. Configuring the LMCompatibilityLevel setting can help manage which version of the NTLM protocol is used in authentication processes. The document discusses various aspects of Windows authentication, including terminology related to authentication and credentials. It highlights how credentials are stored in a reversible encrypted form within the operating system's memory and on disk for secure access during sessions. Additionally, it mentions specific types of authenticators used by Windows systems, such as NTHash which is derived from an unsalted MD4 hash algorithm, providing strong security against brute force attacks due to its fixed length and one-way mathematical representation. This text discusses various aspects of password security and credential storage in Windows operating systems, including LM hashes, local system security authority (LSA), and types of stored credentials such as the Security Accounts Manager (SAM) database and Local Security Authority Subsystem (LSASS). It mentions that while legacy support for LM hashes exists within NTLM protocol suites, their use is discouraged due to security concerns. The text also highlights the limitations of LM hashes, which include requiring passwords shorter than 15 characters and not differentiating between uppercase and lowercase letters. The document continues by explaining how Windows logon verifiers are stored in the registry on a local computer for validating credentials during user logons when an Active Directory connection is unavailable. These verifiers protect against brute force attacks through resource-intensive validation processes and rainbow table attacks with salt values included during calculation, but they cannot be used for credential theft attacks as noted further in the document. Furthermore, Table 5, "Credential Storage," lists various types of storage locations available on Windows operating systems for storing credentials like the SAM database (where local accounts are stored) and LSASS (which stores user credentials in memory during active sessions). The table also explains that while the default configuration does not store LM hashes in the SAM database, it is important to understand that no actual passwords but only their hash values are stored there. Overall, this text provides an overview of how Windows manages and protects various types of credentials, emphasizing the importance of secure password practices and the limitations of legacy authentication methods such as LM hashes. After a system reboot, credentials such as passwords for Active Directory accounts, Windows services, scheduled tasks, and IIS application pools are stored in encrypted form on disk. These credentials can be accessed by an attacker with administrative privileges through exploitation of LSA secrets. The Active Directory database, found within the NTDS.DIT file on writable domain controllers, stores account credentials including username types, current password NT hashes, and history of previous passwords' NT hashes. Additionally, LM hashes might be stored depending on configuration settings. Windows Credential Manager allows users to save passwords using DPAPI for protection. Logon types in Windows include interactive console logon, remote access, scheduled tasks, Windows services, IIS Basic Authn, SQL Server connections, batch jobs, and remote desktop with smartcard or other authenticators. Common administrative tools and methods can expose credentials during remote administration of domain accounts, highlighting the importance of secure practices to mitigate risks. A workstation used to manage servers must have at least the same trust level as the managed servers, ensuring secure management practices are in place. Table 7 outlines various connection methods with their respective logon types and where credentials are created or cached, detailing whether they are exposed or not. The document provides technical details and mitigations against credential theft and reuse attacks such as Pass-the-Hash (PtH) attacks, emphasizing the need for a strategic plan to prevent lateral movement and privilege escalation across an organization's network. Recommendations include restricting high privileged domain accounts, local accounts with administrative privileges, and implementing robust firewall rules to restrict inbound traffic. The provided text outlines a multi-part strategy aimed at enhancing security by separating administrative accounts from user accounts, creating dedicated workstation hosts for administrators, and restricting certain accounts to prevent unauthorized use on lower trust systems. Task 1 involves allocating separate standard user and privileged accounts for personnel engaged in both routine tasks and highly sensitive administrative duties within an organization. Accounts are to be tailored according to the level of access required: from minimum (basic domain administration) to ideal (separate accounts with varying levels of privilege across different system types). It's crucial that privileged accounts do not have access to email or the internet, in order to mitigate potential risks associated with such elevated privileges. Task 2 emphasizes creating specific workstations for administrators only, which are isolated from general use and configured without Internet or email access. This setup aims to reduce vulnerability to cyber threats like phishing attacks. For maximum security, these workstations should also not be members of local administrative groups, nor granted network access beyond managing specified domain controllers and servers. Task 3 focuses on restricting specific accounts, such as Domain Administrator ones, from being used to log in to less secure systems. This is a critical component to prevent potential breaches that could occur if privileged credentials are misused or compromised. Lastly, Task 4 involves disabling the delegation of rights for privileged accounts, which limits their ability to access resources beyond their designated role within the organization. It's important to note that implementing these tasks may present challenges in certain environments and therefore thorough testing is recommended before deployment. The process should be staged with a capability to revert any changes if necessary due to technical issues encountered during implementation. To block Internet access on administrative workstations by creating a Group Policy Object (GPO) with an invalid proxy address in Windows, follow these steps as a domain administrator on a domain controller: 1. **Create a new Organizational Unit (OU) for Administrative Workstations** in Active Directory Users and Computers. 2. **Create computer accounts** for the new workstations. 3. Close Active Directory Users and Computers. 4. Open the Group Policy Management Console (GPMC). 5. Right-click on the newly created OU, select "Create a GPO in this domain," then click "Link it here..." to create a new GPO linked to that OU. 6. Name the GPO and click OK. 7. Expand the GPO, right-click the new GPO, and select "Edit." 8. **Configure local policy settings** for which accounts can log on locally:

• Navigate to Computer Configuration\Policies\Windows Settings\Local Policies\User Rights Assignment.

• Double-click "Allow log on locally" and define these settings by adding Enterprise Admins, Domain Admins, and Administrators.

9. **Configure proxy settings** in Internet Explorer:

• Navigate to User Configuration\Policies\Windows Settings\Internet Explorer\Connection.

• Set the proxy address to 127.0.0.1 (the network Loopback IP address), enable proxy settings, and click OK.

10. **Configure Group Policy loopback processing mode** for all users on the computer:

• Navigate to Computer Configuration\Policies\Administrative Templates\System and double-click "User Group Policy loopback policy processing mode." Set it to Enabled with Merge Mode.

11. Configure software updates by navigating to Computer Configuration\Administrative Templates\Windows Components\Windows Update:

• Enable Automatic Updates, set the schedule for installation (e.g., 03:00 every day), and enable Power Management to automatically wake up the system for scheduled updates. Specify the intranet Microsoft update service location as , where is the DNS name or IP address of the WSUS server in the environment. Set Automatic Updates detection frequency to 6 hours, re-prompt for restart with scheduled installations to 1 minute, and delay Restart for scheduled installations to 5 minutes.

12. **Configure inbound firewall settings** on each profile to block all connections:

• Right-click Windows Firewall with Advanced Security – LDAP://path and select Properties, then ensure that the firewall is enabled and inbound connections are set to Block all connections.

13. Close the GPMC. 14. Install the Windows operating systems on the workstations, assign them the same names as their computer accounts, and join them to the domain. This procedure ensures that administrative workstations do not have Internet access but can still receive updates through a WSUS server. To mitigate security risks associated with highly privileged administrators having access to workstations, it's recommended to implement several levels of restriction. The steps outlined involve restricting domain administrators from logging onto workstations in different ways at minimum, better, and ideal levels. Here’s a summary: 1. **Identify OUs Containing Workstations and Servers**: Ensure all organizational units (OUs) containing workstations and servers are identified to avoid omissions that could leave highly privileged accounts unaffected. 2. **Create GPO for Restricting Administrators**: As a domain administrator, create a Group Policy Object (GPO) that denies local logon rights to domain administrators. This involves:

• Opening the Group Policy Management Console (GPMC).

• Creating a new GPO and naming it appropriately.

• Editing user rights settings within the GPO to deny both log on locally and log on as a batch job or service for Domain Admins and Enterprise Admins.

3. **Link GPO to Workstation OUs**: Link this GPO to the first workstation OU and test its functionality with enterprise applications, then repeat the process for other OUs containing workstations but not the administrative workstation OU created in Task 2. 4. **Disable Account Delegation Right for Privileged Accounts**: This involves ensuring that delegation settings are configured correctly to prevent privileged accounts from being used to access resources beyond their intended use, which could lead to privilege escalation risks if a server is compromised and trusted for delegation. These steps collectively aim to minimize the risk associated with highly privileged administrators having direct logon rights on workstations, thereby enhancing overall security within an Active Directory environment. The provided text outlines several strategies for mitigating security risks associated with compromised local accounts within a domain, specifically targeting privileged user objects in Active Directory (AD) through the "Account is sensitive and cannot be delegated" option, and enforcing restrictions on local administrative accounts via Group Policy. **Mitigation 1: Restrict High-Privileged Accounts in AD** To enhance security against credential theft and lateral movement within a domain, it is recommended to configure user objects for all high-privileged accounts to include the "Account is sensitive and cannot be delegated" setting. This configuration ensures that such accounts cannot be used by other users or services on different computers without explicit permission, thus protecting from potential misuse of stolen credentials. Before implementing this change across the domain, it is crucial to test the settings to ensure they function as intended. **Mitigation 2: Restrict and Protect Local Accounts with Administrative Privileges** This section discusses three specific tasks aimed at restricting local administrative accounts using remote access: 1. **Enforce local account restrictions for remote access**: This involves enabling User Account Control (UAC) settings to enforce elevated privileges for local administrators, ensuring they operate under standard user permissions in network interfaces and cannot remotely administer systems. 2. **Deny network logon to all local accounts**: By revoking network access for local administrator accounts, the risk of unauthorized access through stolen credentials is significantly reduced. This includes configuring policies that explicitly deny access from the network for these accounts. 3. **Create unique passwords for local privileged accounts**: Randomizing passwords on a regular basis can help prevent reuse and theft of password hashes across multiple systems with administrative privileges. While this mitigation does not apply if local admin accounts are disabled, it remains a valuable security practice to implement regardless. Each of these tasks is designed to protect against the misuse of stolen credentials through unique password policies that cannot be transferred between compromised machines. Implementing Task 1 (UAC settings) is recommended due to its simplicity and immediate impact on restricting privileged access. Subsequent implementation of Tasks 2 and 3 should follow as soon as possible, focusing on enhancing security by ensuring unique passwords for local administrators. **Implementation Steps:**

• **Task 1: Enforce local account restrictions for remote access** involves configuring UAC settings in Group Policy to restrict built-in Administrator accounts' privileges when used remotely, accessible via `Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options`.

• **Task 2: Deny network logon to all local accounts** is set through policies like "Deny access to this computer from the network" and "Deny log on through Remote Desktop Services/Terminal Services", configured under `Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment`.

• **Task 3: Create unique passwords for local privileged accounts** involves implementing password randomization strategies across all local administrative accounts.

The provided table summarizes the settings and policy locations required for each task, ensuring that these mitigation efforts are effectively applied within a Windows environment to safeguard against credential theft and unauthorized access. This text provides a detailed guide on how to configure Group Policy Objects (GPOs) in Active Directory to deny network logons for local accounts. The steps involve creating a new GPO, configuring user rights within the GPO, and applying the policy to specific organizational units (OU). Here's a summarized version of the instructions: 1. **Start the Group Policy Management Console (GPMC)** and navigate to the desired domain in the console tree. 2. Right-click on "Group Policy Objects" and select "New" to create a new GPO. Name it appropriately, such as "Deny Local Admin Network Logons." 3. In the details pane of the newly created GPO, click "Edit" to configure its settings. 4. **Configure User Rights** by navigating to:

• Computer Configuration\Policies\Windows Settings and Local Policies\User Rights Assignment.

• Deny access to this computer from the network: Add the local administrator account(s) by typing their username directly, without adding domain or computer names.

5. Configure Remote Desktop (RemoteInteractive) logon restrictions similarly under User Rights Assignment, ensuring you select the correct policy based on Windows version (e.g., "Deny log on through Terminal Services" for older systems and "Define a custom remote desktop policy" for newer versions). 6. **Link the GPO to Workstations OU** by right-clicking the OU in the domain management console, selecting "Link an Existing GPO," then choosing your newly created GPO and confirming the link. 7. **Test enterprise applications** on workstations linked to this GPO to ensure compatibility with the new security settings. 8. Link the GPO to other OUs containing workstations as needed. 9. For servers, repeat steps 2-6 but navigate to Computer Configuration\Policies\Windows Settings and apply similar restrictions under User Rights Assignment and other relevant policies. 10. Ensure that all local accounts are denied network logons by following these detailed steps with an account in the Domain Admins group. This mitigation helps prevent password hash theft (PtH) attacks by restricting lateral movement of credentials. This text is about configuring local privileged accounts and restricting inbound traffic on workstations using Remote Desktop Services and Windows Firewall. It includes steps for creating a Group Policy Object (GPO), assigning unique passwords, and setting firewall rules to block all inbound traffic while allowing specific services through exceptions. The process involves linking the GPO to workstation Organizational Units (OUs), testing enterprise applications, and ensuring no connectivity issues arise from these changes. This document outlines steps for configuring inbound firewall rules using Group Policy Objects (GPOs) on workstations within an organization. To implement these changes, administrators must follow a series of detailed instructions and settings modifications as outlined below: 1. **Enable and Configure Windows Firewall Inbound Policy:**

• Open the Group Policy Management Console.

• Navigate to Computer Configuration > Windows Settings > Security Settings > Windows Firewall with Advanced Security.

• Enable the firewall on all profiles (Domain, Private, Public) and set inbound connections to block except for specific exceptions as needed.

• Ensure that local administrators cannot bypass security settings by selecting "No" under Rule Merging.

2. **Configure an Inbound Exception for Remote Management Hosts:**

• Create a new custom inbound rule in Windows Firewall with Advanced Security.

• Define the scope of allowed IP addresses based on the remote management hosts.

• Allow connections from these IPs and select all appropriate profiles (Domain, Private, Public).

• Name and describe the rule according to the specific application that needs access.

3. **Deploy the GPO:**

• Link the newly created GPO to the Workstation OU or other relevant organizational units.

• Test applications and systems in this OU to ensure compatibility with the new firewall settings.

4. **Appendix B: Pass-the-Hash (PtH) Attack FAQs** addresses concerns about PtH attacks across various platforms, emphasizing that while Windows OS is a common target, other operating systems can be affected too. The document suggests that modifications to code might not be feasible in the short term, but continuous efforts are made to enhance security features of Windows OS. This comprehensive guide helps administrators strengthen network security by controlling inbound traffic through carefully configured firewall rules using GPOs and detailed step-by-step instructions. The document highlights several key points regarding cybersecurity threats such as credential theft and lateral movement attacks. It states that no single solution can prevent these attacks because they involve both lateral movement across multiple systems (requiring a combination of controls) and privilege escalation (necessitating multiple mitigations). The Kerberos protocol is not recommended as a sole mitigation due to its susceptibility to similar attacks like Pass the Ticket, which are already feasible for attackers. Smartcard logons can enhance security but do not eliminate the risk if passwords or hashes have been stolen. Single Sign-On (SSO) simplifies authentication processes without compromising security when used correctly. Regarding specific solutions: 1. Password hash credentials must be stored locally due to situations requiring user validation offline. 2. The Local Security Authority Subsystem (LSASS) will not be enhanced for better protection against attacks, and the recommendation is to move towards using the Kerberos protocol instead. 3. Detecting Pass the Ticket (PtH) attacks and credential theft in a domain is challenging because they can mimic legitimate authentication processes. Monitoring suspicious account usage patterns might help identify such threats. 4. While antimalware and Host-based Intrusion Detection System (HIDS) solutions may detect some aspects of PtH attacks, they face limitations due to evasion techniques employed by attackers. 5. Privileged Password Management tools and password vaults can be effective if configured correctly with features like randomization and timely rotation, which significantly increase the complexity of stolen credentials in the environment. This white paper discusses several key concepts related to cybersecurity, including authentication processes, credential definitions, types of attacks like Pass-the-Hash (PtH) and Pass the Ticket, and various security measures such as password hashing, privileged accounts, salt values, and more. It also outlines technical overviews and provides references for further reading on specific security tools and protocols like AppLocker, Audit logon events, Auditing and restricting NTLM usage, Kerberos Authentication, Microsoft Security Compliance Manager, User Account Control Technical Reference, among others. The paper aims to provide a comprehensive guide for implementing robust security measures in an organizational context, ensuring adherence to the highest standards of authentication rigor similar to those applied to domain controllers and administrators.

Disclaimer:

The content in this post is for informational and educational purposes only. It may reference technologies, configurations, or products that are outdated or no longer supported. If there are any comments or feedback, kindly leave a message and will be responded.