Internal Network Penetration Testing: Scope and Method

Most serious intrusions are decided after the attacker is already inside, when one ordinary foothold turns into domain administrator through weak service account passwords, legacy name resolution, unsigned SMB and flat networks. An internal network penetration test measures exactly that journey under controlled conditions: how far a tester starting from a standard laptop or a compromised user account can get, how quickly, and whether anyone notices. This guide goes deeper than the general Penetration Testing Guide on one test type. It covers starting positions, scope and rules of engagement, the phases of a sound method, the findings that recur in almost every Windows estate, what evidence to demand, and how to turn the result into measurable improvement. It is written for security managers who commission internal tests, in-house testers, and the infrastructure and identity teams who fix what is found. It does not describe attack tooling or techniques step by step.

Key takeaways

Assume the breach and start realistically. Give the tester the foothold an attacker would most likely get, a standard user laptop or account, rather than spending paid days proving that phishing works.
Identity is the real target. Internal tests are won or lost in Active Directory, Entra ID and service accounts; scope directory paths, trusts and certificate services explicitly.
The same misconfigurations keep winning. NSA and CISA red and blue team work lists default configurations, poor privilege separation, flat networks, unsigned SMB and poor credential hygiene among the ten most common weaknesses.
Measure detection as well as compromise. Agree in advance that the SOC will log what it saw and when, so the report shows the gap between the tester's timeline and the defenders' timeline.
Fix paths, not just findings. A chain of four medium findings that ends in domain compromise is the headline; break the chain at the cheapest durable point and retest it.

What an internal test covers and how it differs

An internal network penetration test simulates an attacker who already has some access inside the corporate network, either through a compromised endpoint, stolen credentials or a device plugged into a wired port. The tester tries to discover hosts and services, gather credentials, escalate privileges, move laterally and reach agreed objectives such as domain administrator rights, a payment environment or a crown jewel data store. NIST SP 800-115 frames technical testing as planning, discovery, attack and reporting, and the internal test follows that shape with far more emphasis on identity and lateral movement than an external test. See the External Network Penetration Testing Guide for the perimeter equivalent.

Activity	Question it answers	Starting position	Typical output
Internal vulnerability scan	Which known weaknesses are present on internal hosts?	Authenticated scanner on the network	Host by host list of missing patches and weak configuration
Internal network penetration test	How far can an insider or attacker with a foothold get, and how?	Standard user device, account or network port	Attack paths with evidence, objectives reached, detection timeline
Segmentation test	Do the boundaries between zones actually block traffic?	One host in each zone	Allowed and blocked flows per boundary
Directory security assessment	How is Active Directory configured against known attack paths?	Read access to the directory, often with the owner	Configuration findings and path analysis
Red team exercise	Would a covert, objective driven adversary be detected and stopped?	Varies, often no initial access	Narrative of the operation and detection outcomes

The internal test sits between the scan and the red team. It is not covert by default and it aims for coverage of paths rather than one quiet route. Use the Network Segmentation Testing Guide where boundary validation is the main need, and the Red Teaming Guide once detection is mature enough to be tested covertly.

Choosing the starting position

The starting position decides what the test can tell you. The NCSC points out that a penetration test confirms systems are not vulnerable to known issues on the day of the test, and that checking whether defined controls work is a poor use of testing time. Spend the budget where your own assessment is weakest.

Starting position	What it simulates	Best for	Watch out for
Standard build laptop with a standard user account	Phished or malware infected employee	Most organisations; tests endpoint controls and the directory together	Ship the device through your normal build so it matches reality
Standard user credentials only, tester device on the network	Stolen credentials used from an attacker controlled host	Testing what an account alone can reach	Tester device bypasses your endpoint controls, so endpoint findings are out of view
Unauthenticated device on a wired port or guest network	Visitor, contractor or rogue device	Testing network access control and legacy protocols	Agree physical locations and network access control exceptions in writing
Virtual desktop or remote access session	Compromised remote worker	Organisations where most staff work through VDI or VPN	Include breakout from the virtual desktop in scope or exclude it explicitly
Privileged starting point, such as a help desk account	Insider or compromised support staff	Testing tiering and delegation design	Higher risk of real change; tighten rules on what may be modified

