An internal network penetration test starts inside your network, on the same wire or VLAN as an ordinary employee laptop, and answers one question: if an attacker gets a foothold, how far do they get, how fast, and what stops them. It is a blast-radius measurement, not a perimeter measurement.
Buyers usually arrive here after a clean external test, after an auditor or insurer asked whether internal testing happens, or after an incident elsewhere prompted the board to ask how far one phished laptop would get. All three go wrong the same way: the scope is written as a list of IP addresses, the tester spends the engagement enumerating hosts, and the report arrives as a patch list instead of an attack path. Read this and you should be able to draft your own scope document.
What "internal" means, and why a clean external test predicts nothing
Internal means the tester begins from an assumed-breach position: already on the network, with either no credentials or one ordinary user account. The test deliberately does not model how the attacker got there, because real footholds arrive through a phished user, a contractor's unmanaged device, a reused VPN credential, an unattended port, or an application that was never meant to reach the core. You do not need to relitigate the entry route to price the consequence. Our explainer on assumed-breach engagements covers the reasoning.
A clean external result predicts nothing internally because the environments differ structurally. Your perimeter is a small number of deliberately chosen, hardened, monitored services. Your internal estate is fifteen years of accumulated trust relationships, service accounts nobody can decommission, shares with no owner, and protocols left enabled for one printer. Perimeters get narrower every year; internal estates only get wider.
Question | External test | Internal test |
|---|---|---|
Starting position | Public internet, no credentials | On the LAN or VLAN, unauthenticated device or standard user |
Attack surface | Internet-facing services, remote access, exposed apps | Every host, service, share, protocol and identity reachable from the start segment |
Dominant findings | Forgotten services, weak remote-access authentication, edge patching | Relay and name-resolution abuse, directory identity flaws, credential exposure, flat networks |
A clean result proves | Your front door is narrow | Your blast radius after any foothold is bounded |
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, which is why they are usually bought together as internal and external network penetration testing.
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: you buy an uncredentialed test only, the tester does not obtain credentials inside the time box, and you receive a short, pleasant report that says nothing about your Active Directory estate. That is not a clean bill of health. It is an untested estate with a reassuring cover page.
The best value per dollar comes from a hybrid. 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.
What an internal network penetration test actually finds
These classes account for the large majority of real internal findings, year after year.
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 | Any domain user can request a ticket for accounts holding a service principal name, encrypted with that account's password key | How many service accounts have weak or ancient passwords, and what they reach | Group managed service accounts, long random passwords, AES only, remove stale principal names |
AS-REP roasting | Accounts with Kerberos pre-authentication disabled hand out attackable material to anyone who asks | Whether such legacy accounts exist and whether their passwords survive offline attack | Re-enable pre-authentication. Usually a handful of accounts |
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 | The user VLAN reaches servers, backup, hypervisor management and network device management | Reachability as it is, rather than as the diagram claims | Enforced segmentation and jump hosts for management planes |
Legacy protocols and no NAC | SMBv1, cleartext LDAP binds, Telnet, FTP, default SNMP community strings, unauthenticated out-of-band management, no 802.1X | The connective tissue that turns minor issues into a full attack path | Protocol retirement programme and 802.1X on wired ports |
Two things follow. Defaults have moved but fleets have not: Microsoft's guidance is that SMB signing helps protect deployments "from relay and spoofing attacks", and Windows 11 version 24H2 Enterprise, Pro and Education require both outbound and inbound signing, while Windows Server 2025 requires outbound only and Windows 11 Home requires neither. New machines are protected, older ones are not, and the gap is where relay findings live.
And 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. Our walkthrough of a low-privilege account reaching Domain Admin shows the hops in practice. If your estate is Windows-heavy, 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 it is the component most often omitted from a scope then requested by an auditor three weeks later. 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 senior tester rates.
Be precise about compliance. PCI DSS v4.0.1 is the framework that mandates penetration testing across a general population, and it 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. CMMC mandates penetration testing at Level 3 only. ISO 27001, SOC 2, NIST SP 800-171 and NIS2 do not mandate it, and ISO 27001 and SOC 2 set no frequency, so any cadence there comes from your own policy or a customer contract. 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 our guide to evaluating a pentest report is built for reviewing that sample.
Duration, cost and what actually drives them
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 |
Logistics | On-site presence, a shipped device, or a jump box you provision | Preferred access method per site |
Effort bands help sanity-check a quote if you treat them 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. If a quote sits far below the shape of your environment, the difference is coverage. Field time is also not calendar time: add scheduling lead time for senior testers, access provisioning, reporting and quality review, the readout, then remediation and retest.
For pricing, start at the Stingrai pricing page and request a quote for the network engagement. The published autonomous and hybrid tiers there are scoped to web application testing, so they are not a proxy for a network price. Our guide on comparing penetration testing quotes helps line several up side by side.
One clarification, because vendors blur it. Snipe, Stingrai's autonomous agent, performs web application penetration testing, hunting complex flaws such as IDOR, broken authorization and business logic bugs. It does not test networks, Active Directory, Wi-Fi, physical security or people. Internal network work is delivered by senior human testers holding certifications including OSCE3, OSCP, OSWE, OSEP, CREST CRT, CISSP and CRTO, at a firm CREST-accredited as a penetration testing service provider, with 18 published CVEs and 5.0 out of 5.0 across 19 Clutch reviews. Stingrai was founded in 2021 and works from Toronto and London.
What you must prepare before day one
Most delayed internal tests are delayed by the client, almost always by one of these.
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 |
Contacts | Named technical contacts on both sides during test hours, plus an out-of-hours escalation path | Nobody should be guessing who to call when a fragile host misbehaves |
Constraints | Documented exclusions with reasons, blackout windows such as month-end close or a DR test, 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 |
Objectives | Crown jewels stated in business terms | "Reach the payment processing environment" beats "get domain admin" |
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. It is simply 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 |
Evidence | Plugin output | Host-to-host proof, redacted artefacts, timestamps, reproduction detail |
Effort mix | Predominantly tool runtime | Predominantly human analysis, with tooling used for coverage |
Retest | A rescan | Targeted verification of the specific proven path |
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. If you are weighing which engagement answers your question, our comparison of red team versus penetration test versus continuous validation draws the boundaries.
When your scope document is ready, take it to a provider who will argue with it. The internal and external network penetration testing team at Stingrai will tell you which parts will not produce useful evidence, and where the budget is better spent, before anyone signs.
Frequently Asked Questions
What is internal network penetration testing?
Internal network penetration testing begins from an assumed-breach position inside your network, on the same LAN or VLAN as an ordinary employee device, with either 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.
How much does an internal network penetration test cost?
Internal network 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. There is no meaningful flat rate, and a provider quoting one before asking about your domain structure and segments is pricing a scan. Send CIDR ranges, site count, domain and forest names and your intended segmentation matrix with the quote request.
How long does an internal network 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 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, 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. A clean external result says your front door is narrow; it says nothing about how far someone gets after a phished laptop.
What does an internal network penetration test usually find?
The dominant classes are name-resolution poisoning through LLMNR, NBT-NS and mDNS, NTLM relay against services that do not enforce signing, Active Directory identity flaws such as Kerberoasting, AS-REP roasting, unconstrained delegation and misconfigured certificate templates, local administrator password reuse across a fleet, file shares readable by everyone that hold credentials, and flat networks where the user VLAN reaches backup and hypervisor management. Unpatched hosts appear too, but they are rarely the path that matters. The finding that changes decisions is the chain, not the count.
Should I give the testers a domain account or make them 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.
Is an internal penetration test the same as an authenticated vulnerability scan?
No. An authenticated scan produces a per-host list of missing patches and configuration deviations sorted by base score, and does not analyse object permissions, delegation, service accounts, certificate templates or segmentation. An internal penetration test chains findings into demonstrated attack paths with contextual severity and evidence, and verifies segmentation pair by pair against your written policy. Both are useful controls, but they are not substitutes.
Does PCI DSS require internal network 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 testing of segmentation controls at least every 12 months and after any change to those controls under Requirement 11.4.5, with service providers moving to a six-month clock under Requirement 11.4.6. CMMC mandates penetration testing at Level 3 only. ISO 27001, SOC 2, NIST SP 800-171 and NIS2 do not mandate penetration testing, and ISO 27001 and SOC 2 set no frequency.
