Что такое Threat hunting — проактивная охота за угрозами

В компании регулярно срабатывает SIEM — алерты идут, аналитики загружены, отчёты есть. Но в один момент выясняется: через сервисную учётку несколько недель сливались данные. Причина — система реагировала, но не охотилась.

Threat hunting помогает увидеть незаметное, распознать тихую активность и усилить защиту не количеством алертов, а пониманием происходящего.

Зачем нужен проактивный поиск угроз — Threat hunting

Threat Hunting — это систематический процесс активного поиска скрытых угроз в IT-инфраструктуре путем глубокого анализа поведения пользователей, систем и сетевого трафика. Методика направлена на выявление и нейтрализацию опасных киберинцидентов, которые не выявили традиционные средства защиты.

На первый взгляд может показаться, что классических инструментов хватает: IDS отлавливает вторжения, SIEM собирает логи, а SOC реагирует на инциденты. Но все эти подходы — реактивные. Они работают с тем, что уже произошло. Чтобы угроза была зафиксирована, она должна проявиться. И тут у атакующих появляется преимущество.

Threat hunting — это проактивный процесс. Вместо ожидания сигнала тревоги, специалисты формируют гипотезы о возможной вредоносной активности и проверяют их, даже если алертов нет. И находят то, что проскользнуло мимо автоматической детекции.

Почему организации переходят к проактивному поиску:

1. Сложные атаки становятся нормой. APT-группы, fileless-механизмы, атаки без файлов и вирусов — всё это не ловится сигнатурами. Они не шумят, не взрывают — просто проникают, закрепляются и работают в фоне.
2. Классическая детекция слепа к новому. Алгоритмы и правила могут распознавать известное, но не видят неизвестного. А если не видно — не реагируют.
3. Устойчивость требует контроля. Система может быть защищена снаружи, но если внутри идёт тихое движение — это уже не устойчивость. Хантинг помогает увидеть, что происходит под поверхностью, пока ещё не стало поздно.

Роль Threat hunting в системе информационной безопасности

Threat hunting не заменяет существующие средства защиты — он дополняет их там, где автоматике не хватает контекста и гибкости. В зрелой системе ИБ у каждой технологии своё место: SIEM собирает события, EDR отслеживает поведение на хостах, DLP следит за утечками. Но всё это работает по правилам.

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

Усиливает обнаружение — расширяет границы видимости

Когда SIEM или EDR не выдают тревог, это ещё не значит, что в инфраструктуре всё спокойно. Угроза может прятаться на уровне, который не покрыт правилами или сигнатурами.
Threat hunting помогает увидеть такие вещи:

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

Охотник не ограничен заранее заданными условиями — он ищет то, что не попадает в автоматические фильтры.

Выявляет неизвестные IOC и IOA

IOC (Indicators of Compromise) — это уже случившиеся сигналы атаки: IP-адреса, хэши, домены, процессы. IOA (Indicators of Attack) — поведенческие признаки, которые ещё не оформились в последствия, но говорят о готовящейся атаке.

Threat hunting часто работает именно на уровне IOA. Например:

• серия неудачных логинов с интервалом в точные 30 секунд;
• PowerShell с параметрами кодировки и подключения к внешнему ресурсу;
• запуск скрипта сразу после вставки внешнего носителя.

Такие действия могут не попасть в зону видимости SIEM, но охотник обнаружит закономерность.

Помогает выявить тихих злоумышленников

Большая часть серьёзных атак сейчас не выглядит как вторжение. Это living off the land — использование штатных средств Windows или Linux (net.exe, wmic, certutil), и lateral movement — тихое перемещение по сети с учётками и доступами, которые уже есть.

Никаких вредоносных файлов, сигнатур, эксплойтов. Только подозрительная логика поведения.

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

Типы Threat hunting и как они применяются

У Threat hunting нет универсального сценария — методика зависит от зрелости команды, доступных данных и цели. Условно выделяют три основных подхода: структурированный, неструктурированный и ситуативный. Каждый применяется в своей ситуации, даёт разную глубину анализа, требует разного уровня зрелости команды. Иногда их комбинируют, переходя от одного к другому.

