Active Directory pentesting with tier model: attacks and hardening 2026

Active Directory remains the identity backbone in more than ninety five percent of midsize and large enterprises running a Microsoft stack. AD pentesting is a mature technical discipline with standardized tooling and techniques cataloged in MITRE ATT&CK, but effective hardening cannot be achieved through isolated patches. It requires a structural privilege segmentation model, historically known as the tier model and formalized by Microsoft as the Enterprise Access Model.

This guide describes the real phases of an AD pentest, the attack vectors that appear repeatedly in Red Team reports, the breakdown of the T0/T1/T2 tier model and the countermeasures that actually close the path to Domain Admin. It is written for security leaders, blue teams and technical staff who want to understand what gets validated in a serious project and what needs to be fixed afterwards.

The essentials: compromising the domain equals compromising the entire company. AD pentesting finds the shortest path to Domain Admin through enumeration (BloodHound, SharpHound), Kerberos attacks (Kerberoasting, AS-REP Roasting, Golden Ticket), ACL abuse and AD CS vectors (ESC1 through ESC11). Effective hardening requires applying tier model T0/T1/T2, LSA Protection, Credential Guard, Protected Users, LAPS, Authentication Silos, gMSA and strict discipline over privileged accounts. Without tier segregation, no isolated mitigation holds.

Why AD is a priority target in any pentest

In a typical corporate environment, AD controls user authentication, authorization to internal applications, computer management, security policies and very often the PKI tree and federation with cloud services through Azure AD Connect. An attacker who reaches Domain Admin obtains de facto control over the whole estate: file servers, mail, ERP, databases, hypervisors, jump hosts and frequently the hybrid Microsoft 365 environment as well.

The math is asymmetric. An internal pentester starts with standard user credentials and, in most domains carrying configuration debt, can escalate to full privileges within hours or days. The reason is simple: AD accumulates twenty years of legacy configurations, misconfigured service accounts, inherited ACLs that nobody reviews and delegations that were applied once "to make it work". Every one of those leftovers is a stepping stone.

That is why, in every serious internal pentest, AD takes the largest section of the report. And that is why the tier model has become the defensive standard of reference: it is not a marginal improvement, it is the only structural way to contain blast radius when a credential is compromised.

Phases of AD pentesting

A well executed AD pentest follows an ordered sequence aligned with the classic phases of a real compromise:

1. Discovery. Identification of domain controllers, AD sites, trusts, main OUs, active subnets and services exposed on the internal network.
2. Enumeration. Massive collection of objects: users, groups, computers, GPOs, ACLs, SPNs, delegations, issued certificates, active sessions.
3. Exploitation. Execution of attacks against the findings: Kerberoasting, AS-REP Roasting, ESC1, ACL abuse.
4. Lateral movement. Movement between systems using recovered credentials, stolen tickets or relays.
5. Escalation. Local and domain privilege escalation up to the target tier.
6. Persistence. Access maintenance mechanisms: Golden Ticket, DCShadow, AdminSDHolder, skeletons in privileged groups.
7. Exfiltration. Controlled demonstration of sensitive data extraction (no actual exfiltration takes place in a pentest, the path is documented).

The pentester rotates between phases continuously. A new credential recovered during lateral movement reopens enumeration from a different perspective. That is why a serious project is never measured only in duration but in coverage of critical paths found and validated.

Enumeration and discovery

Enumeration is the longest phase and the one that defines the quality of the rest of the pentest. Standard tools:

• SharpHound (BloodHound collector). Gathers active sessions, group memberships, ACLs, trusts and domain objects. Modern versions (BloodHound CE and BloodHound Enterprise) allow stealth mode collection and OU filtering.
• BloodHound (analyzer). Converts the data into a navigable Neo4j graph. Its built-in queries identify "Shortest Paths to Domain Admins", "Kerberoastable Users", "AS-REP Roastable Users", "Unconstrained Delegation", "Computers with Local Admin" and many more.
• PowerView. PowerShell suite with manual functions: Get-NetUser, Get-NetGroup, Get-NetComputer, Get-NetSession, Get-DomainObjectAcl. Useful when a full BloodHound deployment is not desired.
• ldapsearch and ldapdomaindump. Flat LDAP enumeration, valid on Linux or WSL.
• ROADrecon. BloodHound equivalent for Entra ID. Mandatory when a hybrid tenant exists.
• adPEAS, Snaffler (credential search in shares), PingCastle (in read-only mode for benchmarking).

Metrics that BloodHound exposes and that a pentester always reports: number of paths to Domain Admin from a standard user, number of kerberoastable users, percentage of computers with shared local admin, T0 account sessions detected on T1/T2 machines, computers with unconstrained delegation.

Classic Kerberos attacks

Kerberos is the default authentication protocol in AD, and its design opens multiple abuse paths when weak configurations exist:

• Kerberoasting (T1558.003). Any authenticated user can request a TGS for any account with a registered SPN. The ticket is encrypted with the NT hash of the service account. If the password is weak, it is cracked offline with hashcat -m 13100. Tools: Rubeus.exe kerberoast, GetUserSPNs.py from Impacket.
• AS-REP Roasting (T1558.004). Accounts with the DONT_REQ_PREAUTH flag set emit part of the AS-REP encrypted without prior authentication. That portion is cracked offline. Tools: Rubeus.exe asreproast, GetNPUsers.py.
• Pass-the-Ticket. Reuse of a TGT or TGS extracted from memory with Mimikatz or Rubeus to authenticate as the owning user without knowing the password.
• Pass-the-Hash. Reuse of the NT hash of an account to authenticate via NTLM against domain resources.
• Golden Ticket (T1558.001). Forgery of an arbitrary TGT signed with the hash of the krbtgt account. Grants persistent Domain Admin until krbtgt is rotated twice.
• Silver Ticket. Forgery of an arbitrary Service Ticket signed with the NT hash of a specific service account. Limits the scope to that service but generates no DC traffic and is hard to detect.
• Diamond Ticket. Variant that requests a legitimate TGT from the KDC, decrypts it with krbtgt and modifies internal claims (PAC) to inject membership in privileged groups. Stealthier than the classic Golden.
• Sapphire Ticket. Evolution of Diamond that leverages the S4U2self flow to obtain a valid PAC of an arbitrary privileged account without forging it from scratch. Tracked by advanced Red Team groups since 2023.

Each of these vectors has specific mitigations, but all share a structural countermeasure: apply tier model and separate privileged credentials.

ACL abuse and misconfigurations

Active Directory allows granular permission delegation on objects through ACLs. When those ACLs are not reviewed, rights accumulate that an attacker can chain:

• GenericAll. Total control over the object. Allows password reset, SPN modification, critical attribute changes.
• GenericWrite. Attribute modification. Allows adding an SPN to an account and then Kerberoasting it.
• WriteDACL. Modification of the object's own security descriptor. Equivalent to GenericAll because the attacker grants themselves the remaining permissions.
• WriteOwner. Allows taking ownership of the object and then granting permissions.
• ForceChangePassword. Password change without knowing the previous one.
• AddMember on a group. Self-add to the group, typically a privileged one.
• AllExtendedRights. Includes User-Force-Change-Password, and on the domain object includes DS-Replication-Get-Changes and DS-Replication-Get-Changes-All (DCSync).

BloodHound maps these abuses as edges in the graph and suggests the shortest path to Domain Admin. The pentest question is always the same: how many hops separate a standard user from the Domain Admins group, and which specific ACLs enable each hop.

AD Certificate Services attacks

Active Directory Certificate Services (AD CS) manages the internal PKI. Will Schroeder and Lee Christensen published in 2021 the "Certified Pre-Owned" paper that cataloged eleven vectors known as ESC1 through ESC11. Brief summary:

• ESC1. Certificate template that allows a user to request a certificate specifying the SAN (Subject Alternative Name) with any UPN. Enables requesting a certificate as Domain Admin.
• ESC2. Template with EKU "Any Purpose" or no EKU. Practical equivalent of ESC1.
• ESC3. Enrollment agent template that allows issuing certificates on behalf of other users.
• ESC4. Vulnerable ACL on the certificate template. Allows modifying it and converting it into ESC1.
• ESC5. Vulnerable ACL on PKI objects in AD (CA object, Enrollment Services).
• ESC6. EDITF_ATTRIBUTESUBJECTALTNAME2 flag on the CA. Allows arbitrary SAN in any template.
• ESC7. ManageCA or ManageCertificates permissions on the CA.
• ESC8. NTLM relay to the AD CS HTTP Web Enrollment endpoint. Allows obtaining a certificate for a machine account without password.
• ESC9 and ESC10. Manipulation of userPrincipalName and weak certificate-to-account mapping.
• ESC11. Relay to the CA RPC interface without signing.

Reference tool: Certipy (Python). Enables enumeration (certipy find), exploitation (certipy req, certipy auth) and relay attacks. General mitigation: review templates, disable EDITF_ATTRIBUTESUBJECTALTNAME2, require manager approval for sensitive templates, apply KB5014754 (strong certificate-to-account mapping), enforce LDAP signing and disable HTTP Web Enrollment.

Other 2026 vectors

Beyond Kerberos, ACL and AD CS, the current repertoire includes:

• Print Spooler abuse. PrintNightmare (CVE-2021-34527) still appears in unpatched environments. The Print Spooler service is also used to force machine account authentication against attackers through the RpcRemoteFindFirstPrinterChangeNotificationEx RPC (PrinterBug).
• SCCM/MECM relay. Microsoft Configuration Manager stores privileged credentials, manages network access accounts and enables software distribution. Reference tool: SharpSCCM.
• MSSQL impersonation. SQL Server service accounts with IMPERSONATE rights on sa or other logins allow command execution as those logins. Chained with xp_cmdshell or linked servers it enables lateral movement.
• RBCD (Resource-Based Constrained Delegation). If the attacker controls a computer object with GenericWrite, they can write msDS-AllowedToActOnBehalfOfOtherIdentity on another computer and impersonate any user against that resource. Tools: Rubeus, Impacket.
• DCSync (T1003.006). Replication request to the DC to extract hashes of any account, including krbtgt. Requires DS-Replication-Get-Changes and DS-Replication-Get-Changes-All permissions. Tools: mimikatz lsadump::dcsync, secretsdump.py.
• DCShadow. Registers a temporary malicious DC in the domain and replicates arbitrary changes (SID History modification, AdminSDHolder, ACLs). Advanced persistence that is very hard to detect.
• NTLM Relay. Capture of NTLM authentication and relay to LDAP, SMB, HTTP. ntlmrelayx.py from Impacket is the standard.

Tier model T0/T1/T2 as structural defense

Microsoft formally retired the ESAE / Red Forest model in 2020 and replaced it with the Enterprise Access Model, an evolution that keeps the core principle of tier segmentation but integrates it with cloud identity and modern privileged access workstations.

Operational definition of tiers:

• Tier 0. Root identity of the environment. Includes Domain Controllers, ADFS, PKI servers (AD CS), Azure AD Connect, Privileged Access Management solutions, hypervisors hosting DCs and backup systems containing DC state. Compromising any T0 equals compromising the entire domain.
• Tier 1. Enterprise servers and applications. File servers, SQL, ERP, on-premise mail, internal web servers, document managers. Their compromise affects data and services but must not be able to escalate to T0.
• Tier 2. User workstations and devices. Endpoints, developer machines, corporate laptops. The most exposed tier and where most initial compromises land (phishing, drive-by, USB).

Non-negotiable rules:

1. An account never crosses tiers. A T0 admin never logs onto a T1 or T2 machine. A T1 admin never logs onto T2. If they need to administer a lower-tier system, they do so from their own T0 PAW via RDP jumping or from a dedicated jump server.
2. Separate accounts per tier. The user john has three distinct accounts: john (T2, mailbox and workstation), john-adm-t1 (T1 administration), john-adm-t0 (T0 administration). Each with independent password and mandatory MFA.
3. PAW (Privileged Access Workstation). Physical or virtual workstation dedicated exclusively to administrative tasks, without mail, general browser or productivity software. Only administrative tools and connection to resources of the corresponding tier.
4. Authentication Silos. Native AD configuration that prevents T0 accounts from authenticating against systems outside the T0 silo.
5. Tier 0 is never administered through RDP from the rest. Access through physical console, dedicated PAW or hardened T0 jump host.

Implementing tier model in an organization with historical debt is months of work, not a sprint. But it is the only defense that survives a leaked credential.

Effective hardening post-pentest

After an AD pentest, the report lists individual findings. Useful remediation groups transversal controls:

• LSA Protection (RunAsPPL). Marks the LSASS process as Protected Process Light. Prevents credential dumping with Mimikatz without a signed driver. Enabled via HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL.
• Credential Guard (HVCI). Isolates LSASS in a Hyper-V virtualization container. Even a SYSTEM process cannot read secrets. Requires CPU with virtualization and modern firmware.
• Protected Users group. Applies restrictive policies: prohibits NTLM, RC4, classic delegation and credential caching. Mandatory for every privileged account.
• Tiered admin accounts + PAW. Operational implementation of the tier model described above.
• LAPS / Windows LAPS. Random per-machine password for the local administrator account, rotated periodically and stored in AD. Eliminates the local admin password reused across the entire estate, the main vector for lateral movement.
• Authentication Silos + Policies. Restrict from which machines an account can authenticate and to which machines it can authenticate.
• AD CS hardening. Systematic template review, disabling EDITF_ATTRIBUTESUBJECTALTNAME2, applying KB5014754, removing templates with open EKU "Any Purpose" or "Smart Card Logon", enrollment restriction.
• SMB signing required and LDAP signing + channel binding required on every DC and sensitive server. Closes most NTLM relays.
• Disable NTLMv1. No exceptions. Audit first with Negotiate signing and migrate the applications that still use it.
• Restrict NTLMv2. GPO Network security: Restrict NTLM to minimize outbound and inbound usage.
• Schema permissions audit. Permissions on schema objects (adminSDHolder, Configuration, Schema) must be limited to pure T0 accounts.
• gMSA for service accounts. Progressive replacement of traditional service accounts with Group Managed Service Accounts. 240-byte passwords, automatic rotation every 30 days.
• Periodic krbtgt rotation. Double rotation every 6 to 12 months with the official Microsoft script.

