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.

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 patch and updates do, it is common for some of these holes to remain open.

Below are a few improvements, in order of criticality when a malicious actor lands on your internal network. This list, if implemented correctly, will lower the risk of a compromise or a breach when an attacker or an insider threat has a foothold on the internal network.

1. Lack of Principle of Least Privilege

When system administrators or IT personnel are not following the principle of least privilege, it allows for trivial privilege escalation from domain accounts to domain administrator accounts. In layman terms, the principle of least privilege for user accounts is that they must only be able to access the information that they are required for their business functions.

A. 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).

B. 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.

C. 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 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. Insecure 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 an attacker to perform trivial privilege escalation within a network context.

A. 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.

B. 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. Often times, 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 single user that has ever logged onto a machine before a reboot will have cached credentials in cleartext. Often times, 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 too mature, they would often use batch or VB scripts to change the local administrator’s passwords using group policy. This caused a problem because many of these 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. Prior to 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.

Even though this was a little more than 7 years ago, less mature enterprises are still seen to make a few mistakes. 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. In order to prevent this from happening to your organization, install the patch and remove old XML files that contain passwords.

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. 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 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. Speak to us about how we can help you today.