Kerberos, ACLs,ADCSand what's behind it.

We check for AS-REP roastable accounts without Kerberos pre-authentication and for kerberoastable service accounts: any account with a service principal name hands any domain user a ticket, crackable offline against wordlists. What matters is not how many passwords fall but the rights on those accounts. Then three delegation flavours: unconstrained delegation on non-domain controllers, constrained delegation with protocol transition, and resource-based constrained delegation, which one write permission on a computer object sets up. The BloodHound graph then shows the shortest route from a standard user to Tier 0 – a chain we walked, not theory.

Active Directory Certificate Services is the most underestimated part of any AD environment: an issued certificate outlives a password reset. We cover the known misconfigurations completely: templates letting the requester choose the subject alternative name (ESC1), templates with an Any Purpose EKU or none at all (ESC2) and enrollment agent templates (ESC3), over-broad permissions on templates and PKI objects (ESC4, ESC5), the EDITF_ATTRIBUTESUBJECTALTNAME2 flag (ESC6), abusable CA roles (ESC7), relay to web enrollment (ESC8) and the RPC endpoint (ESC11), an HSM-held CA key usable with shell access (ESC12), weak certificate mapping (ESC9, ESC10, ESC14), issuance and application policies (ESC13, ESC15), a CA that globally disables the SID security extension so every certificate it issues falls back to weak mapping (ESC16), and server authentication templates where the requester sets the name and can impersonate a server such as WSUS (ESC17). Often one template lets any authenticated user own the domain.

We assess the tier model: who may administer Tier-0 objects, which group policies link to the domain controller OU, which chain of permissions leads there from Tier 2? We mean rights appearing in no group membership: GenericAll and WriteDACL on privileged groups, WriteOwner on administrator accounts, ForceChangePassword, write access to computer objects, delegated organisational units. We analyse DCSync rights outside the domain controllers, AdminSDHolder anomalies, SID history from migrations, use of Protected Users, and read access to gMSA passwords and LAPS attributes: whoever reads a LAPS password is a local administrator, whatever group they are in.

Before a path gets interesting, we check what the domain permits in principle: functional levels and trusts with direction, transitivity and SID filtering (a trusted forest is part of your attack surface even if somebody else runs it), the password policy including fine-grained policies, the machine account quota, and leftovers of pre-Windows 2000 compatible access. Enforced LDAP signing, channel binding and SMB signing decide whether an intercepted authentication attempt can be relayed or runs into nothing. Then hardening gaps arriving by group policy (WDigest, AlwaysInstallElevated, point-and-print without a signature requirement), the domain controllers' patch level against Zerologon and PrintNightmare, and unpatched domain members.

We search SYSVOL for group policy preferences carrying cpassword and logon scripts with hard-coded accounts, and the directory for description fields used as password notes. We determine the real LAPS coverage – which computer objects lack a managed administrator password – and who may read BitLocker recovery keys. Finally the services historically holding far-reaching rights: Exchange with its accumulated permissions, SCCM with site servers, network access accounts and client push, and SCOM, whose management servers push code to clients.

adPEAS is a PowerShell tool that part of the AD pentesting world runs as its first enumeration pass. It is written and maintained at SEKurity, by Alexander Sturz, one of the three managing directors. It covers nine check categories, from domain configuration, permissions and delegation through ADCS and group policy to Exchange, SCCM and SCOM, collects data for BloodHound CE, and carries a Kerberos stack implementing AS-REQ/AS-REP, TGS, PKINIT and Pass-the-Ticket entirely in PowerShell. An OPSEC mode leaves the active tests out. For your test that means: writing a tool like this – in plain PowerShell, without third-party dependencies, running in any Windows environment and across every authentication method, from a password to a certificate – takes knowing the protocols underneath, not just a scanner’s output.

