Vectra NDR (WIP)

Pulls the hosts Vectra has observed on the network, along with its threat and certainty scoring and the artefacts it used to identify each one.

Type name	vectra_ndr
Creates	Endpoints
Runs on	A sensor with network reach to the Vectra appliance
Presence flag	vectra_exists
Field prefix	vectra_

What it contributes

Vectra sees hosts by their traffic, so it finds machines that carry no agent and appear in no directory.

• Identity — host ID, name, LUID, URL, host URL
• Network — IP, previous IPs, last source, active traffic flag
• Scoring — threat score (t_score), certainty score (c_score), severity
• Detections — detection set, detection profile, last detection timestamp, custom model flag
• Criticality — key asset flag, targets-key-asset flag
• Ownership signals — probable owner, privilege level, privilege category
• Workflow — state, assigned to, assigned date, past assignments, notes and note modification metadata, tags, groups
• Host artefacts — MAC, rDNS, DNS, DHCP, Kerberos, NetBIOS, VM UUID, VM machine info, Windows Defender name

It writes the shared fields names, private_ip, mac and updated_at.

vectra_probable_owner is a free ownership signal

Vectra infers a likely user from observed authentication traffic. It is weaker than a directory-sourced owner but costs nothing extra, and it covers hosts the ownership integrations cannot see.

Host artefacts are the correlation surface

vectra_host_artifact_set_mac, _dns, _netbios and _vm_uuid are what let a traffic-derived host line up with an agent-derived one. They are worth surfacing in a layout if you rely on Vectra for coverage of unmanaged segments.

Requirements

The integration is outbound-only: it reads the Vectra API on a schedule, so nothing is installed on the appliance, no traffic is mirrored to the platform, and nothing has to reach into the deployment.

Network access

From	To	Protocol	Port
The sensor running the integration	The Vectra appliance named in URL	HTTPS over TCP	443, unless the appliance URL names another

One host: the token is sent as a request header rather than exchanged at a separate token endpoint, so the paged host read is the only call made. The appliance is an internal destination, so the rule belongs in the internal firewall rather than at the perimeter.

If the appliance presents a certificate the sensor host does not trust, install the CA on the host in preference to enabling Ignore SSL — the token is sent on every request.

Access in Vectra

Need	Why
An account that can issue API tokens	The credential is a Vectra API token — see Permissions in Vectra
That account holding a read-only role with host access	Vectra tokens carry their owner's permissions, so the role, not the token, decides what the run can read
An appliance version exposing API v2.5	The run pages /api/v2.5/hosts

In this deployment

Need	Why
A registered, healthy sensor with reach to the appliance	The integration runs on a sensor, on the platform's schedule — see Sensors

There are no special host requirements beyond a sensor that is checking in — this integration reads Vectra's findings rather than observing traffic itself, so it needs none of the NIC configuration a passive sensor does.

Configuration

Field	Required	Notes
Name	Yes	Label for this instance
URL	Yes	Vectra appliance base URL
Token	Yes	Vectra API token
Cookies	No	Extra cookies added to requests
Sensor	Yes	Sensor that will run the integration
Ignore SSL	No	Skips certificate validation

The run pages /api/v2.5/hosts, following the next link until exhausted.

Permissions in Vectra

Issue an API token for an account with read access to hosts. Vectra tokens carry the permissions of their owning account, so create one under a read-only role.

TODO

Confirm which Vectra roles grant read on /api/v2.5/hosts, and note the minimum appliance version exposing v2.5.

See also

• Sensors — the platform's own passive sensor, which covers the same blind spot from inside your own deployment
• Integrations overview — the shared configuration model