In a previous article [1], I analyzed the problems that have given Active Directory (AD) a poor reputation among security admins. However, only a minor share of known vulnerabilities originates from the nature of AD itself. Many problems are the result of the default settings that Microsoft still delivers with AD; configurations and processes that admin teams implement in their AD organizations can be even more problematic.

To design and operate AD as securely as possible – in the context of this article I talk about Active Directory Domain Services (AD DS) – it is very important to understand which of today's cyberthreats affect AD, what goals attackers pursue, and what techniques they deploy to achieve their goals. The current talk can give non-experts the impression that an IT infrastructure is virtually defenseless against cybercriminals if it is based on AD. In reality, though, AD is never the first point of contact or the gateway for the attacker, and hijacking AD is just as rarely the ultimate target.

The initial contact is usually made over a user device (phishing, drive-by downloads) or an application (Exchange administrators might well remember the HAFNIUM zero-day exploit). The attackers' objectives range from total destruction (wiper) to the theft of very specific information (research data for industrial espionage, commercial documents for market manipulation, or whale phishing attacks on high-level executives). Somewhere in between you also see attackers encrypting an organization's entire data as a means of blackmail (ransomware), injecting code into the development cycle (software supply chain attacks), or influencing the networked physical infrastructure (power generation or gas pipeline attacks).

Mitigating Risks

In most AD implementations that have grown historically, attackers find numerous opportunities to achieve their intended targets relatively quickly without attracting attention at an early stage. For initial reconnaissance, a hijacked user account, workstation, or application server can help the attacker discover extensive details about the environment (configurations, permissions, escalation paths) using the operating system's on-board resources. Sometimes access credentials for other accounts are already known – for example, local accounts created by group policies or role accounts with passwords in the description field. I already talked about this part of the attack chain and methods of restricting the visibility of highly privileged objects in the first article [1].

Once the attacker succeeds in gaining control over one or more member computers and is able to execute arbitrary processes in the system context of these machines, they are potentially able to access the credentials of other accounts that have logged on to these computers. In most cases, the material captured is only password hashes, but as long as the NT LAN Manager (NTLM) authentication protocol and the RC4 stream cipher are supported in the environment, a hash can be used for authentication (pass-the-hash attack) or at least to request Kerberos tickets (overpass-the-hash attack).

Hashes that use these methods can be cracked with reasonable effort if the original password is relatively short and simple. If the captured hash material contains the access credentials of highly privileged accounts, the attacker can leverage these credentials to create new privileged identities, extend replication permissions, or manipulate audit settings. If legacy service accounts are used in the environment, they can fall victim to Kerberoasting. These service accounts are often given a non-expiring but relatively short password, which makes cracking a service ticket possible with reasonable overhead.

If the attacker comes across replication permissions during the reconnaissance phase and can exploit them directly, they can replicate valuable data from AD, including the password hashes of the Kerberos ticket-granting ticket (krbtgt) account, which is the ultimate authority for Kerberos authentication in AD domains (Golden Ticket attack), and Data Protection Application Programming Interface (DPAPI) backup keys, which can be used to decrypt all member computer and AD user secrets protected by DPAPI.

If an enterprise public key infrastructure (PKI) is implemented in the AD forest and is not sufficiently hardened, the bad guys can have Kerberos certificates issued that let them log in directly in the context of highly privileged accounts. Computer and service accounts enable further attacks on access data by exploiting misconfigurations in the Kerberos delegation.

Once the attacker is able to manipulate group policies, they usually get far closer to their ultimate goal. In ransomware or wiper scenarios, for example, the malware can be rolled out to the entire environment by startup scripts or scheduled tasks and detonated at the intended time. However, persistence and escalation are also possible; if the intruder manages to link a group policy to the organizational unit (OU) of the domain controller (DC) that assigns Local Admins rights to user accounts on member PCs, they can convert these accounts into Domain Admins.

These and a few other related techniques must be the focus of any initiative aiming to make an AD environment as secure as possible. Bear in mind that IT security is a risk management discipline; it's not about risk avoidance, it's about risk mitigation. If you manage to make every potential attack path as complex and expensive as possible with your hardening measures, cybercriminals may turn to easier prey.

Regulating Authentication

In terms of risk management, a secure AD design reduces the probability of login data misuse; the more extensive the privileges of the target identity, the greater the risk. Additionally, the effect of credential theft must be kept to a minimum, especially if this theft, including clear text passwords, cannot be ruled out, as is the case with domain join accounts, for example.

Limiting the damage requires rigorous implementation of the principle of least privileges, which starts with restricting read and write permissions in AD itself only to what is absolutely necessary for the purpose of the account in question. However, even the ability to log on to computers and start processes involves authorization that can be abused. Under certain circumstances, even simple read-only network access to "officially" shared resources is a valuable asset from the attacker's point of view (e.g., if the target of the attack is stealing a specific document).

Designing a full set of access rights for a least privileges model is a major undertaking, and very few administrators and system architects are capable of creating this kind of design at the drawing board. The task is also complicated by the fact that many of the permissions that ideally need to be revoked are assigned by default to virtual groups such as Authenticated Users or Everyone, from which you cannot remove individual users or computers.

