Vectra Platform API Guide 3.4
Vectra Platform API Guide 3.4
o /v3.4/groups
o /v3.4/groups/<id>
October 2024
Adds query parameter “fields” and “exclude_fields” for the
/api/v3.4/entities endpoint.
September 2024
New endpoints for querying unique host counts and records by given
timespan:
o /v3.4/unique_host_count
o /v3.4/unique_host_count/audit
o /v3.4/unique_host_count_monthly
o /v3.4/unique_host_count_monthly/audit
Adds support for downloading the curated ruleset for Vectra Match
o /api/v3.4/vectra-match/download-vectra-ruleset
/api/v3.4/health/detection
July 2024
New endpoints for health monitoring of external connectors and
EDR’s have been added:
o /v3.4/health/external_connectors
o /v3.4/health/external_connectors/details
o /v3.4/health/edr
o /v3.4/health/edr/details
o /v3.4/health/network_brain/ping
DATE COMMENT
July 2024
Removal of the following endpoints:
/api/v3.4/events/account_scoring/
/api/v3.4/events/account_detection/
/api/v3.4/entities/<id>/notes/:
/api/v3.4/entities/<id>/notes/<id>/:
/api/v3.4/tagging/entity/<id>/:
/api/v3.4/tagging/entity/:
o ‘entity_type’ parameter
/api/v3.4/detections/:
/api/v3.4/detections/<id>/:
o ‘c_score’ parameter/field
o ‘t_score’ parameter/field
o ‘targets_key_asset’ parameter/field
o ‘category’ parameter/field
o ‘c_score_gte’ parameter
o ‘t_score_gte’ parameter
/api/v3.4/entities/:
/api/v3.4/entities/<id>/:
o ‘entity_type’ parameter/field
o ‘entity_importance’ field
/api/v3.4/events/entity_scoring/:
o ‘entity_type’ parameter/field
o ‘entity_importance’ field
o ‘last_detection_id’ field
o ‘last_detection_type’ field
o ‘last_detection_url’ field
/api/v3.4/events/detections/:
/api/v3.4/lockdown/:
o ‘entity_type’ parameter/field
June 2024
Adds support for uploading large rules files to Vectra Match:
/api/v3.4/vectra-match/rules/upload
Detections
Entities
Events
Groups
Health
• Added ability to query health information for external connectors via the endpoint
v3.4/health/external_connectors
• Added ability to query detailed health information for external connectors via the endpoint
v3.4/health/external_connectors/details
• Added ability to query health information for EDR connections via the endpoint
v3.4/health/edr
• Added ability to query detailed health information for EDR connections via the endpoint
v3.4/health/edr/details
Lockdown
Notes
Tagging
• ‘tag_id’ key renamed to ‘entity_id’ in the response. The value of this key and the path for this
endpoint is unchanged.
• Deprecating the param ‘entity_type’.
Users
• Updates /api/v3.4/users endpoint to remove ‘username’ and ‘last_login’ fields and to add
‘name’, ‘verified’, and ‘identities’ fields in the list Users response, adds ability to add Users.
• Adds ability to view, update, and delete single Users via the endpoint /api/v3.4/users/<id>
• Adds ability to list the available roles for user creation via the endpoint
/api/v3.4/users/roles
Vectra Match
Overview
A REST API is available for administrators and developers to integrate Vectra’s breach detection data
into their applications. Vectra RESTful API provides access to security event data, platform
configuration, and health information via URI paths.
Vectra REST API is based on open standards. You can use any web development language to access
and retrieve information via the API. A common use-case would be to retrieve security event information
The REST API can be accessed via HTTPS connection to the interface IP address of the Vectra brain.
The data in the response to the API query is in JSON format.
Examples of security event data that can be integrated into your application:
API Clients
Getting access to the Vectra Platform API is done through the creation of an API Client. Creation of an
API Client will provide a set of OAuth 2.0 credentials that will be used to gain authorization to the Vectra
Platform API. Please note that management of API Clients is restricted to Detect users with the role of
“Super Admin”. To create an API client, log into your Detect portal and navigate to Manage > API
Clients.
• Role – the role maps the API Client to a set of permissions, similar to the way a Detect UI user
would be assigned a role. The role must be one of the following:
• Read-Only
• Restricted Admin
• Security Analyst
• Settings Admin
• Auditor
Once you have entered the API Client information, select ‘Generate Credentials’ to obtain your client
credentials.
First you must authenticate using the Client ID and Secret Key you obtained when creating your API
Client.
Example Request:
POST https://<vectra_portal_url>/oauth2/token
Authorization: Basic <HTTPBasic(<client_id>:<secret_key>)>
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
Example Response:
{
"access_token": "Z0FBQUFB...",
"expires_in": 21600,
"refresh_expires_in": 86400,
Notice that the response includes an access_token and refresh_token which will be used to make
subsequent API requests as a client, outlined in the next sections.
Also, be sure to note the differences in the expires_in and refresh_expires_in timers, which are
expressed in seconds. An access_token will expire in 6 hours, while a refresh_token will take 24 hours to
expire. Once your access_token has expired, you will need to reauthenticate your API client with your
client_id and secret_key in order to receive a new access_token. If your refresh_token has not expired,
you may use it to obtain a new access token using the previous authorization grant.
A refresh token will have the following syntax when returned as part of the /oauth2/token response:
“refresh_token”: “eyJzdWIi..."
As of March 2023, if you manually attempt to refresh your token via an API Client, copying and pasting
this value as is will be valid.
There should be no formatting changes required for using the refresh token via script. For example, in
Python, accessing and saving the refresh token should look like this:
refresh_token = response.get(‘refresh_token’)
If you are using Insomnia for API requests, we recommend the following setup for basic Authentication
and refresh token requests:
1. Create a new environment with your API client credentials. Select the “No Environment”
dropdown found on the top left corner of Insomnia, choose “Manage Environments”.
2. Use the example data below to create a new sub environment. Give the environment a unique
name.
Next, we’ll need to populate Form data for both types of requests: initial auth and refresh.
When authenticating initially for basic auth, form data should just include grant_type:
client_credentials (example below):
Insomnia should now be configured to automatically grab and use the refresh_token field
returned.
If you prefer Postman, we have a public API collection you can import to your environment and use.
Example Request:
POST https://<vectra_portal_url>/oauth2/token
Authorization: Basic <HTTPBasic(client_id:secret_key)>
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
refresh_token=<refresh_token>
Example Response:
{
"access_token": "Z0FBQUFB...",
"expires_in": 21600,
"token_type": "Bearer"
}
Example Response:
{
"count": 16,
"next": "http://<vectra_portal_url>/api/v3.4/accounts?page=1",
"previous": null,
"results": [
...
}
Example Response:
{
"count": 25,
"next": "http://<vectra_portal_url>/api/v3.4/detections?page=2",
"previous": null,
"results": [
...
}
Full sample output for accounts and detections endpoints can be found in Appendix A.
The following rate limits are enforced across all v3.4 API endpoints and methods:
When request submissions exceed the steady-state request rate and burst limits, the v3.4 API will
throttle requests and return a 429 Too Many Requests error response.
Botnet /detections?detection_category=botnet
Reconnaissance /detections?detection_category=reconnaissance
Exfiltration /detections?detection_category=exfiltration
Info /detections?detection_category=info
The API query performs partial word match. For example, you can use /detections?
detection_category=recon to query all Reconnaissance category detections.
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Detections
next URL to the next page of output string Useful when using a web-
based REST API browser.
previous URL link to the previous page of output string Useful when using a web-
based REST API browser.
The following table lists the fields and descriptions present in a Detection. These Detections will be
contained inside the ‘results’ field, which is a top-level field described in the table above.
The available options and filters for detection set is listed below.
QUERY COMMENT
Marking/unmarking a detection as fixed requires the following elements be present in the request body:
• detectionIdList
• mark_as_fixed
An example of using the PATCH method to mark or unmark a detection as fixed can be found in
Appendix A.
Version 3.4 of the API supports download of PCAP for a particular detection. Users can perform a GET
using the following URL format to download PCAP for any detection:
https://<vectra_portal_url>/api/v3.4/detections/<id>/pcap
The download of PCAP via API is subject to RBAC rules just like UI access. The api client role requires
the ‘view pcap’ permission (i.e. security analyst) in order to access PCAP data.
Accounts
Account objects contain information related to accounts observed in the environment. The URL to
retrieve all accounts is https://<vectra_portal_url>/api/v3.4/accounts and uses OAuth2
authentication.
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Accounts
The following table lists the fields and descriptions present in an Account. These Accounts will be
contained inside the ‘results’ field, which is a top-level field described in the table above.
The available options and filters for account set is listed below.
Tagging
The tagging API can be used to manage tags for accounts and detections.
https://<vectra_portal_url>/api/v3.4/tagging/account/<account_id>
https://<vectra_portal_url>/api/v3.4/tagging/host/<host_id>
https://<vectra_portal_url>/api/v3.4/tagging/detection/<detection_id>
To manage tags for any of the above entities, use the following URL with the type of entity specified as a
query parameter:
https://<vectra_portal_url>/api/v3.4/tagging/entity/<entity_id>?type=type
The following table lists the fields and a description of the various elements for tagging operations.
Detailed examples of using GET and PATCH methods on tags is described in Appendix A.
tags List of tags for the host list of strings When doing a PATCH operation,
or detection object. the object will be updated to
match the list of tags provided.
To remove tags for a host or
detection set tags to an empty
list.
message Error message if string Only present when status is
operation was ‘failure’ of operation is a failure.
unsuccessful.
One of the following query parameter is required for the /tagging/entity/<entity_id> endpoint in order to
differentiate the object type:
Triage
Version 3 of triage API supports GET, POST, PUT, and DELETE. The API endpoint for accessing triage
rules is https://<vectra_portal_url>/api/v3.4/rules
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3 API for Triage rules.
ELEMENT DESCRIPTION TYPE NOTES
count The number of object integer
IDs retrieved in the
output
next URL to the next page of string Useful when using a web-based
output REST API browser.
previous URL link to the previous string Useful when using a web-based
page of output REST API browser.
results A list of all Triage rules list
(described in the table
below) being returned
by the query
The following table lists the fields and descriptions present in a Triage rule. These Triage rules will be
contained inside the ‘results’ field, which is a top-level field described in the table above.
ELEMENT DESCRIPTION TYPE NOTES
id The ID of the Triage rule integer
url A v3 URL to the Triage string Useful when using a web-based
rule REST API browser.
enabled Describes if the Triage Boolean
rule is enabled
created_timestamp Describes the time the string Timestamp format:
Triage rule was created YYYY-MM-DD HH-MM-SS GMT
last_timestamp The timestamp when string Timestamp format:
this Triage filter was YYYY-MM-DD HH-MM-SS GMT
triggered
The format of version 2.2 Triage rules is based on AND/OR logic, making them more flexible and
customizable to your specific situation. Both ‘source_conditions’ and ‘additional_conditions’ are now
saved as JSON blobs which represents a tree-like structure. Each tree node is represented in the
following format:
{operator: operand}
For non-leaf nodes: A list of children tree nodes of the form [{operator: operand}, {operator:
operand}, …]
For leaf nodes: A dictionary of the form:
{
‘field’: <FIELD NAME>,
‘values’: [
{‘value’: [<VALUE>]}
],
‘group’: [
{‘value’: [<GROUP ID>]}
]
}
Stipulations on the format of the top-level tree structure as of 2.2 is that the top-level operator must be
an ‘OR’ node, with a single ‘AND’ node as the only child. The ‘AND’ node may have an arbitrary number
of leaf node children. All valid 2.2 Triage rules will look as follows:
{
‘OR’: [
{ ‘AND’: [
<LEAF NODE 1>,
<LEAF NODE 2>,
…
<LEAF NODE N>,
]}
]
}
source_conditions and additional_conditions have different fields that can be used in their leaf nodes.
For source_conditions, the following fields are valid: ip, host, account, sensor. The fields ‘ip’ and ‘host’
also support triaging on groups, meaning that an ip or a host leaf node can be given an IP Group or Host
Group ID, and the Triage rule will apply to every IP/host in the specified group.
For additional_conditions, the following fields are valid: remote1_ip, remote1_proto, remote1_port,
remote1_dns, remote2_ip, remote2_proto, remote2_port, remote2_dns, account, named_pipe, uuid,
Assignments
Assignments are used to assign account objects to analysts for investigation. This information includes
but is not limited to:
• Assigned to user
• Assigned by user
• Date assigned
• Date resolved
• Events
• Outcome
• Account ID
• Triaged detections
Assignment Resolution
Once completed, assignments can be resolved. Assignment resolutions provide a way to label and track
the outcomes of assignments. Outcomes get recorded in the assignment’s history.
Outcome choices may include one of the following built-in assignment outcomes:
Alternatively, users can choose to define their own Custom outcomes for reporting purposes.
The following table lists fields and description of the various elements for assignments.
ELEMENT DESCRIPTION TYPE NOTES
count Number of object integer
IDs retrieved in the
output
next URL to the next string
page of output
previous URL link to the string
previous page of
output
results List of users list of objects
returned in the
output
The following table lists the fields and descriptions present in an assignment. These elements will be
contained inside the ‘results’ field, which is a top-level field described in the table above.
The available options and filters for assignments are listed below.
Users
User objects contain information about users that have access to the Vectra system. These should be
used to create assignments via the Assignments endpoint. The URL to retrieve all user accounts is
https://<vectra_portal_url>/api/v3.4/users and uses OAuth2 authentication.
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Users.
The following table lists the fields and descriptions present in a User. These Users will be contained
inside the ‘results’ field, which is a top-level field described in the table above.
The available options and filters for account set is listed below.
An example of using the GET, POST, PATCH, and DELETE methods for Users can be found in Appendix
A.
• Detection Events
• Audit Log Events
• Entity Scoring Events
These endpoints make use of a checkpoint value, which is used in subsequent requests to get new
events beginning from the last checkpoint.
Detection Events
Detection Events are generated upon initial detection and for each update of the detection.
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Detection Events.
The following table lists the fields and descriptions present in an Account Detection Event.
The available query parameters to filter for Account Detection Events are listed below.
The URL to retrieve accounts detection events from the last checkpoint is
https://<vectra_portal_url>/api/v3.4/events/account_detection?from=101
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Audit Log Events.
The following table lists the fields and descriptions present in an Audit Log Event.
The available query parameters to filter for Audit Log Events are listed below.
The URL to retrieve accounts scoring events from the last checkpoint is
https://<vectra_portal_url>/api/v3.4/events/audits?from=101
Host scoring events prior to May 2023 will have score_decrease enabled to false, so that all scoring
events will be returned. Host scoring events starting May 2023 will be able to be filtered by the
include_score_decreases query param.
NOTE: You must include the type query param in your request to specify if you would like ‘account’ or
‘host’ entity scoring events.
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Entity Scoring Events.
The available query parameters to filter for Entity Scoring events are listed below.
Entities
Entities is an overarching term to cover various types of models, including Accounts and Hosts. Entities
are returned with an entity type, indicating what type of entity it is, along with urgency, importance, and
fields from the original model.
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Entities.
The following table lists the fields and descriptions present in an Entities object.
The available query parameters to filter for Entities are listed below.
Entity Notes
The Entity Notes API can retrieve a list of all notes associated with an entity (Account, Host).
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Entity Notes.
The following table lists the fields and descriptions present in a Group object.
The available query parameters to filter for Entity Notes are listed below.
Groups
The groups API can retrieve a listing of groups that are defined on the system.
Version 3.4 of groups API supports GET, PATCH, POST, and DELETE to not only query the list of
account/IP/host/domain groups, but also create, modify, or delete them.
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Groups.
Note that dynamic groups with large amounts of users may cause the endpoint to time out. To avoid
this, please set the “include_members” query param to False.
The following table lists the fields and descriptions present in a Group object.
The available query parameters to filter for Groups are listed below.
An example of using the GET, POST, PATCH, and DELETE methods for Groups can be found in
Appendix A.
Lockdown
This is a new endpoint for to retrieve a list of entities (Accounts. Hosts) that are currently in “lockdown”
mode. API responses may vary depending on product subscriptions (Network, AWS, M365).
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Lockdown.
The following table lists the fields and descriptions present in an lockdown result.
id Autoincrementing ID integer
lock_event_timestamp Time when the lockdown occurred. string
ISO8601
locked_by User who issued the lockdown. string
unlock_event_timestamp Time when the lockdown expires. string
ISO8601
entity_id ID of the related entity. integer
entity_name Name of the related entity. string
type Type of the related entity. string ‘Account’ or
‘Host’
Hosts
API responses may vary depending on product subscriptions (Network, AWS, M365).
The following table lists the fields and descriptions present in an Entities object.
The available query parameters to filter for Entities are listed below.
Health
API responses may vary depending on product subscriptions (Network, AWS, M365).
updated_at string
ISO8601
connectivity object
sensors array
last_check string
affected_metadata_hours string Field not present if status is ‘OK’
error string
status string Status can be OK, WARNING, CRITICAL, or UNKNOWN
name string
serial_number string
luid string
ip_address string
sensors list of Sensor Information
objects
status string
name string
serial_number string
package_version string
last_seen string
ISO8601
ip_address string
luid string
location string
detection object Detection model health
updated_at string
ISO8601
check_results array One entry per failing detection model, or exactly one entry if
all detection models are healthy
name string
detection_type string
message string
status string Status can be OK or CRITICAL
event_timestamp string
ISO8601
The available query parameters to filter for Health are listed below.
Additionally, Health allows querying by field by appending the field to the end of the request url. For
example: https://<vectra_portal_url>/api/v3.4/health/memory will return only memory fields.
Health information is refreshed every 10 minutes. To get health information at the current time, use the
‘live’ query parameter. If refreshing health data takes more than 30 seconds, results will be stored and
can be accessed by calling the endpoint again without the ‘live’ parameter.
external_connector object
connection_status string Current connection status. ‘enabled’ or ‘disabled’
auth_status object Authentication status. ‘authenticated’,
‘not_authenticated’, or ‘not_configured’
error_states object List of current error states. If a connection is in
error, the error message will be listed here.
lockdown_status string If lockdown can be enabled for a tenant, the
enabled status will be reflected. ‘enabled’ or
‘disabled’
The available query parameters to filter for Health – External Connectors are listed below.
Health information is refreshed every 10 minutes. To get health information at the current time, use the
‘live’ query parameter. If refreshing health data takes more than 30 seconds, results will be stored and
can be accessed by calling the endpoint again without the ‘live’ parameter.
external_connector object
details object Dictionary containing detailed information for an
external connector. Detail information varies per
connector.
The available query parameters to filter for Health – External Connector Details are listed below.
Health – EDR
The URL to retrieve health data is https://<vectra_portal_url>/api/v3.4/health/edr and
uses OAuth2 authentication.
Health information is refreshed every 10 minutes. To get health information at the current time, use the
‘live’ query parameter. If refreshing health data takes more than 30 seconds, results will be stored and
can be accessed by calling the endpoint without the ‘live’ parameter.
edr object
connection_status string Current connection status. ‘enabled’ or ‘disabled’
auth_status object Authentication status. ‘authenticated’,
‘not_authenticated’, or ‘not_configured’
error_states object List of current error states. If a connection is in error, the
error message will be listed here.
lockdown_status string If lockdown can be enabled for a tenant, the enabled
status will be reflected. ‘enabled’ or ‘disabled’
The available query parameters to filter for Health – EDR are listed below.
Health information is refreshed every 10 minutes. To get health information at the current time, use the
‘live’ query parameter. If refreshing health data takes more than 30 seconds, results will be stored and
can be accessed by calling the endpoint again without the ‘live’ parameter.
edr object
details object Dictionary containing detailed information for an EDR
connection. Detail information varies per connection.
EDR Description
The available query parameters to filter for Health – EDR Details are listed below.
Call this endpoint to receive confirmation that network brain is connected. Will also provide information
on time taken to reach the brain.
results object
ping string Brain enabled status.
latency string Time taken to get brain status in milliseconds.
The following table lists the top-level fields present in the response for a GET request to the v3.4 API for
Vectra Match enablement
The enablement POST endpoint requires a json body with two parameters, device_serial and
desired_state (WARNING: POSTing to the enablement endpoint causes a reboot if changing state):
The following table lists the top-level fields present in the response for a POST request to the v3.4 API
for Vectra Match enablement
Examples of GET and POST methods on the vectra-match/enablement endpoint are shown in Appendix
A.
The stats GET endpoint allows for a single optional query parameter, device_serial. If device_serial is
not provided, information for all enabled and previously-enabled devices will be returned.
The following table lists the top-level fields present in the response for a GET request to the v3.4 API for
Vectra Match stats
The status GET endpoint allows for a single optional query parameter, device_serial. If device_serial is
not provided, information for all enabled and previously-enabled devices will be returned.
The following table lists the top-level fields present in the response for a GET request to the v3.4 API for
Vectra Match status
The following table lists the top-level fields present in the response for a GET request to the v3.4 API for
Vectra Match available devices
The following table lists the top-level fields present in the response for a GET request to the v3.4 API for
Vectra Match rules
The rules DELETE endpoint requires a json body with a single parameter, uuid:
The following table lists the top-level fields present in the response for a DELETE request to the v3.4 API
for Vectra Match rules
Examples of GET and DELETE methods on the vectra-match/rules endpoint are shown in Appendix A.
Once a rules file upload has been created, the API will return a uuid. This uuid will be used for managing
the ruleset upload from that point forward. The upload uuid is different to the rules file uuid.
The rules POST endpoint takes the following JSON body parameters:
resp = requests.post("https://<vectra_management_ip>/api/v3.4/vectra-
match/rules/upload/", headers={"Authorization":"Bearer <token>"},
verify=False, json=payload
The following table lists the top-level fields present in the response for a POST request to the v3.4 API
for Vectra Match rules upload
The PATCH endpoint requires a query parameter and json body parameters:
The following table lists the top-level fields present in the response for a PATCH request to the v3.4 API
for Vectra Match rules
The following table lists the top-level fields and descriptions present in the response for a bulk GET
request to the v3.4 API for Vectra Match Rules Uploads.
The following table lists the fields and descriptions present in an Upload object.
The rules GET endpoint can take a single query parameter, uuid:
The GET endpoint will return a single upload object if it exists. See bulk get endpoint above for details of
the upload object.
Examples of GET, POST, and PATCH methods on the vectra-match/rules/upload endpoint are shown in
Appendix A.
The following table lists the top-level fields present in the response for a GET request to the v3.4 API for
Vectra Match assignment
The assignment POST endpoint requires a json body with two parameters, device_serials and uuid:
The following table lists the top-level fields present in the response for a POST request to the v3.4 API
for Vectra Match assignment
The assignment DELETE endpoint requires a json body with two parameters, device_serial and uuid:
The following table lists the top-level fields present in the response for a DELETE request to the v3.4 API
for Vectra Match assignment
Examples of GET, POST, and DELETE methods on the vectra-match/assignment endpoint are shown in
Appendix A.
The alert stats GET endpoint allows for a single optional query parameter, device_serial. If device_serial
is not provided, information for all enabled devices will be returned.
The following table lists the top-level fields present in the response for a GET request to the v3.4 API for
Vectra Match alert stats
Threat Feeds
API responses may vary depending on product subscriptions (Network, AWS, M365).
To obtain the list of threat feeds (GET) or to create a new threat Feed (POST) use the following URL:
https://<vectra_management_ip>/api/v3.4/threatFeeds
To obtain details of any threat feed (GET), add a file to a threat feed (POST), update a threat feed
(PATCH), or delete a threat feed (DELETE) use the following URL:
https://<vectra_management_ip>/api/v3.4/threatFeeds/<id>
To download a threat feed file (GET) or delete a threat feed file (DELETE), use the following URL:
https://<vectra_management_ip>/api/v3.4/threatFeeds/<id>/file
There is a hard limit for file upload sizes of 5 MB at this time. If you receive a “413 Payload Too Large”
error while uploading a file via POST /api/v3.4/threatFeeds/<id>, the file you are attempting to
upload is too large. There is no limit on the amount of threatFeeds files you can upload, so we
recommend splitting apart your STIX file into smaller parts and uploading each as its own threat feed so
that each file is below the 5MB limit.
The following table lists the fields and a description of the various elements for the “threatFeeds”.
Detailed examples of using GET, POST on threatFeeds is described in Appendix A
The available query parameters to filter for Threat Feeds are listed below.
Users with a valid license can request a download link to the file via GET to
https://<vectra_management_ip>/api/v3.4/vectra-match/download-vectra-ruleset
The unique hosts observed API can be used to view the count of all distinct hosts seen during a
calendar month, for each month dating back one year. The endpoint is only available to Restricted
Admin clients.
To obtain the list of unique hosts observed (GET) use the following URL:
https://<vectra_management_ip>/api/v3.4/unique_hosts_observed_monthly/
The following table lists the fields and a description of the various elements for the month results.
Detailed examples of using GET on unique_hosts_observed_monthly is described in Appendix A
unique_hosts_observed Count of unique hosts integer Includes hosts seen from 00:00
observed between UTC on first day of month through
month_start and 23:59 UTC on last day of month
month_end
The available query parameters to filter for Unique Hosts Observed Monthly are listed below.
Note if start and end are left blank, default start will be the beginning of the month of the previous year.
Default end will be the current day.
The unique hosts observed API can be used to view of all the distinct hosts seen during a calendar
month, for each month dating back one year. The endpoint is only available to Restricted Admin clients.
To obtain the list of unique hosts (GET) use the following URL:
https://<vectra_management_ip>/api/v3.4/unique_hosts_observed_monthly/audit
The following table lists the fields and a description of the various elements for the month results.
Detailed examples of using GET on unique_hosts_observed_monthly/audit is described in Appendix A
ip_address string
The available query parameters to filter for Unique Hosts Observed Monthly - Audit are listed below.
The unique hosts observed API can be used to view the count of all distinct hosts seen during a given
timespan dating back one year. The endpoint is only available to Restricted Admin clients.
To obtain the list of unique hosts observed (GET) use the following URL:
https://<vectra_management_ip>/api/v3.4/unique_hosts_observed/
The following table lists the fields and a description of the various elements for the month results.
Detailed examples of using GET on unique_hosts_observed is described in Appendix A
The available query parameters to filter for Unique Hosts Observed are listed below.
The unique hosts observed audit API can be used to view of all the distinct hosts seen during a given
timespan dating back one year. The endpoint is only available to Restricted Admin clients.
Note that counts between unique hosts observed count API and this API may differ. This is because
unique hosts may appear at varying times. This audit endpoint returns all relevant information about
unique hosts including their individual sessions.
To obtain the list of unique hosts (GET) use the following URL:
https://<vectra_management_ip>/api/v3.4/unique_hosts_observed/audit
The following table lists the fields and a description of the various elements for the month results.
Detailed examples of using GET on unique_hosts_observed/audit is described in Appendix A
ip_address string
The available query parameters to filter for Unique Hosts Observed - Audit are listed below.
Note if start and end are left blank, default start will be the beginning of the month of the previous year.
Default end will be the current day.
Appendix A
This section will include examples of data retrieved from the REST API 3.4. Due to the amount of data
that can be retrieved from a single query, the output examples below show only a snippet of the actual
data that can be retrieved.
Note: The information in the following examples was generated in a lab environment. Any reference to IP
addresses similar to those used in your environment is purely coincidental.
Detections
GET
URL: https://<vectra_portal_url>/api/v3.4/detections/4
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
Detections (Notes)
GET
URL: https://<vectra_portal_url>/api/v3.4/detections/<detection_id>/notes
Headers:
"Authorization": "Bearer <access_token>"
Response:
[
{
"id": 1,
"date_created": "2021-01-11T13:42:43Z",
POST
URL: https://<vectra_portal_url>/api/v3.4/detections/<detection_id>/notes
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
Body:
{"note":"this is a detection note"}
Response:
{
"id": 2,
"date_created": "2021-01-11T14:14:10.527603Z",
"date_modified": null,
"created_by": "vadmin",
"modified_by": null,
"note": "this is a detection note"
}
GET
URL: https://<vectra_portal_url>/api/v3.4/detections/<detection_id>/notes/<note_id>
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"id": 1,
"date_created": "2021-01-11T13:54:47.987918Z",
"date_modified": null,
"created_by": "vadmin",
"modified_by": null,
"note": " this is a detection note "
}
URL: https://<vectra_portal_url>/api/v3.4/detections/<detection_id>/notes/<note_id>
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
Body:
{
"note": “updated note”
}
Response:
{
"id": 1,
"date_created": "2021-01-11T13:47:42Z",
"date_modified": "2021-01-11T13:57:11Z",
"created_by": "vadmin",
"modified_by": "vadmin",
"note": "updated note"
}
DELETE
URL: https://<vectra_portal_url>/api/v3.4/detections/<detection_id>/notes/<note_id>
Headers:
"Authorization": "Bearer <access_token>"
Mark as Fixed
PATCH to mark/unmark a detection as fixed.
URL: https://<vectra_portal_url>/api/v3.4/detections
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
Body:
{
"detectionIdList": [128, 129],
"mark_as_fixed": "True"
}
Tagging
GET to list tags on an account or detection.
Headers:
“Authorization”: “Bearer <access_token>”
Response:
{
"status": "success",
"tags": [
"newticket",
"under_investigation"
],
"entity_id": "1000"
}
Headers:
“Authorization”: “Bearer <access_token>”,
“Content-Type”: “application/json”
Body:
{
"tags": [“newticket”, “under_investigation”]
}
Response:
{
"status": "success",
"tags": [
"newticket",
"under_investigation"
],
"entity_id": "1000"
}
Headers:
“Authorization”: “Bearer <access_token>”,
“Content-Type”: “application/json”
Body:
{
"tags": []
}
Patch operation will alter the tags for the account or detection to match the “tags” list provided in the
PATCH.
URL: https://<vectra_portal_url>/api/v3.4/accounts/1
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"id": 1,
"url": "http://123456789.uw2.portal.vectra.ai/api/v3.4/accounts/1",
"name": "O365:[email protected]",
"state": "inactive",
"threat": 0,
"certainty": 0,
"severity": "Low",
"account_type": [
"o365"
],
"tags": [],
"note": null,
"notes": [],
"note_modified_by": null,
"note_modified_timestamp": null,
"privilege_level": null,
"privilege_category": null,
"last_detection_timestamp": "2021-12-20T18:11:16Z",
"detection_set": [
"http://123456789.uw2.portal.vectra.ai/api/v3.4/detections/1",
"http://123456789.uw2.portal.vectra.ai/api/v3.4/detections/4"
],
"probable_home": null,
"assignment": null,
"past_assignments": [],
"sensors": [
"tzlgmx99"
],
"detection_summaries": [
{
"detection_id": 1,
"detection_url":
"http://123456789.uw2.portal.vectra.ai/api/v3.4/detections/1",
"detection_type": "O365 Internal Spearphishing",
"detection_category": "LATERAL MOVEMENT",
Account (Notes)
GET
URL: https://<vectra_portal_url>/api/v3.4/accounts/<account_id>/notes
Headers:
"Authorization": "Bearer <access_token>"
Response:
[
{
"id": 1,
"date_created": "2021-01-11T13:42:43Z",
"date_modified": null,
"created_by": "vadmin",
"modified_by": null,
"note": "this is an account note"
},
{
"id": 2,
… … …
}
]
POST
URL: https://<vectra_portal_url>/api/v3.4/accounts/<account_id>/notes
Headers:
"Authorization": "Bearer <access_token>",
“Content-Type”: “application/json”
Body:
{"note": "this is a note"}
GET
URL: https://<vectra_portal_url>/api/v3.4/accounts/<account_id>/notes/<note_id>
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"id": 1,
"date_created": "2021-01-11T13:54:47.987918Z",
"date_modified": null,
"created_by": "vadmin",
"modified_by": null,
"note": " this is an account note "
}
PATCH
URL: https://<vectra_portal_url>/api/v3.4/accounts/<account_id>/notes/<note_id>
Headers:
"Authorization": "Bearer <access_token>",
“Content-Type”: “application/json”
Body:
{"note": "updated note"}
Response:
{
"id": 1,
"date_created": "2021-01-11T13:47:42Z",
"date_modified": "2021-01-11T13:57:11Z",
"created_by": "vadmin",
"modified_by": "vadmin",
DELETE
URL: https://<vectra_portal_url>/api/v3.4/accounts/<account_id>/notes/<note_id>
Headers:
"Authorization": "Bearer <access_token>"
Triage Rules
GET
URL: https://<vectra_portal_url>/api/v3.4/rules/<id>
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"id": 68,
"url": "https://1.1.1.1/api/v3.4/rules/68",
"description": "Expected behavior from these devices",
"enabled": true,
"created_timestamp": "2019-08-27T20:55:29Z",
"last_timestamp": null,
"is_whitelist": false,
"priority": null,
"active_detections": 2,
"total_detections":3,
"template": true,
"additional_conditions": {
"OR": [
{
"AND": [
{
"ANY_OF": {
"field": "remote1_port",
"values": [
{
"url": null,
"value": "135",
"label": "135"
}
],
POST
URL: https://<vectra_portal_url>/api/v3.4/rules
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
Body:
{
“detection”: The detection that must be triaged. Use the detection name as seen in the UI or the
“Understanding Vectra Detections” guide.
“triage_category”: The name that will be used for the triaged detection. Only applies if “is_whitelist” is
set to 0.
“is_whitelist”: A Boolean flag indicating whether to create a “whitelist” or a “track without scores” rule
source_conditions: conditions that can be applied to the source of a detection. Can be NULL.
additional_conditions: other conditions that are different on a per-detection-type basis. Can be NULL.
Response:
Success
The response contains the id of the triage rule if successful:
{
"_meta": {
"message": "Successfully created triage filter",
"level": "success"
},
"id": 11
Failure
Failure will result in an error message along with an indication of what was incorrect
{
"_meta": {
"message": "Invalid field(s) found",
"level": "error"
},
"host": [
"Invalid host: 5 does not map to a real host"
]
}
PUT
URL: https://<vectra_portal_url>/api/v3.4/rules/<id>
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
Body:
{
"detection_category": "LATERAL MOVEMENT",
"triage_category": "Susp Rmt Exec - Test",
"detection": "Suspicious Remote Execution",
"is_whitelist": 0,
"description": "put test",
"additional_conditions": {
"OR": [
{
"AND": [
{
"ANY_OF": {
"field": "remote1_ip",
"values": [
{
"value": "1.1.1.1"
}
],
"groups": [],
}
}
]
}
DELETE
URL: https://<vectra_portal_url>/api/v3.4/rules/<id>
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
Body:
{
"detectionIdLIst": [<detection_id1>, <detection_id2>, …]
}
Users
GET
URL: https://<vectra_portal_url>/api/v3.4/users
Headers:
"Authorization": "Bearer <access_token>"
},
]
}
POST
URL: https://<vectra_portal_url>/api/v3.4/users
To create users with a local profile (non SAML profile) use this endpoint.
The endpoint cannot create local user profiles for user emails that have logged in with an existing SAML
profile. Input your desired user role using the corresponding snake-case standardized name. Refer to the
/users/role endpoint to list available roles and their standardized names.
The following request body and all its fields are required to use this endpoint.
Headers:
"Authorization": "Bearer <access_token>",
Body:
{
"name": “firstname lastname”,
“role”: “auditor”,
“email”: “[email protected]”
}
Response:
{
"id": 4,
“role”: “Auditor”,
“email”: “[email protected]”,
“name”: “firstname lastname”
“identities”:[
{“type”: “local”}
],
"last_login_timestamp": null,
"verified ": false
}
GET
URL: https://<vectra_portal_url>/api/v3.4/users/<user_id>
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"id": 4,
“email”: “[email protected]”,
“name”: “newfirstname newlastname”
“role”: “super_admins”,
"last_login_timestamp": null,
"verified ": false
}
PATCH
URL: https://<vectra_portal_url>/api/v3.4/users/<user_id>
To modify users, use this endpoint. The endpoint will not update roles for users that only have a SAML
account. Input your desired user role using the corresponding snake-case standardized name. Refer to
the /users/role endpoint to list available roles and their standardized names.
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
Body:
{
"name": “newfirstname newlastname”,
“role”: “super_admins”
}
Response:
{
"id": 4,
“role”: “super_admins”,
“email”: “[email protected]”,
“name”: “newfirstname newlastname”
“identities”:[
{“type”: “local”}
],
"last_login_timestamp": null,
"verified ": false
}
DELETE
URL: https://<vectra_portal_url>/api/v3.4/users/<user_id>
To delete users, use this endpoint. This will deactivate a user’s local and SAML profiles; SAML profiles
can be reactivated by logging in again via the external provider. Note that the last verified super admin
user cannot be deleted using this endpoint.
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
GET
URL: https://<vectra_portal_url>/api/v3.4/users/roles
Headers:
"Authorization": "Bearer <access_token>"
Response:
},
{
"id": 1,
"name": "Super Admin",
"standardized_name": "super_admins",
}
]
Assignments
GET used to retrieve assignments
URL: https://<vectra_portal_url>/api/v3.4/assignments
Headers:
“Authorization”: “Bearer <access_token>”,
“Content-Type”: “application/json"
Response:
{
"count": 3,
"next": null,
"previous": null,
"results": [
{
"id": 4,
"assigned_by": {
"id": 1,
"username": "josem"
},
"date_assigned": "2021-05-18T04:34:48Z",
"date_resolved": null,
"events": [
{
"assignment_id": 4,
"actor": 1,
"event_type": "created",
"datetime": "2021-05-18T04:34:48Z",
"context": {
"to": 20
URL: https://<vectra_portal_url>/api/v3.4/assignments
Headers:
“Authorization”: “Bearer <access_token>”,
“Content-Type”: “application/json"
Body:
{
"assign_account_id": "27",
"assign_to_user_id": "30"
}
Response:
{
"assignment": {
"id": 25,
"assigned_by": {
"id": 45,
"username": "api_client_df405cc568734d4a8b7ebec1753ee647"
},
URL: https://<vectra_portal_url>/api/v3.4/assignments/<id>
Headers:
“Authorization”: “Bearer <access_token>”,
“Content-Type”: “application/json"
Body:
{
"assign_account_id": "27",
"assign_to_user_id": "23"
}
Response:
{
"assignment": {
"id": 25,
"assigned_by": {
URL: https://<vectra_portal_url>/api/v3.4/assignments/<id>
URL: https://<vectra_portal_url>/api/v3.4/assignments/<id>/resolve
Headers:
“Authorization”: “Bearer <access_token>”,
“Content-Type”: “application/json"
Body:
{
"outcome": "1",
"note": "Resolved by JoseM",
"triage_as": "My triage rule",
"detection_ids": [128,120]
}
Response:
{
"assignment": {
"id": 26,
"assigned_by": {
"id": 45,
"username": "api_client_df405cc568734d4a8b7ebec1753ee647"
},
"date_assigned": "2022-03-31T19:16:37Z",
"date_resolved": "2022-03-31T19:20:06Z",
"events": [
{
"assignment_id": 26,
"actor": 45,
"event_type": "resolved",
"datetime": "2022-03-31T19:20:06Z",
"context": {
"entity_t_score": 68,
"entity_c_score": 48,
"triage_as": "My triage rule",
"triaged_detection_ids": [
128,
120
],
"fixed_detection_ids": null,
"created_rule_ids": [
14,
Assignment Outcomes
GET used to list assignment outcomes.
URL: https://<vectra_portal_url>/api/v3.4/assignment_outcomes
Headers:
Response:
{
"count": 3,
"next": null,
"previous": null,
"results": [
{
"id": 1,
"builtin": true,
"user_selectable": true,
"title": "Benign True Positive",
"category": "benign_true_positive"
},
{
"id": 2,
"builtin": true,
"user_selectable": true,
"title": "Malicious True Positive",
"category": "malicious_true_positive"
},
{
"id": 3,
"builtin": true,
"user_selectable": true,
"title": "False Positive",
"category": "false_positive"
}
]
}
URL: https://<vectra_portal_url>/api/v3.4/assignment_outcomes
Headers:
“Authorization”: “Bearer <access_token>”,
“Content-Type”: “application/json"
Body:
{
"title": "Custom outcome",
"category": "benign_true_positive"
}
Response:
PUT used to modify an assignment outcome. The title can always be modified, but category can only be
modified if the assignment outcome has not been used as an outcome for an assignment.
URL: https://<vectra_portal_url>/api/v3.4/assignment_outcomes/<id>
Headers:
“Authorization”: “Bearer <access_token>”,
“Content-Type”: “application/json"
Body:
{
"title": "My New Outcome Title",
"category": "false_positive"
}
Response:
{
"id": 6,
"builtin": false,
"user_selectable": true,
"title": "My New Outcome Title",
"category": "false_positive"
}
URL: https://<vectra_portal_url>/api/v3.4/assignment_outcomes/<id>
Headers:
“Authorization”: “Bearer <access_token>”
Detection Events
GET
URL: https://<vectra_portal_url>/api/v3.4/events/detections?from=222
Response:
{
"events": [
{
"id": 28538,
"category": "command_and_control",
"threat": 50,
"certainty": 50,
"triaged": false,
"detection_type": "Azure AD Redundant Access Creation",
"d_type_vname": "Azure AD Redundant Access Creation",
"detection_id": 959,
"detection_href":
"https://207031206993.uw2.devportal.vectra.ai/detections/959?detail_id=94341",
"entity_id": 1,
"type": "account",
"entity_href": "https://207031206993.uw2.devportal.vectra.ai/accounts/1",
"entity_uid": "O365:ServicePrincipal_3fb87dda-882a-49e1-88b9-
67d2499b2fd4",
"src_entity": "O365:ServicePrincipal_3fb87dda-882a-49e1-88b9-
67d2499b2fd4",
"event_timestamp": "2022-09-12T16:31:35Z",
"detail": {
"operation": "Add member to role.",
"target": "[email protected]",
"change": "Application Administrator",
"results": "Success",
"last_timestamp": "2022-09-09T08:13:58Z"
},
"severity": 5
}
],
"next_checkpoint": 28539,
"remaining_count": 9797
}
URL: https://<vectra_portal_url>/api/v3.4/events/audits?from=16&limit=2
Headers:
"Authorization": "Bearer <access_token>"
Entities
GET
URL: https://<vectra_portal_url>/api/v3.4/entities/<entity_id>?type=account
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"id": 1,
"breadth_contrib": 0,
"importance": 0,
"is_prioritized": false,
"severity": "High",
"urgency_reason": “Ransomware: This entity was prioritized because it was
implicated in an active ransomware detection”,
"urgency_score": 0,
"velocity_contrib": 0,
"detection_set": [
"http://202079170575.uw2.devportal.vectra.ai/api/v3/detections/1",
"http://202079170575.uw2.devportal.vectra.ai/api/v3/detections/408",
"http://202079170575.uw2.devportal.vectra.ai/api/v3/detections/549",
"http://202079170575.uw2.devportal.vectra.ai/api/v3/detections/699"
],
"last_detection_timestamp": "2022-10-06T17:34:23Z",
"name": "SAML:[email protected]",
"notes": [
{
"id": 3,
"date_created": "2022-05-24T14:55:01Z",
"date_modified": null,
"created_by": "api_client_b58f8e28a46f40b59a77bf04d068af61",
"modified_by": null,
"note": "# IMPORTANT - PLEASE READ!! Account under **active
investigation**."
}
],
URL:
https://<vectra_portal_url>/api/v3.4/events/entity_scoring?type=account&from=100&limit
=2
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"events": [
{
"entity_id": 100,
"name": "AWS:None/us-1-east/config:AWSConfig-Describe",
"importance": 0,
"type": "account",
"is_prioritized": false,
"severity": "Low",
"urgency_reason": “Ransomware: This entity was prioritized because it was
implicated in an active ransomware detection”,
"urgency_score": 0,
"url": "https://200888808432.uw2.devportal.vectra.ai/accounts/8",
"category": "ACCOUNT SCORING",
"last_detection": {
"id": 103,
"type": " AWS S3 Enumeration",
"url": " https://200888808432.uw2.devportal.vectra.ai/detections/103"
},
Entity (Notes)
GET
URL: https://<vectra_portal_url>/api/v3.4/entities/<entity_id>/notes?type=account,host
Headers:
"Authorization": "Bearer <access_token>"
Response:
[
POST
URL: https://<vectra_portal_url>/api/v3.4/entities/<entity_id>/notes?type=account
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
Body:
{"note":"this is an account note"}
Response:
{
"id": 2,
"date_created": "2021-01-11T14:14:10.527603Z",
"date_modified": null,
"created_by": "vadmin",
"modified_by": null,
"note": "this is a detection note"
}
GET
URL:
https://<vectra_portal_url>/api/v3.4/entities/<entity_id>/notes/<note_id>?type=account
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"id": 1,
"date_created": "2023-03-15T18:58:48Z",
"date_modified": null,
"created_by": "api_client_8971fa9ddc89461daedebf451cd6e0c8",
"modified_by": null,
PATCH
URL:
https://<vectra_portal_url>/api/v3.4/entities/<entity_id>/notes/<note_id>?type=account
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
Body:
{
"note": “updated note”
}
Response:
{
"id": 1,
"date_created": "2021-01-11T13:47:42Z",
"date_modified": "2021-01-11T13:57:11Z",
"created_by": "vadmin",
"modified_by": "vadmin",
"note": "updated note"
}
DELETE
URL:
https://<vectra_portal_url>/api/v3.4/entities/<entity_id>/notes/<note_id>?type=account
Headers:
"Authorization": "Bearer <access_token>"
Groups
GET
URL: https://<vectra_portal_url>/api/v3.4/groups/<group_id>
Headers:
"Authorization": "Bearer <access_token>"
POST
URL: https://<vectra_portal_url>/api/v3.4/groups
Headers:
"Authorization": "Bearer <access_token>",
"Content-Type": "application/json"
Members:
Members are added to the “members” list in the body. The member value added depends on the group type.
- Account Members: Added by uuid
- Host Members: Added by name, ID, or url
- IP Members: Added by IP address
- Domain Members: Added by domain
Body:
{
"name": "test_group",
"type": "account",
"members":[
"name_1","name_2"
"importance": "high"
Response:
{
"group": {
"id": 5
}
}
Body:
{
"name": "test_regex_group",
"type": "host",
"regex": "(\\w\\d)*@vectra.ai"
Response:
{
"group": {
"id": 6
}
}
PATCH
PATCH method can be used to modify existing groups. A PATCH is a partial override, so the format can include one
or more fields from the POST.
When using the default PATCH functionality to modify the members, a complete new list must be included. For
example, if a group already contains accounts “[email protected]”, and “[email protected]”, and the group should be
modified to include account “[email protected]”, then “[email protected]” should be added to the list, the members
field of the PATCH request should be “[email protected]”,“[email protected]”,“[email protected]”.
Alternatively, the “membership_action” query parameter can be passed in with a value of “replace”, “append”, or
“remove”. The “append” and “remove” values will only affect members listed in the request body; if a user wants to
add or remove account “[email protected]” for a group, then the user can pass the members field of
URL: https://<vectra_portal_url>/api/v3.4/groups/<group_id>
Headers:
Body:
{
"name": "test_group new name"
}
Response:
{
"id": 5,
"name": "test_group new name",
"description": "a test group",
"last_modified": "2022-11-18T18:28:11Z",
"last_modified_by": "API Client c628cdee",
"type": "account",
"members": [
{
"uid": “name_1”
},
{
"uid": “name_2”
}
],
"rules": [],
"importance": "high"
"regex": "",
"membership_evaluation_ongoing": false,
"member_count": 2,
“built_using”: “static_members”
}
DELETE
URL: https://<vectra_portal_url>/api/v3.4/groups/<group_id>
Headers:
"Authorization": "Bearer <access_token>"
URL: https://<vectra_portal_url>/api/v3.4/lockdown
Headers:
"Authorization": "Bearer <access_token>"
Response:
[
{
"id": 1,
"type": "account",
"entity_id": 2,
"entity_name": "O365:[email protected]",
"lock_event_timestamp": "2023-03-06T22:30:06Z",
"locked_by": "vadmin",
"certainty": 0,
"unlock_event_timestamp": "2023-03-07T22:30:06Z"
}
]
Hosts
GET (multiple)
URL: https://<vectra_portal_url>/api/v3.4/hosts
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"count": 1,
"next": null,
"previous": null,
"results": [
{
"id": 1,
"name": "bar.mbpro",
"has_active_traffic": false,
"threat": 60,
"certainty": 96,
"t_score" : 60,
"c_score": 96,
"severity": "critical",
"last_source": "9.0.0.1",
GET (single)
URL: https://<vectra_portal_url>/api/v3.4/hosts/1
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"id": 1,
"name": "bar.mbpro",
"has_active_traffic": false,
GET
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"results": {
"active_directory": {
"connection_status": "enabled",
"auth_status": {
"3a27a16e": "authenticated"
},
"error_states": {},
"lockdown_status": "enabled"
},
"azure_ad_lockdown": {
"connection_status": "enabled",
"auth_status": {
"status": "authenticated"
},
"lockdown_status": "enabled"
},
"aws": {
"connection_status": "disabled"
},
"azure": {
"connection_status": "disabled"
},
"google_cloud": {
"connection_status": "disabled"
},
"reverse_lookup_dns": {
"connection_status": "disabled"
},
"siem": {
"connection_status": "disabled"
},
"vcenter": {
"connection_status": "enabled",
"auth_status": {
"status": "not_configured"
},
"error_states": {
"status": "An error occurred during vCenter connection check, please
try again later"
}
},
GET
URL: https://<vectra_portal_url>/api/v3.4/health/external_connectors/details
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"results": {
"active_directory": {
"connection_status": "enabled",
"details": {
"profiles": {
"3a27a16e": {
"uriConnectionStatus": {
"192.168.49.204": {
"message": "Connected",
"severity": "misc-yep"
}
},
"metrics": {
"numADAccountsFound": 87,
"numADMetricOverlap": 0
},
"connectionStatus": {
"message": "Connected",
"severity": "misc-yep"
}
}
},
Health – EDR
GET
URL: https://<vectra_portal_url>/api/v3.4/health/edr
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"results": {
"carbon_black": {
"connection_status": "enabled",
"auth_status": {
"cbdemo.demo.vectra.io:443": "authenticated"
},
"error_states": {},
"lockdown_status": "enabled"
},
"cb_cloud": {
"connection_status": "enabled",
"auth_status": {
"status": "authenticated"
},
"error_states": {},
"lockdown_status": "enabled"
},
"crowdstrike": {
"connection_status": "disabled"
},
"cybereason": {
"connection_status": "disabled"
},
"fireeye": {
"connection_status": "disabled"
},
"host_lockdown": {
"connection_status": "enabled",
"auth_status": {
"status": "authenticated"
},
"lockdown_status": "enabled"
GET
URL: https://<vectra_portal_url>/api/v3.4/health/edr/details
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"results": {
"host_lockdown": {
"connection_status": "enabled",
"details": {
"activeIntegrations": [
"Microsoft Defender ATP",
"Carbon Black",
"Carbon Black Cloud"
],
"lockdownAutoEnabled": true
}
},
"windows_defender": {
"connection_status": "enabled",
"details": {
"status": "Connected",
"severity": "misc-yep",
"hostLockdown": {
"enabled": true
}
}
GET
Headers:
"Authorization": "Bearer <access_token>"
Response:
{
"results": {
"ping": "Brain enabled",
"latency": "311.43ms"
}
}
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/enablement
Headers:
“Authorization”: “Token <api-key>”
Query Params:
{“device_serial”:”<device_serial>”}
Response:
Status Code: 200
{
"is_enabled": true
}
POST
Used to enable or disable Vectra Match on a given device (WARNING: POSTing to the enablement endpoint causes
a reboot if changing state). A valid Vectra Match license is required to enable this feature on a given paired device,
but is not required to disable Match.
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/enablement
Headers:
“Authorization”: “Token <api-key>”
Response:
Status code: 200
{
"is_enabled": true
}
eve_stats: statistics directly pulled from the Vectra Match (suricata) engine
interface_stats: statistics about each network interface and its processing/drop rate
ft_stats: statistics about each flow thread and its processing/drop rate
forwarder_stats: statistics about how many syslog messages Vectra Match is producing
device_serial: serial of the device for which the stats are given
timestamp: timestamp of when the information was gathered
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/stats
Headers:
“Authorization”: “Token <api-key>”
Response:
Status Code: 200
{
"stats": [
{
"eve_stats": {
"timestamp": "2023-02-01T01:05:45.123456+00:00",
"event_type": "stats",
"stats": {
"uptime": 177,
"capture": {
"packets": 1361,
"rx_errors": 0,
"tx_errors": 0,
"dpdk": {
"imissed": 0,
"no_mbufs": 0,
"ierrors": 0
}
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/status
Headers:
“Authorization”: “Token <api-key>”
Response:
Status Code: 200
{
"status": [
{
"device_serial": "U12312300000123",
"is_enabled": true,
"process_health": "healthy",
"timestamp": "2023-02-01T01:23:45.123456+00:00"
},
{
"device_serial": "U12312300000456",
"is_enabled": true,
"process_health": "healthy",
"timestamp": "2023-02-01T01:23:46.234567+00:00"
},
{
"device_serial": "U12312300000789",
"is_enabled": true,
"process_health": "healthy",
"timestamp": "2023-02-01T01:23:47.345678+00:00"
}
]
}
Used to retrieve devices on which Vectra Match can be enabled. Returned fields include:
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/available-devices
Headers:
“Authorization”: “Token <api-key>”
Response:
Status Code: 200
{
"devices": [
{
"device_serial": "U12312300000123",
"ip_address": "192.168.0.10",
"is_virtual": false,
"product_name": "X29v2",
"version": "7.5.0-1-9036",
“mode”: “mixed”,
},
{
"alias": "Sensor-Office",
"device_serial": "U12312300000456",
"headend_uri": "x29v2-5-10.example.local",
"ip_address": "192.168.1.10",
"is_virtual": false,
"last_seen": "2023-02-01T12:34:56Z",
"location": "Main Office",
"product_name": "S101",
"version": "7.5.0-1-9036",
“mode”: “sensor”,
},
{
"alias": "Sensor-DC",
"device_serial": "U12312300000789",
"headend_uri": "x29v2-5-10.example.local",
"ip_address": "192.168.2.10",
"is_virtual": false,
"last_seen": "2023-02-01T01:23:45Z",
"location": "New Office",
"product_name": "S11",
"version": "7.5.0-1-9036",
“mode”: “sensor”,
Used to retrieve information about a Vectra Match ruleset, given its UUID
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/rules
Headers:
“Authorization”: “Token <api-key>”
Query Params:
{“uuid”:”<uuid>”}
Response:
Status Code: 200
{
"device_serials": [],
"hashsum": "e5227116937f484e3044ba1f28d6053edb33fc565581d0fda73b587d6a2bfed9",
"name": "valid_rules.rules",
"notes": {
"creator": "vectra",
"description": "test note"
},
"timestamp": "2023-02-01T01:23:45.123456+00:00",
"uuid": "6aea451c-4156-4ac6-bbeb-c9e0b16b1da5"
}
DELETE
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/rules
Headers:
“Authorization”: “Token <api-key>”
Response:
Status code: 200
{
POST
Used to upload a new Vectra Match ruleset. A valid Vectra Match license is required to use this endpoint.
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/rules/upload/
Headers:
“Authorization”: “Bearer <api-key>”
resp = requests.post("https://<vectra_management_ip>/api/v3.4/vectra-
match/rules/upload/", headers={"Authorization":"Bearer <token>"}, verify=False,
json=payload
Response:
{
"urls": [
"<temporary-upload-url-valid-for-2-mins>"
],
"id": "b68f41be-1312-4275-8c36-4ba0f738cf8a"
}
PUT
Response:
PATCH
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/rules/upload/<upload-uuid>
Headers:
“Authorization”: “Bearer <api-key>”
Response:
Status code: 200
{
"upload_status": "completed"
GET
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/rules/upload/<upload-uuid>
Headers:
“Authorization”: “Bearer <api-key>”
Response:
Status code: 200
{
“id": "b68f41be-1312-4275-8c36-4ba0f738cf8a",
"upload_status": "completed",
"external_task_status": "not_started",
"external_task_updated_at": "2024-02-29T09:58:28Z"
}
GET LIST
Get the list of the users uploads from the last 24 hours.
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/rules/upload/
Headers:
“Authorization”: “Bearer <api-key>”
Response:
Status code: 200
[
{
“id": "b68f41be-1312-4275-8c36-4ba0f738cf8a",
"upload_status": "completed",
"external_task_status": "not_started",
"external_task_updated_at": "2024-02-29T09:58:28Z"
}
]
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/assignment
Headers:
“Authorization”: “Token <api-key>”
Response:
Status Code: 200
{
"device_to_rules_map": [
{
"device_serial": "U12312300000123",
"rules": [
"6aea451c-4156-4ac6-bbeb-c9e0b16b1da5"
POST
Used to assign a Vectra Match ruleset to one or more devices. A valid Vectra Match license is required to use this
endpoint.
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/assignment
Response:
Status code: 200
{
"details": "success"
}
DELETE
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/assignment
Headers:
“Authorization”: “Token <api-key>”
Response:
Status code: 200
{
"details": "success"
}
top_alert_counts: statistics directly pulled from the Vectra Match (suricata) engine about the top 10 alerts
that have been processed since the last rotation of the suricata’s eve.json event log
eve_log_rotated_time: ISO-8601 timestamp of the last time the eve.json log was rotated, which helps to
indicate the time window the alert counts were collected over (from this timestamp until the current time)
device_serial: serial of the device for which the stats are given
URL: https://<vectra_management_ip>/api/v3.4/vectra-match/alert-stats
Headers:
“Authorization”: “Token <api-key>”
Threat
GET
- Used to retrieve a download url for the Vectra Match Curated Ruleset file
- Download url expires after 2 minutes
Threat Feeds
GET
URL: https://<vectra_management_ip>/api/v3.4/threatFeeds/
Headers:
“Authorization”: “Token <api-key>”
Response:
{
"count": 1,
"next": null,
"previous": null,
"results": [
{
"id": "40822ff3a8098b4073851996b5735185",
"_rev": "2-563284353939596519e8b8a9f058193f",
"name": "test-feed-2",
"lastUpdatedBy": "api_client_78d7360065524aa9919dd127d56c1d81",
"version": "7.8-336-g1de329dc878",
"uploadDate": "2023-08-23T15:22:22.563534+00:00",
"lastUpdated": "2023-08-31T15:35:23.837079+00:00",
"defaults": {
"indicatorType": "Anonymization",
"certainty": "Low",
"duration": 7,
"category": "cnc"
},
"uploadResults": "{
'indicatorType': 'Malware Artifacts',
'observableCount': 2,
'certainty': 'Low',
'expiration': '2023-09-07T15:35:23.727684+00:00',
'category': 'cnc'
}",
"type": "STIX"
},
]
}
URL: https://<vectra_management_ip>/api/v3.4/threatFeeds/
Headers:
“Authorization”: “Token <api-key>”
Body:
{
"threatFeed": {
"name":"test-feed",
"defaults": {
"certainty":"High",
"duration":7,
"indicatorType":"Anonymization",
"category":"cnc"
}
}
}
All the fields shown above are mandatory. See the section on threatFeeds for possible values each label can take.
URL: https://<vectra_management_ip>/api/v3.4/threatFeeds/<id>
Headers:
“Authorization”: “Token <api-key>”
Body:
{
"threatFeed": {
"name":"test-feed",
"defaults": {
"certainty":"High",
"duration":7,
"indicatorType":"Anonymization",
"category":"cnc"
},
“upload”: {
“replace_filename”: “test_stix_file.xml”,
“filename”: “existing_stix_file.xml”
}
}
}
Note: The replace_filename must be an already uploaded STIX file. This action will delete the former Threat Feed File
and link the current Threat Feed object to the replacement file.
URL: https://<vectra_management_ip>/api/v3.4/threatFeeds/<id>/
Headers:
“Authorization”: “Token <api-key>”
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="stix_test_url_anon.xml"
Content-Type: text/xml
------WebKitFormBoundary7MA4YWxkTrZu0gW—
Response Success:
{
"threatFeed": {
"uploadResults": {
"category": "cnc",
"certainty": "High",
"expiration": "2019-08-27T20:55:29.27Z ",
"indicatorType": "Anonymization",
"observableCount": 4
}
}
}
If you are using a tool like postman, perform the POST with the body of the POST as “form-data” with Key as “file”
and value as the selected file from the file system. Do not add a content type header explicitly for postman, since
the tool does it automatically.
URL: https://<vectra_portal_url>/api/v3.4/unique_hosts_observed_monthly
Headers:
“Authorization”: “Bearer <access_token>”
Response:
URL: https://<vectra_portal_url>/api/v3.4/unique_hosts_observed_monthly/audit
Headers:
“Authorization”: “Bearer <access_token>”
Response:
"count": 21,
"next":
"https://208328399689.uw2.devportal.vectra.ai/api/v3.4/unique_hosts_observed_monthly/a
udit?page=2&page_size=10",
"previous": null,
"results": [
{
"month": "2023-09",
"host_id": 1,
"host_luid": "test1",
"ip_address": "1.2.3.4",
"host_artifact_value": "test",
"host_artifact_type": "generic",
"last_seen_start": "2023-09-12T16:00:00Z",
"last_seen_end": "2023-09-29T19:18:03Z"
},
{
"month": "2023-09",
URL: https://<vectra_portal_url>/api/v3.4/unique_hosts_observed
Headers:
“Authorization”: “Bearer <access_token>”
Response:
[
{
"month_start": "2023-06-01",
"month_end": "2023-10-15",
"unique_hosts_observed": 230
}
]
URL: https://<vectra_portal_url>/api/v3.4/unique_hosts_observed/audit
Headers:
“Authorization”: “Bearer <access_token>”
Response:
"count": 21,
"next":
"https://<vectra_portal_url>.uw2.devportal.vectra.ai/api/v3.4/unique_hosts_observed/au
dit?page=3&page_size=6",
"previous": null,
"results": [
{
"host_id": 1,
Appendix B
Detections
Predefined categories and vnames
CATEGORY VNAME
Command and Control
Azure AD Admin Account Creation
Azure AD MFA-Failed Suspicious Sign-On
O365 Power Automate HTTP Flow Creation
Azure AD Redundant Access Creation
Azure AD Suspicious OAuth Application
O365 Suspicious Power Automate Flow Creation
Azure AD Suspicious Sign-On
Azure AD TOR Activity
AWS Root Credential Usage
AWS Suspicious Credential Usage
AWS TOR Activity
Botnet
AWS Cryptomining
Reconnaissance
O365 Suspicious Compliance Search
O365 Unusual eDiscovery Search
O365 Suspect eDiscovery Usage
AWS EC2 Enumeration
AWS Organization Discovery
AWS S3 Enumeration
AWS Suspect Credential Access from EC2
AWS Suspect Credential Access from ECS
AWS Suspect Credential Access from SSM
AWS Suspect Escalation Reconnaissance