Velociraptor: сбор артефактов с хоста за минуты вместо ручного обхода через PowerShell

На реальном инциденте — шифровальщик в сети на 120 рабочих станций — я собирал артефакты с 15 хостов вручную: PowerShell-скрипты для дампа реестра, WMIC-запросы для списка процессов, ручное копирование Event Logs через wevtutil. На каждый хост уходило от 20 до 40 минут, тикал SLA в 4 часа, и на шестом хосте стало ясно: не успеваю. Атакующий быстрее. Через полгода я запустил Hunt в Velociraptor на 50 машин одновременно — те же данные собрались за 8 минут. Ниже — разбор перехода от ручного обхода к автоматизации реагирования на инциденты: настройка Velociraptor, VQL-запросы, массовый хантинг по хосту и offline-коллектор для изолированных машин.

Почему ручной сбор артефактов через PowerShell и WMIC не масштабируется

Типичная задача при инциденте: собрать с каждого подозрительного хоста список запущенных процессов, Event Logs (журналы событий Windows), файлы Prefetch (кеш запуска программ — показывает, что и когда запускалось), ключи реестра автозагрузки и, возможно, $MFT (Master File Table — индекс всех файлов на NTFS-разделе; по нему можно восстановить, какие файлы были на диске, даже если их уже удалили).

Стандартный ручной подход: подключаешься к хосту через WinRM или RDP, запускаешь PowerShell-скрипт, который через Get-Process, Get-WinEvent, reg export вытаскивает нужное. Для удалённого сбора часто используют WMI — Windows Management Instrumentation. В классификации MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1047 — её идентификаторы, по которым аналитики ссылаются на конкретные техники) это T1047. По сути ты вручную прогоняешь те же техники, которые атакующие применяют для разведки: Process Discovery (T1057), Query Registry (T1012), File and Directory Discovery (T1083).

Проблемы начинаются, как только хостов больше пяти:

• Время. 20–40 минут на хост, умноженные на 20 хостов — 7–13 часов работы одного аналитика. При SLA на сдерживание в 4 часа ты физически проигрываешь. Атакующий за это время успевает зачистить следы на непроверенных машинах.
• Ошибки. На третьем хосте забываешь скопировать один из логов. На пятом скрипт падает, потому что на машине стоит PowerShell 2.0 вместо 5.1. На восьмом нет прав локального администратора. Каждый сбой — время на диагностику вместо расследования.
• Нет единого хранилища. Результаты лежат в папках \\host1\evidence, \\host2\evidence, в разных форматах — CSV, XML, бинарные дампы. Сравнивать данные между хостами приходится вручную, сводя таблицы в Excel. На 15 хостах это кошмар.
• Нет параллельности. Пока обрабатываешь один хост, остальные 19 простаивают. Никакой оркестрации — только терминал и надежда, что скрипт не зависнет.

По данным Mandiant (M-Trends 2025), медианное время нахождения атакующего в сети до обнаружения — 11 дней. Каждый час ручного сбора — это час, который атакующий использует для закрепления, а ты тратишь на рутину.

Что такое Velociraptor и как он меняет DFIR-workflow

Velociraptor — open-source платформа для endpoint forensics (форензика конечных точек — сбор и анализ цифровых следов прямо на рабочих станциях и серверах) и incident response. Создал Mike Cohen, с 2021 года проект под крылом Rapid7, лицензия AGPLv3 — инструмент полностью бесплатный. Velociraptor — один из ключевых DFIR инструментов для цифровой криминалистики и threat hunting (целенаправленный поиск угроз в инфраструктуре, когда ты не ждёшь алерта, а сам ищешь следы атакующего).

Ключевая идея: вместо того чтобы копировать гигабайты сырых данных на центральный сервер и потом их разбирать, Velociraptor отправляет запросы прямо на хосты. Парсинг происходит на эндпоинте, на сервер возвращаются уже готовые результаты. Разница принципиальная. Вместо того чтобы тащить 5 ГБ $MFT с каждого из 100 хостов, ты отправляешь запрос «покажи файлы, созданные за последние 48 часов в каталоге Users» — и получаешь таблицу на 200 строк за секунды.

