Externally Sealed Off

Active Directory (AD) environments are often the focus of attackers. As soon as malware can access credentials on a domain member PC, the entire AD is at risk of being taken over. In particular, privileged user and administrator accounts are under fire. In this article, I apply best practices to demonstrate how you can increase security in the Microsoft directory service.

For optimal AD security, small and medium-sized companies should position themselves as enterprise environments, which, in most cases, have access to significantly more resources for securing their IT infrastructure. Microsoft itself provides detailed instructions for securing its directory service [1].

Inquisitive Intruders

An attacker usually enters a network through a single endpoint, such as an insecure PC, server, router, or other network device. Once this endpoint has been taken over, the criminal must familiarize himself with the network, because only with sufficient information can the intruder efficiently spy on the rest of the network or carry out further attacks. This spying is also called reconnaissance, or recon.

Locating administrator accounts in the network is an important step in this process. By using a pass-the-hash (PtH) attack, for example, an attacker can access the network and privileged user accounts with the rights of the transferred account and do damage to the network almost completely unobserved.

Dangerous PtH Attacks

Pass-the-hash attacks are targeted directly at AD user accounts; those with privileged rights are particularly interesting, of course, and can be administrator or user accounts that have the right to change user passwords, for example. With changes to the user account, attackers gain access rights other than PtH. PtH attacks are based not only on user passwords, but also on the hashes that are assigned to a user account after authentication. Simply put, they are tickets into AD.

As soon as an attacker detects a user account in AD or the user administration of a server, they can try to gain access to a hash of the account with PtH attacks, even without knowing the password. The process does not aim to hack passwords or decrypt the hash. Attackers want to take over the original hash and use the rights of the corresponding account. If this succeeds, an attacker can easily act with admin rights in the network, even without knowing the account password.

This is particularly serious in single sign-on (SSO) environments. If configured appropriately, an attacker can not only use the hash to cause damage to the local network but can also access other services, such as the cloud. Hybrid environments with Microsoft Azure or Office 365 are particularly at risk.

Allocating Rights Sensibly

Administrator accounts should be used very carefully in AD environments. In doing so, administrators and those responsible in the company should take various things into account. Much is already possible with the standard options in AD. First of all, different administrator accounts should be used for the different server applications in the company. SQL Server administrator accounts should not be used for Exchange or AD management. If such an account is compromised, all other server services are also in danger.

But it also makes sense to work with different accounts within the Windows Server standard services. Windows Server offers different user groups that are available by default. These standard groups are important in the root domain, especially in overall structures:

• DHCP Administrators: Allows the management of DHCP servers in the domain. This group is created after the first DHCP server is installed on a domain controller (DC).
• DHCP Users: Contains user accounts that read the information of the DHCP service but are not allowed to make any changes. This group is only relevant for administrators and operators, not for normal users or computers. Computers that request DHCP addresses do not need to be included in this group.
• DnsAdmins: Contains the administrators for DNS servers. No users are assigned to it. It can be used to delegate the DNS server administration. This is especially important if a company's DNS infrastructure is managed by administrators who are not responsible for the AD environment. The group is not created until a DNS server has been created on a DC that manages its information in AD.
• DnsUpdateProxy: Contains computers that can act as proxies for dynamically updating DNS entries. This group is only available if a DC is created. For example, you can include DHCP servers that create dynamic DNS entries for the clients on the DNS servers in this group.
• Group Policy Creator Owners: Includes users who are allowed to create group policies for the domain. This can be administrators who only take care of this task in the overall structure.

The groups DnsUpdateProxy, Enterprise Admins, Schema Admins, and DnsAdmins are defined in the first domain set up in an AD forest and is also the topmost domain of the first structure of the forest. You can add users and user groups from different domains of the forest to a group.