Decision guidance: a small organisation with one site and a single domain usually gets most value from one week starting on a standard laptop. A large group with several forests, trusts and acquired companies should split the work: one test per forest or business unit, plus a short test from the guest or contractor network, rather than one thin test across everything.

Scope and rules of engagement

NCSC scoping guidance says the scope should involve risk owners, technical staff who know the systems and a test team representative, and should end in a plan covering technical boundaries, test types, timeframe, scenarios, reporting and constraints. For internal work the boundaries are more about identity and safety than address ranges. The Penetration Test Scoping Checklist holds the reusable questions; the items below are the internal specific ones.

Directory scope: name every Active Directory forest and domain, trust relationship, Entra ID tenant synchronised from them, and the certificate services (AD CS) hierarchy. State whether moving across a trust into a partner or subsidiary domain is allowed; usually it is not without that owner's written consent.
Network scope: list internal ranges and zones, including server, user, management, payment and OT segments. Mark OT and safety systems out of scope unless a specialist plan exists (see the OT Penetration Testing Guide).
Objectives: agree two to four, for example domain administrator equivalent rights, read access to a named finance share, access to the cardholder data environment, or control of the backup platform.
Prohibited actions: no denial of service, no changes to group policy or production configuration, no account lockouts beyond an agreed threshold, no persistence beyond the test window, and no access to personal mailboxes or HR data even if reachable.
Password guessing: state whether it is allowed, against which accounts and at what rate, aligned to the domain lockout policy.
Credential and data handling: captured hashes, tickets and cleartext passwords are sensitive data. Require encrypted storage, destruction at the end of the engagement and no cracking on third party cloud services.
Stop conditions: name a technical contact available at short notice, as the NCSC recommends, and agree what makes the tester stop and call: signs of a real intruder, an unstable host, or reaching data outside the agreed objective.

Method: the phases of an internal test

Each phase maps to behaviour catalogued in MITRE ATT&CK. Asking the tester to label their activity with technique IDs lets the SOC check, after the test, which steps it saw and which it missed.

Phase	What the tester is trying to learn	ATT&CK behaviour exercised	What you should receive
Situational awareness	Which hosts, services and shares exist and what the foothold can reach	T1046 Network Service Discovery, T1135 Network Share Discovery	Reachability map compared with intended segmentation
Directory discovery	Users, groups, privileged accounts, delegation, trusts and certificate templates	T1087.002 Domain Account, T1482 Domain Trust Discovery	Privileged path analysis, highlighting the shortest routes to tier 0
Credential access	Whether credentials can be captured from the network, the directory or files	T1557.001 Name Resolution Poisoning and SMB Relay, T1558.003 Kerberoasting, T1552.001 Credentials In Files	Which accounts were exposed, how, and how strong their passwords were
Privilege escalation	Whether misconfigurations grant higher rights	T1649 Steal or Forge Authentication Certificates, T1078.002 Domain Accounts	Each misconfiguration used, with the directory object and setting
Lateral movement	Whether one host's credentials open others	T1021.002 SMB/Windows Admin Shares, T1550.002 Pass the Hash	Hosts reached, the credential used for each, and why it worked there
Objective	Whether agreed targets can be reached	For domain dominance, T1003.006 DCSync	Proof of access with minimal data touched, and timestamps
Clean up and report	Removing artefacts and test accounts	None	Artefact list, removal confirmation, report and debrief

The Lateral Movement Guide covers the defensive side of the movement phase, and the BloodHound and Active Directory Attack Path Guide explains how path analysis works so you can run it yourself between tests.

What internal tests keep finding

The joint NSA and CISA advisory on the top ten cybersecurity misconfigurations (AA23-278A) drew on red and blue team assessments, hunt and incident response work, and vulnerability assessments of over 1,000 network enclaves, most of them Windows and Active Directory environments. Its list is a good predictor of an internal test report. The table maps the recurring findings to the fix and to deeper NHI Mgmt Group guidance.