Архитектура и VQL — язык запросов Velociraptor

Velociraptor работает в клиент-серверной модели:

Сервер разворачивается на Linux VM (Ubuntu, Debian). Предоставляет веб-интерфейс для аналитиков. Один сервер тянет 10 000–15 000 эндпоинтов, с multi-frontend архитектурой — свыше 100 000.

Клиент (агент) — один бинарный файл размером около 50 МБ, без внешних зависимостей. Ставится на каждый эндпоинт. Работает на Windows, Linux, macOS, FreeBSD.

VQL (Velociraptor Query Language) — язык запросов, на котором пишутся все задания. Синтаксис напоминает SQL, но заточен под задачи форензики Windows хоста: парсинг реестра, NTFS-структур, Event Logs, Prefetch — всё прямо на хосте.

Готовые VQL-запросы оформлены в артефакты (artifacts) — шаблоны сбора конкретного типа данных. Velociraptor поставляется с сотнями встроенных артефактов: от Windows.System.Pslist (список процессов) до Windows.Forensics.Prefetch (разбор кеша запуска). Дополнительные можно загрузить с Artifact Exchange — общественной биржи. Артефакты — альтернатива PowerShell для сбора артефактов: не нужно писать и отлаживать скрипты, достаточно выбрать шаблон и нажать Launch.

Настройка Velociraptor: первый запуск за пять минут

Прежде чем разворачивать боевую инфраструктуру, попробуй Velociraptor в демо-режиме на своей машине. Это буквально одна команда.

Предпосылки: Windows 10 или 11, права администратора, бинарный файл Velociraptor с официального GitHub-репозитория (github.com/Velocidex/velociraptor/releases — бери последний релиз для windows-amd64).

Быстрый старт в демо-режиме

Шаг 1. Открой PowerShell или cmd с правами администратора. Перейди в папку с бинарным файлом. Заранее создай подпапку temp для хранения данных.

Шаг 2. Запусти: .\velociraptor.exe gui --datastore temp. Параметр gui создаёт временную конфигурацию: сервер и клиент стартуют на одной машине. --datastore temp указывает, куда писать данные. Если всё прошло штатно, в консоли побегут логи, а в браузере откроется веб-интерфейс по адресу https://127.0.0.1:8889. Логин — admin, пароль генерируется и выводится в консоль при первом запуске.

Шаг 3. В веб-интерфейсе нажми иконку лупы вверху — появится список подключённых клиентов. В демо-режиме будет один клиент — твоя машина. Кликни на его Client ID.

Ожидаемый результат: карточка клиента с информацией об ОС, hostname, IP-адресе, времени последнего heartbeat. Видишь это — настройка Velociraptor в демо-режиме завершена, можно переходить к сбору.

Развёртывание Velociraptor в продакшн-среде

Для боевой работы Velociraptor разворачивается в полноценной клиент-серверной конфигурации. Серверная часть — на Linux VM. Конфигурация генерируется командой velociraptor config generate -i — интерактивный мастер спросит про DNS-имя сервера, порты, параметры TLS.

Варианты развёртывания агента на хосты:

А бывает, что агент установить нельзя вовсе. Для этого есть offline-коллектор — о нём дальше.

Сбор артефактов с одного хоста: делай раз, делай два, делай три

Допустим, EDR (Endpoint Detection and Response — система, которая мониторит активность на конечных точках и поднимает алерты при подозрительном поведении) зафиксировала подозрительный процесс на хосте. Нужно собрать данные для расследования.

Процессы — первое, что смотришь

Зайди в карточку клиента → раздел Collected Artifacts → нажми «+» → в поиске набери Windows.System.Pslist → выбери артефакт → нажми Launch.

Через несколько секунд во вкладке Results появится таблица: имя процесса, PID, PPID (идентификатор родительского процесса — по нему видно, кто породил этот процесс), полная командная строка запуска, хеши исполняемого файла. Хеши можно сразу проверить на VirusTotal — если процесс вредоносный, это выяснится за секунды.

