Active Directory remains one of the most targeted systems in any organization, and for a pretty straightforward reason: it controls who gets access to what. If an attacker can compromise AD, they can move laterally through the network, escalate privileges, and access sensitive data without triggering many alarms. The unfortunate truth is that many AD environments were set up years ago and haven't been hardened to match the threat landscape of 2024.
I spend a lot of time thinking about AD security, partly because the attacks keep evolving while the defenses in many organizations stay static. So I wanted to walk through some of the most common identity-based attacks targeting Active Directory and what you can actually do about them.
Credential-based attacks are still the biggest problem
Most breaches don't start with some exotic zero-day exploit. They start with stolen or guessed credentials. Attackers know that humans pick bad passwords, reuse them across services, and rarely change them unless forced to. That makes credential-based attacks the path of least resistance into most networks.
One of the more persistent threats is password spraying, where an attacker takes a small set of commonly used passwords and tries them against a large number of accounts. Unlike brute force, which hammers a single account with thousands of guesses, password spraying spreads the attempts across many accounts. This keeps the number of failed logins per account low, which often flies under the radar of lockout policies. If you're unfamiliar with the mechanics of this type of attack, Cayosoft has a solid breakdown of what is password spraying that's worth reading.
The reason password spraying works so well against Active Directory is that AD environments tend to have large numbers of user accounts, many of which still use weak or predictable passwords. Service accounts are especially vulnerable because they often get set up with a simple password and then forgotten about for years. An attacker only needs one match to get a foothold.
Kerberoasting and why service accounts matter more than you think
Kerberoasting is another attack that specifically targets AD's Kerberos authentication protocol. Here's how it works: any authenticated domain user can request a service ticket for any service account that has a Service Principal Name (SPN) registered. The ticket is encrypted with the service account's password hash. The attacker takes that ticket offline and cracks it at their leisure, with no further interaction with the domain controller.
If the service account has a weak password (and many do), the attacker can crack it in minutes or hours using commodity hardware. Once they have the plaintext password, they can authenticate as that service account, which often has elevated privileges.
The fix here isn't complicated, but it requires discipline. Use long, randomly generated passwords for service accounts, at least 25 characters. Where possible, use Group Managed Service Accounts (gMSAs), which rotate their passwords automatically. Audit your SPNs regularly and remove any that are no longer needed. You'd be surprised how many legacy SPNs are still sitting in production AD environments, attached to accounts that haven't been touched in years.
Pass-the-hash and pass-the-ticket attacks
These attacks exploit the way Windows handles authentication tokens. In a pass-the-hash attack, an adversary captures the NTLM hash of a user's password from memory (using tools like Mimikatz) and uses it to authenticate as that user without ever needing the actual password. Pass-the-ticket works similarly but with Kerberos tickets instead of NTLM hashes.
What makes these attacks especially dangerous is that they can work even if the user has a strong, complex password. The attacker doesn't need to crack anything. They just need to grab the token from a compromised machine's memory.
Defending against this requires reducing the exposure of privileged credentials. Don't log into regular workstations with domain admin accounts. Use tiered administration models so that Tier 0 credentials (domain admins, domain controllers) are only used on Tier 0 systems. Implement Local Administrator Password Solution (LAPS) so that local admin passwords are unique per machine and rotated regularly. If an attacker compromises one workstation, they shouldn't be able to reuse that local admin hash on every other machine in the environment.
Misconfigured permissions are an open door
Beyond these well-known attack techniques, one of the quieter risks in AD security is misconfigured permissions. Over time, AD environments accumulate permission bloat. Users get added to groups for a specific project and never removed. Delegation of control is granted broadly because it was faster than figuring out the minimum permissions needed. Nested group memberships create indirect access paths that are hard to trace.
I've seen environments where a help desk group had the ability to reset passwords for domain admins because of a delegation that was set up during a migration five years ago. No one remembered it was there. An attacker who compromises a help desk account in that environment can escalate to domain admin in one step.
Regular access reviews are important, but they need to go deeper than just checking group memberships. You need to audit the actual permissions on AD objects, including organizational units, group policy objects, and the AdminSDHolder container. Tools that can map effective permissions and alert on changes to sensitive objects make this much more manageable than trying to do it manually.
Monitoring and detection: what to actually watch for
Prevention is always preferable, but you also need to assume that some attacks will get through. Detection in an AD environment means watching for specific patterns in event logs and authentication traffic.
Some things worth monitoring:
- A spike in Kerberos service ticket requests from a single account (possible Kerberoasting)
- Authentication attempts against many accounts in a short time window from the same source IP (possible password spraying)
- Changes to sensitive groups like Domain Admins, Enterprise Admins, or Schema Admins
- Modifications to Group Policy Objects, especially those linked to domain controllers
- New SPNs being registered on user accounts
Windows Event IDs 4769 (Kerberos service ticket request), 4771 (Kerberos pre-authentication failure), and 4625 (failed logon) are your friends here. But raw event logs generate enormous volumes of data, and most security teams don't have the bandwidth to review them manually. A SIEM or a dedicated AD monitoring tool that can correlate events and surface anomalies is practically a requirement for any environment with more than a few hundred users.
The role of backup and recovery in AD security
Something that gets overlooked in AD security conversations is recovery. If an attacker does compromise your AD environment, whether through ransomware, a Golden Ticket attack, or simply deleting critical objects, how quickly can you get back to a known good state?
Native AD recovery options (authoritative restore from a system state backup) are slow and error-prone. They require booting into Directory Services Restore Mode, which takes the domain controller offline. In a multi-domain-controller environment, you also have to worry about replication conflicts and lingering objects. If the attacker has planted persistence mechanisms (modified the KRBTGT account, added backdoor accounts, changed ACLs on sensitive objects), a simple restore might bring those right back.
Having the ability to recover individual AD objects, or even roll back specific attribute changes, without taking a domain controller offline is a meaningful advantage during an incident. It turns a potential multi-day outage into something that can be resolved in minutes. The gap between "we can restore" and "we can restore quickly and selectively" is the difference between a bad day and a catastrophic week.
Practical steps you can take this week
If I had to pick the highest-impact things most organizations could do to improve their AD security posture right now, these would be on the list:
- Audit your service accounts. Find every account with an SPN, check its password age, and reset anything using a weak or old password. Switch to gMSAs where you can.
- Enforce multi-factor authentication for all privileged access. This alone blocks a huge percentage of credential-based attacks, including password spraying.
- Implement tiered administration. Stop using domain admin credentials on regular workstations. It feels inconvenient at first, but the security improvement is massive.
- Review delegated permissions in AD. Look at who can modify what, especially around sensitive containers and objects. Remove anything that's no longer needed.
- Test your recovery process. Don't wait for an actual incident to find out that your AD backup is corrupt or your restore procedure takes 14 hours. Run a drill.
AD security isn't a single project you finish and move on from. It's an ongoing process that requires attention as the environment changes, as new accounts are created, as new applications are integrated. The organizations that do it well aren't necessarily using fancier technology. They're just paying closer attention to the basics, consistently, over time. And honestly, that's harder than it sounds.
Top comments (0)