> For the complete documentation index, see [llms.txt](https://docs.vectra.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vectra.ai/configuration/coverage/detection-engineering-best-practices/detection-engineering-cloud.md).
# Detection Engineering Cloud
Configure, enable, and investigate custom cloud detection rules based on flow and DNS logs.
{% hint style="info" %}
**Please Note:**
Detection Engineering is currently in Private Preview. If the feature is not available in your tenant and you wish to participate in the Private Preview, please reach out to your Vectra AI account team to discuss.
{% endhint %}
## Overview
Detection Engineering is the Vectra AI Platform feature where users build, tune, and manage custom detections. These are rules that alert on activity specific to an organization's environment or policies, covering cases that Vectra AI's models do not address on their own.
This feature is only available in Respond UX (RUX deployments). If you are unsure of your deployment type, please see [Analyst UX options (RUX vs QUX)](/deployment/getting-started/analyst-ux-options-rux-vs-qux.md).
### Where to find it
Navigate in your Vectra AI UI to *Configuration→ Detection Engineering*. The landing page lists the detections that are available to use in private preview.
### Who can use it
All users have read access to view detections. Only Admins, Restricted Admins, and Super Admins can enable/disable a detection.
This feature will be available to Vectra AI Cloud Base (with restrictions) and Pro (full access) customers.
## Walkthrough: Enabling or Edit an available Detection
### Prerequisite: configure a Data Source
Flow detections can only evaluate traffic from a connected, actively-ingesting data source. Before building or enabling any flow detection, go to *Configuration → Data Sources* and connect the cloud environment the detection should run against:
* AWS CloudTrail — create an AWS connection and confirm its status shows Logs flowing before relying on it.
* Microsoft Azure — connect the Azure subscription providing flow logs.
{% stepper %}
{% step %}
#### **View all available Rules**
Go to Detection Engineering Dashboard to see the available rules
*Configuration → Detection Engineering*
{% endstep %}
{% step %}
#### **Enable or Edit a Rule**
Click on edit icon and review the existing configuration before hitting **Activate**.
* Some fields can be edited as per the use-case. For example here the **Filter** can be updated to the source country code needed for the use-case.
* **Time window** and **Threshold** can also be edited.
* **Detection Description** and **Prioritization** can be updated to suite customer preference.
{% endstep %}
{% step %}
#### **Monitor Rule Hits**
**Last Triggered** and **Triggers In Last 30 Days** columns in dashboard show any recent rule hits. Click on any recent Triggers to see more details about the Detection.
{% endstep %}
{% step %}
#### **Investigate the Detection**
Takes you to the Detection page where this detection can be investigated to see the impacted Host, Account, Status, Time Stamps, etc.
{% endstep %}
{% step %}
#### **Deeper into the activity**
Drill down further to see more details about this activity timeline.
{% endstep %}
{% step %}
#### **Host specific detection summary**
See other Detections on this host and information like host ip address, AD membership, Asset Importance, etc.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
**Note:** The above workflow is for the purpose of walkthrough only. In a real environment with Active rules, if the behavior is continuously seen, Vectra AI automatically triages the behavior and prioritizes the impacted host in “Priorities” page for an Analyst to view and investigate further like any other detections.
{% endhint %}
## Use-Case Scenarios
Detection Engineering is best used to close specific, known gaps in customer environment. Below are some use-case scenarios that helps explain the feature and get started. In preview there are limited out of the box rules available for customers to test.
### Command and control (C2) communication
Outbound traffic to identified malware command and control infrastructure catches a host inside the environment reaching out to infrastructure known to be malicious. Traffic to identified malware command and control infrastructure that appears to be return flows from inbound traffic catches the reverse case: return traffic consistent with a C2 server responding to inbound initiated contact. Together, the two rules cover a compromised host beaconing out and infrastructure reaching back in.
### Infrastructure abuse and anonymized access
CLDAP reflection attack and Finding DNS amplification participants both look for the environment's infrastructure being used as a reflector or amplifier in a denial of service attack against a third party. This covers whether the environment is being used as a weapon against others just as much as whether it has been compromised. Connection to a known Tor entry node adds coverage for any flow into the Tor network, which is used both to mask C2 or exfiltration activity and, for many organizations, is also a policy or compliance violation on its own.
### Covert DNS channels
DNS tunneling and DNS tunneling over TCP both catch data being smuggled inside DNS queries and responses. This is a common exfiltration and C2 channel because it bypasses most egress controls that only inspect HTTP/S traffic.
### Brute force against internal services
Brute force login attack against an internal RPC Endpoint Mapper service by an internal attacker catches password guessing activity against RPC (port 135) originating from inside the network. This is a lateral movement pattern that is easy to miss when looking at any single flow, since it is the volume over time that makes it a brute force.
### Anomalous remote access and low reputation IP activity
Successful RDP connections headed out flags a host inside the environment establishing a successful outbound RDP session. This is worth reviewing whenever remote desktop is not expected to leave the network. Interactive login session with low reputation IP and Long duration HTTPS flow from low reputation IP add coverage by using IP reputation as the filter condition rather than a fixed indicator list. Under this rule, an interactive login or an unusually long lived HTTPS session to or from a poorly rated IP is treated as suspicious, regardless of which specific IP it is.
## Field Reference
The tables below explain every field on the detection creation/edit page, grouped by section, in the order they appear on screen.
### Conditions
| **Field** | **Purpose** | **Notes** |
| --------------------------------------- | -------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data Stream | The data stream type the detection evaluates (for example flowlog) | Determines which fields are available in the Filter SQL and which Attribute To options appear. |
| Data Source | The originating source category for the stream (Azure, AWS, Cross Source) | Filters the Data Stream list; also used as a top-level filter on the landing page. |
| Include Flow Logs from all data sources | When selected automatically runs the detection over every source with the flowlog stream. | can be left un-checked if rule needs to be configured specific to a Data Source like AWS or Azure. |
| Attribute To | The entity to attribute the detection to. | Options by stream e.g. Source Source Host Session ID / Destination Host Session ID for Flow Logs. Determines which entity the resulting detection appears on. |
| Filter | The SQL condition that selects which records match this detection. | Keep filters as specific as possible, an unbounded or blank filter can match a very high percentage of events. |
| Use Threshold | Toggles aggregation mode on. | Turn this on for detection logic that requires aggregating multiple records. |
| Group By | The field(s) matching records are bucketed by before the threshold is evaluated. | Only shown when Use Threshold is checked. Example: source host, so each host accumulates its own count independently. |
| Time Window | The rolling lookback period over which the threshold is evaluated. | Only shown when Use Threshold is checked. |
| Threshold | The condition (count, sum, average, etc.) that must be met within the time window for the group to fire. | Required when Use Threshold is checked the form blocks saving until this is filled in. |
| Context Fields | The fields from the matching record(s) to surface in the detection's summary. | context fields are only available when there is no threshold. For threshold detections, group by fields and aggregate functions inside the threshold expression will appear in the detections. |
### Detection Details
| **Field** | **Purpose** | **Notes** |
| --------------------- | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Detection Description | Free-text explanation of what the detection is for. | optional but strongly recommended. This is what the next person maintaining the detection, or you in six months, will rely on. |
| Threat Detection | Chooses whether matches are treated as a security detection (contributes to the attack narrative) | Threat Detection requires a MITRE ATT\&CK Tactic |
| Info Detection | Chooses whether matches are treated as purely informational. | Info Detection cannot have prioritization impact configured, and will always have no contribution. |
| MITRE ATT\&CK Tactic | Maps the detection to a MITRE tactic (e.g. Exfiltration). | Only shown for Threat Detection. Also sets the “Vectra AI Category” shown just below the field, which drives how the detection is categorized alongside AI-generated detections. |
### Prioritization Impact
| **Option** | **Effect** |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Use AI prioritization | Default. This allows the detection to contribute to Vectra AI’s standard prioritization logic. |
| Always prioritize | Forces the entity to be prioritized whenever this detection fires, regardless of what AI prioritization would otherwise conclude. Use it sparingly, and reserve it for conditions you always want a person to see, such as a confirmed zero trust violation. |
| No contribution | The detection does not affect entity scoring at all. No contribution is set by default when Info Detection is selected. |
## Supported Filters, Thresholds & Rules
### Available rules in preview
The following detection rules will be available for Cloud Private Preview. Customers can enable, disable, or edit any of them.
* Possible SMB Exfiltration
* Possible Data Transfer over DNS (UDP)
* Possible Data Transfer over DNS (TCP)
* Outbound TOR Activity
* Outbound RDP Connection
* Outbound Brute-Force: POP3
* Kerberos User Enumeration
* Internal Brute-Force: MongoDB
* Internal Brute-Force: DCE-RPC
* Inbound SSH/RDP Connection from Suspicious IP
* Inbound Remote Access from ITAR Country
* Inbound Connection to Non-HTTP(S) Port
* Denial of Service: CLDAP Reflection
### Filter and Threshold supported operators in Preview
| **Operators** |
| ------------- |
| **Operators** |
| -------------------- |
| > |
| >= |
| < |
| <= |
| != |
| = |
| AND |
| IS NOT NULL |
| IS NULL |
| NOT |
| OR |
| IN |
| LIKE |
| REGEXP\_LIKE |
| BETWEEN ... AND ... |
| LOWER |
| AVG |
| COUNT |
| LENGTH |
| COALESCE |
| TRY\_CAST and CAST |
| UPPER |
| ABS |
| CONCAT |
| DATE |
| TIMESTAMP |
| DATE\_ADD |
| DATE\_DIFF |
| CONTAINS(array, val) |
| **Operator not available** | **Alternative syntax to use** |
| -------------------------- | ---------------------------------------------------------- |
| ! | NOT FALSE |
| DATE\_ADD | DATE '2025-03-01' + INTERVAL '1 day' |
| DATE\_DIFF | (DATE '2025-03-02' - DATE '2025-03-01') / INTERVAL '1 day' |
MAX, MIN, SUM operator only available for Threshold.
### Available field names (flow schema, by category)
Coming soon.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.vectra.ai/configuration/coverage/detection-engineering-best-practices/detection-engineering-cloud.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
