Table of Contents
- 1. Implement the principle of least privilege
- 2. Modify default security protocols
- 3. Cleartext Credentials Cached in Memory
- 4. Insecure Password Storage in Group Policy Preferences
- 5. Ensure AD backup and recovery
- 6. Implement a strong password policy
- 7. Educate employees
- 8. Conduct regular penetration tests to ensure that your Active Directory is secure
- How we can help
Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. It is a set of services and a database that allows users to connect to various corporate resources and allows administrators to manage permissions and access to network resources.
Active Directory is a critical part of any organization’s infrastructure as it is essential in organizing a company’s users and computers. Approximately 95% of Fortune 1000 companies leverage the benefits of using Active Directory for their environment; however, securing it across an organization is not always easy. AD security is vital as everything from user credentials, applications and sensitive data can be stored in the database. This is also why AD is a significant target for cyberattacks.
Organizations lacking skilled staff tend to only focus on configuring the minimum requirements to complete and implement the deployment of the server. As for server patches and upgrades, there often requires qualified personnel to remove specific files or turn off certain protocols to finish securing the Active Directory server. Without a thorough understanding of what each of the patches and updates do, it is common for some of these holes to remain open.
To ensure the security of your AD, here are some best practices you should follow.
1. Implement the principle of least privilege
The Principle of Least Privilege (PoLP), refers to the theory and practice of restricting access rights for users, accounts, and computing processes to only those staff who are absolutely required to perform regular, authorized activities.
Limit Local Administrator Access
If all users in an organization have local administrator access and a higher privileged account logs into the same workstation or server, then it is possible for users to assume the privileges of the higher privileged account (e.g. Domain Administrator).
Limit Privileged Administrator Usage
Privileged accounts, such as one in the Domain Administrators or Enterprise Administrators group, should not be used to perform general tasks that do not require such high privileges.
Segment Administrative Accounts
Administrative accounts should be divided into different groups of different tiers. A good example of an effective division is as follows:
Workstation Administrators – should only be allowed to log in to workstations to perform administrative tasks on workstations
Server Administrators – should only be allowed to log in to servers
Domain Administrators – should only be allowed to log in to domain controllers
When each group is prohibited from performing logins to another tier, then even if one group is compromised, they are effectively segmented.
2. Modify default security protocols
Since Microsoft Windows builds backwards compatibility from an older operating system generation to a newer one, many legacy protocols are used by default. These insecure protocols may often enable attackers to escalate trivial privileges within a network context.
Legacy Windows Broadcast Protocols
One common behaviour that a Windows environment uses to assist in resolving hostnames when the DNS protocol fails are the Link-Local Multicast Name Resolution (LLMNR) and the NetBIOS Name Service (NBT-NS) protocols. A malicious actor in the network can respond to the broadcast requests, and impersonate the non-existent requested resource. When this is done to the victim machine, they will often respond with their credentials in hash form.
Furthermore, if the environment is found to have SMB signing enabled, a malicious actor may forward the SMB authentication attempt to a target without SMB signing. If the target does not follow the principle of least privilege, then an attacker may be able to obtain unauthorized access.
Figure 1: LLMNR and NBT-NS Attack Concept
In order to prevent such an abuse, it is recommended to disable legacy protocols on Windows hosts and require SMB signing which can be enforced through Active Directory’s group policies. Additionally, on each workstation and server, NetBIOS over TCP/IP should also be disabled.
Default IPv6 Configuration and Legacy WPAD
IPv6 is by no means a legacy protocol, however, most internal organizations do not actively use the IPv6 protocol, but are completely unaware that Windows operating systems above Vista prefer IPv6 over their older IPv4 counterparts. If an attacker responds to DHCPv6 requests from Windows clients, the attacker’s IP can effectively become the DNS for all affected clients. This creates a suitable position between the attacker and all its targets, and by replying to DNS requests, an attacker can serve a WPAD file to obtain the NTLM challenge/response or relay it to a target. This would result in complete compromise of the target server.
Figure 2: Default IPv6 Configuration Attack Concept
In order to prevent this abuse, it is recommended to disable IPv6 in the affected environment and disable the proxy auto detection through the Active Directory group policy settings.
3. Cleartext Credentials Cached in Memory
Microsoft Windows services often strive to make technology more user-friendly and efficient. Oftentimes, when accessing file shares, Windows does not prompt us for authentication because it caches credentials in cleartext in memory (in a process called lsass.exe). Every user logged onto a machine before a reboot will have cached credentials in cleartext. Oftentimes, these credentials lead to other systems that have a higher-level privileged account (service accounts).
Throughout the course of our engagements, this is often seen on older workstations and servers such as Windows 7, Windows 8 (below 8.1), Windows Server 2008, and Windows Server 2012. Abusing credentials will often lead to privilege escalation and compromises of other critical servers in the environment. These older servers require the KB2871997 patch and a registry key setting change of “UseLogonCredential” set to 0 in the WDigest of HKEY_LOCAL_MACHINE. Ensure a reboot of the system after these settings have been applied.
4. Insecure Password Storage in Group Policy Preferences
In organizations where their IT processes or personnel are not mature, they often use batch or VB scripts to change the local administrator’s passwords using group policy. This caused a problem because many scripts store plaintext passwords in the script files. In 2008, Microsoft released Group Policy Preferences to help system administrators hash the password on SYSVOL with AES-256-bit encryption. Before 2012, Microsoft disclosed the AES private key on the MSDN stored on the SYSVOL share on the domain controller. Unfortunately, all domain-joined users have access to the SYSVOL share, which would allow them to decrypt the password.
Many of them seem to know to apply the patch KB2962486 that prevented passwords stored in groups.xml. However, the old groups.xml file would not be deleted, and the password to the old domain controller still works in the upgraded environment. To prevent this from happening to your organization, install the patch and remove old XML files that contain passwords.
5. Ensure AD backup and recovery
It is best practice to conduct regular backups - preferably every 60 days, as AD tombstone objects have a 60 day lifetime. It may also be beneficial to use more than one backup in a different location in case one gets compromised.
6. Implement a strong password policy
Strong passwords are something we talk about all the time - but what does that mean? A strong password contains 12-16 characters, uppercase letters, lowercase letters, symbols and numbers. The best type of password is one that is randomly generated and is not an actual word. While these types of passwords are the strongest, they are hard to remember. Password managers are a great solution to this issue.
See more about the dangers of weak passwords in your active directory
7. Educate employees
Employees surprisingly post a major security risk. By unknowingly clicking bad links, your staff could share sensitive company data or user credentials. Educating your staff to identify malware attacks, phishing attacks, and the dangers of a cyberattack can help lessen the risk for the organization.
8. Conduct regular penetration tests to ensure that your Active Directory is secure
Once your Active Directory is set up, it is good practice to regularly schedule a penetration test to ensure there are no gaps or vulnerabilities in your system. Regular penetration testing greatly lessens the risk of a cyberattack and can provide peace of mind to the organization.
How we can help
Fully hardening your Active Directory server and locking down your network is not always an easy task in an enterprise or even a small to medium-sized environment. Packetlabs is one of the few organizations that provides 95% manual penetration testing services to help strengthen your security posture.
The Packetlabs team is composed of highly trained and experienced ethical hackers that focus and excel at the discovery, exploiting, and chaining together multiple vulnerabilities that allow unauthorized access. Our team members have the highest regarded certifications in the industry, including the Offensive Security Certified Professional (OSCP), Offensive Security Certified Expert (OSCE), GIAC Web Application Penetration Tester (GWAPT), and GIAC Exploit Researcher and Advanced Penetration Tester (GXPN) certifications.