Для сравнения: ручной аналог — Get-Process | Select-Object Name, Id, Path в PowerShell (T1059.001). Velociraptor возвращает хеши и временные метки автоматически, результат сохраняется на сервере и доступен другим аналитикам. PowerShell-скрипт — одноразовый, хеши считай отдельно, результат — в локальном файле на хосте.

Следы запуска программ — Prefetch

Новый сбор: «+» → Windows.Forensics.Prefetch. В параметре prefetchGlobs можно указать glob-фильтр: C:\Windows\Prefetch\*.pf для всех файлов или C:\Windows\Prefetch\suspicious*.pf для конкретного имени.

Результат: таблица с колонками Executable (имя программы), RunCount (сколько раз запускалась), LastRunTimes (временные метки последних 8 запусков). Это критически важный артефакт для таймлайна инцидента — видно, когда именно вредонос запускался и сколько раз.

Поиск файла и временные метки NTFS

Нужно найти конкретный файл — используй Windows.Search.FileFinder. В параметре SearchFilesGlob укажи путь (например, C:\Users\**\*.exe), включи флаг Upload_File, чтобы файл скачался на сервер для дальнейшего анализа.

Во вкладке Results появятся четыре временные метки NTFS — так называемые MACB-тайммарки (Modified, Accessed, Changed, Birth):

BTime подскажет момент появления файла на хосте — вероятно, момент загрузки. ATime — когда его запускали. Нюанс: атакующий может подделать временные метки (timestomping, T1070.006), поэтому их стоит перепроверять по Prefetch и Event Logs. Если Prefetch говорит «запускался в 14:32», а BTime файла — «создан вчера в 09:00», а CTime — «три месяца назад» — скорее всего, метки подкрутили.

Журналы событий Windows

Для Event Logs — артефакт Windows.EventLogs.EvtxHunter. В параметрах задай фильтры: канал (Security, System, Microsoft-Windows-PowerShell/Operational), конкретные Event ID. Самые полезные для начала:

• 4624 — успешный вход в систему (кто, откуда, каким методом)
• 4688 — создание процесса (что запускалось)
• 1102 — очистка журнала безопасности (если видишь это — атакующий заметал следы)

На ручном сборе это потребовало бы цепочки: wevtutil epl Security C:\evidence\security.evtx → копирование файла на аналитическую станцию → разбор в Event Log Explorer или EZ Tools. Velociraptor делает парсинг прямо на хосте и возвращает уже отфильтрованные записи.

Hunt — массовый сбор артефактов с десятков хостов

Hunt — механизм, который превращает Velociraptor из инструмента для одного хоста в платформу для хантинга по хосту масштаба всей организации. Вместо последовательного обхода создаёшь одно задание и отправляешь его на все эндпоинты разом.

Шаг 1. В левом меню выбери Hunt Manager → нажми «+» (Create New Hunt). На вкладке Configure Hunt задай описание и теги — это помогает потом не путать Hunt-задания между инцидентами. Я обычно пишу дату и краткое описание: 2025-01-15_ransomware_lateral.

Шаг 2. На вкладке Select Artifacts добавь нужные артефакты. Можно комбинировать несколько в одном Hunt: Windows.System.Pslist + Windows.Forensics.Prefetch + Windows.EventLogs.EvtxHunter.

Шаг 3. На Configure Parameters настрой фильтры для каждого артефакта. Для Event Logs — конкретный канал и Event ID. Для Prefetch — glob-фильтр. Чем точнее фильтры, тем меньше данных передаётся и тем быстрее Hunt завершится.

Шаг 4. На Specify Resources ограничь потребление CPU и RAM на клиентах. Это не формальность: на продакшн-серверах Velociraptor-агент не должен мешать бизнес-процессам. Я видел ситуацию, когда агент без лимитов положил 1С на бухгалтерской машине — после этого ресурсные ограничения ставлю всегда.

Шаг 5. На Review проверь задание — оно показывается в виде VQL. Затем Launch.

В Hunt Manager появится задание со статусом. Во вкладке Clients — список хостов, которые уже вернули результаты. Каждый кликабелен: заходишь и видишь те же таблицы, что при одиночном сборе. Вкладка Download Results позволяет выгрузить всё в CSV или JSON для обработки в Timeline Explorer, Splunk или Elastic.

