Active Directory Security Assessments Explained

In most organisations that run Windows, Active Directory (AD) decides who can log in to what. It controls access to file shares, servers, email, VPNs, and often the cloud through a synced identity. It has usually grown over many years, through migrations, mergers and quick fixes.

That combination makes AD the place where internal attacks are won or lost. This guide explains what an Active Directory security assessment involves, why attackers think in attack paths, the weaknesses that come up most often, and how a good test stays safe.

It’s written for engineering and IT leaders. It explains concepts rather than techniques, and contains no step-by-step attack instructions.

Why Active Directory is the prime target

When attackers get into a corporate network, whether through a phishing email, a stolen password or an exposed service, their first goal is usually more privilege. AD is where that privilege lives.

Gaining control of AD typically means:

• Access to every domain-joined computer and server
• The ability to read, change or delete data across the organisation
• The ability to create accounts and hide persistence
• In hybrid setups, a possible route into cloud identity

That is why AD is such an attractive target for ransomware operators: if the domain falls, everything joined to it is at risk.

Attack paths: how small issues add up

AD compromises are rarely caused by one dramatic vulnerability. They come from attack paths: chains of individually minor issues that together lead from an ordinary account to full control.

A simplified example:

1. A standard user can read a configuration file on a share that contains a service account’s password.
2. That service account is a local administrator on a group of servers.
3. An administrator logged in to one of those servers recently, and their credentials can be recovered from memory.
4. That administrator belongs to a group with rights over the domain.

No single step looks critical in isolation. Together, they’re a route to domain admin. An AD assessment looks for these chains, because that’s how real attackers work.

Assumed breach: starting from the inside

An external test asks whether someone can get in. An assumed-breach assessment asks a different question: if someone is already in, how far can they get?

The test usually starts with:

• A standard domain user account, the same as a typical employee would have
• A normal workstation or a virtual machine on the corporate network
• No special knowledge beyond what that user would have

This reflects reality. Phishing, password reuse and infostealer malware mean a compromised user account is a realistic starting point for almost any organisation. The assessment shows what happens next.

Common Active Directory weaknesses

These are some of the issues assessments find most often, explained at a conceptual level.

Weakness	What it is	Why it matters
Kerberoastable service accounts	Service accounts whose Kerberos tickets can be requested by any user and cracked offline	Weak service-account passwords can be recovered without touching the account directly
Delegation abuse	Accounts or computers trusted to act on behalf of other users	Misconfigured delegation can let an attacker impersonate privileged users
Excessive ACL rights	Permissions on AD objects that let one account modify another, such as resetting passwords or changing group membership	Hidden rights often create unexpected paths to admin
AD CS misconfigurations	Weak settings in Active Directory Certificate Services templates or enrolment	Can let a user obtain a certificate that authenticates as someone more privileged
Credential exposure	Passwords in scripts, shares, descriptions or old policy files	Gives attackers new accounts to use without any exploitation
Privileged sprawl	Too many admin accounts, or admins logging in to ordinary workstations	Increases the places where powerful credentials can be stolen
Weak segmentation	Users can reach management interfaces and servers they never need	Makes lateral movement easier

Kerberoasting

In Kerberos, any authenticated user can request a service ticket for a service account. Part of that ticket is encrypted with the service account’s password. If the password is weak, it can be cracked offline, with no alerts on the account itself.

Defensive takeaway: use long, random passwords for service accounts, or managed service accounts, and limit their privileges.

Delegation abuse

Delegation lets a service act on behalf of users, for example a web server accessing a database as the logged-in user. Unconstrained or poorly scoped delegation can let an attacker who controls that service impersonate other users, sometimes including administrators.

Defensive takeaway: review which accounts and computers are trusted for delegation, prefer constrained or resource-based delegation, and mark sensitive accounts as unable to be delegated.

ACL abuse

Every AD object has an access control list. Over time, rights accumulate: a helpdesk group that can reset passwords for an admin group, or a user that can add members to a privileged group. These rights are easy to miss in normal administration.

Defensive takeaway: review rights over privileged groups and accounts, and remove what isn’t needed.

AD CS misconfigurations

Active Directory Certificate Services issues certificates that can be used to authenticate. Certain template and enrolment settings can let a low-privileged user request a certificate that identifies them as someone else. This class of issue has become one of the most significant AD risks in recent years.

Defensive takeaway: audit certificate templates and enrolment permissions, and restrict who can request certificates for authentication.

How a safe AD assessment works

AD is business-critical, so safety is part of the design of the test, not an afterthought.

• Written authorisation and scope. In-scope ranges, systems to avoid and testing windows are agreed in advance.
• Remote delivery. Testers connect through a VPN, a jump host or a small virtual machine on your network.
• Non-disruptive techniques. Testers avoid actions that could lock out accounts, crash services or change production configuration, unless you explicitly approve them.
• Proof without damage. Impact is demonstrated, for example by showing that a privileged group could be modified, without making the change permanent or touching business data.
• Immediate escalation. If testers reach domain admin or find something critical, they tell your named contact straight away.
• Stop on request. You can pause or stop testing at any time.

Our how we work page explains our rules of engagement in more detail.

What an assessment typically covers

Every environment is different, but most AD assessments work through the same broad areas:

• Discovery and mapping. Enumerating users, groups, computers, trusts and permissions, then building a picture of how they relate.
• Credential hygiene. Looking for passwords in shares, scripts and object descriptions, and for weak or reused service-account passwords.
• Privilege and attack-path analysis. Identifying the shortest routes from the starting account to high-value targets such as domain admins, backup systems and key servers.
• Kerberos configuration. Reviewing service accounts, delegation settings and pre-authentication requirements.
• Certificate services. Auditing AD CS templates, enrolment rights and certificate authority settings.
• Lateral movement and segmentation. Checking what a compromised machine can reach, and whether admin interfaces are exposed to ordinary users.
• Hybrid identity. Where in scope, examining how on-premises AD connects to Entra ID and whether paths cross between them.

The goal isn’t to list every setting that differs from a benchmark. It’s to show which combinations actually let an attacker progress, and which fixes break those paths most efficiently.

Who should be involved

AD assessments touch shared infrastructure, so involve the right people early:

• Your identity or infrastructure owner, who knows the history behind the configuration and can explain unusual setups.
• Your security operations or monitoring team, depending on whether you want to test detection (see the callout above).
• An escalation contact who can make decisions quickly if a critical issue is found during testing.
• Change management, if your organisation requires notice before testing on production networks.

A short kickoff call with these people saves time later. Testers can ask about known quirks, and your team knows exactly when testing will happen and what to expect.

What to prepare

• Access: VPN credentials, a jump host, or a virtual machine on your network
• A standard domain user account for assumed-breach testing
• In-scope IP ranges and any systems that must not be touched
• Agreed testing windows and an emergency contact
• Details of any hybrid identity setup, if Entra ID is in scope

Reading the results

A good AD report shows the attack paths it found, step by step, with evidence for each link in the chain. That matters because the fix is often to break the chain at its cheapest point, not to fix every link at once.

Expect findings grouped by theme, such as credential hygiene, delegation, ACLs and certificate services, with clear remediation for each. A retest then confirms that the paths are closed. Our methodology explains how we rate severity by business impact.

Bringing it together

Active Directory is complex because the organisations it serves are complex. Attackers don’t need it to be badly broken, only to contain one path from an ordinary account to the top. An assumed-breach assessment finds those paths before an attacker does, safely and with minimal disruption.

To plan an assessment, see our internal network and Active Directory testing service.