What you’ll take away
- Read each attack path from its agreed starting account and network position, with evidence for every demonstrated step.
- Distinguish a reachable service, a successful sign-in, and authority to perform a consequential action.
- Choose changes that interrupt the path, preserve legitimate work, and leave the remaining uncertainty visible.
In this guide
Connect the test to a business operation you need to protect
The operations director at a fictional distributor wants to know whether a compromised employee account could threaten recovery of its ordering system. Staff need shared files to coordinate shipments. Automated services need access to production systems. A separate backup platform holds the data the company would use to recover. The security question is how those ordinary connections might combine to give an intruder more authority than any employee should have.
An internal network penetration test examines that question from an agreed position inside the environment. NIST SP 800-115 describes penetration testing as exercising vulnerabilities to understand the access an attacker could gain, including how weaknesses can combine. [1] The report should connect the demonstrated steps to the operation leadership cares about, with enough evidence to distinguish a credible concern from a confirmed capability.
For the distributor, the objective is specific. Can a standard employee account reach sensitive backup administration through the systems it already uses? The fictional observations below illustrate how to interpret such a test. They are examples, not results from a customer engagement. A useful answer may identify a complete path, show where a control stopped progress, or reveal a consequential uncertainty that needs another authorized check. Each outcome can support a different business decision.
Make the starting position part of every conclusion
A test account should resemble the employee or device whose compromise concerns you. For the distributor, that means ordinary group memberships, a workstation connection used by staff, and the usual access controls. Record any exceptions the assessment requires. An account granted temporary administrative rights or a device placed on a special testing network changes what the result says about an everyday employee.
Providing a standard account lets the engagement investigate what follows a foothold. The report should state that the initial account was supplied, and identify its permissions at the start. A separate activity would be needed to demonstrate how an outsider could obtain that foothold. If remote access, local office access, and a cloud session expose different systems, name the position actually exercised. Keep each later observation attached to that starting context.
Agree on the business objective and the permitted evidence before testing begins. For backup administration, the system owner may permit a read-only check of effective permissions or a harmless action against a disposable test object. The authorization should identify the permitted method and stopping point. If the final action remains outside the agreement, the report must retain that limit. This gives the tester a way to investigate the path while the people responsible for production retain control over consequential operations.
Read the path one demonstrated step at a time
In the fictional test record, the employee account can read an operations shared folder. A configuration file there contains credential material for a service identity used by automation. After confirming the owner and permitted validation method, the tester performs a benign sign-in that the authentication service accepts. The result establishes that the exposed credential material works for that identity at the tested service and time.
A role export also lists the service identity in a group associated with backup management. The agreed test stops before exercising a backup administrative action. The diagram therefore has two demonstrated transitions, from employee access to the file and from the exposed material to a valid service sign-in. Its final connection to backup administration remains an open question supported by configuration evidence. The service’s actual authorization rules and any additional approval controls still matter.
MITRE ATT&CK describes how adversaries can abuse valid accounts and overlapping permissions to gain access across systems. [2] Use that pattern to ask why this particular service identity has its permissions and where it can authenticate. Preserve the evidence for each transition, including the original account, resource, effective identity, time, and outcome. A role name or a line in a diagram deserves closer examination when it is carrying the entire conclusion about business impact.
One account. A path with a missing proof.
- Provided startEmployee
Standard test account on the agreed network.
- Read shownShared folder
Operations files expose service credential material.
- Sign-in shownService identity
Benign sign-in succeeds; a role record suggests backup authority.
- Not testedBackup action
Administrative action remains an open question.
Examine network separation and identity permissions together
A network rule determines whether one location can communicate with a service. An identity decision determines what a particular account can do through that service. These controls interact. A backup management interface might be reachable only from an administration network, while an overly powerful service identity is usable through another approved system. Conversely, an employee may reach a login page and still have no permission to enter or perform a task.
NIST SP 800-207 treats authentication and authorization as decisions tied to access to a resource, rather than granting trust merely because something is on an internal network. [3] For a buyer, the practical question is which location, account, device conditions, and requested operation a result covers. A statement that a server responded should identify those conditions before anyone interprets it as access to the business data behind it.
Ask for segmentation results organized by the relevant starting zones and destinations. Each tested route should show what communication was expected, what was observed, and what remains unresolved. If a destination is unavailable, establish whether a control blocked it or the service was simply down. Include an authorized operational check where appropriate. A result from one workstation segment says something about that route during the test. Other offices, remote access paths, and administrator systems need their own evidence when they are part of the decision.
Match the strength of the claim to the evidence
Reachability evidence answers whether traffic reached the relevant interface from the tested position. It can include a connection result correlated with a firewall or service record. Access evidence answers whether an identity authenticated and which permitted operation succeeded. A recorded read of an agreed file can establish readable access to that file. A successful sign-in establishes authentication and requires further evidence before making claims about administrative authority.
Business-impact evidence connects a capability to a consequential operation. For the distributor, that might mean effective permission to change a backup policy, together with confirmation of the affected recovery process. A harmless demonstration on a disposable object can add evidence where agreed. Its relationship to production must be explained, including any differences in roles or protective controls. The strength of the conclusion should follow the evidence actually collected.
The fictional report can confidently say that an ordinary account could obtain usable service credentials. It can also explain that a role export suggests a route toward backup administration. It should leave the final action marked untested and identify what would resolve that uncertainty. Configuration review can establish important facts even when a live action is inappropriate. Record whether the evidence demonstrates an effective permission, a configured relationship, or a hypothesis that depends on another condition.
Keep these three claims separate.
A service responds from the test host.
Does not prove sign-in or permissions.
An identity completes an agreed action.
A sign-in alone does not prove backup privileges.
A separately authorized, bounded action validates a specific impact.
The backup action is untested in this example.
Choose an objective that reflects how the business would be hurt
Reaching a widely privileged account can be significant, but the company also needs to understand the resources that account affects. Ask the backup owner which actions would threaten recovery, which require additional authorization, and which safeguards remain independent of the exposed identity. The answer could differ for reading a job status, changing retention, administering storage, or accessing the credentials used to restore a system.
The UK National Cyber Security Centre’s guidance for on-premises backups recommends restricting management access and separating backup administration credentials from ordinary network administration and user activity. [4] Those principles help the distributor evaluate the suspected path. Its team can review the management interface and administrative identity separately from the connections that move backup data. Both serve legitimate purposes, but they need different access decisions.
Document the consequence as conditional where the final authority remains unverified. For example, an account able to alter the relevant backup settings could weaken the company’s recovery options, depending on retention protections and independent copies. Demonstrating that relationship requires more than showing a group name. The confirmed credential exposure still deserves action while the owner resolves the backup question. Keep testing of recovery performance tied to the actual recovery procedure and its evidence so leadership can see which questions this engagement answered.
Establish what the defenders could observe
If detection is part of the engagement, agree which events the defenders should receive and how the team will evaluate their response. In the distributor’s example, relevant observations could include access to the operations file, a service sign-in from an unusual location, or an attempted administrative operation when that check is authorized. Correlate the tester’s timeline with records available to the security team and the case they investigated.
Separate the stages in that evidence. A source log shows that an event was recorded. An alert shows that a rule or analytic raised it for attention. An investigation record shows what the defender understood and did. For a measured case, capture the event and alert times, the analyst’s interpretation, and any agreed response. An alert labelled with an account name may still leave the analyst unable to connect the file access to the later service sign-in.
Describe the testing conditions alongside those observations. Advance notice, temporary monitoring exceptions, and a prearranged test window influence the result. If the objective is to examine access paths and detection is outside the exercise, state that coverage boundary in the report. Leadership can then decide whether to commission an additional detection exercise. Avoid assigning a detection success rate to a set of actions whose expected alerts and evaluation conditions were never agreed.
Interrupt the demonstrated path and preserve the required work
For this distributor, a response begins with the exposed service credential and the permissions that made it readable. The service owner should identify dependent automation before rotating the credential, review where the replacement will be stored, and confirm which staff or systems require access. The identity and backup owners can separately examine the suspicious management membership. Changes should address the demonstrated exposure while preserving the legitimate job the service performs.
Define the expected result before replaying the path. From the original employee position, the sensitive credential material should be inaccessible. The retired credential should fail at the previously tested service. The approved automation should still complete its intended task. If a management permission changes, verify the relevant allowed and denied operations using an agreed safe method. Retain the starting conditions so the comparison explains which control changed the outcome.
Report the point where the replay stops and any remaining route or uncertainty. A denied file read provides evidence about that read path. Other copies of the credential, existing sessions, or unrelated privileged identities may need additional checks according to scope. The backup action remains unresolved until supported evidence answers it. Give each follow-up to an owner with a decision date, particularly when different teams maintain the shared folder, automation, directory, and backup service.
Close the path. Keep the work running.
Coordinate dependencies and rollback with the service owner.
Repeat shared-folder access and the agreed benign sign-in.
Confirm approved operations and backup jobs still function.
Blocked, still possible, or not retested. Assign remaining questions and the next check.
Ask for a report that supports the next decision
A leadership summary should name the starting position, the sensitive operation at issue, the furthest demonstrated capability, and the controls or limits that stopped further work. It should then identify the decision needed. In this example, management can assign the credential exposure for correction and request a bounded review of backup authority. That is a more actionable result than counting findings without showing how they relate to recovery of the ordering system.
Source Point Security’s Internal Network Penetration Testing starts from an agreed foothold and examines reachable hosts, shared resources, credential and trust paths, privilege escalation, and network segmentation within scope. Deliverables include an attack-path narrative, an identity diagram, segmentation results, findings with evidence and owner-specific fixes, and scoped retesting. The report should make partial paths and limits visible alongside demonstrated access so the organization can make decisions from what was actually established.
Where the findings reveal a broader design problem, SPS’s Enterprise Identity Architecture service reviews identity stores, access policies, and privileged access relationships and develops a target design and migration plan. Customer operators implement the changes. For an initial testing discussion, bring the employee or device position that concerns you, the operation you need to protect, and the owners of the systems along the suspected path. Those details help turn a general concern about internal compromise into a test with a useful answer.
See what useful reporting looks like. Our illustrative sample pentest report shows scope, evidence, risk, remediation, and verification using a fictional environment.
Find out what an internal foothold can reach
Bring the starting account or network position and the business operation you need to protect. We can define an internal penetration test with clear objectives and evidence for your next decision.
Discuss Internal Network Penetration Testing