• adPEAS on GitHub

  Source, documentation and issue tracker – every claim above can be read back there. On ADCS the tool checks the template and enrolment paths: ESC1 to ESC5, ESC8, ESC9, ESC13 to ESC15, and ESC10 through the group policy check.

• blog.sekurity.de: adPEAS v2 in depth

  The technical series on the second version: architecture, authentication, the Kerberos stack and the data collection, explained step by step. If you want to know how deep the understanding behind a finding goes, it is written down there.

The process is the same for every AD test, only the scope differs. Up front we record in writing which domains are in scope, which account we start from, which changes we may make. Critical findings are reported immediately: an open route from standard user to domain admin is no report item, it is a phone call.

1. 01

   Scoping & authorisation

   We settle which domains, forests and trusts are tested, whether ADCS and Tier-0 containment are included, and who is reachable for escalation. The result is a written authorisation listing the actions we may take and their rollback.

2. 02

   Starting position

   The normal case is an unprivileged domain account created for the test, plus network access from a managed client, jump host or VPN. On request we start with no credentials, showing how far an attacker gets before holding an account.

3. 03

   Enumeration

   At first we only read: domain configuration, trusts, policies, accounts and groups, permissions, delegation, certificate templates, group policies, LAPS coverage. That yields the graph of possible paths; nothing is exploited or changed.

4. 04

   Verifying the paths

   The paths are walked manually and under control: tickets cracked offline, DCSync evidenced through the permission, certificates requested against an agreed template. Every active step is timestamped so your SOC can attribute it.

5. 05

   Report & debrief

   You receive a report with a management summary and a technical part, each finding with a reproduction, evidence, a rating and a recommendation. We prioritise together; a retest is itemised separately.

This page too deliberately carries no day rates, person-day figures or price ranges: an AD test follows the environment you run, and that cannot be judged from outside. Rather than a number too high for half of all enquiries and too low for the rest, we set out what drives it.

• Domains, forests and trusts

  A single domain is a different project from a grown forest with resource domains and trusts to group companies or providers. Every trust is a check of its own: rights travel across it in unintended directions.

• Number of user and computer objects

  The object count sets the size of the permission graph and with it the manual verification effort. A few hundred accounts can be walked completely; with tens of thousands and hundreds of group policies the work lies in sorting out paths that exist on paper only.

• ADCS in scope or not

  An AD-integrated PKI is an attack surface of its own: every certification authority, template and enrollment endpoint is assessed individually. Without one the section falls away; with several CAs it is the largest single item.

• Tier-0 containment

  Whether we only look for paths or also assess your administrative model is a scoping decision. The second examines account separation, privileged workstations, logon restrictions, and whether a compromised client reaches Tier-0 credentials at all.

• On-premises or hybrid with Entra ID

  With Entra ID a second identity world hangs off your domain: the synchronisation server and its accounts, the sign-in method (password hash sync, pass-through authentication, federation), Seamless SSO, and whether a local administrator inherits rights in the cloud.

How you get to a number you can rely on.

In a scoping conversation we settle the five points above – usually the number of domains, a rough object count and whether ADCS and Entra ID are in scope. Out of it comes a written proposal with a fixed scope, fixed price and committed time window, free and without obligation.

We do not work to an in-house method nobody outside the company knows. Testing follows publicly documented references: the catalogue of attacker techniques, the vendor's access model, the guide German auditors go by.

• MITRE ATT&CK Enterprise

  The catalogue of documented attacker techniques we map every finding onto – for Active Directory, Kerberoasting, DCSync and delegation abuse among them. Your SOC can then test its detection against the techniques that worked on you.

• Microsoft: Enterprise Access Model

  The vendor's reference model for privileged access, successor to the classic tier model. It defines what Tier 0 comprises and is the yardstick we measure account separation and containment against, rather than our own opinion.

• BSI: practical guide to IS penetration testing

  The guide from Germany's Federal Office for Information Security, including its classification by information base and aggressiveness. The usual reference when a German auditor or authority asks what was tested against.