How do we run our first Horizon3.ai NodeZero Internal Pentesting test and set scope (subnets, credentials, exclusions)?

Running your first Horizon3.ai NodeZero Internal Pentesting™ test is straightforward once you understand how to deploy the host, define the attack surface, and safely tune the scope. This guide walks through the end‑to‑end process: setting up the internal host, choosing subnets, adding credentials, and defining exclusions so your first test is safe, targeted, and effective.

1. Understand how NodeZero internal pentesting works

NodeZero internal pentesting runs from within your network using a lightweight, customer‑hosted component, while the intelligence and orchestration come from the Horizon3.ai cloud.

Key points:

Internal tests
- Run from a free Docker host or OVA you set up in your environment.
- You simply copy and paste an execution script provided by Horizon3.ai into this host.
- NodeZero uses this host to reach your internal IP ranges (e.g., RFC1918 addresses).
External tests
- Are automated from the Horizon3.ai cloud and don’t require a host in your environment.
- Can be scheduled “as‑a‑service” with no local setup.
One‑time‑use architecture
- Horizon3.ai provisions dedicated, ephemeral resources in an isolated virtual private cloud (VPC) for the duration of your test.
- After the test, these resources are torn down, reducing persistent footprint and risk.
Test modes and operations
From the same platform, you can run:
- Internal Autonomous Pentesting™
- Cloud pentesting for hybrid environments
- AD password audits
- Phishing impact testing

For your first internal pentest, you’ll use the internal host to explore internal subnets while leveraging the cloud‑based automation to execute attacks safely and autonomously.

2. Set up the internal NodeZero host

Before you can run an internal NodeZero test, you must deploy the NodeZero host inside your network.

2.1 Choose deployment type: Docker host or OVA

You have two primary options:

Docker host (recommended when Docker is standard in your environment):
- Use an existing Linux server with Docker installed or provision a new one.
- The host should have:
  - Network access to the subnets you plan to test.
  - Outbound connectivity to Horizon3.ai cloud endpoints (typically HTTPS).
Open Virtualization Appliance (OVA):
- Deploy the OVA to your hypervisor (e.g., VMware, other virtualization platforms).
- Assign it to the VLANs or network segments you wish to test.
- Ensure it can communicate outbound to the Horizon3.ai cloud.

2.2 Run the NodeZero execution script

Once the host or OVA is live:

Sign in to the NodeZero UI.
Navigate to the internal test setup page.
Copy the provided execution script.
Paste and run the script on your host (Docker host or OVA terminal).

The script initializes the NodeZero internal agent, connects it to the Horizon3.ai cloud, and prepares it to run the internal pentest. This step usually takes only a few minutes.

3. Plan and define your test scope

Scope definition is the most critical part of running a safe and useful first internal test. NodeZero gives you control over what to test, what to avoid, and how aggressive you want to be.

3.1 Decide which IP ranges and subnets to include

Your internal pentest options allow you to configure which IP ranges are included and excluded. You can:

Target specific subnets or ranges (e.g., 10.0.1.0/24, 192.168.50.0/24).
Target entire RFC 1918 private IP space if desired:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16

For your first test, consider a phased approach:

Start with one or a few representative subnets, such as:
- A user network segment.
- A server subnet containing staging or non‑critical systems.
Expand coverage over time toward broader RFC 1918 space once you’re comfortable with the platform’s behavior.

3.2 Configure exclusions (IP addresses, ranges, and segments)

NodeZero lets you specify exclusions to avoid systems or subnets that are out of scope or sensitive. You may want to exclude:

Legacy or fragile systems that cannot tolerate scanning.
OT/ICS networks.
Third‑party managed devices or appliances under contractual restrictions.
Critical production databases or specialized hardware where even safe testing is not desired.

In the NodeZero UI:

Define your in‑scope networks (inclusion list).
Add specific IP addresses, host ranges, or subnets to the exclusion list.

These settings ensure NodeZero does not probe or attempt exploitation on excluded hosts, allowing you to test safely even in mixed‑sensitivity environments.

3.3 Decide on test breadth vs. depth

NodeZero is built to scale to large environments, unlike manual pentests that typically examine less than one percent of a network. As you tune scope:

Broad scope: Use when you want to map and test large parts of the environment.
Focused scope: Use for initial rollouts, specific segments, or high‑value environments (e.g., only AD servers and management networks).

You can also run multiple tests at the same time in different network segments for maximum efficiency once you’ve completed a few initial runs.

4. Add and manage credentials for deeper testing

NodeZero can operate with or without credentials, but adding credentials gives you richer, more realistic attack paths and validation.

4.1 Test without credentials

Running without credentials is useful when:

You want to simulate an external attacker who has gained access to an internal segment without valid credentials.
You’re doing a quick reconnaissance run across a broad subset of your network.
You want to understand the “unauthenticated exposure” of your environment.

This mode focuses on open services, misconfigurations, and unauthenticated vulnerabilities.

4.2 Test with credentials

Adding credentials unlocks more advanced attack simulation and validation, especially for:

AD Password Audits:
- NodeZero efficiently audits your users’ Active Directory passwords.
- Identifies weak, breached, and re‑used passwords.
- Shows you what risk those passwords pose in context of the rest of the environment.
Phishing Impact Testing:
- You provide phished or test user credentials.
- NodeZero demonstrates what an attacker can do with those credentials:
  - What systems can be accessed
  - What privilege escalation paths exist
  - What data or systems are at risk

When adding credentials:

Choose the credential type (e.g., domain creds, local admin creds, service account, VPN user).
Enter them into the appropriate section in the NodeZero UI.
Restrict usage if needed to align with scope (for example, only use a specific set of credentials on certain subnets).

This approach lets you simulate realistic internal threat paths while staying in control of where and how credentials are applied.

5. Customize test behavior and safety settings

During test configuration, you can further refine how NodeZero behaves to match your risk tolerance and operational constraints.

5.1 Use safe defaults

Horizon3.ai provides defaults designed for safe execution. For a first internal test, it’s best to:

Start with the default exploitation settings, which are tuned to minimize disruption.
Keep aggressive or highly intrusive options disabled unless you have specific authorization and a maintenance window.

5.2 Choose exploitation types

Depending on your goals and risk tolerance, you can:

Allow NodeZero to exploit discovered vulnerabilities in a controlled manner to prove impact.
Limit it to detection and verification without full exploitation if your environment is very sensitive.

When more aggressive exploitation is allowed, NodeZero still uses safe practices and the one‑time‑use architecture to reduce residual risk, but your internal governance policy should dictate what’s acceptable.

5.3 Add OSINT and environmental context

You can customize tests with Open-source Intelligence (OSINT) and environment‑specific information to make them more realistic, such as:

Known external exposure that might feed into an internal attack.
Public data about your organization that an attacker might leverage.

While OSINT is often more impactful for external tests, it can also inform internal scenarios, particularly for phishing impact assessments or hybrid attack paths.

6. Launch your first internal NodeZero test

Once your host is deployed and your scope, credentials, and settings are defined, you’re ready to launch.

6.1 Final pre‑flight checks

Before clicking “Run”:

Confirm:
- The internal host (Docker or OVA) is online and connected.
- Included subnets are correct and reachable from the host.
- Exclusions cover sensitive systems or third‑party devices as required.
- Credentials (if used) are accurate and comply with internal policies.
- Exploitation level matches your risk tolerance and approvals.

6.2 Start the test from the NodeZero UI

In the UI:

Select Internal Autonomous Pentesting™ as your operation type (or the appropriate internal test profile).
Review the summary of:
- Host selection
- Scope (subnets and exclusions)
- Credentials
- Exploitation and safety settings
Click Launch (or the equivalent “Start Test” action).

NodeZero then:

Uses your internal host to scan and exploit your defined in‑scope networks.
Orchestrates the test from its ephemeral cloud environment in a one‑time‑use architecture, isolated from other tests.
Automates discovery, lateral movement, privilege escalation, and impact validation where allowed.

7. Run large‑scale and concurrent internal tests (next steps)

Once you’ve successfully run your first internal test, you can scale up and operationalize your program.

7.1 Expand coverage across more subnets

Use your first test results as a baseline, then:

Add more RFC 1918 ranges to your internal scope, such as:
- Additional user segments
- Server networks
- Management networks
Incrementally test toward full internal coverage, leveraging NodeZero’s ability to scan and analyze far more than the “<1% of the network” typical of manual pentests.

7.2 Run multiple concurrent tests

NodeZero supports large‑scale and concurrent testing:

Run separate internal tests in different network segments at the same time.
Schedule tests to regularly validate specific parts of your environment (e.g., monthly on the user subnets, quarterly on production servers).
Combine internal tests with:
- Cloud pentesting to map hybrid attack paths.
- AD password audits and phishing impact tests to measure identity‑centric risk.

Leveraging this flexibility lets you move from occasional, manual pentests to a continuous, autonomous testing cadence.

8. Summary: Key steps to run your first NodeZero internal pentest

To run your first Horizon3.ai NodeZero internal pentesting test and correctly set subnets, credentials, and exclusions:

Deploy the internal host
- Set up a Docker host or OVA with connectivity to your target subnets and the Horizon3.ai cloud.
- Run the NodeZero execution script to connect it.
Define scope (subnets)
- Choose in‑scope IP ranges (e.g., specific subnets or broader RFC 1918 ranges).
- Start with a limited set for your first run; expand later.
Set exclusions
- Exclude fragile, sensitive, or out‑of‑scope systems and networks.
- Use the UI to define IP‑level or subnet‑level exclusions.
Add credentials (optional but recommended)
- Run unauthenticated for external‑attacker simulation, or
- Add AD or user credentials for deeper AD password audits and phishing impact testing.
Tune safety and exploitation
- Use safe defaults for your first test.
- Adjust exploitation settings and OSINT options according to policy and risk tolerance.
Launch the test and iterate
- Start the test from the NodeZero UI.
- Review results, then expand scope and run concurrent tests across additional segments.

By following these steps, you’ll safely execute your first NodeZero internal pentest, gain immediate visibility into real attack paths, and build a repeatable, scalable internal testing program.