Internal penetration testing is a security assessment that starts inside your network, from an ordinary employee device or account, and measures how far an attacker with a foothold can move, escalate and reach critical systems. It is a blast-radius measurement, not a perimeter measurement.
Quick answer: Buy an internal penetration test when you need evidence of what one phished account or compromised laptop reaches, and scope it by start positions, Active Directory and named segmentation pairs rather than a list of IP addresses. In Stingrai's own data, 8 internal network tests produced 408 verified findings, 92% of them High or Critical, and outdated or unpatched software made up 56.9% of them. Internal engagements are quoted to scope, against a 2026 market benchmark of US$5,000 to US$40,000 for a network test, delivered by Stingrai's certified penetration testers, with a quote returned within 24 hours of a Get a Quote request.
Internal vs external penetration testing
The full side-by-side comparison, with compliance requirements and which to buy first, is in our guide to internal vs external penetration testing. In short:
Internal testing begins from an assumed-breach position: already on the network, with no credentials or one ordinary user account. It deliberately does not model how the attacker got in, because real footholds arrive through a phished user, a contractor's unmanaged device, a reused VPN credential or an application that was never meant to reach the core. Our explainer on assumed-breach engagements covers the reasoning. External testing starts on the public internet with no credentials. The two answer different questions, and a clean result on one predicts nothing about the other.
Question | External penetration test | Internal penetration test |
|---|---|---|
Starting position | Public internet, no credentials | On the LAN or VLAN, as an unauthenticated device or a standard user |
Question it answers | What can an attacker reach before authentication? | How far does an attacker get after any foothold? |
Attack surface | Internet-facing services, edge appliances, remote access, mail and DNS, exposed apps | Every host, service, share, protocol and identity reachable from the start segment |
Dominant findings | Exposed management planes, edge patching, weak remote-access authentication | Outdated software, relay and name-resolution abuse, directory identity flaws, credential exposure, flat networks |
Stingrai data, Oct 2024 to Aug 2026 | 6 tests, 23 findings, median 1 per test, 48% High or Critical | 8 tests, 408 findings, median 11 per test, 92% High or Critical |
A clean result proves | Your front door is narrow | Your blast radius after a foothold is bounded |
PCI DSS v4.0.1 | Requirement 11.4.3: at least every 12 months and after significant change | Requirement 11.4.2: at least every 12 months and after significant change, plus segmentation testing under 11.4.5 |
How access is delivered | Remotely, from declared tester source addresses | On-site, a shipped device, a VM on the target subnet, or VPN landing inside the segment |
Common scoping failure | Shadow IT outside the ranges you supplied | Scope stops at a host list and never touches Active Directory |
Both belong in a mature programme, and some rules require both: New York's 23 NYCRR 500.5(a)(1) asks covered entities for penetration testing "from both inside and outside the information systems' boundaries" at least annually, per the DFS amendment text. When the budget forces an order, start external if your exposure is edge appliances and remote access, and start internal if you run a Windows domain, have had a phishing incident, or an auditor has asked for segmentation evidence. The perimeter half is covered in our guide to external penetration testing, and the two are usually bought together as internal and external network penetration testing.
What internal penetration tests find: Stingrai's 2026 data
Stingrai published the class mix of its own engagements in The State of Penetration Testing 2026, covering 55 penetration tests between October 2024 and August 2026. Split by test type, internal network work looks nothing like the rest of the corpus.
Internal network finding class (n = 408) | Share of findings |
|---|---|
Outdated or unpatched software | 56.9% |
Misconfiguration and hardening | 11.8% |
Injection | 10.5% |
Authentication and session | 8.6% |
Source: Stingrai penetration testing platform data, October 2024 to August 2026.
Three readings follow. Internal tests produce more findings than the other segmented test types, a median of 11 per test against 8 for web applications and 1 for external networks. Severity runs far higher: 92% of internal findings were rated High or Critical, against 54% for web application testing. And patch and lifecycle management is not one workstream among several; it is the majority of what an internal tester reports. Two cautions keep the figures honest. They come from 8 tests at one firm, and they count findings, so a large estate with hundreds of unpatched hosts weighs more than a small one. A finding count measures volume; the route to a domain administrator usually runs through the identity and protocol issues described below, which a count understates.
Where the tester starts, and why that choice changes the result
Each start position is a separate run of the methodology, so each costs money and each proves something different.
Start position | What the tester gets | What a clean result proves | When to choose it |
|---|---|---|---|
Unauthenticated on the user VLAN | A live drop, or a VM on the user subnet, no credentials | Device access alone yields no credentials and no privileged reach | The default. Best evidence of the first hours of an intrusion |
Standard domain user | One account provisioned exactly like a new joiner | An ordinary employee identity cannot escalate or reach data outside its role | The most informative single start. Mirrors the post-phishing reality |
Compromised workstation | A real managed laptop from your build, normal user logged in | Endpoint hardening, admin tiering and local privilege boundaries hold | When you want endpoint controls and detection in evidence |
Server or DMZ segment | Access from a server VLAN or DMZ host | A compromised internet-facing server cannot pivot into the core | Where the realistic entry point is an application, not a person |
Vendor, site or OT segment | Access from a third-party VLAN, branch or plant network | Partner and site networks cannot reach the core estate | Manufacturing, healthcare, multi-site retail, busy vendor VLANs |
The failure mode buyers rarely anticipate: an uncredentialed-only test in which the tester does not obtain credentials inside the time box returns a short, pleasant report that says nothing about Active Directory. That is an untested estate with a reassuring cover page.
The best value per dollar comes from a hybrid start. Begin uncredentialed, then hand over a standard domain account at a fixed checkpoint written into the rules of engagement, for example the end of day two. You get the honest answer about whether an unauthenticated device can bootstrap itself, plus full coverage of the identity layer where the serious findings live.
What is in scope, and what is explicitly out
A good scope names estates, not just addresses. The table below is close to a template you can lift.
Area | Default status | What it covers |
|---|---|---|
Host and service enumeration | In scope | Named CIDR ranges, live host discovery, service and version identification, patch posture |
Active Directory | In scope, name it explicitly | Domain and forest structure, trusts, object permissions, group nesting, delegation, Group Policy, admin tiering |
Authentication protocols | In scope | NTLM and Kerberos usage, LDAP binding and signing, SMB signing enforcement, name-resolution fallbacks |
File shares and data exposure | In scope | Share permissions, readable content, credentials and keys in shares, deployment artefacts |
Infrastructure services | In scope | Databases, hypervisor and backup management planes, print services, out-of-band and network device management |
Certificate services | Decide explicitly | Enterprise certificate authorities, template permissions, enrollment endpoints |
Segmentation | Decide explicitly | Named source-to-destination pairs against your written policy |
Password strength | Decide explicitly | Whether offline attacks on captured material are permitted, and what may be reported |
Detection and response | Decide explicitly | Whether the SOC is informed, and whether alert timelines are a deliverable |
Denial of service, destructive testing | Out by default | Never a default inclusion on a production internal test |
Social engineering, physical entry | Out by default | Separate engagements: phishing and physical assessment |
Third-party hosted systems | Out without written authorization | Anything you do not own needs the owner's signature, not yours |
OT and ICS devices | Out without a safety plan | Live plant and clinical devices need passive handling and an agreed protocol |
Settle four decisions before kickoff. Whether domain administrator is an objective and what happens after it is reached. How deep proof-of-access to sensitive data goes. Whether the tester may create or modify anything, and whether persistence is allowed. And whether endpoint agents get allowlisted, which should be no by default, because allowlisting the tester quietly converts a security test into a configuration review.
The finding classes behind internal attack paths
Patch debt dominates the count. These classes are the ones that turn a foothold into an attack path, and each has a configuration-level fix.
Finding class | What it is | What a test proves | Primary fix |
|---|---|---|---|
LLMNR, NBT-NS and mDNS poisoning | When DNS fails, Windows can ask the local segment to resolve a name and any device may answer | Presence on a VLAN alone yields authentication material | Disable the fallback protocols by policy, then fix the DNS records causing the fallback |
NTLM relay | Captured authentication is forwarded to a service that does not verify who it is talking to | Which services accept unsigned or unbound authentication, and what they reach | SMB signing, LDAP signing plus channel binding, Extended Protection for Authentication |
SMB signing not enforced | Message integrity is optional across much of the fleet, so relayed sessions are accepted | The exact host set that will accept relayed authentication today | Require signing on clients and servers; audit devices that cannot support it |
Kerberoasting and AS-REP roasting | Any domain user can request tickets for service accounts, and accounts without Kerberos pre-authentication hand out attackable material | How many service and legacy accounts have weak passwords, and what they reach | Group managed service accounts, long random passwords, AES only, pre-authentication re-enabled |
Certificate services misconfiguration (ADCS ESC family) | Templates letting a low-privileged enrollee name their own subject, or enrollment endpoints accepting relayed authentication | Which templates and endpoints are exposed, to whom, and how durable the access is | Remove requester-supplied subjects, require manager approval, enforce channel binding on enrollment |
Unconstrained delegation | A host caches the Kerberos ticket-granting ticket of everyone who authenticates to it | Which hosts are configured this way and whether privileged accounts touch them | Remove it, move to constrained or resource-based delegation, use Protected Users |
Over-permissioned directory objects | Rights granted years ago, inherited down an OU, or held by a group that has since grown | That a low-privileged principal can reset a password, add a member, or write to a privileged object | Review permissions as a graph, then strip legacy and inherited grants |
Local admin password reuse | The same local administrator password across an entire build image | That one compromised endpoint authenticates to the whole fleet | Windows LAPS, unique randomized password per host |
Over-permissioned file shares | Shares readable by Everyone or Authenticated Users holding scripts with passwords, config backups, keys and exports | Exactly what a standard user account can read across the estate | Permission cleanup, named owners, and removing secrets from shares entirely |
Flat networks and legacy protocols | The user VLAN reaches servers, backup and management planes; SMBv1, cleartext LDAP binds, default SNMP strings, no 802.1X | Reachability as it is, rather than as the diagram claims | Enforced segmentation, jump hosts for management planes, protocol retirement and 802.1X on wired ports |
Defaults have moved, but fleets have not. Microsoft's guidance is that SMB signing helps protect deployments "from relay and spoofing attacks", and per its SMB signing documentation Windows 11 version 24H2 Enterprise, Pro and Education require both outbound and inbound signing, Windows Server 2025 requires outbound signing only, and Windows 11 24H2 Home requires neither. New machines are protected; older ones are not, and the gap is where relay findings live.
The value of the report is the chain, not the count. A typical chain runs: presence on a segment yields authentication material, that material relays to a service that does not enforce signing, that access yields a credential store or a certificate, and that identity reaches a tier-zero asset or the backup platform. Every hop has a control that would have broken it, and a good report names it. Stingrai's penetration testers maintain StingAD, an open-source (Apache 2.0) Go toolkit for authorized Active Directory assessments that runs from one low-privilege account and checks, among other things, SMB and LDAP signing, delegation, certificate templates, Kerberoastable and AS-REP roastable accounts and LAPS coverage, with text, JSON or CSV output. Our walkthrough of a low-privilege account reaching Domain Admin shows the hops in practice, and the same checks tell a defender which settings to fix first. In a Windows-heavy estate, scope Active Directory security testing as a named component rather than hoping it is implied.
Segmentation validation: the part buyers under-scope
Segmentation testing is a matrix, not a search, and the component most often omitted from a scope then requested by an auditor. You declare the intended policy in writing; the tester records what is actually reachable, pair by pair, with evidence.
Source segment | Destination | Intended policy | What the test records |
|---|---|---|---|
User VLAN | Regulated or cardholder segment | No access | Reachable ports and protocols, and any authenticated access achieved |
Guest Wi-Fi | Corporate VLAN | No access | Whether any route or service is reachable at all |
Vendor or third-party VLAN | Server VLAN | Named ports only | The actual reachable set against the named set |
Server VLAN | Hypervisor and backup management | Via jump host only | Whether direct paths bypass the jump host |
Branch site | Core site services | Named services only | Reachability and authentication outcome per service |
Any segment | Out-of-band management network | No access | Reachability of management interfaces from user space |
Bring that matrix with you. If nobody can produce it, the first days of the engagement become documentation archaeology at tester day rates.
Be precise about compliance. PCI DSS v4.0.1 treats internal testing (Requirement 11.4.2, at least every 12 months and after significant change) and segmentation testing (Requirement 11.4.5, at least every 12 months and after any change to segmentation controls) as separate obligations, with Requirement 11.4.6 moving service providers to a six-month segmentation clock; our PCI DSS penetration testing guide walks through Requirement 11.4. CMMC mandates penetration testing only at Level 3, and Level 3 cannot currently be designated after the July 2026 suspension memo; see does CMMC require penetration testing. ISO 27001, SOC 2, NIST SP 800-171 and NIS2 do not mandate it. Our breakdown of which pentest evidence auditors accept works through the clause text. Stingrai's testing supports these programmes by producing the evidence.
What the deliverable contains
Ask for a redacted sample before you sign, and check it against this list.
Executive summary in business language, naming the worst realistic outcome demonstrated and how many steps it took.
Attack path narratives, one per chain, every hop annotated with the control that would have broken it.
Finding register with contextual severity rather than a raw base score, the affected host list, evidence, and remediation at configuration level: the exact policy, setting, template or group, not "apply vendor best practice".
Segmentation matrix results, intended policy against actual reachability, pair by pair.
Credential exposure appendix, delivered on a separate secure channel, with a stated destruction date.
Detection and response timeline, recording what alerted, what did not, and when.
Prioritized remediation plan split into quick wins, structural work such as admin tiering or a LAPS rollout, and monitoring improvements.
Retest scope and a summary letter for customers, insurers and auditors. Our comparison of a completion letter versus the full report explains what each audience should get, and the penetration testing report sample walks through a real internal network report page by page.
Internal penetration testing cost and duration
Internal engagements are scoped individually. The same host count can describe a single-domain single-site environment or a four-domain forest across nine sites, and those are not the same job.
Cost driver | Why it moves effort | What to state in your RFP |
|---|---|---|
Live host count and ranges | Enumeration scales with real hosts, not allocated space | Exact CIDRs plus a live-host estimate |
Subnet and VLAN count | Each segment adds discovery and reachability testing | The VLAN list, and which pairs you want proven |
Active Directory footprint | Domain and forest count, trusts and object counts drive the identity work | Domain and forest names, user and computer counts, trusts |
Certificate services | Template and enrollment review is a distinct workstream | Whether enterprise certificate authorities are in scope |
Physical sites | Each site needs its own start position and logistics | Site count and whether each requires testing |
Start positions purchased | Each start is a fresh run of the methodology | List them, with any handover checkpoints |
Adjacent estates | Backup, virtualization, endpoint management, Linux and macOS fleets, network devices, OT adjacency | Name each one in or out |
Evasive versus open testing | Evasion buys realism and costs coverage, because quiet work is slower | Whether the SOC is informed |
Retesting | Verifying fixes is separate effort from the original test | How many retests, and in what window |
Stingrai's 2026 market benchmark puts a network penetration test at about US$5,000 to US$40,000, with host count and internal scope moving it most; the full breakdown is in our penetration testing cost guide. Published day counts show the same spread. On 25 October 2026, EJN Labs listed an internal network test of up to about 150 hosts at 1 to 3 days and £1,200 to £3,600, and Precursor Security listed 5 to 8 days and £6,250 to £10,000 or more at about £1,200 a day. Same rate, different scope: our guide to day rates explains why quotes diverge.
As shapes rather than prices: a single site, one domain, a few hundred live hosts and one or two start positions is commonly around a working week of field time plus reporting and quality assurance. Two or three sites with several hundred to a couple of thousand hosts and a segmentation matrix runs materially longer. A multi-domain forest across many sites with certificate services, backup and virtualization in scope is usually phased. A quote far below the shape of your environment buys less coverage, and field time is not calendar time.
Stingrai's published Autonomous (US$3,000) and Hybrid (US$6,800) prices on the pricing page cover one web application and associated APIs, so they are not a proxy for a network price; internal engagements are quoted through Get a Quote. Snipe, Stingrai's autonomous agent, tests web applications and associated APIs, and AI and LLM applications. Internal network and Active Directory work is human-led, delivered by two named penetration testers from a team holding OSCE³, OSEP, OSWE, CREST CRT and CISSP certifications, at a firm CREST-accredited as a penetration testing service provider. Our guide on comparing penetration testing quotes helps line several up side by side.
What you must prepare before day one
Most delayed internal tests are delayed by a missing item from this list. Also state crown jewels in business terms: "reach the payment processing environment" beats "get domain admin".
Item | What you actually need | Why it matters |
|---|---|---|
Authorization | Signed rules of engagement approved by someone with authority over every in-scope network, plus written authorization from any hosting or managed service provider | Testing systems you do not own is not covered by your signature |
Access | A live drop on the correct VLAN at each site, a VM on the target subnet, a device the tester ships you, or VPN landing on a routed address inside the segment | Two days of connectivity troubleshooting is two days of lost testing |
Accounts | One or two standard domain accounts provisioned exactly like a real new joiner, released at the agreed checkpoint | A "pentest account" with extra rights describes an environment that does not exist |
Constraints | Documented exclusions with reasons, blackout windows, and a decision on endpoint agent allowlisting | Undocumented exclusions become disputes; undocumented allowlisting becomes a misleading report |
Inventory and intent | In-scope CIDRs with a live-host estimate, a VLAN map, domain and forest names, and the intended segmentation matrix | Accurate scope is the difference between a precise quote and a padded one |
Data handling | How credentials, hashes and evidence are stored, transmitted and destroyed, and who receives the report | Agree it before the tester holds anything sensitive, not after |
How to tell a real internal test from an authenticated vulnerability scan
Authenticated vulnerability scanning is a legitimate control, but a different one, and it is regularly sold as a penetration test.
Signal | Authenticated vulnerability scan | Real internal penetration test |
|---|---|---|
Primary output | Per-host list of missing patches and configuration deviations, sorted by base score | Attack path narratives showing chained findings and demonstrated impact |
Identity layer | Not examined, or reported as generic configuration items | Object permissions, delegation, group nesting, service accounts and certificate templates analysed as a graph |
Relay and name resolution | Flagged as a setting, if at all | Demonstrated end to end, with the reachable service set enumerated |
Segmentation | Not tested | Verified pair by pair against your written policy, with evidence |
Severity | Base score from a vulnerability database | Contextual, reflecting exploitability and reachability in your environment |
Five red flags in a proposal. A price quoted purely per IP address with no discussion of your domain, sites or segments. No mention of a starting position anywhere. A sample report that is a tool export with a cover page. No named tester and no way to ask about their certifications. And any variant of "we will run a credentialed scan and manually validate", which describes scan triage. Our comparison of red team versus penetration test versus continuous validation draws the boundaries when the real question is detection rather than coverage.
Frequently Asked Questions
What is internal penetration testing?
Internal penetration testing is a security assessment that starts inside your network, on the same LAN or VLAN as an ordinary employee device, with no credentials or one standard user account. It measures how far an attacker moves after any foothold rather than whether the perimeter can be breached. The output is a set of attack paths showing what a starting position reaches and which control would have stopped each step.
What is the difference between internal and external penetration testing?
An external test starts on the public internet with no credentials and assesses internet-facing services, edge appliances, remote access and exposed applications. An internal test starts inside the network and assesses everything reachable from that position, including Active Directory, file shares, infrastructure services and segmentation. In Stingrai's data, internal tests returned a median of 11 findings with 92% High or Critical, against a median of 1 and 48% for external tests, so a clean external result says nothing about how far someone gets after a phished laptop.
How much does an internal penetration test cost?
Internal engagements are scoped and priced individually, because cost is driven by live host count, VLAN and site count, Active Directory footprint, how many starting positions you buy, and which adjacent estates are in scope. Stingrai's 2026 market benchmark puts a network penetration test at about US$5,000 to US$40,000. Send CIDR ranges, site count, domain and forest names and your intended segmentation matrix with the quote request, and treat a flat rate offered before anyone asks about your domain as the price of a scan.
How long does an internal penetration test take?
Field time for a single site with one Active Directory domain and a few hundred live hosts is commonly around a working week, and larger multi-site or multi-domain environments run considerably longer and are often phased. Field time is not calendar time: add scheduling lead time, access provisioning, reporting and quality review, the readout, then remediation and retest. Book well ahead of any audit or board deadline the result has to meet.
What does an internal penetration test usually find?
By count, outdated or unpatched software dominates: it was 56.9% of 408 internal network findings in Stingrai's 2026 data, followed by misconfiguration and hardening at 11.8%, injection at 10.5% and authentication and session at 8.6%, with 92% rated High or Critical. The attack paths that reach domain administrator usually run through name-resolution poisoning, NTLM relay against hosts that do not enforce signing, Kerberoastable service accounts, misconfigured certificate templates, local administrator password reuse and flat networks. The finding that changes decisions is the chain, not the count.
Should the testers get a domain account or start blind?
Give them both, at different times. The most informative structure is to start uncredentialed and hand over one standard domain account, provisioned exactly like a real new joiner, at a checkpoint written into the rules of engagement. An uncredentialed-only test that fails to obtain credentials inside the time box produces a short reassuring report and leaves your Active Directory estate untested.
Does PCI DSS require internal penetration testing?
Yes. PCI DSS v4.0.1 requires internal penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change under Requirement 11.4.2, and separately requires segmentation testing at least every 12 months and after any change to segmentation controls under Requirement 11.4.5, with service providers on a six-month clock under Requirement 11.4.6. NYDFS 23 NYCRR 500.5 asks for testing from both inside and outside the system boundaries at least annually. ISO 27001, SOC 2, NIST SP 800-171 and NIS2 do not mandate penetration testing.
Related reading
Internal vs external penetration testing: differences, scope and cost
The State of Penetration Testing 2026: an analysis of 1,206 verified findings
Active Directory security assessment: what it covers and what it finds
Assumed breach engagements: when to start the test from inside
Wi-Fi penetration testing: wireless security assessment scope and cost
Talk to Stingrai
Scoping an internal penetration test against what this guide covers takes one short conversation. Stingrai is a CREST-accredited penetration testing company, accredited for both Penetration Testing and AI-Enabled Penetration Testing, offering fully human-led and hybrid (human penetration testers plus AI agents) penetration tests, delivered by experienced penetration testers who are also world-class security researchers and bug bounty hunters, with OSCE³, OSWE, OSEP and CREST CRT certifications across the team. Founded in Toronto, Canada in 2021, it is trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA, with engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements. Internal network work is human-led and delivered one-time or as a continuous programme, with findings posted to the PTaaS portal as they are confirmed, live chat with the assigned penetration testers, retesting of remediated findings, and an attestation letter with every human-led report. The internal and external network penetration testing team will tell you which parts of your scope will not produce useful evidence before anyone signs. Book a free scoping call, get a quote, or read the published pricing.
