> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oasm.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Internal Networks
> Model and scan internal, non-internet-facing network ranges separately from your external attack surface
Attack surface management traditionally focuses on what is exposed to the internet: domains, IPs, and services reachable from outside. OASM extends that model with **internal networks** — network ranges that are not internet-facing but still part of your attack surface. Printers, legacy systems, development servers, and intranet applications all live on internal ranges, and they are routinely the weakest point an attacker pivots through after initial access.
The **Internal Networks** page (reachable from the sidebar) lets you model these ranges, associate them with [workers](/worker) that can reach them, and scan them independently of your external targets. Every [target](/target) is classified by its scope — Internal or External — so the platform can treat the two surfaces differently.
The page lists your networks with **Name**, **Worker agents**, and **Created** columns, and each network opens into a detail view where you manage its worker associations and targets.
## Key concepts
### Internal network
An internal network is a named range of addresses that is scanned from inside your perimeter. It is a container for internal targets and the workers that scan them.
### Scope types
A target is either inside your network (Internal) or exposed to the internet (External):
* **Internal** — the target is not reachable from the internet and is scanned from inside the network. Typical use: intranet apps, printers, legacy systems, internal services.
* **External** — the target is reachable from the internet and is scanned from outside. Typical use: public domains, web apps, public IPs.
### Worker association
An internal network must be reachable to be scanned. A **worker agent** associates with an internal network to scan it — the worker is placed inside (or with connectivity to) that network range, and executes scan jobs against it. External scanning workers do not need this association.
## Why internal networks matter
An attacker rarely starts inside your network — they start outside and move inward. Your internal surface is where the sensitive assets live: file servers, databases, internal dashboards, network-attached printers, and legacy systems that were never meant to face the internet but also never received modern hardening.
Scanning internal ranges separately gives you:
* **Visibility into the post-compromise surface** — knowing what an attacker could reach after the first foothold.
* **A clean separation of concerns** — internal scans do not pollute your external asset inventory, and vice versa.
* **Worker placement flexibility** — each internal network can be scanned by a worker positioned in the right segment, without exposing those ranges to the internet.
## Internal vs. external scanning
Internal and external scans differ in reachability, placement, and what they find:
| Dimension | Internal | External |
| ---------------- | ------------------------------------------------------------------------ | ------------------------------------------------- |
| Reachability | Not reachable from the internet; scanned from inside the perimeter | Reachable from the internet; scanned from outside |
| Worker placement | Worker must sit inside, or have connectivity to, the network range | Worker can run anywhere with internet access |
| Credentials | Often needs internal credentials or agent placement to reach hosts | Usually credential-free, internet-facing probing |
| Typical findings | Printers, legacy systems, intranet apps, internal services, file servers | Public web apps, public domains, exposed services |
The two surfaces should never be mixed: an external scan cannot reach an internal range, and an internal scan would waste time probing ranges that an external scanner already covers.
## Prerequisites
Before you scan an internal network, three things must be in place:
* **A reachable worker.** A [worker](/worker) that can reach the network range must be associated with the network — see [assign a worker](#assign-a-worker-to-the-network).
* **Installed tools.** The [tools](/tools) you want to execute (subdomain discovery, port scanning, website probing, and so on) must be installed in the platform.
* **Internal targets.** Targets marked with the Internal scope type must exist inside the network so discovery has something to run against.
## Create an internal network
Select **Internal Networks** from the sidebar. The page lists existing networks with **Name**, **Worker agents**, and **Created** columns.
The **Create network** button opens the creation form.
Give the network a descriptive name, such as prod-intranet or office-192-168-1-0-24.
Specify the range of addresses the network covers, in the same way you would scope any [target](/target).
Submit the form. The network appears in the list.
## Assign a worker to the network
An internal network is scanned by workers that can reach it:
Select the network from the list to open its detail page.
Assign a worker that is placed inside — or has connectivity to — the network range. The detail page reflects the worker agents associated with the network.
Confirm the worker's placement and scope allow it to reach the network's addresses. See [Worker](/worker) for how worker scope controls which jobs a worker can access.
**A worker placed on a sensitive network can reach everything on it.** Associate a worker only with networks it must scan, and use the narrowest scope that lets it do its job. A broadly scoped worker inside your network is a high-value target if it is compromised.
The network still exists and can hold targets, but no internal scan jobs can run against its range — workers pull jobs through their own association and scope, so a network without an associated worker has no execution path. Associate a worker before you expect discovery to produce results.
## Run discovery against the network
Add targets under the network and mark them as Internal. Targets define the hosts and services to scan; the scope tells the platform this is an internal range.
Execute discovery jobs against the internal targets. The associated worker pulls the jobs and runs the installed [tools](/tools) against the range.
Discovered hosts and services flow into your [assets](/asset) inventory, exactly as external findings do — but tracked as internal findings.
**The scope is a property of the target, not the network.** The internal network organizes and associates ranges and workers; each target within it still has its own Internal or External scope. Keep internal targets consistently marked Internal so reporting and dashboards treat them correctly.
## Manage networks over time
Internal networks are rarely static — segments are added when offices open, reorganized when infrastructure changes, and decommissioned when systems retire:
* **Update** a network's details from its page when its range or purpose changes.
* **Delete** a network once the segment is fully decommissioned. Deleting removes the network container; review its targets first so you do not lose internal scope definitions you still need.
* **Re-assign workers** whenever placement changes, so each network is always scanned by a worker that can actually reach it.
Keep the network list itself as the source of truth for your internal segments: if a range is not listed here, it is not being scanned as internal — and unknown internal ranges are exactly the blind spot internal scanning is meant to close.
## Best practices
* **Segment by worker placement.** Create one internal network per network segment or office location, and associate workers physically placed in that segment. A worker that must route across your whole corporate network is a bigger blast radius if it is compromised.
* **Apply least privilege to internal scanning credentials.** The credentials used to reach internal ranges should have the minimum rights needed to scan — never domain-admin or root-level access shared across networks.
* **Scope internal targets precisely.** Define ranges as narrowly as the environment allows. Broad ranges create noise and slow down discovery.
* **Keep internal and external inventories separate.** Rely on the Internal and External scope types so internal findings never masquerade as internet-exposed assets (and vice versa) in your reports.
* **Use dedicated workers for sensitive ranges.** If a segment contains regulated or high-value systems, dedicate a worker to it and restrict what that worker can access through its scope.
* **Monitor worker health per network.** A network whose associated worker goes offline silently stops being scanned. Treat worker status as part of internal network hygiene, and re-associate promptly after a worker is replaced.
## API
Everything available in the console is also available through the API — see the API Reference tab.
## Related
Define the hosts and services scanned within each network scope
Understand how workers pull and execute scan jobs by scope
Install the scanning tools workers execute against internal ranges
Review the assets and services discovered on internal networks