What we test · Internal network
Internal network penetration testing
In one paragraph
An internal network penetration test assumes an attacker already has a foothold inside, such as a compromised laptop or a stolen employee login, and proves how far they could go from there. It measures lateral movement, privilege escalation and whether network segmentation actually keeps sensitive systems apart. The result is a map of real attack paths from an ordinary starting point to the systems you care about most, and the specific links to break.
What the test covers
Segmentation
Whether boundaries between office, server, production, payment and guest networks block traffic the way the diagrams say they do.
Lateral movement
How an attacker could hop from one machine to the next using shared credentials, remote management tools or open file shares. MITRE ATT&CK catalogs these as lateral movement techniques.
Privilege escalation
Paths from a standard user to local administrator, and from there to domain or infrastructure administrator.
Directory and authentication protocols
Weak service account passwords, legacy authentication protocols and misconfigured certificate services inside Active Directory environments.
Internal services and management interfaces
Databases, backup consoles, hypervisor admin panels and printers reachable from user networks, often with default or shared credentials.
Credentials at rest
Passwords in scripts, file shares, configuration files and browser stores that hand an attacker the next step.
Detection
Optionally, which actions your monitoring tools noticed, so the blue side learns as much as the red side.
What is an assumed-breach test and why start there?
Perimeter defenses fail eventually. A phishing email gets clicked, a contractor's laptop is compromised, a VPN credential is reused from another breach. Rather than spending the engagement trying to get in, an assumed-breach test gives the tester a realistic foothold up front, typically a standard domain user and a company-built laptop or a virtual machine on the corporate network, and spends the time on what happens next.
This answers the question executives actually ask after an incident: how bad could it have been? It also tests the controls that matter once someone is inside, which a purely external test never reaches.
Which starting point should you choose?
| Starting point | Simulates | Good for |
|---|---|---|
| Network port only, no credentials | A rogue device plugged into an office or a compromised printer | Testing network access control and unauthenticated exposure |
| Standard user account and laptop | A phished employee | The most common and usually most informative choice |
| VPN access as a remote employee | Stolen remote credentials | Remote-first companies with little office network |
| Access to one server or workload | A compromised internet-facing service | Testing segmentation between application tiers |
Many companies today have small offices and most infrastructure in the cloud. In that case an internal test often becomes a blend of network, identity and cloud testing, because the paths cross all three.
What does an internal penetration test usually find?
Internal findings are rarely one dramatic flaw. They are chains. A service account with a weak password, a file share every employee can read containing a script with that password in it, and a backup server that trusts that account. Each link looks minor in a scan. Together they are an attack path from a new hire's laptop to every backup the company has.
Reporting these as paths rather than isolated issues changes how they get fixed. Instead of patching forty medium findings in arbitrary order, you break the two or three links that most paths depend on, then confirm the paths are gone.
What do you need to provide?
- The agreed starting point: an account, a laptop or VM image, VPN access or a network drop.
- The network ranges in scope, and any fragile systems (industrial controls, medical devices, legacy servers) to avoid or treat gently.
- The crown jewels: which systems or data would hurt most if reached, so the test can aim at them.
- Whether your security monitoring team should be told, which decides whether detection is part of what is measured.
How long does it take, and how are findings proven and fixed?
Length depends on the number of sites and network ranges, the size and age of the directory, how many distinct trust zones exist, and whether detection testing is included. A flat network with one directory domain is quicker to assess than several merged environments with forest trusts.
In Brexa's Prove stage each path is walked by a human operator with every step recorded, and actions stay within the signed rules of engagement (no destructive changes, no access to data beyond what proves the point). Verify replays the path after fixes ship. For internal networks this matters because fixing one link sometimes reveals that an alternative route still works; the finding closes only when no route in the tested path does. See retesting and fix verification for why this step is easy to skip and expensive to miss.
Two ways to engage
Test this surface once with a one-time vulnerability assessment, or keep it under continuous testing with autonomous agents. Either way every finding is reproduced by a person before it reaches you, and closes only after a retest shows the original attack fails.
Frequently asked questions
Do we need an internal test if everything is in the cloud?
You may not need a traditional network test, but the assumed-breach question still applies. It usually becomes a test of what a compromised laptop or account can reach across identity, SaaS and cloud.
Can internal testing be done remotely?
Usually yes. A pre-configured device or virtual machine placed on your network, or VPN access, lets the tester work without being on site.
Is an internal penetration test the same as a red team exercise?
No. An internal pentest tries to find as many paths as possible and is often coordinated with your team. A red team exercise pursues a specific goal quietly to test whether you detect and respond.
Does segmentation testing satisfy PCI DSS?
PCI DSS requires segmentation controls to be tested when segmentation is used to reduce scope, and an internal test can provide that evidence. Confirm the exact requirements and frequency with your assessor.
References
- MITRE ATT&CK: Lateral Movement (TA0008)
- MITRE ATT&CK: Privilege Escalation (TA0004)
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
- NIST SP 800-207, Zero Trust Architecture
- PCI Security Standards Council Document Library (PCI DSS v4.0.1)
- PCI SSC FAQ: How often must service providers test segmentation controls?
Guides for this surface
Other surfaces we test
Book a internal network assessment.
Book a short scoping call. Nothing is tested until scope and rules of engagement are signed, and every finding comes with proof.