Internal Pentest Methodology: What to Expect

Most organizations focus their security budget on the perimeter-firewalls, WAFs, external port scans. That’s a reasonable starting point, but it sidesteps the more dangerous question: what happens once an attacker is already inside?

According to the Verizon Data Breach Investigations Report, phishing, stolen credentials, and compromised endpoints are consistently among the top initial access vectors. Once an attacker has a foothold on your internal network-whether through a phishing email, a credential dump, or a compromised vendor-your perimeter controls become irrelevant. The attack surface expands dramatically from there.

Internal network penetration testing simulates exactly that scenario. A tester with a foothold on your network acts like a real attacker: enumerating systems, harvesting credentials, escalating privileges, and moving laterally until they reach your crown jewels-or demonstrate they can’t. This post walks through what that process looks like in practice, why it matters more than external scanning alone, and what a rigorous engagement actually delivers to your team.

What Internal Network Penetration Testing Actually Tests

Internal network penetration testing isn’t a vulnerability scan relabeled. The goal isn’t to produce a CVE list-it’s to determine what an attacker can accomplish with internal access. That distinction changes everything about how the engagement is run and what it finds.

Why Perimeter-Only Testing Leaves You Exposed

External pentests and perimeter scans are valuable, but they only answer whether your front door is locked. They can’t tell you:

• Whether a compromised workstation can reach your domain controller over port 445
• Whether a junior employee’s domain credentials can be used to extract the NTDS.dit password database
• Whether SMB signing is disabled across your fleet, enabling relay attacks without cracking a single password
• Whether misconfigured Group Policy or certificate templates give an attacker a path to Domain Admin in under two hours

Real breaches don’t end at the perimeter. Threat actors pivot-sometimes for weeks or months before taking action. An internal pentest tests that pivot explicitly, measuring how far an attacker gets once they’re past the front door.

The Assumed-Breach Model

Most internal engagements operate under an assumed-breach model: the tester starts with a foothold inside the network, typically a standard domain user account and a machine on the domain, simulating a phished or otherwise compromised employee. From that position, everything within scope is fair game.

Some engagements run a “zero-knowledge” variant instead, where the tester begins with only network access and no credentials-testing whether unauthenticated internal access alone is sufficient to escalate to Domain Admin. Both are valid approaches. The right choice depends on what threat scenario your organization is most concerned about.

The Internal Pentest Methodology: Phase by Phase

A rigorous internal pentest follows a structured methodology. Shortcuts in any phase produce incomplete results. Here’s what each stage involves and why it matters.

The 8-Phase Internal Pentest Process

1. Scoping and Rules of Engagement

Before anything touches the network, the engagement scope is defined precisely. This includes which IP ranges and systems are in scope, what’s explicitly off-limits (production databases, OT/ICS environments, business-critical services), authorized testing hours, emergency escalation contacts, and signed authorization documentation. Vague scoping causes problems downstream-either critical systems get excluded unnecessarily or testers avoid important areas out of caution.

2. Network Discovery and Enumeration

With access established, testers map the environment. Nmap sweeps identify live hosts, open ports, running services, and OS fingerprints. LDAP and SMB queries enumerate domain users, groups, computers, shared folders, and trust relationships. NetBIOS traffic reveals additional host information. The output of this phase is an accurate attack surface map before any exploitation occurs.

3. Service and Vulnerability Identification

Once the network is mapped, testers identify exploitable conditions. This includes unpatched services with known CVEs, deprecated protocols (SMBv1, NTLMv1, LLMNR), misconfigured file shares, weak Kerberos delegation settings, and Active Directory Certificate Services misconfigurations. Automated scanners (Nessus, OpenVAS) assist, but they miss configuration-based vulnerabilities that experienced testers identify by reading service banners, reviewing GPO output, and querying AD directly.

4. Exploitation of Identified Weaknesses

Testers now attempt to exploit identified conditions to gain higher-privilege access. Responder captures Net-NTLMv2 hashes through LLMNR/NBT-NS poisoning when other machines broadcast credential requests on the local segment. Weak passwords are cracked offline using hashcat against captured hashes. Services running as SYSTEM with writable binary paths become targets for privilege escalation. The aim at this stage is gaining a more privileged foothold to enable the next phase.

5. Post-Exploitation and Privilege Escalation

With elevated access, testers extract credentials from memory and the file system. Mimikatz and Impacket’s secretsdump pull NTLM hashes and Kerberos tickets from LSASS. CrackMapExec (now maintained as NetExec) tests extracted credentials across the entire subnet in parallel, identifying which systems accept the same local admin password-a remarkably common misconfiguration. Kerberoastable service accounts are identified and their tickets are cracked offline. AS-REP roasting targets accounts where Kerberos pre-authentication is disabled, a condition that allows any unauthenticated user to request an encrypted response that can be cracked without any prior access.