Пример кастомного VQL-запроса в Hunt

Если встроенных артефактов недостаточно, Velociraptor VQL запросы позволяют описать произвольную логику сбора. Пример — поиск исполняемых файлов, появившихся на хосте за последние 48 часов в профилях пользователей:

SELECT FullPath, Size, Mtime, Btime
FROM glob(globs="C:\\Users\\**\\*.exe")
WHERE Btime > now() - 48 * 60 * 60
ORDER BY Btime DESC

Функция glob() перебирает файлы по паттерну. Фильтр по Btime (дата создания) отсекает всё старше 48 часов. now() возвращает текущее время в Unix-формате. Результат — компактная таблица с путями и датами, а не гигабайты $MFT. Запрос выполняется на каждом хосте параллельно: при Hunt на 50 машин результаты собираются за минуты.

Offline-коллектор: когда агент развернуть нельзя

Бывают ситуации, когда установить агент невозможно: изолированный сегмент сети без связи с сервером, ноутбук сотрудника в командировке, заказчик категорически против установки стороннего ПО. Для таких случаев Velociraptor умеет создавать offline-коллектор — автономный exe-файл с зашитыми артефактами.

Как создать:

1. В веб-интерфейсе перейди в Server Artifacts → нажми иконку «самолётика» (Build Offline Collector).
2. Выбери артефакты. Хороший вариант для начала — Windows.KapeFiles.Targets. KapeFiles — структурированный набор путей к форензик-артефактам Windows (Event Logs, Prefetch, Registry Hives, $MFT, Browser History и десятки других категорий), изначально созданный для инструмента KAPE, но адаптированный под Velociraptor.
3. Настрой параметры: какие категории собирать. На вкладке Configure Collection включи шифрование архива (если данные чувствительные) и, при необходимости, автовыгрузку в облачное хранилище (T1560.001 — Archive via Utility).
4. Нажми Launch. Velociraptor сгенерирует standalone-exe.

Готовый файл передаёшь пользователю или доставляешь на хост любым доступным способом. Пользователь запускает его с правами администратора (без админских прав доступ к системным артефактам будет ограничен — Prefetch и $MFT не отдадутся). Коллектор собирает данные в zip-архив, который потом импортируется на сервер Velociraptor для анализа в том же интерфейсе — как если бы данные пришли от обычного агента.

Что собирать при типичном инциденте: карта артефактов

Выбирать артефакты в момент инцидента — потеря времени. Лучше заранее подготовить набор для типовых сценариев. Минимальный список для форензики Windows хоста при подозрении на компрометацию:

Этот набор оформляется как единый Hunt: один раз настраиваешь, сохраняешь — при следующем инциденте запускаешь одной кнопкой. Так и выглядит incident response автоматизация на практике: не «волшебная кнопка», а заранее подготовленный workflow.

Сравнение: PowerShell vs Velociraptor на реальном сборе

Разница — не в процентах. Это переход от ручного обхода к масштабируемому сбору артефактов с хоста, и он кардинально меняет скорость реагирования.

Но инструмент — полдела. Большинство команд, за которыми я наблюдал, разворачивают Velociraptor, запускают пару встроенных артефактов — и на этом останавливаются. Через полгода при реальном инциденте выясняется: никто не помнит, какие артефакты нужны для конкретного сценария, кастомных VQL-запросов никто не писал, offline-коллектор ни разу не тестировали на хостах с нестандартной конфигурацией. Velociraptor в трее, но не в голове — и аналитик снова открывает PowerShell, потому что «так привычнее».

Реальная проблема DFIR не в отсутствии инструментов. Проблема в том, что команды не прогоняют сценарии сбора до инцидента — на тестовых стендах, в лабораторных условиях, хотя бы в том самом демо-режиме gui. Без регулярной практики любая автоматизация реагирования на инциденты превращается в ещё одну неиспользуемую иконку. Если ищешь структуру входа в SOC или DFIR вместо хаотичного прыгания по YouTube-плейлистам — на IB Basics эту базу закрывают: от процессов реагирования до первых реальных задач.