What Is Internal Penetration Testing?
Written By
Sarwat Iftikhar
Most security programs spend the majority of their attention on the perimeter. Firewalls, web application testing, and external vulnerability scanning all focus on what an attacker can reach from the internet. That attention is warranted because the perimeter is where most unauthorized access begins. It is not where most serious breaches end.
Once an attacker gains a foothold inside a network, the controls that matter most are the internal ones: whether the internal network is properly segmented, whether Active Directory is configured securely, whether a standard user account can be escalated to domain administrator, whether one compromised workstation can reach every other system in the environment. These are the questions that determine how far a breach goes and how much damage it causes, and they can only be answered by testing from inside.
Internal penetration testing simulates exactly this scenario. A qualified tester starts from a position already inside the network, with the access level a compromised standard employee account would have, and attempts to escalate privileges, move laterally to sensitive systems, and demonstrate what a real attacker would achieve once initial access has been established. The findings reveal not whether an attacker can break in, but what happens when one does.
Key Takeaways
- Internal penetration testing simulates an attacker who has already gained a foothold inside the network, testing whether internal controls would limit the damage of a real breach.
- Active Directory misconfiguration is the most consistently discovered critical finding in Bugstrix internal assessments, appearing in the majority of environments tested and providing reliable paths to domain compromise from a standard user starting position.
- Internal testing and external testing answer different questions, and neither substitutes for the other. Both are required by PCI DSS v4.0, expected by SOC 2 auditors, and needed for a complete security picture.
- The most dangerous internal attack paths in most environments are not sophisticated zero-day exploits. They are well-documented Active Directory attack techniques exploiting configurations that have existed for years without anyone testing whether they are present.
- In Bugstrix internal assessments, the average time from standard domain user access to domain administrator compromise in environments that have not been formally tested is significantly shorter than most security teams expect.
What Is Internal Penetration Testing?
Internal penetration testing is a security assessment in which a qualified tester simulates an attacker operating from within the organization’s network, using the access level of a standard authenticated user and attempting to escalate privileges, move laterally across systems, access sensitive data and infrastructure, and demonstrate the realistic impact of a breach that has already passed the external perimeter.
The starting position of an internal penetration test is the key distinction from all other security assessment types. Rather than beginning from the internet as an unauthenticated outsider, the tester begins from inside the network with credentials equivalent to a standard employee account. This simulates the most common real-world breach scenario: an attacker who gained initial access through phishing, a compromised VPN credential, an infected endpoint, or any other initial access technique and is now operating from within the trusted internal environment.
The questions an internal penetration test is designed to answer are fundamentally different from those addressed by external testing. External testing answers: can an attacker get in? Internal testing answers: given that an attacker is in, what can they do, how far can they get, and what would they actually reach? Both questions matter, and neither assessment answers the other.
For an overview of the full penetration testing discipline and how internal testing fits within it, our guide to what penetration testing is covers the complete methodology landscape.
How Does Internal Penetration Testing Differ from External Penetration Testing?
Internal and external penetration testing simulate different attacker positions and answer different security questions. External testing begins from the internet with no prior access and asks whether the perimeter can be breached. Internal testing begins from inside the network with authenticated access and asks what an attacker who has already breached the perimeter can accomplish.
The two are complementary halves of a complete network security assessment. External testing validates whether an attacker can gain initial access through the internet-facing infrastructure. Internal testing validates whether the organization’s internal controls, segmentation, and detection capabilities would limit what that attacker could do once inside. A network that resists external attack but allows unconstrained lateral movement once a single workstation is compromised has not addressed the part of the problem that determines how bad a real breach gets.
The skills and techniques involved in each also differ significantly. External testing requires expertise in web application security, network reconnaissance, and the specific vulnerabilities present in internet-facing services. Internal testing requires deep expertise in Active Directory attack paths, Windows and Linux privilege escalation, lateral movement techniques, credential harvesting, and network segmentation analysis. Most experienced practitioners are skilled in both, but the internal testing skill set is more specialized and less commonly available in the market.
Most major compliance frameworks require both. PCI DSS v4.0 Requirement 11.4 explicitly mandates both external and internal annual penetration testing of the Cardholder Data Environment. SOC 2 auditors expect both as part of the evidence package supporting CC4.1 and CC6.1. ISO 27001 requires technical vulnerability testing that encompasses both the external perimeter and the internal environment.
Our post on what external penetration testing is covers the external assessment in detail, which provides useful context for understanding how the two complement each other in a complete program.
What Does an Internal Penetration Test Cover?
An internal penetration test covers the full internal network environment: Active Directory infrastructure and domain configuration, internal network services and management interfaces, workstations and servers reachable from the internal network, network segmentation controls, privileged access and credential management, and any internal web applications or services not exposed to the internet.
Active Directory is the highest-priority testing domain in almost every internal assessment. AD is the identity and access backbone of Windows enterprise environments, and its misconfiguration is the most reliable path from a standard domain user to full domain compromise in the majority of organizations. Common AD attack paths including Kerberoasting, AS-REP roasting, unconstrained and constrained delegation abuse, ACL-based privilege escalation, and misconfigured Group Policy Objects are systematically evaluated during every internal assessment.
Network services and management interfaces examine what services are reachable from the internal network, whether they use secure configurations and current software versions, and whether management interfaces for servers, network devices, and internal applications are accessible to standard user accounts that should not have access to them. Internal network services are frequently less rigorously maintained than internet-facing ones because the assumption that the internal network is a trusted environment reduces the urgency of patching and hardening.
Network segmentation validates whether the controls designed to isolate different parts of the network, such as separating production from development, restricting access between user workstations and servers, and isolating sensitive systems, actually work under adversarial testing. In PCI DSS environments, this segmentation testing is a specific mandatory component rather than an optional addition.
Credential harvesting and reuse testing evaluates whether credentials obtainable from a compromised workstation, such as cached credentials, browser-stored passwords, or credentials in configuration files, can be reused to access other systems. Credential reuse is one of the most reliable lateral movement techniques in real-world attacks because it requires no vulnerability exploitation, only the application of credentials obtained through one compromise to attempt access to other systems.
Privilege escalation tests whether a standard user account can be escalated to administrator-level access through misconfigurations in local system configurations, service permissions, scheduled tasks, or Active Directory properties that grant unintended elevated privileges.
Sensitive system access validates whether the most critical systems in the environment, domain controllers, database servers, backup infrastructure, and cloud management interfaces, are reachable and accessible to an attacker who has escalated privileges from a standard user starting position.
How Does an Internal Penetration Test Work?
An internal penetration test works through four phases: scoping and access setup, enumeration and attack surface mapping, exploitation and objective pursuit, and reporting with remediation guidance. The engagement begins with the tester connected to the internal network with standard domain user credentials and ends with a complete documented attack narrative.
Phase 1: Scoping and access setup. Before the assessment begins, the scope is defined: which network segments are in scope, what credentials will be provided for the starting position, whether any systems are explicitly excluded, and what the primary objectives of the engagement are. In most internal assessments, the starting position is a standard domain user account connected to the internal network, either physically on-site or via VPN. Some engagements start with a more restricted starting position to simulate a compromised guest network or a contractor account.
Phase 2: Enumeration and attack surface mapping. From the starting position, the tester enumerates the internal environment: Active Directory users, groups, computers, and configurations; network services and reachable hosts; software versions and patch levels on identified systems; and trust relationships between systems and domains. This phase builds the map that informs which attack paths are most likely to succeed.
Phase 3: Exploitation and objective pursuit. The tester actively exploits identified vulnerabilities and misconfigurations to escalate privileges and move laterally toward the engagement’s objectives. This phase is documented step by step with screenshots, command output, and timestamps to create the attack narrative that forms the core of the final report. At Bugstrix, we specifically focus this phase on demonstrating realistic attack chains rather than cataloguing individual findings in isolation, because the business impact of a series of connected steps is what executive stakeholders and compliance auditors need to understand.
Phase 4: Reporting. The final report documents the attack narrative, the specific vulnerabilities and misconfigurations exploited at each step, the systems and data that were accessible at the conclusion of the attack chain, severity ratings for each finding, and specific remediation guidance for the technology stack and environment tested.
What Vulnerabilities Does Internal Penetration Testing Find?
Internal penetration testing consistently finds vulnerabilities in Active Directory configuration, credential management, network segmentation, and the trust relationships between systems that accumulated over years of operational growth without formal security review. The most impactful findings are not typically sophisticated or unusual. They are well-documented weaknesses that persist because they were never tested under adversarial conditions.
The findings that appear most consistently across Bugstrix internal assessments:
Kerberoastable service accounts with weak passwords. Service accounts in Active Directory with Service Principal Names set can have their Kerberos tickets requested by any domain user and cracked offline. When those service accounts have weak passwords, this provides an attacker with elevated credentials without exploiting any software vulnerability. The technique is well-documented and decades old, yet it remains one of the most reliable privilege escalation paths in modern enterprise environments.
Unconstrained delegation. Systems configured with unconstrained delegation cache the Kerberos tickets of any user who authenticates to them, including domain administrators. An attacker who compromises a system with unconstrained delegation can extract those cached tickets and use them to authenticate as the domain administrator. This configuration exists in many environments as a legacy artifact from early Active Directory deployments and is rarely reviewed or revoked.
NTLM relay attacks. Protocols including SMB and HTTP that still use NTLM authentication in many environments can be exploited through relay attacks where authentication credentials are captured and replayed to a different target system. With tooling that automates this process, an attacker on the internal network who can trigger authentication attempts can frequently escalate to administrator access on other systems.
Excessive Active Directory permissions. Users, groups, or service accounts with write access to sensitive AD objects through misassigned ACLs, often the result of administrative convenience decisions made years ago and never reviewed. These permissions allow an attacker with access to a low-privilege account to modify higher-privilege objects and effectively grant themselves elevated access.
Password reuse across accounts. Credentials obtained from one compromised system, whether through a memory dump, a browser credential store, or a configuration file, that are valid on other systems because the same password was reused across multiple accounts. This is a lateral movement technique that requires no vulnerability exploitation at all, only access to credentials and the presence of other systems accepting them.
Missing or ineffective network segmentation. Internal networks where a compromised workstation in one segment can directly reach domain controllers, database servers, or other sensitive systems in supposedly isolated segments. This finding is particularly significant for PCI DSS environments where segmentation forms the basis of scope reduction.
Unpatched internal systems. Internal servers and services running software versions with known exploits that have not been patched because they are not internet-facing and therefore perceived as lower priority. The assumption that internal systems are less critical to patch because they are not directly accessible from the internet is consistently invalidated when an attacker gains initial access and finds an easy lateral movement path through an unpatched internal service.
Why Does Active Directory Security Matter So Much for Internal Testing?
Active Directory is the identity and access infrastructure that governs who can access what in most enterprise Windows environments, and its misconfiguration provides the most reliable attack paths from standard domain user access to full domain administrator compromise. Understanding why AD is so central to internal penetration testing requires understanding what it controls and what happens when that control is misconfigured.
AD defines every user account, computer, group, and policy in the Windows environment. Domain administrator access in an AD environment is not just access to one system. It is effective access to every system joined to the domain, which in most enterprise environments means the majority of the organization’s infrastructure. This is why the path from standard user to domain administrator is the central objective of most internal penetration tests.
The reason AD misconfigurations are so persistent and so consistently discoverable is that Active Directory is complex, changes accumulate over years of operation, and the security implications of specific configurations are not always visible to administrators managing the environment for day-to-day operations. A service account configured with unconstrained delegation ten years ago for a product that was subsequently retired may still exist in the environment, its dangerous configuration forgotten entirely. A test that specifically searches for these configurations finds them regardless of how long they have existed.
For organizations that want a deeper understanding of how network and infrastructure security testing addresses these findings, our post on network penetration testing covers the overlapping discipline in detail.
Who Needs Internal Penetration Testing?
Any organization running a Windows network with Active Directory, which describes the overwhelming majority of enterprise and mid-market businesses, needs internal penetration testing. The scale and complexity of the test adapts to the size of the environment, but the need does not scale down with organizational size because the attack techniques that internal testing evaluates work equally well against small and large AD environments.
The compliance-driven case applies to a broad segment of the market. PCI DSS v4.0 mandates annual internal penetration testing alongside external testing for all organizations processing cardholder data. SOC 2 Type II auditors expect evidence of testing that addresses the internal environment in addition to external surfaces. ISO 27001 requires technical vulnerability testing that encompasses internal systems and services.
Beyond compliance, the business case is straightforward. An organization that has only ever tested its external perimeter has no evidence of what an attacker who successfully phishes one employee would be able to do from that starting point. Given that phishing is consistently among the most common initial access vectors in real-world breaches, the absence of internal testing means the organization has deliberately not tested the scenario that most commonly leads to serious damage.
For small and mid-market businesses thinking through where internal penetration testing fits in an overall security investment, our post on how much a small business should spend on cybersecurity provides context for prioritizing security investments against organizational risk profile.
Our penetration testing services cover internal network assessments alongside external testing, structured around the compliance requirements and business objectives of each engagement.
How Often Should Internal Penetration Testing Be Conducted?
Internal penetration testing should be conducted at minimum annually, triggered additionally by significant changes to the internal environment, including Active Directory restructuring, major infrastructure migrations, significant changes to network segmentation, and post-merger or acquisition integration events that bring new systems and identities into the internal environment.
The annual minimum is driven by compliance frameworks for most organizations: PCI DSS Requirement 11.4 requires it, SOC 2 expects it within the audit observation period for Type II, and ISO 27001 requires periodic technical testing.
Beyond the compliance calendar, the right frequency is determined by how quickly the internal environment changes. Active Directory environments accumulate new configurations, new service accounts, new trust relationships, and new delegations as the organization grows and evolves. Each change can introduce new attack paths. Annual testing catches the accumulation of those changes. Organizations with active IT programs that frequently modify their AD configuration or add new infrastructure benefit from more frequent testing to avoid building up untested configuration debt between annual cycles.
A practical complement to annual internal penetration testing is continuous attack surface monitoring of the internal environment. Our attack surface management service provides ongoing visibility into the internal attack surface between testing cycles, identifying newly exposed services and configuration changes that would warrant attention before the next scheduled test.
How Much Does Internal Penetration Testing Cost?
Internal penetration testing for a typical mid-market organization with a standard Windows Active Directory environment costs $8,000 to $25,000. Environments with more complex AD configurations, multiple sites, cloud integration, or large numbers of network segments sit at the higher end. Smaller environments with limited AD complexity and a single site sit at the lower end.
The primary cost drivers are Active Directory complexity, the number of in-scope network segments and systems, whether cloud environments connected to the internal network are in scope, and whether compliance-specific reporting is required. Combined internal and external assessments covering both attack surfaces in a single engagement typically offer better value than running them as entirely separate projects because the reconnaissance and evidence collection phases overlap.
For a complete breakdown of what drives penetration testing costs across all scope types and how to assess whether a quote reflects genuine manual testing rather than automated scanning, our post on penetration test costs in 2026 covers the full pricing landscape in detail.
How Do You Choose the Right Internal Penetration Testing Provider?
Choosing the right internal penetration testing provider requires specifically evaluating their Active Directory expertise, their approach to attack chain development rather than isolated finding discovery, and their experience with the compliance frameworks relevant to the engagement. Internal penetration testing is a more specialized discipline than external testing, and the quality gap between providers is more pronounced.
The questions that separate genuine internal penetration testing expertise from generalist providers:
Can they describe specific AD attack techniques and when they apply? Ask specifically about their approach to Kerberoasting, delegation abuse, NTLM relay, and ACL-based privilege escalation. A provider who can discuss these techniques in detail and explain how they evaluate which apply in a given environment has genuine internal testing expertise. A provider who describes their methodology primarily in terms of scanning tools does not.
Do they develop attack chains rather than lists of individual findings? The value of an internal penetration test is not a catalogue of individual misconfigurations. It is a demonstrated path from standard user to domain administrator, documented step by step with exploitation evidence at each stage. Ask to see an example report structure. A report organized around an attack narrative provides a fundamentally different level of insight than a findings list organized by severity.
Do they include Active Directory-specific remediation guidance? Remediating an AD misconfiguration requires knowledge of how AD works and how specific changes affect the overall configuration. Generic advice like “review delegation settings” is not actionable. Specific guidance referencing the exact AD attribute to modify, the PowerShell command to verify the change, and the downstream implications of the remediation is what allows your IT team to act effectively on findings.
For a comprehensive evaluation framework covering all penetration testing provider selection criteria, our post on how to choose a penetration testing company in 2026 covers the specific questions to ask before committing to any engagement.
Does Internal Penetration Testing Cover Internal Web Applications?
Internal penetration testing that focuses on network infrastructure and Active Directory does not automatically cover internal web applications at the level of depth those applications warrant. Internal web applications, including internal portals, intranet sites, internal APIs, and admin panels accessible only from the internal network, have their own vulnerability classes, including authentication weaknesses, authorization failures, and injection vulnerabilities that require dedicated application testing methodology.
For organizations with significant internal web application environments, a combined engagement that covers both the network and Active Directory layer and the internal application layer produces more complete coverage than either assessment alone. Our web application penetration testing services are structured to address the application security layer that network-focused internal testing does not reach, and can be combined with network-layer internal testing in a single engagement.
For organizations with internal mobile device management environments or mobile applications accessible only on the internal network, our mobile app penetration testing services cover the device-side attack surface that network testing alone does not address.
Frequently Asked Questions
Is internal penetration testing the same as a vulnerability assessment?
No. A vulnerability assessment identifies and catalogues potential weaknesses across internal systems using automated scanning, without actively exploiting them. An internal penetration test actively exploits confirmed vulnerabilities, develops attack chains that link multiple findings together, and demonstrates realistic impact, including privilege escalation and lateral movement. Vulnerability assessments are efficient and repeatable. Internal penetration testing produces the depth and attack chain evidence that compliance auditors and security leadership specifically require.
Does internal penetration testing require physical presence on-site?
Not always. Internal penetration testing can be conducted remotely by providing the tester with VPN access to the internal network with appropriate credentials, which is functionally equivalent to being physically on the internal network for most assessment purposes. Some specific test scenarios, particularly those involving physical access or network device proximity, may benefit from on-site presence. Most standard internal assessments are conducted remotely without loss of effectiveness.
What is the difference between internal penetration testing and a red team exercise?
An internal penetration test is scoped, time-limited, and focused on finding and documenting vulnerabilities in the internal environment. The security team knows the test is happening. A red team exercise is objective-based, extended, and focused on testing whether detection and response capabilities would identify and stop an attacker pursuing a specific goal. In a red team exercise, the security team operates without knowing the attack is happening. Internal penetration testing provides foundational security evidence. Red teaming provides operational validation that the program works in practice.
What credentials should be provided for an internal penetration test?
The standard starting position for an internal penetration test is a single standard domain user account with no elevated privileges, which mirrors the access level a phished employee’s account would provide. Some engagements use multiple user accounts at different privilege levels to evaluate how the attack paths differ. The starting credentials should not include administrator-level access, as the assessment is specifically designed to test whether those privileges can be obtained rather than assuming them.
How long does an internal penetration test take?
A standard internal penetration test of a mid-market Active Directory environment takes five to ten business days for the testing phase. Larger environments with multiple sites, complex segmentation, and extensive cloud integration take ten to fifteen days. Report writing and debrief add two to four additional business days. Combined external and internal assessments covering both attack surfaces typically run two to three weeks in total for the testing phase.
The Question External Testing Cannot Answer
External penetration testing answers whether an attacker can break through the perimeter. It does not answer what happens next. An organization that has only ever tested its external perimeter knows its front door is locked. It does not know whether the hallways inside are open, whether a key to every room is sitting in an unlocked drawer, or whether anyone would notice an intruder who made it past the entrance and started exploring.
Internal penetration testing answers those questions. It demonstrates, using the same techniques a real attacker would use, what a compromised employee account enables. It shows whether the internal network is organized to limit the blast radius of a breach or whether a single foothold provides a highway to every sensitive system in the environment. It reveals whether Active Directory, the identity backbone of the enterprise, is configured to resist attack or to enable it.
The organizations that understand their internal security posture are the ones that have tested it. Understanding what an attacker could do from the inside is not a question that documentation, configuration reviews, or automated scanning can answer. It requires an adversarial test conducted by someone who knows how to find and exploit the specific weaknesses that internal networks consistently contain.
Contact us to discuss an internal penetration test for your organization