Структурированный поиск: когда есть гипотеза

Самый формализованный вариант. Охотник заранее формулирует гипотезу и проверяет её с опорой на известные модели поведения злоумышленников. Основой чаще всего служит MITRE ATT&CK — фреймворк, который описывает тактики и техники атакующих: от первичного доступа до эксфильтрации данных.

Пример гипотезы:
 «Если атакующий получил доступ к системе, он может использовать certutil.exe для загрузки полезной нагрузки».

Что делает хантер:

• Пишет запрос в SIEM по событиям, связанным с certutil;
• Отбирает нестандартные вызовы (с внешними URL, кодировкой, ключами);
• Сравнивает с базовой активностью — ищет аномалии.

Где применимо:

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

Такой подход масштабируется: на каждую технику — свои сценарии, свои запросы. Хантер работает почти как аналитик: гипотеза, проверка, вывод.

Неструктурированный поиск: когда ориентир — интуиция и опыт

Иногда хантер просто знает: «что-то не так». Он не опирается на формальные модели, а изучает логи, поведение, метрики — ищет странности. Это может быть медленная утечка данных, подозрительная активность новой учётной записи, всплески трафика в ночное время.

Пример кейса:
После внедрения нового сервиса в компании начались ночные обращения к API с сервера, который раньше никогда туда не подключался. SIEM не тревожится — всё легитимно. Но хантер видит, что объём трафика нестандартный, а структура запросов отличается.

Что делает охотник:

• Анализирует временные аномалии;
• Сверяет логи с другими источниками (например, NetFlow);
• Проверяет, есть ли признаки обхода защиты.

Где применимо:

1. В небольших командах, где Threat Hunting — ещё не формализованный процесс;
2. При изучении новых сервисов, интеграций, поведений;
3. В нестандартных инфраструктурах, где нет baseline — эталона нормального поведения.

Такой подход требует сильной насмотренности и уверенности в себе. Здесь главный инструмент — не фреймворк, а аналитическое мышление.

Ситуативный и гибридный подходы: реакция на событие + исследование

Этот тип Threat Hunting начинается с конкретного повода. Например:

• Появилась информация о новой критичной уязвимости (CVE).
• Команда SOC увидела подозрительное поведение, но алерта нет.
• DLP поймал нетипичный экспорт данных.

Аналитик начинает с сигнала и разворачивает исследование. Это не совсем реакция, как в IR, и не полноценная гипотеза, но повод начать проверку есть.

Пример:
Вышла критическая уязвимость в Apache Struts (CVE‑2023‑XXXX). Инфраструктура использует этот фреймворк. Хантер:

• Проверяет, какие хосты уязвимы.
• Строит запросы по признакам эксплуатации.
• Смотрит, были ли отклонения в поведении сервисов за последние дни.

Где применимо:

• При реагировании на инцидент, когда нет ещё полной картины.
• Когда нужно подтвердить или опровергнуть эксплойт в своей инфраструктуре.
• Как стартовая точка регулярного хантинга.

Такой подход часто используют как боевое применение Threat hunting — быстрый разбор по свежему сигналу, а не плановая аналитика.

Хантинг — не стихийный процесс, а системная аналитическая работа. Она строится на фреймворках, логике, гипотезах, цикличной проверке. Без чёткой методологии охота легко превращается в «поиск наобум» с огромным количеством потраченного времени и минимумом результата.

На чём держится Threat hunting — фреймворки и модели

Самый популярный инструмент при построении процесса — MITRE ATT&CK. Это база знаний о тактиках, техниках и процедурах злоумышленников, построенная на реальных атаках.
Каждая техника — это конкретное поведение: например, запуск regsvr32.exe с параметром URL — приём загрузки вредоносного кода из интернета.

Хантеры используют ATT&CK, чтобы:

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

Пример: если в организации нет мониторинга вызовов wmic.exe или psexec, значит, возможен lateral movement без фиксации. Это сразу становится направлением для Threat hunting.

