ProjectDiscovery Internal Network Scanning¶

Summary¶

Use ProjectDiscovery's pd-agent to discover and validate services from an internal foothold or network segment during an authorized assessment. The workflow combines local reachability with Nuclei, httpx, naabu, dnsx, and tlsx checks, then preserves the confirming request and response for replay.

This is a ProjectDiscovery Cloud workflow, not a replacement for a manually operated Nuclei or port-scanning campaign. Installation begins with a network-specific command generated by the platform; do not invent or reuse another environment's bootstrap command.

Use when¶

• the assessment includes internal CIDRs, VPN-reachable ranges, or a customer-provided test appliance
• you need an unauthenticated, attacker-view inventory rather than an installed-software list
• segmentation or pivot reachability is part of the question
• Kubernetes node, pod, or service ranges are explicitly in scope
• a newly disclosed issue needs to be checked across an approved internal estate with replayable evidence

Do not use this workflow merely because a private range is technically reachable. The agent's placement, every target range, and every active template must be authorized.

Prerequisites¶

• a ProjectDiscovery Cloud organization and team workspace
• permission to create a distinct network in the platform
• a host or Kubernetes workload placed in the approved source segment
• egress from the agent to ProjectDiscovery Cloud
• at least 2 vCPU, 4 GB RAM, and 10 GB disk for the agent host
• an approved CIDR/hostname allowlist, exclusion list, scan window, and rate ceiling
• approval for the selected Nuclei templates and SYN scanning, if used

Container deployments need host networking for interface discovery and the NET_RAW and NET_ADMIN capabilities for SYN scanning. Treat those capabilities as privileged: grant them only to the dedicated agent container, not broadly to unrelated workloads.

Inputs¶

Record these before deployment:

engagement_id=
network_name=
source_segment=
approved_cidrs=
excluded_hosts=
kubernetes_node_cidrs=
kubernetes_pod_cidrs=
kubernetes_service_cidrs=
template_selection=
scan_window=
rate_or_concurrency_limit=
evidence_location=

Keep production, staging, office, acquisition, and regulated segments as separate network objects. A finding is meaningful only when its source vantage point is preserved.

Deployment workflow¶

1. Create a network for one approved environment in ProjectDiscovery Cloud.
2. Copy the unique install command shown by the platform.
3. Review the generated command before execution:
4. verify the image or binary source;
5. identify where the organization credential is stored;
6. confirm only the required container capabilities are granted;
7. confirm diagnostic and scan-log upload settings match the engagement rules.
8. Run the generated command on the dedicated agent host. For Docker, preserve the platform-generated arguments rather than translating them from memory.
9. Confirm the agent appears under the expected organization, workspace, and network.
10. Compare the subnets reported by the agent with the approved scope. In Kubernetes, separately review node, pod, and service CIDRs.
11. Remove every auto-discovered range that is not explicitly authorized before starting discovery.
12. After a short controlled test, place the agent under the supported process manager appropriate to the environment, such as systemd, Kubernetes, launchd, or NSSM.

Discovery pass¶

Start with one small canary range containing known hosts.

1. Run discovery from the network object against only that canary range.
2. Confirm expected live hosts and services appear.
3. Confirm a deliberately unroutable or denied control range produces no assets.
4. Review unexpected network hardware, dashboards, databases, and orchestration APIs as candidate attack-path nodes.
5. Expand one approved range at a time, preserving the source network and scan identifier.

The key result is vantage-point reachability. The same target should be tested from separate agents when the assessment asks whether segmentation changes exposure.

Use a decision table:

Do not infer a segmentation bypass from inventory alone. Reproduce the relevant connection from the same source vantage point and preserve protocol-level evidence.

Validation pass¶

After discovery, scan an asset group or narrow manual target list with the smallest relevant template set.

1. Select templates by observed protocol, technology, or a specific approved CVE.
2. Run one conservative pass; the agent holds one scan open by default and sizes chunks to host CPU count.
3. Review each finding's confirming request and response.
4. Replay the proof manually from the same network when the template is safe and the engagement permits it.
5. Add a negative control:
6. a patched canary;
7. a route where the component is absent;
8. or the same target from a segment that should not reach it.
9. Classify results as:
10. confirmed and replayed;
11. template-confirmed, replay pending;
12. reachable/version-indicated only;
13. not reproducible.

A banner or version match is not proof of exploitability. Conversely, a Nuclei match should not be escalated beyond what its exact request/response demonstrates.

Attack-path hand-off¶

Shape the output into nodes and edges rather than a flat vulnerability list:

source vantage -> reachable service -> confirmed condition -> next authorized boundary

Prioritize services that can change the reachable graph, such as:

• CI/CD controllers with access to deployment credentials
• virtualization or container control planes
• internal identity and administrative portals
• backup infrastructure
• forgotten web applications bridging multiple segments
• Kubernetes dashboards, kubelet APIs, or management endpoints

Stop at the approved validation boundary. A confirmed foothold-to-service path does not authorize credential collection, destructive actions, or a further pivot.

Evidence to capture¶

• engagement and ProjectDiscovery network names
• agent source segment and redacted agent identifier
• approved and excluded ranges
• discovery and scan identifiers with timestamps
• selected template IDs and template versions
• exact target asset group or manual list
• confirming request and response, with secrets and personal data redacted
• replay command or procedure
• negative-control result
• source-to-target reachability matrix
• limitations, including unrouted segments and excluded protocols

Scan logs are not uploaded unless enabled according to ProjectDiscovery's launch documentation, and diagnostic upload can be disabled. Verify these settings in the deployed version rather than assuming defaults remain unchanged.

Safety boundaries¶

• Use only on networks you own or have explicit written permission to assess.
• Never accept auto-discovered private, pod, service, or adjacent ranges as implicit scope.
• Keep concurrency conservative on fragile appliances, printers, OT, storage, and legacy middleware.
• Exclude state-changing, brute-force, fuzzing, denial-of-service, and destructive templates unless separately approved.
• Do not place the agent in a more privileged segment merely to increase coverage; placement is part of the test model.
• Do not collect credentials, tokens, customer records, or sensitive response bodies for evidence.
• Remove the agent, its capabilities, and enrollment material at engagement close.

Source¶

• ProjectDiscovery: Introducing Internal Network Scanning (July 21, 2026)

The source confirms the agent model, bundled ProjectDiscovery tools, network and Kubernetes CIDR discovery, host requirements, container capabilities, outbound-only connection, evidence model, and default single-scan behavior. Exact installation commands and current platform controls must be taken from the authenticated ProjectDiscovery interface and current documentation.