Active Directory security

“Active Directory” is a term used to refer to various services Microsoft has released, updated, and rebranded numerous times since 2000. The suite of services broadly known as Active Directory is for on-premises deployments, while the service currently known as Entra ID is for the cloud, and the utility now called Entra Connect is for hybrid environments.

This interconnected trio provides the foundation for endpoint management, identity, and authentication services, which makes them some of the most critical services used by organizations of all sizes. Banks, government agencies, small businesses, and the vast majority of the Fortune 500 all use Active Directory. That ubiquity comes with several benefits—including a rich community, a mature training ecosystem, and a large talent pool in which it’s not uncommon to find people with decades of experience—but it also makes Active Directory and Entra ID a uniquely compelling target for attackers.

Adversaries can invest time, money, and effort into developing their skills at attacking Active Directory for two reasons: because successfully compromising Active Directory can give them control over any computer, identity, or process managed with the service; and because their knowledge of Active Directory’s mechanisms and the widely available tools that can be used to exploit them will prove useful in attacks on practically any organization worth attacking. The question isn’t whether or not malicious hackers will target Active Directory; it’s whether or not defenders will be able to stop them before disaster strikes.

In this article, we’ll explore some of the most common attacks on Active Directory, Entra ID, and Entra Connect; the security controls and best practices that proactively secure these critical services; how the Active Directory threat landscape is changing in response to the shift towards hybrid environments, the rise of AI, and other trends; and some frequently asked questions about securing Active Directory.

Understanding the Active Directory attack surface and common threats

The inherent complexity involved with managing untold numbers of systems, identities, and their associated permissions means that many organizations make the same mistakes when securing Active Directory. These flaws are so common they have enabled the development of widely available, reliable, and consistently effective tools and techniques for exploiting Active Directory.

Combining the abundance of ways adversaries can exploit Active Directory, the lack of clarity afforded by the services themselves, and the extraordinarily rare usage of endpoint firewalls and other defensive tooling results in a high-value target practically begging to be compromised. Attackers know the following tools and techniques like the back of their hands; defenders must also become familiar with them if they want to protect their organizations.

Active Directory makes it difficult to detect malicious activity

Windows and Active Directory make it nearly impossible to effectively audit what capabilities have been made available to a given account. Whether that means permissions on an Active Directory object, local administrator rights on a computer, or effective rights granted to a security group, these critical services were not designed to answer even seemingly obvious questions like “who has administrator rights on this computer?” So how are defenders supposed to find answers to far more difficult questions, especially when they have to differentiate between everyday sysadmin tasks and malicious activity?

Consider someone who uses a variety of well-known Active Directory-related tools to access and manage dozens of systems. Is that an attacker stealing confidential information, laying the groundwork for a ransomware attack, or tampering with critical assets… or is it someone who works in the organization’s IT support department making their way through requests for help? What if that account is compromised? Would defenders be able to detect the malicious activity, and if so, how long would it take for them to do so?

Modern systems administrators and defenders quickly learn the tooling provided by Active Directory is insufficient for planning, establishing, and maintaining secure and reliable environments at scale. They will probably have to turn to third-party software and services intended to make up for the first-party tooling’s shortfalls. Their adversaries have had the same realizations, however, and will often use the very same tools in their own operations in ways that are practically indistinguishable from legitimate activity.

Reconnaissance and enumeration: Who, what, and why?

Third-party tools, like Active Directory itself, are double-edged swords. System administrators and security teams alike need to know what accounts are supposed to be in their environment, what those accounts are supposed to be able to do, and why they are supposed to be able to do it. Adversaries want to have a similar understanding of the organization’s infrastructure; they just plan to do something very different with the information they obtain.

Defenders want to know what accounts are supposed to be in their environment so they can remove unnecessary accounts, monitor suspicious activity from existing accounts, and investigate new accounts when they’re created. Attackers want to know if there are dormant accounts they can take over, if an actively used account would be worth compromising, and how likely an organization’s security team would be to detect the creation of a new account. Both are seeking the same information; the only difference is what they plan to do with it.

The “what” and “why” are similar. Organizations want information for one purpose; adversaries want the same information for their own purpose. A tool designed to help Active Directory administrators learn the “who”, “what”, and “why” of an environment is probably also going to appeal to attackers. BloodHound is a prime example of this phenomenon.