Diamond Model — другая аналитическая модель. Она описывает атаку как пересечение четырёх сущностей:

1. Актор (кто атакует).
2. Инфраструктура (откуда).
3. Возможности (что применяет).
4. Жертва (на кого).

Подходит для структурирования информации при ретроспективной охоте — особенно при работе с группами APT.

Cyber Kill Chain — классика от Lockheed Martin. Этапы атаки — от разведки до выполнения. Хотя модель уступает ATT&CK в детализации, она хорошо работает как общий шаблон мышления: где мы находимся? На стадии входа или уже эксфильтрации?

И наконец, сам процесс Threat hunting почти всегда строится по логике:

Гипотеза → Сбор данных → Анализ → Вывод → Повтор.
Это не разовое действие, а итерация. Новые выводы становятся основой для новых гипотез.

Гипотезы и формулирование целей поиска

В отличие от реагирования, где задача сформулирована извне (есть инцидент — нужно действовать), в Threat hunting задача возникает изнутри. Охотник сам задаёт вопрос, на который пытается ответить. Это и есть гипотеза.

Типичные гипотезы:

• Поведение, не характерное для системы.
  Например: «если кто-то использует PowerShell с параметрами кодировки и сетевого подключения — это повод для расследования».
• Аномалия в логике доступа.
  «Админ вошёл в систему в 4 утра из другого города — такое бывает?»
• Нарушение бизнес-логики.
  «Пользователь скачал 3 ГБ данных с файлового сервера, но в этот день не работал по графику».

Конкретные примеры задач:

• Обнаружение использования Mimikatz: отслеживание подозрительных вызовов sekurlsa::logonpasswords, exe, нестандартных прав доступа к памяти.
• Выявление lateral movement через RDP: поиск цепочек логинов с одной учёткой к разным хостам в течение короткого времени, особенно если сессии идут от хостов без постоянных пользователей.
• Подозрение на tunneling через DNS:отслеживание однотипных DNS-запросов с высокой энтропией, регулярностью, необычными TTL.

Хорошая гипотеза:

• не слишком широкая — «найти всё странное»
• не слишком узкая, иначе станет просто фильтром
• основана на контексте инфраструктуры: то, что нормально для одного отдела, может быть подозрительно для другого

Сформулированная задача — это уже полдела. Дальше начинается охота: запросы, логика, анализ, документирование.

Как проходит охота: этапы Threat hunting

Threat hunting — это не разовая проверка, а цикл. Начинается с подготовки, заканчивается выводами, которые могут стать частью новых гипотез, настроек систем или даже запуском процесса реагирования. Успешная охота — это всегда повторяемый процесс.

Определение нормального поведения

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

Что учитывается:

• Поведение пользователей и учёток (время входа, активность, частота операций);
• Сетевые связи между системами (какие узлы общаются, объём трафика);
• Типовые вызовы приложений, команд, API.

Как строят baseline:

• Используют поведенческие движки (UEBA, UBA);
• Сравнивают исторические логи за период (неделя, месяц, квартал);
• Опрашивают админов и службы эксплуатации — никакая автоматизация не заменит понимание специфики бизнеса.

Хороший baseline — это не только способ искать отклонения, но и защита от ложных срабатываний. Чем лучше известна норма, тем точнее ловится аномалия.

Сбор и корреляция данных

Следующий шаг — получить все нужные данные. Здесь ключевое — не просто собрать логи, а собрать релевантные. Хантеру не нужны терабайты «всего подряд» — только то, что связано с гипотезой.

Типичные источники данных:

• SIEM — единая точка сбора (например, MaxPatrol SIEM, UserGate SIEM, RuSIEM);
• EDR/NDR — поведение хостов и сетевые связи;
• DNS‑логи, прокси, NetFlow — что, куда, как часто уходит;
• Active Directory — входы, токены, группы, сессии;
• UEBA — поведенческие модели.

Корреляция — это способ соединить разрозненные сигналы в одну картину.

