The Importance of Protecting Privileged Accounts

By: Shlomo Elbaz - Information Security Consultant   |   Updated: 7/7/2022

This article will focus on common cyber-attacks that target Active Directory (AD). Active Directory is deployed across many organizations worldwide to deliver networking services so that users and computers can be easily authenticated and authorized to access network resources or log on to windows systems.

Most users are usually provided with a username and password linked to their AD Account Object. AD uses LDAP (Lightweight Directory Access Protocol) to verify a user is authorized as part of the group or policy and that the password is correct. Standard users will usually be part of a Domain Users group and have access to any object where Domain Users are authorized. An AD Admin will be part of a group called Domain Admins, a highly privileged group that can literally do anything within the network. AD has numerous groups that allow for various roles and permissions. Organizations must manage and secure their AD to reduce the risk of malicious actors gaining access via simple Active Directory misconfigurations. 

Securing privileged access to AD should be a top priority. If an attacker gains access to your Domain Admin accounts, it is essentially game over for the organization.

Another key security consideration for domain admins is that each domain admin should use a separate, unique, low-level account that does not have elevated permissions for their daily activities. Browsing the web, checking email, and other day-to-day activities can expose users to threats if they accidentally click on a link they shouldn't have or download something harmful. As such, administrators should have a separate account for logging in to their workstation to perform these riskier activities, and use the domain administrator account only when performing necessary IT functions. The separation dramatically reduces the exposure of these more privileged accounts.

Shared administrative accounts should also be avoided. With shared accounts, the password is shared between users and likely written down somewhere, making it generally less secure. Additionally, shared accounts prevent non-repudiation - if one user decides to go rogue and cause damage, it cannot be proven which person with access performed the malicious actions.

To gain access to victims, attackers use a variety of hacking tactics and techniques that take advantage of poor access management, misconfigurations, and unpatched systems. Most commonly, breaches begin with the hacker gaining access to a privileged account, so securing these particular accounts is vital to protecting sensitive information and critical systems from cyber-attack. Most attackers use a methodical, multi-step approach to access your critical systems and data. They often start by taking over accounts using default or common passwords. This is the foot in the door they need since their real goal is to take over privileged accounts and escalate their access to applications, data, and key administrative functions. To compromise privileged accounts, an attacker might employ tactics like compromising a local account, performing patient and stealthy reconnaissance, studying the daily routines of IT teams, impersonating employees, establishing ongoing access, and causing harm—both in the short-term and over the long haul.

One option for protecting sensitive elevated AD accounts is to add them to the Protected Users group since legacy functions are blocked for all group members. By default, The group ("Protected Users") exists in the Users container. Accounts that are members of this group are protected, especially against pass-the-hash and pass-the-ticket attacks, by disabling NTLM, a legacy technology and authentication protocol that still exists for backward compatibility.

Protected Users are primarily intended for domain and enterprise administrator accounts, which are particularly vulnerable to attack because they provide wide-open access to systems in the event of a compromise. That is not to say that other user accounts that could be considered a target cannot be added to protected users. However, due to the strict restrictions imposed on members of Protected Users, it is important to conduct thorough compatibility testing beforehand.

Changing the password for each user before adding the account to the Protected Users group is essential. Since weak encryption keys are not supported for users in the Protected Users group, their AES (Advanced Encryption Standards) keys must reside in Active Directory. Changing the user password before adding the account to the group ensures that this requirement is met. In addition, the password reset assures that the user credentials stored locally on machines used by the account will be useless if a malicious entity decrypts them.

The second option is enabling the 'Account is sensitive and cannot be delegated' option - an easy-to-enable feature for a service or Local System account. Once this feature is enabled, an account's credentials can't be reused or distributed, thus limiting the scope of potential attacks.

The third option is to reset the password for the KRBTGT account every 180 days. The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, the account name cannot be changed, and it cannot be enabled in Active Directory. The KRBTGT account is the entity for the KRBTGT security principal, and it is created automatically when a new domain is created. The KRBTGT account functions as a service account for the KDC service. With control of the KRBTGT account, attackers can create fraudulent TGTs (Ticket Granting Ticket) to access any resources they want. This scenario is the essence of a Golden Ticket attack, which allows threat actors to impersonate any user in AD if performed successfully. The attack is difficult to detect and can be used by threat actors to persist under the radar for long periods of time.

Reset the password for the KRBTGT account a least once every 180 days. The password must be changed twice to remove the password history effectively. Changing twice in rapid succession forces clients to re-authenticate (including application services), which is desired in case of suspected compromise. Password reset can be performed using a script created by Microsoft.

In addition, the following recommendations can be applied:

• Employ the principle of least privilege; reduce the privilege level of each user to only what is essential. This strategy facilitates monitoring privileged activity and reduces the number of high-priority accounts to protect.

• Enforce separation of duties; Grant users access only to the domains under their responsibility. If an attacker gains access to a privileged account, this will make it more difficult for them to move laterally in the network.

• Disallow account sharing; use multi-factor authentication and account activity logging to ensure each account and its user are held accountable for their actions.

• Refrain from using default Administrator accounts; default accounts are often targeted by attackers. Activity by default accounts is difficult to attribute to a specific employee, making it challenging to determine if the activity is legitimate. If a default account shows significant atypical activity, this is an easy indicator of a possible breach.

• Keep an up-to-date log of privileged accounts; Employees will come and go, and the list of required privileged accounts will change. Ensure effective management policies are in place to reduce inactive or unnecessary privileged accounts and inform security teams of relevant changes, especially any outsourced managed security providers.

• Enforce password policies; users should have complex passwords and be required to change them regularly. Privileged accounts should especially use strong password policies. Unique password policies for these groups can be implemented using FGPP (Fine-Grained Password Policy).

• LAPS; Local Administrator Password Solution (LAPS) is a password manager that utilizes the AD to manage passwords for local Administrator accounts across all of your Windows endpoints. By ensuring that all local Administrator accounts have unique, complex passwords, LAPS helps mitigate the risk of lateral movement and privilege escalation: An attacker who compromises one local Administrator account cannot move laterally to other endpoints simply by using the same password.

• MFA ; At the very least, implementing multi-factor authentication for privileged accounts is the recommended solution for securing these accounts. Microsoft does not yet have a native solution, but several third-party companies on the market can provide this solution.

Back