We created BloodHound to make it easier to understand the relationships within an Active Directory or Entra ID environment. In the years since, defenders and attackers alike have used BloodHound to better understand an organization’s infrastructure, with the former looking to eliminate potential attack paths before the latter can exploit them. We’ve heard from many organizations that BloodHound was invaluable to them in their efforts to secure Active Directory; we’ve also gotten used to reading about how BloodHound was used by adversaries in incident response reports published by other security firms. There’s no question about whether or not BloodHound is the right tool for the job, it’s simply a matter of knowing whether or not that happened to be the right job.

Credential theft and abuse

We said at the start that “Active Directory” is often used to refer to Active Directory proper, Entra ID, and Entra Connect. The term can also give the impression that Active Directory is a single piece of software or a standalone service that provides some of the tools administrators need to manage their environments. That isn’t really the case either. Active Directory is built atop the Kerberos protocol developed in the ’80s, the Lightweight Directory Access Protocol (LDAP) released in the ’90s, and the New Technology LAN Manager (NTLM) protocols Microsoft’s been iterating on since the ’90s, among other things.

That means Active Directory can essentially “inherit” vulnerabilities, configuration woes, and technical debt from each of those protocols. (As well as the other protocols, libraries, and software it depends on.) The ways those protocols interact with each other can introduce their own challenges, too, and organizations running outdated versions also have to contend with known Active Directory vulnerabilities that remain effective against their infrastructure. That any of this works even half as well as it’s supposed to is a minor miracle.

Perhaps the most telling example of how Active Directory suffers from its underlying protocols arrives via NTLM. Microsoft has said that developers “are generally advised not to use NTLM” since 2010 because it doesn’t support modern cryptographic methods. Researchers have also developed numerous tools capable of cracking NTLM-hashed passwords in hours, proven the utility of “pass the hash” attacks, and found ways to make NTLM-related attacks relevant years after a particular technique was thought to have been obviated. Yet NTLM remains. (Microsoft said in early 2026 that NTLM was being “phased out” of Windows 11, but given the rate at which organizations respond to changes like that, the protocols are likely to remain a problem for the foreseeable future.)

NTLM isn’t the only part of Active Directory’s foundation that’s been susceptible to credential theft and abuse. Kerberos has also had problems, such as “Golden Ticket” attacks that can be used to gain almost total control over an organization’s environment. These attacks—named for the golden ticket presented to the titular character in “Charlie and the Chocolate Factory” that gives him access to a mad confectioner’s house of saccharine horrors—are also more difficult to detect than other methods of compromising Active Directory.

Privilege escalation pathways

Adversaries can’t always compromise accounts with the ability to wreak havoc within an Active Directory environment. Instead, they’re more likely to be able to take over a low-value account with restricted capabilities. That’s better than leaving high-value accounts vulnerable, of course, but it doesn’t mean attackers will simply give up when they’re stymied by the limits of a compromised account’s permissions. There’s a good chance they’ll try to exploit privilege escalation pathways to make the most of the compromised account.

The core concept of privilege escalation is straightforward: find ways to gain capabilities that aren’t supposed to be available to that particular account. Anyone who’s tried to install software on a managed device, for example, has probably been stopped from doing so with a dialog that either requests the password associated with an administrator’s account or simply explains that app downloads have been disabled on that machine. In that case, someone would use privilege escalation to proceed with the installation of that software anyway.

Privilege escalation in the context of Active Directory is significantly more complex. The most impactful change adversaries could make would be moving from an unprivileged user—someone whose accounts, services, and devices are simply managed by their organization—to a Domain Administrator. That would allow an attacker to manage other accounts, change security policies for specific assets, and otherwise grant them some level of access to pretty much everything Active Directory interacts with. Preventing this is mission-critical.

Proactive Active Directory hardening and best practices

By now it should be clear that securing Active Directory is critical. It’s not the only thing defenders have to worry about—there are plenty of other ways for attackers to infiltrate, traverse, and cause problems within an environment—but it’s almost certainly the most important thing. Investing in securing other aspects of the environment while neglecting Active Directory would be like putting shatterproof windows in a vehicle while leaving its doors unlocked and the keys in the ignition. Those windows aren’t going to make much of a difference when an adversary’s driving that vehicle off into the sunset.