Например:

лог входа с IP-адреса → вызов PowerShell → загрузка файла из интернета

или

лог DNS-запроса → HTTP GET → новый процесс → утечка трафика.

Корреляция — один из главных навыков хантеров: не просто анализ отдельных событий, а умение собрать их в историю.

Построение гипотезы и запросов

Когда есть понимание нормы и доступ к данным, формируется гипотеза. Это основа всей охоты. Без неё работа превращается в бессмысленное копание в логах.

Гипотезы:

1. Кто или что могло быть нарушителем.
2. Что он делал (какое поведение мы ищем).
3. Где это поведение можно зафиксировать.

Формат запроса:

1. Что ищем?
    Пример: вызовы powershell.exe с параметрами -enc или -w hidden.
2. Где ищем?
    В логах процессов, Windows Event Logs, telemetry EDR.
3. Почему это важно?
    Такие параметры часто используются при fileless-атаках, которые не срабатывают в антивирусах.

Аналитик переводит запрос в структурированный запрос для siem sistem.

Анализ и подтверждение

Результаты запроса — не ответ. Это исходник для анализа. На этом этапе хантер:

1. Сравнивает активность с baseline.
2. Проверяет, повторяется ли поведение.
3. Сопоставляет с внешними источниками — TI-репозиториями, CVE, IOC-базами.

Что помогает:

• IOC и поведенческие индикаторы (IOA);
• Визуализация в Kibana, Grafana, XDR-интерфейсах;
• Отладка с помощью скриптов — Python, Jupyter.

Пример:
Если обнаружен набор IP-адресов, хантер может проверить их по TI-источникам (VirusTotal, MISP) и выяснить, входят ли они в инфраструктуру ботнета.

Важный момент: хантер не просто ловит — он доказывает. Нужно понимать, почему срабатывание не ложное.

Документирование, выводы, передача в IR

Даже если найденная активность не является прямой атакой — выводы нужно зафиксировать.

Что фиксируют:

1. Гипотезу, по которой велась охота.
2. Данные, которые использовались.
3. Что именно было обнаружено (и не обнаружено).
4. Какие действия были предприняты.
5. Что улучшить: логирование, правила, модель поведения.

Если угроза реальна — информация передаётся в SOC или команду реагирования.
Если нет — вывод всё равно полезен: он помогает уточнить baseline, сформировать новые правила, улучшить модели.

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

Успешный Threat hunting невозможен без инструментов сбора, анализа и сопоставления данных. Даже самый опытный хантер не сможет эффективно работать без доступа к логам, сетевому трафику и контексту активности пользователей. В этом разделе разберём, какие российские системы реально применяются в охоте, как автоматизировать процесс.

Основные системы

SIEM: сбор, агрегация, аналитика

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

В статье разобрали, что такое SIEM, кому и когда он нужен.

Российские SIEM-платформы:

• MaxPatrol SIEM (Positive Technologies): одна из самых зрелых систем, поддерживает расширенные сценарии хантинга, есть готовые интеграции с DLP, TI, AD.
• UserGate SIEM — современная платформа с аналитикой, корреляцией событий и встроенной системой реагирования. Поддерживает сбор логов с сетевых устройств, рабочих станций, серверов, WMI/SNMP-источников. Есть собственный IR-интерфейс для обработки инцидентов.

Во всех случаях хантер использует SIEM как точку входа: здесь он формулирует запросы, отслеживает подозрительные события и строит цепочки активности.

EDR/NDR: анализ поведения на хостах и в сети

EDR и NDR нужны, чтобы видеть то, что не попадает в журналы событий — процессы, сетевые соединения, обращения к памяти и другим подсистемам.

Как работают EDR-системы, зачем они нужны и как выбрать — читайте полный обзор.

Из отечественных решений применимы:

