Internal network segmentation penetration testing

Internal network penetration testing and segmentation validation determine whether the compromise of one endpoint is actually contained to its trust zone. A diagram containing multiple VLANs is not evidence. The assessment must measure real routing, firewall decisions, administrative paths, directory services, DNS, proxies, IPv6, wireless networks, backup infrastructure and the identities crossing zone boundaries.

The useful conclusion is not merely “a port was open”. It is: which source zone and identity can reach which service and business process, what outcome becomes possible, and which control was expected to prevent it. A safe assessment proves this with bounded connections, tagged sensors and purpose-built accounts. It does not require production disruption, high-volume password attacks or destructive exploitation.

What a segmentation test must prove

Segmentation is effective when it enforces the minimum required flow even if the source endpoint is misconfigured or compromised. The test should evaluate at least five properties:

horizontal isolation — a user workstation cannot freely reach peer workstations, printers, IoT or operational technology;
vertical isolation — an ordinary zone cannot access management networks, hypervisors, backup, security platforms and domain controllers beyond documented services;
directionality — return traffic for an approved connection does not create a general path initiated in the opposite direction;
identity and device context — high-risk access is not authorised solely because a packet originates from an internal IP address;
alternative-path consistency — IPv6, VPN, Wi-Fi, cloud links, recovery networks, proxies and administrative tunnels enforce the same trust assumptions.

NIST SP 800-207 explains that network location alone should not establish trust. Segmentation still matters, but it is stronger when integrated with Zero Trust security: continuous decisions based on identity, device, destination and session risk.

Technical model: zone, flow, identity and impact

Before testing, build a model that can be reconciled with reality. Every approved flow needs an owner and structured record:

Field	What it establishes
Source	user zone, application tier, vendor VPN or another trust domain
Destination	named service, VIP, host or resource group
Protocol	TCP/UDP/ICMP, port, application protocol and TLS expectation
Direction	initiator and stateful return behaviour
Identity	user, service account, certificate, device or workload
Business purpose	why the path exists and who approved it
Enforcement	firewall, ACL, microsegmentation, host firewall, proxy or NAC
Logging	where a decision is recorded and for how long
Criticality	confidentiality, integrity and availability consequence

This becomes a flow matrix, from which the team can derive a reachability graph. The assessment compares three states: designed, configured and actually reachable flows. The gap between those states is often more significant than one exposed listener.

Layers that require separate validation

Layer 2: broadcast domains and access admission

A VLAN separates a broadcast domain; it is not a complete security boundary. Review access and trunk ports, unused interfaces, native VLAN handling, switch-management networks, 802.1X/NAC behaviour and the policy for devices that cannot authenticate. Disruptive manipulation of STP, DHCP or forwarding tables should be excluded unless the organisation provides a dedicated laboratory window.

Safe validation connects an authorised sensor to representative ports and records the assigned zone, NAC policy and available routes. The team can check the response to an unknown device and a controlled posture change without impersonating an employee or interfering with other clients.

Layers 3 and 4: routing, ACLs and stateful firewalls

Here the test measures protocol reachability between zones. Scanning must use an approved rate, defined targets and safeguards for connection-sensitive services. Results should distinguish open, closed, filtered, active reject and timeout. A timeout is not automatically proof of intended enforcement; asymmetric routing, a host firewall or an unhealthy service may produce the same observation.

NIST SP 800-41 Rev. 1 treats firewall policy as an implementation of organisational requirements and risk decisions. Validation should identify any-any rules, broad source ranges, whole subnets used where named services would suffice, expired temporary exceptions and paths that bypass the expected enforcement point.

Layer 7: proxies, DNS and application gateways

Restricting traffic to TCP 443 does not by itself produce least privilege. A proxy that permits arbitrary destinations, internal-name resolution or generic tunnelling can provide far more reach than a firewall rule suggests. Validate destination allowlists, HTTP methods, SNI, certificate handling, DNS policy, private zones and egress controls. Administrative flows should traverse controlled bastions or PAM rather than rely on direct routing.

IPv6 and undocumented routes

An environment may process IPv6 even if its design only documents IPv4. Link-local addressing, router advertisements, DHCPv6 and automatic configuration create an independent surface. Determine whether IPv6 is managed and filtered or merely assumed to be unused. Also assess hypervisor interfaces, storage networks, backup paths, cluster networks, cloud tunnels and remote-support tooling.

Active Directory is part of the segmentation model

Domain endpoints legitimately reach DNS, Kerberos, LDAP, SMB and related services on domain controllers. These flows make administrative separation more important, not less. The test should identify whether a standard workstation can reach management interfaces, tier-zero systems, administrator workstations, certificate services, identity synchronisation or Active Directory backups.