Active Directory, Entra ID, and Entra Connect are so complex and can be used for such a wide variety of purposes that organizations will have to independently figure out how their particular environment needs to be secured. To continue with the vehicle analogy: snow tires are a luxury for people who live near a desert; they’re a necessity for people who know it’s only a matter of time until a blizzard rolls through their region. Still, there are some best practices for securing Active Directory that are about as universally applicable as “lock the doors” and “don’t leave the keys in the ignition.”

Monitor Active Directory and related infrastructure

Perhaps the easiest mistake to make when securing Active Directory is assuming that a configuration, policy, or defensive measure that was effective when it was set up will remain effective in perpetuity. That is rarely the case. Adversaries constantly discover new software vulnerabilities and ways to exploit the many protocols and programs under the Active Directory umbrella. The services themselves might change between updates. Organizational requirements might lead to modified policies, new paradigms, and other changes over time that could have unexpected consequences for the security of the environment. A point-in-time understanding of that environment is no longer sufficient, especially if the point in question is “when it was first set up.”

Modern environments require continuous monitoring solutions that can notify defenders of suspicious activity, capture the information they’ll need to investigate that activity, and provide ways to analyze that data quickly enough for them to conduct that investigation before “suspicious activity” becomes “critical incident.” These aren’t trivial problems to solve, especially if organizations have to contend with equipment shortages or market conditions that make compute or storage prohibitively expensive, but it’s far more difficult to secure Active Directory without up-to-date knowledge about how it’s being managed and what it’s being expected to do within an environment.

Don’t neglect the security of your Active Directory stack

Active Directory can’t be treated like it’s just one of the many services an organization relies on. It’s too important to the rest of the org’s infrastructure, and it’s too compelling a target for adversaries, for that. Other parts of the infrastructure might be seen as the equivalent of box trucks–they’re easy to replace, so it’s okay if they’re worn down and beat up–but Active Directory is more like a top-of-the-line race car that’s practically irreplaceable and requires a dedicated maintenance team.

In practice, that means Active Directory should be administered from dedicated systems that use strict access policies, multi-factor authentication, and endpoint security tools. (In keeping with our vehicle metaphor: lock the door.) Because Active Directory is such a high-value target, the physical security of these administrative hosts might have to be considered. Attackers with physical access to a device can often find ways around most defensive measures. Seeking that access is usually more trouble than it’s worth, but depending on the organization, an adversary might be willing to take the risk. Plan accordingly.

The same applies to the servers on which Active Directory actually runs, which are called “domain controllers.” Microsoft says, “because domain controllers can read from and write to anything in the [Active Directory Domain Services] database, compromise of a domain controller means that your Active Directory forest can never be considered trustworthy again, unless you can recover it by using a known good backup and close the gaps that allowed the compromise.” The company also says, “depending on an attacker’s preparation, tooling, and skill, irreparable damage can be completed in minutes or hours, not days or weeks.”

Ensuring the integrity of these domain controllers is crucial. These systems must be locked down–they have to be properly configured, they should be prioritized in any vulnerability management strategy, and they cannot be used for other purposes. (In our vehicle metaphor: don’t leave the keys in the ignition.) These servers are the most important part of a foundational aspect of an organization’s infrastructure and should be defended as such.

Remember that they’re called ‘privileges’ for a reason

An uncomfortable truth has persisted since computers were first used as more than just fancy calculators: not everyone who relies on an organization-issued computer should be allowed to do whatever they want with that computer. Not only would that be nearly impossible to manage–pity the support team required to troubleshoot systems over which individual users have total control–but also it would make it far more difficult to keep critical assets secure. There’s a reason why the ability to make changes to an organization-managed system or the environment in which it operates are called “privileges,” and it’s because not everyone in the organization needs to have them.

Calling the task of assigning, managing, and potentially revoking privileges within a modern environment “Sisyphean” would be an understatement. Sisyphus had a clearly defined job to do—push this boulder up that hill—that happened to be in an endless loop. For that to be similar to managing privileges in Active Directory, Sisyphus would have to push countless boulders up infinite hills, all while being subject to constant requests to push the boulder in a different way or move the boulder from one hill to the other. Oh, and he’d have to be blindfolded to simulate the difficulty of learning who has what privilege we mentioned earlier. Then the comparison would be more appropriate.

