Active Directory penetration testing

Active Directory,
the way it actually falls.

Domain compromise is rarely an exploit. It is a chain of small, boring misconfigurations that nobody owned: a service account with an old password, a certificate template with the wrong flag, an ACL granted in 2019 for a migration that finished years ago.

Nothing here is a vulnerability. Everything here is a path.

You will not find these on a patch report, because none of them are missing patches. They are the accumulated result of a directory that has been running for fifteen years and has never been audited from an attacker's point of view. That is precisely what this engagement is.

The chains we
test for.

Each one is walked by hand from a standard domain user, which is what an attacker gets from one phishing email.

01

Kerberos attacks

Kerberoasting service accounts with weak passwords, AS-REP roasting accounts without pre authentication, and Golden and Silver ticket forging where key material is reachable.

02

Delegation abuse

Unconstrained delegation on machines that should never have had it, constrained delegation with protocol transition, and resource based constrained delegation abused from a machine account quota that is still the default of ten.

03

AD CS misconfiguration

Certificate templates that permit requester supplied subject names or client authentication for any authenticated user. ESC1 through ESC11, tested individually. Read the field guide.

04

ACL and object rights

GenericAll, WriteDacl, WriteOwner and ForceChangePassword edges that create a path to a privileged group, mapped and then walked to prove the path is real.

05

Coercion and relay

Authentication coercion combined with NTLM relay to LDAP or AD CS, on the hosts where signing and channel binding were never enforced.

06

Credential reuse

Local administrator password reuse across the estate, cached credentials on shared hosts, and passwords sitting in SYSVOL scripts, share drives and group policy preferences.

Seen in the field

What it looks like
in practice.

An illustrative example of the class of issue this engagement is built to find, and what changes after it.

Illustrative example, not client data

operator@overwatch: certificate services, template review Illustrative example

BeforeWhat we found

# any authenticated user may request this template
$ certreq -template UserAuth \
    -san upn=administrator@corp.local

[*] ENROLLEE_SUPPLIES_SUBJECT: enabled
[*] Client Authentication EKU:  present
[*] Manager approval:           disabled
[+] Certificate issued
[+] TGT obtained as Domain Admin

AfterAfter the fix

# template corrected, same request
$ certreq -template UserAuth \
    -san upn=administrator@corp.local

[*] ENROLLEE_SUPPLIES_SUBJECT: disabled
[*] Manager approval:           required
[-] Request denied: subject not permitted

AD CS, ESC1. A certificate template let any authenticated user name the identity on their own certificate. That is domain compromise from a standard account, and it never appears on a patch report. One flag and an approval requirement close it.

From one user
to the domain.

We start with a standard domain account and no special rights, because that is the realistic starting position.

01

Enumerate

Full directory collection and graph analysis. Users, groups, sessions, ACLs, trusts, certificate templates and Group Policy, assembled into a map of who can reach what.

02

Find the shortest path

The graph almost always contains a path from an ordinary user to a privileged group. We identify every such path, not just the first one.

03

Walk it for real

A path on a graph is a hypothesis. We execute each step to prove it works in your environment, with your controls in place.

04

Report the fix order

Domain compromise usually has one or two choke points. Break those edges and dozens of paths disappear at once. We tell you which ones they are.

Test the directory.

Request a quote

What should have
alerted, and did not.

Every technique we run has a well known detection. We record what we did and when, so your team can check their coverage against a real timeline.

Timeline

A timestamped activity log

Every action with its timestamp, source host and account, so your SOC can replay the engagement against their own telemetry.

Gaps

Coverage gaps named

Which techniques produced no alert at all, and which produced one that nobody actioned. Both are findings and they need different fixes.

Tuning

Concrete detection guidance

The specific event identifiers and log sources that would have caught each step, so improvement does not require a new product purchase.

Questions

The usual
questions.

Do you need Domain Admin to run this test?

No. We start from a standard domain user with no special privileges, because that is what an attacker has after a single successful phish. Getting to Domain Admin from there is the exercise.

Is this safe to run in production?

Yes, with agreed rules. We avoid destructive techniques by default, and anything with real risk such as certificate authority interaction is agreed in writing beforehand and coordinated with your team.

What is AD CS and why does it matter so much?

Active Directory Certificate Services issues certificates for authentication. A single misconfigured template can let any authenticated user request a certificate that authenticates as a domain administrator. It is common, it is quiet, and it is often the fastest path in. We wrote a full field guide on ESC1 to ESC11.

We already run BloodHound ourselves. What do you add?

BloodHound produces the graph. It does not tell you which edges are actually walkable in your environment, which ones your controls break, or which two you should fix first. We execute the paths and prioritise by real exploitability.

How long does an Active Directory assessment take?

Typically one to two weeks depending on the size of the estate and the number of domains and trusts. You get a fixed timeline before starting.

Test the directory.

A senior operator replies within one business day. No sales pipeline, no bot.