A blocked port cannot compensate for privileged credentials being used on a low-trust endpoint. Network results must therefore be reconciled with Active Directory security, administrative tiers and privileged access management.

A safe engagement uses accounts with explicit test roles and avoids indiscriminate password spraying. The team can prove that a service is reachable and that a test account is correctly denied without collecting another user’s credentials.

A risk-led penetration-testing process

NIST SP 800-115 structures technical assessments around planning, execution, analysis and post-testing activity. For an internal network, that becomes the following workflow.

1. Define objectives and rules of engagement

List sites, subnets, zones, OT or medical systems, legacy devices, operating windows, traffic limits, prohibited data and emergency contacts. Establish whether the objective is policy compliance, resilience after laptop compromise, vendor-access validation or a route to a named crown-jewel service. Make the distinction between a red-team exercise and a penetration test explicit: segmentation validation seeks representative control coverage rather than stealth at any cost.

2. Place sensors in representative zones

One test location is insufficient. Use controlled sources in user, server, guest, VPN, wireless, administrative and—where authorised—cloud or branch zones. Each sensor needs a known address, owner, test identifier and synchronised clock so that operations can be correlated with telemetry.

3. Reconcile routes and reachability

Start with routes, name resolution and low-impact responses. Then run bounded tests to approved targets and services, measuring the result from both sides. Do not infer that silence means enforcement at the intended firewall; the owner should identify the firewall, ACL, proxy or host log recording the decision.

4. Validate identity controls on allowed paths

For reachable services, verify that access still requires the intended user identity, MFA, device certificate or bastion session. Network segmentation cannot repair anonymous services, shared accounts or unconstrained service identities.

5. Prove impact minimally

Evidence may be a TLS handshake, correct application-layer denial, retrieval of a harmless canary file or login with a dedicated test identity. Do not copy business data or persist access. If a more invasive step is necessary to differentiate risk, obtain explicit approval for that step.

6. Retest in both directions

After a rule change, repeat the original path and test dependent approved flows. An overly broad block can break backup, monitoring or authentication. The retest must confirm both closure of the unwanted path and continued operation of the authorised service.

Detection: proving that enforcement is observable

The engagement should generate tagged events that the SOC can retrieve. Useful telemetry includes firewall decisions, NetFlow/IPFIX, DNS, proxy, NAC, EDR, Windows events, network-device syslog, VPN and authentication logs. A shared time reference and mapping between address, device and user are essential.

High-value detection cases include:

user-zone connections to management or tier-zero networks;
one source contacting many internal hosts or services;
administrative protocols used outside an approved bastion;
rare internal DNS queries for infrastructure zones;
peer-to-peer workstation traffic that is absent from the baseline;
a new device or unexpected NAC profile transition;
IPv6 activity in an environment without a managed deployment;
access to backup, hypervisor or domain-controller services from an unapproved source.

No alert does not necessarily mean no telemetry. Report the difference between failure to block, blocking without evidence, logging without detection and detection without a rehearsed response.

Hardening segmentation and reducing lateral movement

Durable remediation starts by assigning an owner to every flow. Policies should be deny-by-default, constrained by source, destination, protocol and purpose, and carry a review or expiry date. Route administration through bastions or PAM and place privileged workstations in a separate trust zone. Host firewalls and microsegmentation address east-west traffic invisible to a central perimeter firewall.

Additional controls should:

separate backup and security platforms from the ordinary user domain;
block direct workstation-to-workstation traffic where there is no business requirement;
constrain server egress to named services and repositories;
manage IPv6 consistently or disable it through a supported configuration, not by assumption;
deploy 802.1X/NAC with a restricted zone for unknown devices;
segment remote clients by role and device posture;
expire temporary firewall rules automatically;
rerun validation after routing, cloud, SD-WAN and merger-related changes.

Internal network assessment checklist

Reporting results engineers can use

Each finding should identify source zone, destination zone, protocol, identity context, expected policy, observed result, minimal evidence, impact and remediation owner. A reachability diagram is more useful than thousands of raw scanner rows. Prioritise paths to tier zero, backup, management planes, regulated data and deployment systems.

Repeat validation after material network redesign, SD-WAN or ZTNA rollout, cloud migration, acquisitions and changes to the administrative model. Segmentation is a continuously changing control, not a one-time firewall project.

Design new zones, rules and services according to CISA Secure by Design principles, making a constrained flow the default pattern rather than an incident-driven retrofit.