Almost every internal network compromise ends in Active Directory, because Active Directory holds the credentials, the trust, and the keys to everything else. Active Directory penetration testing starts where a real intrusion starts, with one ordinary user account or one workstation, and works toward Domain Admin the way an attacker would. This guide explains the paths testers actually use, what an assessment covers, and the small set of fixes that close most of them.
Why Active Directory is the target
A Windows domain is a trust system. Every user, computer, service, and group is an object, and the relationships between them decide who can do what. Those relationships accumulate for years: a helpdesk group given rights to reset passwords, a service account added to Domain Admins in 2016 to make a backup job work, a legacy server that still speaks protocols the rest of the network abandoned. Attackers do not exploit Active Directory so much as read it, find the relationships that were never meant to exist, and follow them.
That is why an internal network penetration test spends most of its time on the domain, and why an external test that never reaches the inside tells you little about how a breach would actually unfold.
Where the test starts
Active Directory testing is an assumed-breach exercise. The tester is given what an attacker would have after a successful phishing email or a compromised laptop:
- A standard domain user account with no special privileges, or
- A workstation on the internal network with no credentials at all.
Both starting points are realistic, and a thorough assessment covers both. At Invadel the tester connects remotely through a small device shipped to the office or a VPN the client provides, so the engagement needs no travel and no one to host a visitor.
Written by
Invadel Team
Senior penetration testers writing from real engagements, the same team that scopes, tests, and reports for our clients. About Invadel →