Therefore, you need to pluck up courage and boldly remove the authorization entries of these virtual groups, replacing them with a combination of options that delegate the required permissions to groups that actually exist. This change gives you the opportunity to make highly privileged objects invisible to normal users and computers from the outset. You will always want to use scripts to assign permissions in AD, because it already provides 90 percent of the code you need to check later for correct permissions and helps you assign them quickly in another forest.

Protecting Login Data

When it comes to protecting credentials against theft and misuse, you need to consider the various threat scenarios. First is the disclosure of the username and password (i.e., the famous Post-it note under the keyboard or the passwords.txt file on the desktop). In the modern cloud world, you can at least mitigate these threats to some extent with multifactor authentication (MFA). Traditional on-premises technologies offer far less leeway in this respect, which leaves consistent training of all employees, including admins, as the only way to counteract physical password sharing.

Another approach that also works well locally is to dispense with passwords in favor of smart cards or Windows Hello for Business. To begin, check whether all applications in your infrastructure support Kerberos or at least NTLM. If you need to run an important web application used by many that insists on users entering usernames and passwords on a login screen, make sure you check whether it supports Active Directory Federation Services (ADFS) as an authentication method.

The next item on the list is brute-force attacks on explicit authentication. The obvious answer to this type of threat is an account lockout policy, but automatic account lockout is a double-edged sword – after all, it can paralyze the entire operation with minimal effort. If you really want to use this policy, set the number of failed logins until lockout to a far higher value than the 10 that both Microsoft and the Center for Internet Security (CIS) recommend by default.

One possible solution without denial of service potential is adaptive throttling. Applications with a web front end regularly use this technology, as any Fritz!Box user who has mistyped their password knows. Microsoft introduced the authentication rate limiter for Server Message Block (SMB) file shares in Server 2025. Although this method is not adaptive in the sense that the interval grows with each additional unsuccessful login attempt, it is definitely a step in the right direction.

Authentication policies can, to a certain extent, help limit the attack surface for brute force. For example, a Tier 0 account cannot be blocked by a brute-force attack on application servers, a service account cannot be blocked by a client, and a normal user cannot be blocked by attacks on the NETLOGON share of a DC. As a final means of protection, you can always monitor failed login attempts – of course, you only achieve advantages in operations if you actually follow up on the messages without delay.

Brute-force attacks on captured password hashes include hashes that are read from logon sessions on workstations or servers and techniques such as Kerberoasting, which is based on the data structure of a Kerberos service ticket and takes advantage of the ability of every user to request a service ticket for every service by default.

The recommended approach is to define rigorously where users can log in, for which you can use authentication and group policies (assigning user rights), although the former is far more effective. This approach is known as administrative tiering for the protection of highly privileged accounts, but you can also use it within a tier (zoning) to channel potentially accessible credentials further and make both escalation and lateral movement more difficult. Microsoft also offers Credential Guard on all supported Windows versions, which is an extremely effective virtualization-based technology you need to enable.

The only thing that really helps to make the last part of the attack more difficult – that is, reconstructing the plain-text password from the hash or service ticket by brute force – is a drastic increase in password length, ideally enforced by password policies or by the process you set up for changing passwords. User education with the goal of replacing passwords with passphrases and therefore implementing long but memorable passwords is a very worthwhile endeavor.

Recommendations from both the US National Institute of Standards and Technology (NIST) and German Federal Office for Information Security (BSI) even go so far as to recommend that companies do away with regular password changes for passwords greater than a certain minimum length (typically 20 characters). In a hypothetical environment where a password is typed in a dialog from a keyboard, this recommendation might even be justified. Unfortunately, password hashes are often still valuable assets without brute force, which forces admins to implement a workable password change procedure for every kind of account – normal users, admins, service accounts, and even break glass (emergency access) accounts.

When attackers inject password hashes directly (pass-the-hash or overpass-the-hash), they are exploiting two peculiarities in the Windows authentication system. First, NTLM only requires the password hash for the entire authentication process, and second, the RC4 hash in Kerberos is identical to the NTLM hash. If the hashes are injected directly, the length of the underlying passwords is irrelevant. As long as your environment still accepts NTLM or Kerberos allows RC4 cryptography, abolishing regular password changes is not an option; regular password changes are vital for security.

You will want to follow the authentication guidelines or at least use the Protected Users group for privileged accounts so that NTLM and RC4 are ruled out or are restricted to specific communication relationships. Also, consider switching to Group Managed Service Accounts (gMSAs) for service and task accounts if you have not already done so. AD automatically carries out password changes in this case. All the other approaches described previously that prevent hashes from being captured can also help shut off this attack route.

Of course, sniffing hashes from login sessions is not the only way to obtain this valuable material. A whole bunch of relay and replay attack techniques, all of which have the word "potato" in their names [2], aim to collect hash material. Once attackers have managed to grab replication authorizations, they can read the hashes directly from AD by directory replication. Of course, an unprotected system state backup of a DC, should it fall into the wrong hands, offers unhindered access to this information. The statement that Microsoft only supports a system state backup in the event of a disaster is one of the most persistent myths about disaster recovery in the AD ecosystem. System state backups of DCs can be found in many environments, and if you base your disaster recovery strategy for AD on them, you need at least to ensure that access to these datasets is extremely restrictive.