Recurring finding	Why it matters inside the network	Durable fix	Further guidance
LLMNR and NBT-NS enabled	Lets a foothold capture or relay authentication from nearby hosts	Disable both by policy where not needed; monitor for poisoning	LLMNR and NBT-NS Poisoning
SMB signing not required	Allows relayed authentication to be used against file servers	Set "Microsoft network server: Digitally sign communications (always)" and the client equivalent	SMB Signing Guide
Shared or reused local administrator password	One compromised host opens every host with the same password	Windows LAPS with unique, rotated passwords backed up to AD or Entra ID	Windows LAPS Guide
Service accounts with SPNs and weak passwords	Their tickets can be requested by any user and attacked offline	Group managed service accounts, or long random passwords and AES only encryption	Kerberoasting and AS-REP Roasting Defence Guide
Vulnerable AD CS templates or web enrolment	Can let a standard user obtain a certificate for a privileged identity	Review template enrolment rights and subject name settings; remove unused web enrolment	How to audit AD CS certificate templates
Excessive ACLs on shares and directory objects	Credentials in scripts and writable objects create short paths to privilege	Share permission reviews, credential scanning of shares, directory ACL clean up	Active Directory ACL and Delegation Hygiene Guide
Administrators logging on to user workstations	Privileged credentials are left where a foothold can reach them	Administrative tiering, dedicated admin accounts and privileged access workstations	Privileged Access Workstations Guide
Flat network	Every host can reach every other host and the management plane	Zone servers, users and management; restrict administrative protocols to jump hosts	Zero Trust Network Segmentation Playbook for Flat Networks

Microsoft documents SMB signing as available in all versions of Windows and required by domain controllers for connections to them, mainly for SYSVOL and NETLOGON, so a finding usually concerns member servers and clients. For the most common report entries across all test types see Top 10 Penetration Test Findings.

Where identity fits

An internal test is largely an identity test. CISA's SILENTSHIELD red team assessment of a federal agency (AA24-193A) described weak and exposed credentials, including service accounts and backup files, unsecured administrative credentials that led to full domain compromise, and weak service account passwords used across a trust into a partner domain. Accounts that were not enrolled in the agency's identity management system bypassed its controls entirely.

Service accounts: ask the tester to report every non-human account they compromised, how, and what it could reach. That list is a direct input to your service account clean up. See the Service Account Security Guide and How to build a service account inventory from Active Directory.
Secrets in files: scripts, configuration files and deployment shares often hold passwords for service accounts and databases. Treat every one found as compromised and rotate it.
Test accounts: accounts created for the tester are real identities with real access. Give them an owner, an expiry date, monitoring and verified deletion at close.
Hybrid identity: where AD synchronises to Entra ID, include the synchronisation server and its service account in scope, because control of it can reach the cloud tenant.

Choosing the approach

Choice	Option A	Option B	When to prefer B
Knowledge	Grey box: network diagrams, standard account, list of crown jewels	Black box: foothold only	Only when you specifically want to measure discovery; otherwise grey box gives more depth per day
Detection	SOC informed, logs activity openly	SOC not told (no notice)	When detection and response maturity is the question; keep a named white cell who can confirm the test is authorised
Provider	External specialist firm	In-house team	For frequent, narrower tests between external engagements; keep an independent test at least annually
Delivery	Manual, time boxed test	Automated internal testing platform	For frequent regression checks of known paths; it does not replace manual creativity. See the AI-Assisted and Autonomous Penetration Testing Guide
Length	Five to ten days for one forest	Several weeks	Multiple forests, trusts, segmented sites or a separate objective per business unit

Smaller organisations should start with one grey box test and an informed SOC. Larger organisations with a functioning SOC get more from rotating between informed tests for coverage and occasional no notice tests for response, then moving to purple team exercises. See the Purple Teaming Guide.

Implementation: running one test well

Prepare (two to four weeks before): run your own authenticated vulnerability scan and directory path analysis, fix what is obvious, and share the results with the tester. The NCSC recommends sharing your current vulnerability assessment so the test can judge how accurate it is.
Authorise: get written sign off from the owner of every domain, network and hosted service in scope, plus any managed service provider whose contract covers those systems.
Stage the foothold: build the test laptop through your normal process, enrol it in endpoint protection, and create the test account with an expiry date and an owner.
Brief the SOC: agree whether the test is announced, give the white cell contact, and ask analysts to record every alert and the time they acted.
Run with daily check ins: a short daily call to hear what the tester has reached, raise critical findings immediately (for example, a path to domain administrator in hours) and confirm no instability.
Close down: confirm removal of test accounts, tools, scheduled tasks, certificates issued during testing and any changed object, and reset passwords the tester learned. Your rollback is this artefact list, so require it in the contract.
Debrief and plan fixes: walk through each attack path, choose the break point, assign owners and dates, and book the retest. The How to Read a Penetration Test Report Guide covers judging the report itself.
Retest and feed detection: retest the fixed paths, and turn every technique the SOC missed into a detection engineering ticket.

