Skip to main content
Most security testing focuses on what’s externally reachable. But the majority of real-world breaches don’t stop at the perimeter. An attacker who compromises a single endpoint, phishes a developer, or exploits an exposed service is now inside your network, and the damage they do from there depends entirely on how your internal environment is configured. Internal networks are where privilege escalation happens, where lateral movement goes unchecked, and where attackers reach the systems that actually matter: databases, admin panels, CI/CD pipelines, secrets stores, and internal APIs that were never designed to face hostile traffic. Most organizations have limited visibility into what an attacker can reach once they’re past the perimeter, because internal pentesting is expensive, disruptive, and happens infrequently at best.

​
How Neo Solves This

Neo conducts internal network assessments by simulating post-compromise scenarios: starting from a foothold inside your network and systematically testing how far an attacker can go, what they can access, and what damage they can inflict.
  1. Establishes a starting position — Neo begins from a defined entry point inside your network: a compromised workstation, a developer laptop, a container within your cluster, or any segment you want to test from. This simulates realistic breach scenarios where an attacker has already bypassed perimeter defenses.
  2. Discovers internal services and assets — from the starting position, Neo maps the internal network: identifying reachable hosts, open ports, running services, internal APIs, databases, management interfaces, and infrastructure components. It builds a picture of what’s accessible from the compromised vantage point.
  3. Tests for privilege escalation — Neo probes internal services for weaknesses that enable escalation: default credentials on management interfaces, misconfigured service accounts, overly permissive IAM roles, unpatched internal services with known CVEs, weak authentication on internal APIs, and exposed secrets in configuration files or environment variables.
  4. Maps lateral movement paths — when Neo gains access to one internal system, it tests what that access enables. Can it reach other network segments? Can it access databases or secrets stores? Can it pivot from a development environment to production? Neo traces these paths to demonstrate how a single compromise cascades across your internal infrastructure.
  5. Assesses post-compromise impact — Neo doesn’t stop at proving access. It demonstrates what an attacker can do with that access: extracting sensitive data, modifying configurations, accessing customer records, reaching CI/CD systems, or compromising deployment pipelines. The findings reflect real business impact, not theoretical risk.
  6. Tests segmentation and controls — Neo validates whether your network segmentation, firewall rules, and access controls actually prevent lateral movement. It identifies gaps where controls are configured but not enforced, where segmentation exists on paper but not in practice, and where trust relationships between services create unintended access paths.

​
What This Looks Like in Practice

You ask Neo to simulate an internal breach scenario:
Neo begins from the developer VLAN, discovers 140+ reachable internal services, and identifies that the internal Jenkins instance at 10.0.2.30 accepts the developer’s AD credentials with no additional authentication. From Jenkins, Neo accesses stored deployment credentials, uses them to authenticate to the production Kubernetes cluster, and demonstrates read access to production database secrets. The full attack chain (developer workstation to Jenkins to deployment credentials to production cluster to database secrets) is documented with evidence at every step and specific remediation for each link in the chain.

​
What You Get

  • Realistic breach simulation — testing that starts from a credible internal foothold rather than an external scan, reflecting how real attacks unfold after initial compromise
  • Lateral movement mapping — complete documentation of how far an attacker can move from a given starting position, with every hop validated and evidenced
  • Privilege escalation paths — confirmed escalation routes through misconfigured services, weak credentials, exposed secrets, and unpatched internal software
  • Segmentation validation — evidence of whether your network controls and segmentation actually prevent lateral movement between environments and trust zones
  • Real impact demonstration — findings that show what an attacker can access and do, not just which services are reachable, including data exposure, configuration tampering, and pipeline compromise
  • Chained attack narratives — multi-step attack paths documented end to end with evidence at each stage, making it clear how individual weaknesses combine into critical exposure

​
Common Internal Testing Scenarios

​
Developer Workstation Compromise

Simulates an attacker who has phished a developer or compromised their laptop. Tests what internal systems a developer’s credentials and network position can reach, whether escalation to production systems is possible, and how effective segmentation is between development and production environments.

​
Container Escape and Cluster Pivoting

Starts from a compromised container within your Kubernetes or Docker environment. Tests for container escape paths, access to the node’s host system, cluster-level privilege escalation via misconfigured RBAC, and lateral movement to other workloads, namespaces, or the underlying cloud infrastructure.

​
Post-Phishing Lateral Movement

