Визуализация дерева процессов для расследования инцидентов

Когда срабатывает алерт безопасности, первые вопросы всегда одни и те же: Что запустило этот процесс? Что ещё он сделал? Где началась цепочка атаки? Отвечать на них из плоских логов — долго и ненадёжно. Визуализация дерева процессов делает цепочку видимой мгновенно.

Узкое место расследований

Отраслевые данные стабильно показывают, что среднее время расследования (MTTI) — один из крупнейших вкладов в общее время реагирования на инцидент. Аналитики тратят большую часть времени триажа не на принятие решений, а на сбор контекста: корреляцию записей логов, поиск родительских процессов, сверку PID с временными метками и мысленную сборку цепочки выполнения.

На типичном Linux-сервере одна скомпрометированная сессия может породить десятки короткоживущих процессов за секунды. Каждый из них — отдельная строка в лог-вьюере. Аналитик вынужден:

• искать алертный процесс по PID;
• найти parent PID, искать снова;
• повторять вверх по цепочке 5–10 раз;
• отдельно искать дочерние процессы и горизонтальное перемещение;
• коррелировать сетевые соединения, файловые операции и DNS-запросы по временным меткам и PID.

Этот ручной процесс занимает 15–30 минут на алерт даже у опытных аналитиков. У младших членов команды — часы, или, что хуже, некорректные выводы из-за пропущенного звена в цепочке.

Почему цепочка процессов меняет всё

Каждый процесс в Linux имеет родителя. Атакующие полагаются на эту цепочку:

• начальный доступ порождает дочерний процесс;
• тот может повысить привилегии, скачать инструменты или переместиться горизонтально;
• каждый шаг — новый процесс, связанный с родителем.

Одно событие в алерте показывает только один узел. Настоящая история — это предки выше и активность ниже. Визуализация дерева процессов сворачивает ручной цикл «поиск—корреляция—повтор» в единое представление:

• Мгновенная идентификация первопричины. Вместо поиска вверх по PID аналитик видит всю цепочку предков сразу. Процесс порождён sshd, cron, docker или веб-сервером? Ответ виден мгновенно.
• Оценка радиуса поражения. Потомки подозрительного процесса показывают, что произошло после начальной компрометации. Атакующий скачал дополнительные инструменты? Породил ещё shell? Переместился горизонтально? Дерево раскрывает полный масштаб без дополнительных запросов.
• Коррелированная телеметрия по процессам. Файловые записи, сетевые соединения, DNS-запросы и другие события безопасности сгруппированы по процессу, который их сгенерировал. Это устраняет необходимость ручной сверки временных меток и PID.
• Быстрые решения об эскалации. Когда аналитик SOC видит полную цепочку за секунды, он может эскалировать уверенно — или закрыть ложное срабатывание, не тратя ресурсы старших коллег.

Практический эффект: расследования, которые требовали 20+ минут ручной корреляции логов, теперь занимают менее 2 минут от алерта до понимания.

Что показывает дерево процессов SecureExec

SecureExec отслеживает process_guid — уникальный идентификатор, основанный на PID, времени старта и ID агента — для каждого события процесса. Связи «родитель—потомок» сохраняются через parent_process_guid. Это позволяет автоматически восстанавливать полную иерархию процессов, даже когда PID были переиспользованы (распространённая проблема с короткоживущими процессами).

Дерево процессов показывает:

• цепочку предков — поднимается по иерархии родителей, показывая, как был запущен процесс (до 10 уровней по умолчанию);
• прямых потомков — какие процессы породил исследуемый;
• связанные события безопасности — файловые операции, сетевые соединения, DNS-запросы и другая телеметрия, привязанная к каждому процессу в дереве (до 20 событий на узел);
• IOC-коррелированные процессы — другие процессы, работавшие с теми же IP-адресами, DNS-именами или файлами, автоматически обнаруживаются и добавляются в дерево (подробнее ниже);
• цветовую кодировку — целевой процесс (красный), его предки (серые), потомки (синие) и IOC-связанные процессы (оранжевые с пунктирной рамкой) визуально различаются;
• метаданные процесса — PID, пользователь, полная командная строка, ID контейнера и hostname на каждом узле.

Как это сокращает время расследования

Без дерева процессов	С деревом процессов
Поиск PID в логах	Клик «Дерево процессов» на алерте
Найти parent PID, искать снова	Вся цепочка предков видна
Повторить 5–10 раз вверх	Готово в одном представлении
Отдельно искать дочерние PID	Потомки показаны автоматически
Сверять сетевые/файловые события по timestamp	События сгруппированы по процессу
Вручную сверять контекст контейнера	ID контейнера на каждом узле
15–30 мин на алерт	< 2 мин на алерт

Для SOC-команд, обрабатывающих десятки алертов в день, это складывается в часы, сэкономленные за смену. Это также снижает порог квалификации — младшие аналитики эффективно триажат, потому что визуальный контекст заменяет опыт навигации по сырым логам.

