ExtraHop RevealX 360

Network detections from ExtraHop RevealX 360, with the vendor's own risk bands preserved. Read-only: nothing here changes a detection's status or assignee.

• Connector id: extrahop
• Category: ndr

Configuration

Field	Label	Type	Required	Default	Notes
api_host	API endpoint	string	yes	—	The API Endpoint shown on the RevealX 360 API Access page. Do not include the /oauth2/token suffix.
client_id	REST API credential ID	string	yes	—	—
client_secret	REST API credential secret	secret	yes	—	encrypted at rest · Generated on the RevealX 360 API Access page. An API key works against a sensor or console but is not compatible with the RevealX 360 REST API.
risk_score_min	Minimum risk score	number	no	1	Only detections at or above this risk score are pulled. 1 is every scored detection; the vendor's bands are 1-30, 31-79 and 80-99.

Credential handling

client_secret is encrypted at rest by the credential vault before the row is written, and decrypted only at poll time. The value is never logged and never returned by the API — a read of the saved connector shows the field as set, not its contents. See credential vault.

Capabilities

• pull_alerts

Setup

1. In the console, go to Connectors → Add connector and pick ExtraHop RevealX 360.
2. Fill in the fields above and run Test connection. The test is read-only and does not save anything.
3. Save. Polling starts on a jittered schedule within about a minute; the connector row shows last_sync once the first poll completes.

If last_sync stays empty

The first poll is the honest signal that the credential works. A connector that saves cleanly and never syncs usually means the credential lacks a scope the vendor requires for reads — check the connectors service log for the vendor's own error, which is passed through verbatim rather than summarised.

Getting the credential

RevealX 360 is OAuth2 client credentials, and an API key will not work. The vendor documents this explicitly: a key authenticates against a sensor or a console and is not compatible with the RevealX 360 REST API. If you paste one here the token exchange answers 401, which reads like a wrong secret and is not.

1. In RevealX 360, open System Settings → API Access.
2. Copy the API Endpoint. That is the api_host value. Do not include the /oauth2/token suffix the page shows beside it.
3. Create REST API credentials and copy the ID and the secret.
4. The credential needs the NDR module privilege to read security detections. Without it the connector's test answers 403 and says so.

The severity ladder stops at high, on purpose

ExtraHop publishes three risk bands and no fourth. From the vendor's detections documentation, verbatim: the risk score icon is "color coded by severity as red (80-99), orange (31-79), or yellow (1-30)."

This connector maps them straight through:

ExtraHop risk score	AiSOC severity
80-99	high
31-79	medium
1-30	low

No detection from this connector is ever critical. That is deliberate. Promoting the top band would assert a severity ExtraHop does not publish, which is the same defect as collapsing a vendor's real critical into high, in the other direction. Nothing is lost by it: these events are filed as OCSF Security Findings (class 2001, category 2), which the fusion promoter promotes to an alert regardless of severity.

A detection with no risk score at all is a performance detection rather than a security one. It carries no severity and still becomes an alert.

Network evidence during an investigation

Polling brings you detections. Two read-only verbs bring you the evidence around one address while an analyst or the agent is working an alert:

• lookup_network_flows — the flow and protocol records involving an address, across the client, server, sender and receiver roles.
• lookup_network_device — what the appliance has discovered at an address: role, analysis level, criticality and observed software.

lookup_network_flows needs somewhere for records to live. In RevealX 360 that means a cloud-based recordstore with Premium Investigation. A deployment without one gets a refusal naming the reason, not an empty result: "no flows involving this address" and "this tenant stores no records" are different facts and only one of them is evidence.

Both verbs are read-only and run without approval. Nothing in this integration changes vendor state, including the detection status and assignee fields the API would allow a write on.