• MaxPatrol EDR (Positive Technologies). Собирает телеметрию с рабочих станций: запуски процессов, обращения к памяти, сетевую активность. Позволяет строить цепочки событий, выявлять fileless-атаки, lateral movement и закрепление в системе. Подходит для ручного анализа и интеграции в SIEM.
• Kaspersky EDR / EDR Optimum. Фиксирует поведение приложений, визуализирует цепочки действий (например, Word → PowerShell → сеть). Есть функции изоляции хоста, выгрузки файлов и реагирования. Используется для расследований и поддержки ручного хантинга.

Хантер может использовать данные от этих агентов для построения корреляций: кто и когда запускал определённый скрипт, какова была реакция системы, происходила ли попытка соединения с внешними адресами.

UEBA: выявление аномалий в поведении

Анализ поведения пользователей (User & Entity Behavior Analytics) особенно важен для охоты на инсайдеров, скомпрометированные учётки и латеральные перемещения.

Рассказываем подробно, как поведенческая аналитика помогает ловить незаметные атаки

Применяемые в РФ решения:

• InfoWatch Prediction (DLP + UEBA). Модуль поведенческого анализа в составе InfoWatch DLP. Строит профили сотрудников по действиям в системах, документах, почте. Выявляет отклонения, связанные с повышенным риском (например, копирование конфиденциальных данных перед увольнением).
• Kaspersky Fraud Prevention (для финтеха). Не классическая UEBA, а специализированная поведенческая аналитика для защиты цифровых каналов: интернет-банка, мобильных приложений. Распознаёт аномальное поведение пользователей, заражённые устройства, подмену сессий.
• Solar Dozor UBA (Ростелеком-Solar) Модуль анализа активности пользователей в системе Solar Dozor. Отслеживает взаимодействия с файлами, системами и почтой. Выявляет отклонения от привычного сценария: скачивание большого объёма данных, смену модели поведения, нетипичный доступ.

UEBA особенно полезна для ситуаций, где технических IOC нет, а поведение отклоняется от нормы: вход не с того региона, запуск команд в нерабочее время, массовое копирование файлов.

TI-фиды и базы угроз

Threat Intelligence в российском хантинге тоже используется в локализованной форме.

Источники:

• MaxPatrol TI: собственная база индикаторов угроз от Positive Technologies, регулярно обновляется.
• GIB TI (Group-IB): включает фиды по инфраструктурам ботнетов, вредоносным адресам, активностям группировок.
• Роскомнадзор и ФСТЭК: реестры актуальных угроз и уязвимостей (включая БДУ ФСТЭК).
• Внутренние базы SOC и интеграторов: накопленные IOC по проектам, обмен в рамках ГосСОПКА.

Такие фиды позволяют оперативно добавлять IOC в сценарии поиска, проверять свои логи и трафик на предмет актуальных индикаторов.

Скрипты и автоматизация

Хантер может многое сделать вручную, но на больших объёмах данных это просто невыгодно. Автоматизация нужна даже для частных задач: ускорить проверку гипотез, повторно запускать сценарии, документировать цепочки.

Что реально используется в России:

• Python‑скрипты: для выборки логов, трансформации данных, парсинга выгрузок из SIEM.
• Jupyter Notebook: интерактивная среда, где хантер может запускать код, строить графики, фиксировать результаты. Особенно удобно для командной работы.
• Sigma‑форматы: стандарт описания правил хантинга. Поддерживается рядом SIEM отечественной сборки через трансляторы.
• Внутренние утилиты: у крупных организаций часто есть самописные скрипты для фильтрации логов, поиска аномалий, обработки почтовых журналов, анализа прокси.

Хорошая практика — сохранять все скрипты и шаблоны запросов в репозитории. Это даёт возможность повторить охоту в будущем или масштабировать её на другие узлы.

Примеры кейсов и практики охоты на угрозы

Покажем, как Threat hunting реализуется с использованием отечественных решений и в типичных российских инфраструктурах. Это не теория из западных учебников, а рабочий инструмент в условиях импортозамещения.

Использование MaxPatrol SIEM для охоты

Кейс:

• Организация: крупная финансовая структура.
• Сценарий: в SIEM фиксируются периодические обращения к PowerShell с параметрами, указывающими на попытку lateral movement.
• Действия:
  • Хантер формирует гипотезу о внутренней атаке.
  • Строит запрос в MaxPatrol SIEM по событиям из Windows Event Log (ID 4688, 4624).
  • Находит цепочку команд, включающих Invoke-Command и EncodedCommand.

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

Поиск C2-каналов в Traffic Monitor

Кейс:

• Организация: телеком-компания.
• Инструмент: InfoWatch Traffic Monitor в связке с анализом сетевого трафика и DLP.
• Сценарий: DNS-запросы к слабоизвестным доменам, с высоким TTL и регулярным интервалом.
• Подозрение: DNS-туннелирование для C2.
• Действия:
  • Построен фильтр по нестандартному поведению DNS.
  • Проверка через локальные IOC-базы.
  • Блокировка подозрительных доменов и сбор дампов с подозрительных машин.

Вывод: российский DLP успешно используется не только по профилю, но и как вспомогательный инструмент hunt.

Имитация атаки Red Team и реагирование

Кейс:

• Инструменты: Positive Technologies MaxPatrol SIEM + PT NAD (сетевойанализ) + Purple Team подход.
• Сценарий: команда ИБ инициировала внутреннюю имитацию атаки — условный APT-нападение с lateral movement, dump credentials, persistence.
• Хантер по гипотезе выявляет непрофильную активность в AD, подозрительное использование PsExec.
• Настраивается фильтр: «повторяющиеся логины к хостам с одинаковыми токенами».
• Угроза локализована, отчёт задокументирован.

Вывод: российские решения дают нужный инструментарий для полноценных охот при наличии методологии и команды.

Как встроить Threat hunting в ИБ-практику

Threat hunting не получится внедрить «по регламенту» — как, например, обновление антивируса. Это не кнопка, которую можно включить, и не инструмент — купил и он работает. Это процесс, который требует культуры, навыков, времени и понятных целей.

Чтобы хантинг стал частью ИБ-практики, его нужно встроить: в ежедневную рутину, в систему метрик, в процесс управления рисками. Расскажем, как это сделать.

Кто должен этим заниматься

Threat hunting — не обязанность одного администратора. Это командная работа, где каждый участник вносит свой вклад.

Минимальный состав:

• Хантер-аналитик: формирует гипотезы, пишет запросы, исследует логи.
• Инженер по данным: отвечает за доступ к источникам, корректность логирования, настройку SIEM.
• Старший аналитик или CISO: оценивает бизнес-контекст, принимает решения по результатам, расставляет приоритеты.

Если в компании нет выделенного подразделения Threat hunting, можно начать с инициативной роли внутри SOC или группы ИБ. Один сотрудник начинает копать «вглубь» на основе простых гипотез, фиксирует результаты, делится сценариями, и процесс постепенно масштабируется.

Какие навыки нужны:

1. Логическое мышление и аналитика — умение строить причинно-следственные связи.
2. Знание инфраструктуры: кто, где, как работает; какие системы на что влияют.
3. Понимание MITRE ATT&CK, техник lateral movement, fileless‑атак.
4. Умение работать с логами, скриптами, визуализацией.
5. Желание копать и докапываться — без этого никуда.

Обучение:

• Внутренние тренировки — идеальный вариант. Пусть SOC подкинет хантеру задачу, а он попробует её «выловить».
• Участие в CTF и red team-симуляциях.

Как измерить эффективность

Хантинг — затратный процесс, требует времени и ресурсов, в том числе интеллектуальных. Чтобы его поддерживали, он должен быть измерим, иначе через полгода в отчёте напишут: «Результатов нет, зачем мы этим вообще занимались».

Какие метрики Threat hunting реально работают:

• Количество найденных угроз. Главное — не в абсолютных цифрах, а в качестве: удалось ли найти то, что прошло мимо остальных систем, предотвратить развитие угрозы.
• False Positive Rate. Если каждая гипотеза даёт десятки ложных срабатываний — либо гипотеза плохая, либо baseline не настроен.
• Coverage по MITRE ATT&CK. Сколько техник покрыто сценариями хантинга, сколько из них проверяется регулярно.
• Время от гипотезы до результата. Сколько уходит на полный цикл: сформулировали → написали запрос → нашли/не нашли → оформили вывод. Это влияет на темп работы и загрузку команды.
• Регулярность охоты. Раз в неделю, дважды в месяц, при выходе нового CVE — должна быть чёткая периодичность. Если охота проводится только «по вдохновению» — она исчезнет.

Дополнительно можно ввести рейтинг гипотез, карту зрелости Threat hunting (например, по уровням: ручной, частично автоматизированный, встроенный в SOC) и вести журнал успешных кейсов.

Главное: результаты нужно не просто считать, а показывать бизнесу. Если хантинг выявил скрытую утечку или предупредил инцидент — это сильнее любого отчёта о «1000 алертов в SIEM».

Нормативные требования

Threat hunting напрямую не прописан в российских законах. Но его функции и результаты перекрывают ряд обязанностей, которые регуляторы возлагают на владельцев ИС, КИИ и операторов ПДн. Хантинг может не называться обязательным, но его отсутствие почти всегда означает, что организация либо не логирует, либо не анализирует происходящее внутри.

Как Threat hunting помогает

Threat hunting не заменяет выполнение требований, но он делает их выполнение реальным, а не на бумаге. Его задача — фактическое обнаружение и контроль.

Хантинг помогает отлавливать нарушения поведения до того, как они перерастают в инцидент:

• необычное поведение учётной записи администратора;
• нетипичная активность в выходные;
• внутреннее сканирование сети;
• подмена процесса обновления.

Без хантинга — лог есть, срабатывания нет, угроза продолжает развиваться.

ФСТЭК требует уведомлять о происшествиях. Если инцидент зафиксирован задним числом — это уже нарушение сроков. Threat hunting позволяет:

• локализовать подозрительную активность;
• проверить, распространилась ли угроза;
• сформировать отчёт до того, как события получат широкий масштаб.

Раннее выявление — способ не доводить дело до уведомления или минимизировать объём и ущерб.

Главное

Threat hunting — это активная разведка внутри инфраструктуры, а не пассивное ожидание срабатываний.
Он нужен там, где нельзя надеяться только на правила, сигнатуры и алерты. Особенно когда речь о сложных атаках или скрытной активности.

Хантинг дополняет, а не заменяет SOC, SIEM и IR.
Расширяет зону видимости и помогает выявить то, что ускользает от автоматизированных систем. Его ценность — в способности находить угрозы до инцидента.

Есть несколько подходов: структурированный, неструктурированный и ситуативный.
Нет единственно правильного способа охотиться. Главное — наличие гипотезы, данных и логики действий. Формат охоты зависит от зрелости команды и доступных инструментов.

Хантинг строится на фреймворках и здравом смысле.
MITRE ATT&CK — база для построения гипотез. Diamond Model, Kill Chain и другие помогают структурировать логику атак. Но без контекста инфраструктуры и опыта команды фреймворки не работают.

Главный инструмент хантера — не SIEM, а гипотеза.
Вопрос «а что, если…» — отправная точка любой охоты. Умение ставить правильный вопрос и находить подтверждение важнее, чем знание 100 команд.

Успех зависит от команды, не от лицензий.
Нужны не просто сотрудники, а люди, которые умеют думать, замечать отклонения, работать с логами.

Без документирования хантинг не работает.
Каждая проверка — это новый кейс, опыт, шаблон. Без фиксации выводов процесс не развивается, а знания теряются. Повторяемость и передача результатов в SOC/IR — обязательны.

Хантинг помогает соответствовать требованиям.
Да, его нигде не требуют напрямую. Но без него невозможно доказать, что вы реально контролируете происходящее.

Внедрять хантинг — не значит тратить миллионы.
Можно начать с базовых гипотез, собственных логов, одного SIEM и здравого смысла. Главное — начать задавать правильные вопросы.