IOC-обогащение: за пределами связей «родитель—потомок»

Традиционные деревья процессов показывают только цепочку parent-child. Но реальные атаки оставляют следы в нескольких несвязанных процессах — один и тот же C2 IP, один и тот же сброшенный файл, один и тот же DNS-домен. Дерево процессов SecureExec автоматически обогащает граф IOC-коррелированными процессами: другими процессами на том же хосте, которые взаимодействовали с теми же индикаторами компрометации.

Как это работает:

1. После построения дерева «родитель—потомок» бэкенд извлекает IOC-значения из собранных событий — IP назначения, DNS-имена запросов и файловые пути.
2. Шум фильтруется автоматически: loopback-адреса, типичные системные файлы (/proc/, /etc/passwd), известные публичные DNS-резолверы и link-local адреса исключаются.
3. Запрос к Elasticsearch находит события других процессов (не входящих в дерево), которые обращались к тем же IOC-значениям, в окне ±2 часа.
4. Найденные процессы появляются в графе как оранжевые пунктирные узлы, соединённые с узлом дерева, разделяющим IOC, анимированными оранжевыми рёбрами с подписью совпавшего индикатора.

Это превращает простое представление цепочки в мини граф атаки — показывая не только что делал процесс атакующего, но и что ещё на хосте взаимодействовало с той же инфраструктурой.

Как это работает

Фича состоит из двух частей:

Бэкенд. Отдельный API-эндпоинт формирует запросы к Elasticsearch для сборки дерева. Он начинает с целевого процесса, рекурсивно обходит предков, получает прямых потомков одним пакетным запросом, собирает связанные события безопасности для всех найденных процессов, затем выполняет IOC-обогащение для поиска коррелированной активности. Обнаружение циклов, ограничение глубины и фильтрация IOC-шума гарантируют быстрое завершение — как правило, менее 500 мс.

Фронтенд. Интерактивный граф на React Flow с автоматической раскладкой через dagre. Узлы показывают имя процесса, PID, пользователя, командную строку и количество событий. IOC-узлы визуально отличаются пунктирной оранжевой рамкой и бейджем «IOC». Клик по узлу открывает боковую панель с полным списком событий, совпавшими IOC-индикаторами и прямыми ссылками на поиск событий. Масштабирование, перемещение и мини-карта поддерживают навигацию по большим деревьям.

От алерта к графу атаки в один клик

Дерево процессов доступно из двух мест:

• Страница деталей алерта — кнопка «Дерево процессов» появляется на каждом алерте, привязанная к соответствующему процессу;
• Страница событий — при раскрытии строки любого события кнопка «Дерево процессов» появляется, если событие содержит process_guid.

Один клик переносит вас от единичного алерта к полному контексту выполнения. Без ручного построения запросов, без синтаксиса Elasticsearch, без охоты за PID — только визуальная цепочка событий.

Пример: расследование алерта reverse shell

1. Срабатывает алерт reverse_shell — bash подключился к внешнему IP.
2. Нажмите «Дерево процессов» на алерте.
3. Граф показывает: sshd → bash → curl (скачал скрипт) → bash (reverse shell).
4. Кликните на начальный узел sshd — увидите события SSH-аутентификации, включая IP источника, получившего доступ.
5. Кликните на узел curl — увидите DNS-запрос, разрешивший домен C2, и событие записи файла с payload.
6. Кликните на reverse shell bash — увидите исходящее соединение к IP и порту атакующего.

Менее чем за минуту вся цепочка атаки построена: начальный доступ через SSH с конкретного IP, загрузка инструмента с известного домена и обратный вызов reverse shell к серверу атакующего. У аналитика есть всё для реагирования: IP источника для блокировки, C2-домен для чёрного списка, скомпрометированный аккаунт для отключения.

Пример: триаж ложного срабатывания

Не каждый алерт — атака. Дерево процессов ускоряет закрытие ложных срабатываний:

1. Срабатывает алерт fileless_execution — вызван memfd_create.
2. Откройте дерево процессов.
3. Граф показывает: systemd → fwupdmgr (менеджер обновления прошивок).
4. Цепочка родителей мгновенно показывает, что это легитимная системная операция, а не малварь.
5. Закройте алерт как false positive за секунды, дальнейшее расследование не нужно.

Без дерева аналитик искал бы PID, проверял родителя, верифицировал путь бинарника и подтверждал, что это известный системный компонент — процесс на несколько минут.

Попробуйте

Визуализация дерева процессов доступна в веб-консоли SecureExec. Разверните агент на своих Linux-серверах и начните расследовать алерты с полным контекстом процессов.

Начните работу с SecureExec — разверните за минуты с Docker Compose и увидите первые деревья процессов уже сегодня.