How to measure AD maturity

After applying hardening, results must be measured. Tools and metrics used:

• BloodHound queries. Built-in queries "Shortest Paths to Domain Admins from Owned" and "Critical Assets" quantify progress. The key metric: number of paths existing in the graph from a standard user to Domain Admins. Reasonable goal after hardening: zero direct paths in fewer than five hops without active exploitation.
• PingCastle. Automated AD health report with score 0-100 (lower is better). Covers configuration anomalies, inactive accounts, trusts, known vulnerabilities. The most widely used consulting benchmark.
• Purple Knight (Semperis). Free tool oriented to detecting exposure indicators. Generates a report categorized by area (account security, Kerberos, AD delegation, AD infrastructure security).
• Microsoft Defender for Identity. Sensor on DCs that detects anomalous behavior and maps identities to tier. Integrated with Microsoft 365 Defender.
• Ad-hoc scripts. Custom audits of forgotten SPNs, accounts with PasswordNotRequired, unconstrained delegations, members of Schema Admins and Enterprise Admins.

A mature organization runs PingCastle quarterly, BloodHound after every significant change and a full AD pentest annually.

Frequently asked questions

Does the same approach apply to on-premise AD and Entra ID?

Not in the same way. Entra ID (formerly Azure AD) does not use Kerberos as primary authentication, has no domain controllers in the classic sense, and its privilege model is managed with RBAC roles and Privileged Identity Management. However, almost every organization has a hybrid environment with Azure AD Connect, which creates an additional attack surface: compromising the sync server is compromising the tenant. ROADrecon is the BloodHound equivalent for Entra ID. The tier model applies conceptually: Global Admin accounts are pure T0 and must not be used for operational tasks.

Is it legal to use BloodHound against my company's domain?

Yes, provided there is formal authorization. BloodHound is an audit tool, not an exploit. Any external consultant needs a signed scope in the contract. Internally, the security team must have authorization from the IT lead and the security lead. Without authorization, running SharpHound can be considered unauthorized access under most cybercrime statutes including the UK Computer Misuse Act and equivalent EU legislation.

How long does a full AD pentest take?

A quality internal AD pentest takes between two and four weeks of effective work, depending on domain size, number of OUs, existing trusts and requested depth. The first two weeks focus on enumeration, exploitation and lateral movement. The following weeks on critical path validation, persistence and report writing. A Red Team with AD as primary objective can extend to six or eight weeks.

Is a retest required after applying hardening?

Yes. The retest is the only way to validate that countermeasures work in production and that no new exposures were introduced during remediation. The usual approach is to contract a focused retest, not a full pentest, three to six months after the initial report delivery. If the client applies tier model as part of the hardening, the retest must include specific validation of the segregation.

Can an SMB realistically implement tier model?

With adapted scale, yes. An SMB with a single domain, thirty servers and two hundred endpoints can implement a simplified version: a virtual PAW for the domain admin, separate T0 and T2 accounts, LAPS deployed, Protected Users enabled for administrators. Reasonable effort is a three to six week project. It is not Microsoft's full ESAE, but it closes the critical paths.

Is ESAE still valid as reference?

Microsoft retired ESAE as a formal recommendation in 2020 and stopped updating the guide. The official successor is the Enterprise Access Model, which keeps the principles (segmentation, PAW, account separation) but adapts them to hybrid and cloud-first environments. Legacy ESAE implementations remain valid if maintained; new implementations should follow Enterprise Access Model.

Related resources

• Kerberos attacks in Active Directory: expanded technical detail on Kerberoasting, AS-REP Roasting and Golden Ticket.
• What is Mimikatz and credential dumping: the tool that still sets the pace of AD post-exploitation.
• Red Team: business guide: how AD pentest fits into broader offensive exercises.
• What is PKI: foundation on which AD CS and its ESC vectors are built.
• What is MITRE ATT&CK: framework that catalogs every technique mentioned in this guide.
• Infrastructure penetration testing internal and external: methodology and deliverables of a real project.
• Penetration testing vs Red Team: differences between both approaches when scoping AD work.

AD audit with Secra

At Secra we run Active Directory pentesting focused on finding the real path to Domain Admin and, above all, on documenting how to close it. The project includes enumeration with BloodHound and ROADrecon, controlled execution of Kerberos and AD CS attacks, ACL and delegation auditing, T0/T1/T2 tier model design adapted to the actual organization size and prioritized hardening recommendations for the following six months. We also cover the retest phase once countermeasures are applied. If your organization runs on AD and has never been audited, is on its third systems lead or needs to validate the domain before a NIS2, DORA or ISO 27001 audit, write to us through contact and we plan the scope.