6. Lateral Movement and Domain Compromise Simulation

Pass-the-Hash (PtH) and Pass-the-Ticket (PtT) techniques allow movement across systems without ever knowing a plaintext password. BloodHound ingests Active Directory data via SharpHound and maps all relationships between users, groups, computers, and ACL permissions-then identifies the shortest attack path to Domain Admin. If DCSync rights can be obtained (directly or through privilege escalation), the tester replicates all password hashes from AD, including the krbtgt hash. That represents full domain compromise.

7. Evidence Collection and Cleanup

Throughout the engagement, testers document every action: timestamps, tool output, screenshots proving successful exploitation, and data accessed. At the end of the engagement, any tools, scripts, or artifacts dropped on systems are removed. The environment is left in the same state it was found-minus any discovered weaknesses your team now knows about.

8. Report Delivery and Debrief

The final report covers the full attack narrative, all findings with contextual risk ratings, and specific remediation steps. A debrief call with your technical team walks through the findings, answers questions, and helps prioritize the remediation backlog. Good pentest firms don’t just hand you a PDF and disappear.

Active Directory Penetration Testing

For most enterprise environments, Active Directory is the central target inside the perimeter. Control the domain, and you control everything attached to it. Most internal pentests-regardless of what else they find-converge on the domain controller as the primary objective.

Why AD Is the Primary Attack Surface

Active Directory manages authentication and authorization for every domain-joined system in the environment. A Domain Admin compromise, or the ability to forge Kerberos tickets using a stolen krbtgt hash (a Golden Ticket attack), gives an attacker persistent, near-undetectable access across the entire organization. This is why network penetration testing that skips AD-specific testing is fundamentally incomplete.

Common Active Directory Attack Paths

Kerberoasting: Any authenticated domain user can request Kerberos service tickets for accounts with registered Service Principal Names (SPNs). Those tickets are encrypted with the service account’s password hash. Offline cracking with hashcat can break weak passwords in minutes to hours-and service accounts frequently have weak passwords and rarely rotate.

AS-REP Roasting: Accounts with Kerberos pre-authentication disabled (the DONT_REQ_PREAUTH flag) return an encrypted AS-REP to any requestor, no password required. Testers enumerate these accounts via LDAP and crack the encrypted responses offline. This attack requires no initial credentials in a zero-knowledge scenario.

NTLM Relay Attacks: When SMB signing isn’t enforced across the environment-which is the default on domain workstations (though not domain controllers), NTLM authentication requests can be captured and relayed to other systems. Combining Responder with ntlmrelayx can convert a low-privilege network position into local administrator access on multiple machines without ever cracking a password.

BloodHound Attack Path Analysis: BloodHound ingests Active Directory data and maps every relationship between objects, user memberships, ACL permissions, session data, trust paths. It then identifies the shortest chain from a low-privilege account to Domain Admin. These paths routinely run through innocuous-looking misconfigurations: a help desk group with GenericWrite on a privileged service account, or an OU that delegates FullControl to an IT group that includes shared service accounts.

AD CS Misconfigurations (ESC1–ESC8): Active Directory Certificate Services attack paths, documented by SpecterOps researchers, represent one of the most impactful classes of AD vulnerabilities. Misconfigured certificate templates can allow any authenticated user to request a certificate that authenticates as a Domain Admin, often without triggering a single alert. If your AD CS deployment hasn’t been reviewed against the ESC vulnerability classes, assume it’s exploitable.

DCSync: Once a tester holds an account with domain replication privileges (DS-Replication-Get-Changes-All), whether granted directly or obtained through ACL abuse, they can simulate a domain controller and pull all password hashes from Active Directory. At that point, the engagement has achieved complete domain compromise.

According to NIST SP 800-115, penetration testing should explicitly include tests against authentication systems and privilege escalation paths. Active Directory attacks satisfy both requirements and represent the highest-impact findings in most internal engagements.

Lateral Movement Testing

Lateral movement is how attackers expand their reach after initial access. It’s the phase where point-in-time compromises become organization-wide breaches. Testing it explicitly, rather than inferring it from CVE severity scores, is what separates internal penetration testing from passive scanning.

What Lateral Movement Actually Looks Like

Attackers don’t stay on the first machine they compromise. They move:

• From a phished developer’s workstation to a CI/CD build server with access to source code and secrets
• From a compromised domain service account to a file server storing PII or intellectual property
• From a misconfigured network share to a backup server holding AD snapshots and credential stores
• From a network device management panel to the management VLAN, eliminating segmentation as a control

The central question an internal pentest answers is: starting from a single compromised endpoint or credential, how far can an attacker move, and what can they access when they get there?

Techniques Testers Use

Pass-the-Hash (PtH): NTLM hashes extracted from one system authenticate directly against others without knowing the underlying plaintext password. If the same local administrator password hash appears across multiple workstations, a persistent misconfiguration in environments that haven’t deployed LAPS, one compromised machine opens access to all of them.

Pass-the-Ticket (PtT): Kerberos tickets stored in memory can be exported from a compromised system and injected into another session using Rubeus or Mimikatz. This lets a tester impersonate an authenticated user against any service that ticket is valid for, without touching domain controller authentication again.

Token Impersonation: If a privileged user is logged into a machine the tester controls-common on shared servers or jump boxes, their security tokens can be impersonated through Windows API calls, achieving local privilege escalation without any exploitation.

Credential Harvesting at Scale: NetExec (formerly CrackMapExec) automates credential spraying, pass-the-hash, and pass-the-ticket attempts across entire subnets simultaneously. It maps which systems accept a given set of credentials in minutes, converting a single credential pair into a complete reachability map across the internal network.

Internal Vulnerability Assessment vs. Penetration Testing

These two are frequently conflated in procurement conversations and compliance discussions. They’re fundamentally different engagements that answer different questions.

A vulnerability assessment tells you what the holes are. A penetration test tells you what a real attacker can accomplish by walking through them. They’re complementary, not interchangeable.

Most mature programs run both: quarterly or monthly vulnerability assessments for operational hygiene, and an annual or biannual internal network penetration test to validate that controls actually prevent an attacker from reaching sensitive systems. Compliance frameworks increasingly require both.

What to Expect in Your Deliverables

Deliverable quality varies significantly between firms. A report that lists CVEs and CVSS scores without context isn’t useful to your engineering team and won’t pass scrutiny from a serious auditor. Here’s what a rigorous internal pentest report should contain.

The Attack Narrative

The report should open with an attack narrative: a clear, chronological walkthrough of how the tester moved through the environment, what they compromised at each stage, and what data or systems they were able to access as a result. This section should be readable by both technical staff and non-technical stakeholders such as your CISO or board-level contacts without losing accuracy.

Findings with Contextual Risk Ratings

Raw CVSS scores without context mislead remediation prioritization. Every finding should include:

• Technical description: What the vulnerability or misconfiguration is, precisely
• Evidence: Screenshots, command output, and proof-of-concept demonstrating successful exploitation
• Contextual risk rating: CVSS adjusted for your environment. A critical CVE on an isolated, non-networked system is lower priority than a medium-severity misconfiguration that chains to Domain Admin in three steps
• Business impact: What an attacker who exploited this finding could access, exfiltrate, or destroy
• Remediation guidance: Specific, actionable steps, not “apply vendor patches” or “implement least privilege”

Attack Path Diagrams

BloodHound visualizations and manual attack path diagrams help your engineering team understand how individual findings chain together. Remediation decisions change when the conversation shifts from “we have a medium-severity Kerberoasting exposure” to “these three medium-severity findings combine to give an attacker Domain Admin in under four steps.”

Remediation Verification

The best firms offer a retest after your team addresses the critical and high findings, confirming fixes work as intended and that no new issues were introduced. This step is often undervalued and frequently skipped when organizations treat pentesting as a compliance checkbox rather than a security program input.

CISA’s cybersecurity resources also emphasize that testing alone isn’t sufficient, organizations need a clear remediation loop that closes the gap between findings and fixes.

See our penetration testing services page for what’s included in each engagement tier, including retest options and reporting formats.

Conclusion

An internal network penetration test answers the question your firewall can’t: once an attacker has a foothold, how far do they get?

In most environments, the answer is sobering. Lateral movement to Domain Admin within a few hours. Credential access to file servers, backup systems, and CI/CD pipelines. Attack paths that no automated scanner would flag because they run through Active Directory logic, not missing patches. And organizations that thought their segmentation was working discovering it wasn’t.

If your security program relies on perimeter controls and periodic vulnerability scans without validating what happens after a breach, you’re measuring the wrong thing. External hardening tells you about one side of the attack surface. Internal testing tells you about the damage radius when, not if, something gets through.

Book a free scoping call to define the right scope for your environment, understand your realistic threat model, and get a fixed-price proposal with no surprises.