The Vilkas Wire
When Active Directory Is in Scope, Don’t Handcuff the Pentest
Jan 6, 2026 · By Ben Rollin
If your organization uses Active Directory (AD), then AD is your security boundary (or at least a major one), and a compromise often leads to an attacker obtaining the "keys to the kingdom." Whether it be a file share containing R&D data, sensitive customer data, databases containing Personally Identifiable Information (PII), etc.
Firewalls, EDR, and MFA are all must-haves. However, in a Windows enterprise, identity is the thing that everything ultimately trusts, and when it fails, everything behind it falls with it. This is why a meaningful internal penetration test cannot treat Active Directory as an afterthought, and why the way AD is tested matters just as much as whether it is listed as "in scope."
The majority of our highest-impact internal penetration testing findings in many environments continue to be Active Directory-related. That is not because we look harder for them, but because AD presents a vast attack surface, takes considerable effort to secure, and hence is where real risk lives in real environments.
Internal Testing Should Reflect How Attacks Actually Happen
A common issue we see with internal penetration testing is treating it as a single scenario: the tester is "on the network", runs some tools, collects results, and a report is written and delivered, whether they were able to obtain an AD foothold or not.
This narrowly scoped approach to testing misses the reality of how compromises actually unfold. The first phase of an internal pentest should begin with no credentials at all. An attacker gains network access through physical access, an exposed port, a misconfigured wireless network, malware, an unmanaged device, or a system that should not have been accessible from the public Internet. From here, the attacker exploits misconfigurations or other vulnerabilities to establish a foothold in the domain.
The second phase begins with credentials: a successful phishing email or vishing (social engineering via phone) attack, credentials disclosed due to insider threat (i.e., a threat actor paying for access), credential reuse from a public data breach database, a lost/stolen laptop, a rogue employee, a third-party vendor with network access being compromised, the list goes on.
A strong internal penetration test should cover both types of scenarios, not because it makes the pentester look better in the report, but because this is how environments fail in practice.
Why Unauthenticated Testing Comes First
Starting from an unauthenticated standpoint is intentional and essential. This phase addresses a question that matters deeply to security leadership: if a rogue actor gains access to our internal network, what can they do/what level of access can they achieve before we even know they are there?
Unauthenticated testing looks for things like:
- Anonymous or low-friction enumeration
- Legacy protocols that can be abused for access
- Broadcast or name resolution abuse
- Credential capture opportunities
- Misconfigurations that facilitate an initial foothold
If a foothold is achieved during this phase of testing, it can be eye-opening. It means an attacker did not need to trick a user or steal credentials to gain access and start moving deeper into the network.
In many of our assessments, we do gain a foothold this way. When that happens, the test naturally progresses, often leading to Active Directory compromise without ever requiring the credentials that were initially offered. When a tester is unable to gain a foothold, this is a significant security win, indicating that controls such as segmentation, hardening, and detection have been effective.
However, it does not mean that the test should stop. At this point, we have validated that an attacker cannot achieve a foothold within a timeboxed test, but we have not determined what could happen if they did.
Why Low-Privilege Credentials Are Still Essential
If unauthenticated testing does not lead to a foothold, providing low-privileged Active Directory credentials allows the test to continue modeling reality. This phase of testing is often misunderstood. Providing credentials is not cheating or "helping the tester", but rather simulates a compromised user.
Testing what a normal domain user can do answers a different set of questions:
- Can privilege escalation occur without exploits?
- Are group memberships and ACLs designed safely?
- Can standard users access resources not meant for them?
- Does tiering actually hold up under pressure?
- Can one user become many, and then become an admin?
In most environments, identity misconfigurations matter more than missing patches. This is where in-depth Active Directory testing proves its value.
"You Only Got In Because We Gave You Credentials" Is the Wrong Take
This objection typically arises from a misunderstanding, rather than malicious intent. Providing credentials does not invalidate a finding. It contextualizes it, but it's also the tester's responsibility to frame this correctly in the report narrative and the finding write-ups.
A professional testing team does not start with credentials out of convenience. They should first earn a set of credentials by attempting unauthenticated access and documenting what holds up under pressure. When credentials are used, it should be because the hardened state of the environment forced that transition.
If a tester never asks for low-privileged credentials, that should raise questions. It may mean the test is constrained by optics instead of driven by risk, or that the tester lacks the requisite skill set to perform in-depth, credentialed testing.
Comprehensive testing is not about proving the tester is clever. It is about discovering how your environment breaks or holds up under real pressure.
Reporting Should Tell a Clear, Honest Story
A high-quality internal penetration test report should never blur where the findings came from.
It should clearly show:
- Which findings were identified during unauthenticated testing
- Which findings required authenticated access
- Which issues led to host compromise
- Which paths led to domain compromise
This level of detail matters for both leadership and for defenders. Executives need to understand whether controls failed early or whether identity flaws allowed impact once a user was compromised.
Technical teams need to understand exactly which misconfigurations were chained together and why, as well as "first fix" findings, to break these attack chains and prioritize remediation efforts. Attack chains tell this story far better than isolated findings, as they show an attacker's movement, what slowed them down, and where containment failed.
Why Active Directory Dominates High-Impact Findings
The most damaging internal penetration testing findings are almost always tied to Active Directory. The pattern repeats itself across industries, company sizes, and maturity levels. This is not because AD is broken, but because it is powerful and complex. Issues can often accumulate over years of change, and one change in one portion of the network can open up one or multiple holes in another.
Issues that arise from privilege creep, legacy configurations/protocols, weak passwords, over-provisioned access due to convenience, inherited permissions, or nearly unavoidable human error compound quietly. Attackers do not need zero-day exploits; they need patience and understanding.
For this very reason, Active Directory warrants focused and deliberate testing. Generic internal scanning will never surface this class of risk. Many environments suffer from issues that should have been remediated a decade ago but persist due to poor scoping or inadequate testing. In-depth testing by a qualified tester covering both unauthenticated and authenticated perspectives is a must.
Do Not Handcuff Your Own Test
If your organization uses Active Directory, the goal of an internal penetration test should be clarity, not comfort. Your tester should start unauthenticated, but progress into credentialed testing when appropriate.
As a client, expect transparency regarding when and why credentials were used in testing, which will help you better understand the risks present in your environment. Demand reporting that clearly separates paths and impact.
Ultimately, the purpose of testing is not to pass. It is to learn how your environment fails before an "unsanctioned" tester does. When Active Directory is involved, depth matters. Anything less leaves blind spots where real attackers thrive.
Have Active Directory in scope, and are you unsure if your current internal test accurately reflects a compromised user scenario?
Reach out to review your existing or upcoming internal AD pentest scope, and get a concrete plan for safely testing both unauthenticated access and low‑privilege “compromised user” paths in your own environment.
Please fill out the form, and we'll get back to you shortly.