Detection and measurement

CISA's SILENTSHIELD findings are a useful warning: detections built on known tool names and file names missed alternative techniques such as Kerberoasting, endpoint alerts were not reviewed daily, and log retention of 60 to 90 days with siloed data left analysts short of evidence. During and after the test, check that you collect at least the following.

Directory events: Kerberos service ticket requests (Windows event 4769) with weak encryption types, directory replication requests from non domain controllers, certificate requests against sensitive templates, and changes to privileged groups. See the Active Directory Security Monitoring and Event IDs Guide.
Endpoint telemetry: remote service creation, administrative share access and credential access attempts on hosts.
Network telemetry: name resolution poisoning, unusual SMB and remote management flows between workstations, and outbound traffic from servers.

Metric	What it shows	Direction
Time from foothold to first privileged credential	How resistant the directory and endpoints are	Up, ideally not reached
Percentage of tester techniques detected by the SOC	Detection coverage against real behaviour	Up
Mean time from first alert to analyst action during the test	Whether alerts are triaged, not just generated	Down
Number of distinct paths to tier 0 in the report	Attack path density	Down between tests
Critical and high findings closed and retested within the agreed window	Remediation discipline	Up, towards 100 percent
Repeat findings from the previous test	Whether fixes are durable	Down, towards zero

Framework mapping

Framework	Reference	How the internal test relates
NIST SP 800-53 Rev. 5	CA-8 Penetration Testing; CA-8(1) Independent Penetration Testing Agent or Team; CA-8(2) Red Team Exercises	The control that requires testing, with enhancements for independence and red teaming
NIST SP 800-53 Rev. 5	RA-5 Vulnerability Monitoring and Scanning; CA-2 Control Assessments	The scanning and assessment the test validates
NIST CSF 2.0	ID.RA-01; ID.IM-02	Vulnerabilities identified, validated and recorded; improvements identified from security tests and exercises
CIS Controls v8.1	Control 18, Safeguard 18.5 Perform Periodic Internal Penetration Tests	Internal testing is an IG3 safeguard. See the CIS Control 18 Penetration Testing Guide
PCI DSS v4.0	Requirement 11.4	Requires internal penetration testing and testing of segmentation controls for the cardholder data environment. See the PCI DSS 4.0 Guide
MITRE ATT&CK v20	Discovery, Credential Access and Lateral Movement tactics	Technique IDs in the method table give a shared language for tester and SOC
MITRE D3FEND	D3-NI Network Isolation	The defensive technique most internal reports recommend for flat networks

Common failure patterns

Testing from a tester owned laptop only: it skips your endpoint controls, so the report says nothing about whether your standard build would have stopped the first step.
Excluding the directory as too sensitive: an internal test without Active Directory and certificate services in scope misses the paths attackers actually use.
Treating each finding separately: four medium findings that chain to domain compromise get scheduled as four low priority tickets, and the path survives.
No SOC timeline: without a record of what defenders saw and when, the organisation learns nothing about detection from an expensive test.
Same scope every year: the identical test repeated annually finds the identical issues; rotate starting positions and objectives, and retest fixed paths in between.

Practitioner checklist

Choose a starting position that matches your likeliest compromise, normally a standard build laptop and user account.
Name every forest, domain, trust, Entra ID tenant and AD CS hierarchy in scope, and the OT and third party systems that are out.
Agree two to four objectives, prohibited actions, password guessing limits and stop conditions in writing.
Require secure handling and destruction of captured credentials and a full artefact list at close.
Run your own scan and path analysis first and share the results with the tester.
Give test accounts an owner, an expiry date and monitoring, and verify their deletion.
Ask for ATT&CK technique IDs and timestamps in the report and compare them with the SOC's timeline.
Fix each attack path at its cheapest durable break point and retest it.
Rotate every credential the tester obtained, including service account passwords found in files.

Internal Network Penetration Testing Guide: Scope, Method and What Good Looks Like