Simulates the aftermath of a successful phishing attack on a non-technical employee. Tests what an attacker can reach with standard corporate credentials: internal applications, file shares, admin panels, and whether they can escalate from a low-privilege position to systems containing sensitive data.

​
CI/CD Pipeline Compromise

Assesses what an attacker who gains access to your build and deployment infrastructure can do: injecting code into builds, accessing deployment secrets, modifying production configurations, or using the pipeline as a pivot point to reach production systems directly.

​
Trust Boundary Validation

Systematically tests the boundaries between network segments, environments (development, staging, production), and trust zones. Validates that firewall rules, network policies, and access controls prevent unauthorized cross-boundary access in practice, not just in configuration.

​
Safety Considerations

Internal networks contain devices that external-facing scans rarely touch: printers, badge readers, industrial controllers, VoIP phones, and other embedded systems. These devices often run minimal firmware with thin network stacks, and they don’t always fail safely when probed.

​
Printer and MFP Templates

Nuclei’s template library includes checks that interact directly with printers and multi-function devices over raw printing protocols (port 9100 / JetDirect), IPP, or SNMP. Run against real hardware, these can have physical, visible side effects rather than a silent pass or fail:
  • Unintended print jobs — some checks submit a PJL or PostScript payload to confirm a device accepts raw jobs. On live hardware, this can print pages or display a message on the control panel, not just log a finding.
  • Consumable waste and disruption — repeated scans can burn through paper and toner, and a printer spontaneously printing mid-scan can alarm whoever is standing next to it.
  • Device instability — embedded print controllers commonly run old, resource-constrained firmware. Malformed jobs or rapid connection attempts can hang or crash the device until someone finds it and power-cycles it.
Treat printer and MFP fleets as their own category when scoping internal testing:
  • Exclude printer/MFP IP ranges or device classes from active Nuclei template runs unless you specifically intend to test them, and say so explicitly in the scope notes when starting a task.
  • If printers are in scope, schedule the run for a window when IT or facilities is aware, and expect consumable use or a reboot as a normal outcome rather than a failure.
  • Prefer non-intrusive detection (banner grabs, SNMP reads, version fingerprinting) over templates that submit jobs or exploit firmware, unless you’re specifically validating a finding.

​
Other Fragile Internal Targets

The same caution applies to other categories of internal devices that were never designed to withstand adversarial traffic:
  • OT/ICS and building systems — PLCs, HVAC controllers, badge readers, and fire/life-safety systems can misbehave or fail unsafely under scanning. These typically warrant read-only, passive discovery rather than active exploitation, plus explicit sign-off from whoever owns the physical systems.
  • VoIP phones and embedded peripherals — like printers, desk phones and other embedded appliances can ring, display messages, or crash when hit with intrusive checks.
  • Legacy and end-of-life systems — internal networks accumulate unpatched, unsupported hardware that external scans never reach. These are often the least resilient to aggressive scanning and the hardest to recover if they go down.
  • Directory services and credential checks — testing credentials against Active Directory or other identity systems can lock out real user and service accounts. Coordinate lockout thresholds and any brute-force testing with whoever owns identity infrastructure before running it.
  • Resource-constrained network appliances — firewalls, load balancers, and older switches can have small connection tables; a fast port sweep across an internal segment can exhaust them and disrupt production traffic unrelated to the test.
When scoping an internal engagement, call out any of these categories explicitly, either as in-scope with acknowledged side effects, or as excluded targets, the same way you’d exclude production databases or destructive actions in an application pentest.

​
Setup

To run internal network pentesting:
  1. Give Neo an approved network position inside the target environment:
    • Install a self-hosted sandbox on a workstation, server, VM, or private network segment that can reach the targets.
    • Configure VPN access when the Neo-managed cloud sandbox should connect to the private network.
    • Use enterprise networking such as VPC peering when required by your architecture.
  2. Provide internal credentials via Settings → Secrets to simulate specific compromise scenarios (developer credentials, service account tokens, standard employee access).
  3. Select the sandbox that has the intended network position.
  4. Start a new conversation describing the scenario you want to test. Define the starting position and scope: which network segment, host, or role Neo should start from, and which systems are in scope. Explicitly call out any fragile device categories (printers, OT/ICS, VoIP, legacy hardware) as in-scope or excluded.
  5. Optionally, set up a scheduled assessment for recurring internal testing.