home / home-lab / isolated research range
Isolated Research Range
A disposable, default-deny lab for reproducing vulnerabilities safely, with the network instrumented so every run is also a detection exercise.
Objective
Reproducing a vulnerability means running code and traffic I do not fully trust. The range exists so that happens somewhere with a known boundary, no route to the internet, and no real data. It supports the “smallest reproduction in an isolated, reproducible environment” part of my method.
Every run has two outputs: the reproduction itself, and what the instrumented network and hosts saw, which feeds the detection rules on this site.
Architecture
trust zones, flows and logging pointsLegend
- A control host: builds target images and drives scenarios. No target runs here.
- B gateway + sensors: the only path into the target network. A default-deny filter plus network and host sensing.
- C target network: disposable virtual machines with no uplink. Reverted to a clean snapshot after each run.
- D log store: append-only and outside the range, so a compromised target cannot rewrite its own history.
- E export: a one-way, read-only path for results, reviewed before anything leaves.
- Solid arrow: permitted data flow. Dashed arrow: reviewed, manual release.
Trust zones
| Zone | Trust | May reach | Logged |
|---|---|---|---|
| A control host | Trusted | B (management only) | Command history |
| B gateway | Trusted, hardened | A, C, D | Packet filter, network metadata |
| C targets | Untrusted | B only, on listed ports | Host audit, network metadata |
| D log store | Trusted | Receives from B and C | Access log |
Build and reproducibility
Target machines are described declaratively and built from pinned inputs, so the environment for a reproduction can be rebuilt exactly and its definition committed next to the write-up. A clean snapshot is taken after build, and every run starts from it.
- Pinned toolchain and package set for each target, recorded with the report.
- Clean snapshot per target; revert after every run, success or failure.
- No shared writable state between runs, and no shared credentials between targets and the control host.
Monitoring
The gateway records network metadata and runs signature-based inspection on traffic crossing into and out of the target network. Targets run kernel audit rules that record process execution and changes to sensitive files, and ship those events to the log store.
This is the same data the published Linux detections assume, so each rule can be tested against a real run before it is published.
Hardening of the range itself
- Default-deny at the gateway: nothing is allowed unless a scenario lists it.
- No route from the target network to the internet, to the control host, or to any machine holding real data.
- Targets are never given real credentials, real data or real network addresses; documentation address ranges only.
- Results leave only through the reviewed export path.
- The control host and gateway are patched and kept minimal; the targets are deliberately not.
Scenario: reproducing an authorisation bypass
worked exampleObjective
Confirm that an API route behind a Next.js application is reachable without a session when the middleware matcher covers only the page routes (see finding WM-2026-001).
Setup
One target VM running a minimal application with the vulnerable matcher, built from the pinned definition, and one client VM. Both in the target network, reverted to a clean snapshot.
What was run
A request to the protected page route (expected redirect) and the same resource through the API route, with no session cookie. Then a request with a valid session, as a control.
What was detected
Network metadata showed 2xx responses on the API path with no session cookie in the request, which is the signal the detection in the finding relies on. Nothing was observed leaving the target network.
How it was handled
Targets were reverted and the logs archived with the report. The reproduction steps were reduced to the minimum request set before writing the finding.
What changed
A route-coverage test was added to the report checklist: every route under a protected prefix is requested without a session.
Limitations
- Virtual machines share a hypervisor; a hypervisor escape would defeat the boundary. Anything that needs stronger separation is run on separate hardware.
- Signature-based inspection sees known patterns only; the range is for learning what a behaviour looks like, not for proving something is undetectable.
- Results from a small lab do not show how a technique behaves at production scale.
Tags
#lab#isolation#detection#linux