How to plan an internal network penetration test
← All guidesInternal network penetration testing examines what an attacker could access from a position inside an organization's network. The test attempts to turn that starting access into an agreed objective, such as control of a server or access to a restricted file share.
The starting network segment and identity define the question. A test from the employee network can examine a route to finance systems. A test from a server segment begins with different reachability. An assumed-breach assessment adds a specified identity, such as an ordinary employee account.
Internal and external tests start from different positions
An external test starts outside the private network and examines exposed services within its scope. An internal test starts with access to an authorized internal segment. Record that position when interpreting the result: a route available from one segment may be unreachable from another.
Internal testing can examine credentials exposed in shared files, excessive permissions and access between systems. Active Directory testing concentrates on directory identities, delegated rights and trusts. Internal network testing can also include Linux servers or databases that are reachable within the agreed scope.
Write the assessment conditions before deployment
| Condition | What to record |
|---|---|
| Objective | The named system or data and the access that would count as success. |
| Starting position | The deployment segment and any credentials supplied, including their existing privileges. |
| Authorized scope | The permitted target ranges and exclusions, including systems that might provide an intermediate route. |
| Permitted actions | The change permissions, stopping procedure and operational contact for the assessment. |
| Success evidence | The evidence needed to establish the requested access and any limits on data collection. |
A directory trust or newly discovered subnet does not extend authorization. Identify the intended scope before testing. The objective guide explains how to separate the requested outcome from the systems the test may use.
Work through an employee-to-finance assessment
In this hypothetical example, an employee account should have no access to a restricted finance share. Choose a designated test document on that share as the objective. Place the deployment host on the employee network and supply credentials with the employee's ordinary permissions.
Include the finance server and the authorized intermediate systems in scope. Keep exclusions explicit. Agree that reading the designated document counts as success and specify the evidence to retain from that read.
A route could involve an exposed service credential on another reachable host. If that credential opens the finance share, the result identifies a credential-handling problem along that route. The starting employee account's direct permissions remain a separate fact.
Giving the test a finance administrator account at the start would answer a different question. Keep supplied access separate from access gained during the assessment.
Read the result and plan the next test
A successful read of the designated document answers this example's objective. Review the recorded route to identify which exposed credential or permission enabled it, and give that evidence to the responsible system owner.
For an open objective, review the campaign status and access gained with the recorded starting conditions. A blocked route may leave systems deeper in that route untested. When testing a segmentation change, keep the original segment and target in scope and inspect the new campaign's result.
The penetration test report guide shows how to prepare a handoff and retest the affected access.
Run an internal campaign with AutoAttack
AutoAttack provides automated network penetration testing from a temporary Docker container on a dedicated Linux host. You choose the objective, starting access and authorized scope. The report shows the access gained and whether the objective was reached.
Review the host and network requirements and campaign controls before deployment. The quickstart covers creating the campaign and running its Docker command. A free campaign shows a masked report; a subscription reveals the target identities, captured evidence and recommended fixes.