Yet the fact remains that effective privilege management is a key component of Active Directory security. That’s what BloodHound Enterprise is for: making this more Sisyphean-than-Sisyphus task attainable. It helps organizations see how privileges are being managed within the environment, what privileges have been granted to which accounts, and more, all so Active Directory administrators and defenders can be confident that only a carefully selected group of people have been trusted with these capabilities. Not everyone needs those abilities. If they did, we’d call them “rights.”

Evolving Active Directory security: Hybrid, cloud, and future trends

Organizations have been managing Active Directory for the last 30 years. A lot has changed in that time, especially as the shift from on-premises to cloud-based computing inspired the creation of Entra ID and its ilk, but many of the basic principles and the protocols surrounding them remain the same. So it’s probably safe to say that organizations will continue to rely on Active Directory for decades to come. The question is how Active Directory and companies are expected to change in that time and why those changes are likely to occur.

The rise of AI and the problem with big numbers

The popularization of large language models (LLMs), which have become a stand-in for the broader concept of artificial intelligence (AI) among seemingly everyone who hasn’t spent decades in that field, has made it even more difficult to manage Active Directory in modern environments. There are two reasons for this: the rise of “agentic” computing has resulted in unforeseeable growth in the number of “identities” within an environment, and the proliferation of AI-based hacking tools combined with incidents where even benign agents behaved in unpredictable ways, with cataclysmic results.

For decades most organizations only had to manage a relatively small number of identities and devices. There was a time when it was reasonable to expect one person to use a single device they accessed with a single account. Then smartphones came along, and suddenly organizations had to manage several devices per employee, with more and more people expecting to be able to use smartphones and tablets and laptops and desktop computers each year. Now organizations have to handle all of those devices as well as however many accounts and services they’ve set up for “agents” that don’t really exist.

Meanwhile, the information security industry has been sounding the alarm about how automated hacking tools are going to pose even bigger problems as LLMs continue to develop additional capabilities. Sometimes these “agents” are being used by adversaries to assist with their operations; sometimes they seem to simply “go rogue” and decide to do some hacking on their own. There have also been multiple incidents wherein AI companies have claimed their agents escaped their sandboxes so they could hack another organization. With an abundance of resources for learning how to compromise Active Directory available online, it’s probably best to assume these LLMs have at least some of this information in their training sets, which could result in even more attacks on this critical infrastructure. That’s dire news for already-overwhelmed defenders.

Even if those attacks never come, Active Directory management is also vital to organizations experimenting with AI in their environments. There have been multiple reports from individuals and organizations alike describing how an “agent” either hallucinated, misunderstood a prompt, or malfunctioned, with consequences ranging from “it wiped my personal hard drive” to “it deleted our production database as well as the backups” and everywhere in between. Organizations looking to prevent that within their own environments—and that should be all of them—will have to carefully manage permissions for identities used by “agents” to safeguard against these potentially colossal mistakes.

Feet on the ground, head in the clouds

For a while it seemed like every organization would put all of their infrastructure “in the cloud.” A few orgs certainly did, but a combination of market pressure, stipulations for companies seeking government contracts, and the realization that no cloud provider could promise infinite uptime has prompted many organizations to reconsider any plans to abandon on-premise servers entirely. Some have abandoned “the cloud” in favor of exclusively relying on their own infrastructure, but for most organizations, a hybrid approach seems to offer the best of both worlds. If it makes more sense for them to put something in the cloud, they do. If it would be more sensible to run something on-premise, they do that instead. (At least in theory.)

A hybrid approach introduces its own problems, however. The most basic is keeping policies, permissions, etc. in sync between on-premise Active Directory and cloud-based Entra ID. Microsoft’s Entra Connect helps with that task, but system administrators and defenders still have an additional layer of complexity to manage in already highly complex environments that are also contending with the changes arriving with the dawn of agentic computing. There are definite upsides to this approach—that’s why it’s becoming so popular—but there’s no use pretending it doesn’t also involve considerable effort.