Threat hunting: с чего начать и как встроить в работу SOC

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

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

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

Чем threat hunting отличается от реагирования на срабатывания

Реагирование начинается с алерта: правило детектирования сработало, и аналитик проверяет, реальна ли угроза. Threat hunting устроен наоборот — аналитик начинает с гипотезы «здесь могла быть активность, которую мы не увидели бы штатным детектированием» и идет проверять ее напрямую по сырой телеметрии, вне зависимости от того, сработало что-то или нет.

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

Проактивный поиск не отменяет ни триаж, ни расследование инцидентов в EDR — методика чтения телеметрии и построения таймлайна, разобранная в статье «Расследование инцидента в EDR», нужна охотнику ровно так же, как аналитику, который разбирает готовый алерт. Отличается только повод начать смотреть в данные.

Что нужно иметь до старта: данные, хранение и доступ

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

Телеметрия конечных точек

Основной источник для большинства гипотез — телеметрия процессов, сетевых соединений, файловой активности и запуска команд на рабочих станциях и серверах. Именно эти данные собирает EDR, и без них охотник ограничен логами, которые ведутся не для целей расследования, а для эксплуатации системы. Что такое EDR, как устроен сбор телеметрии и почему это не то же самое, что антивирус, разобрано в статье «Что такое EDR».

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

Журналы почты и DNS

Часть техник закрепления и связи с управляющей инфраструктурой видна не на конечной точке, а на уровне почты и DNS-запросов. Журнал DNS-запросов помогает увидеть, обращался ли узел к домену, который не был заблокирован автоматически, но выглядит подозрительно постфактум — например, недавно зарегистрированному или похожему на легитимный бренд. Принцип работы такого журналирования и то, какие данные в нем доступны, описаны в статье «Как работает Secure DNS».

Почтовые журналы, в свою очередь, дают историю доставленных писем, вложений и переходов по ссылкам — полезно для гипотез о фишинге, который не был заблокирован на входе. Смежная тема разобрана в статье «Secure DNS против фишинга»: она показывает, как DNS-слой и почтовая защита закрывают разные части одного и того же пути атаки, и почему для охотника важны данные из обоих источников.

Хранение и доступ аналитика

Гипотеза часто требует данных за недели, а не за последние часы — техника закрепления могла сработать до того, как о ней стало известно. Если телеметрия хранится неделю, а не месяцы, часть гипотез в принципе не проверить: данных, которые нужно посмотреть, уже не существует. Срок хранения — это не техническая деталь, а прямое ограничение того, какие вопросы SOC способен себе задать.

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

Как формулировать и проверять гипотезу

Хорошая гипотеза threat hunting строится не из общего опасения «а вдруг нас взломали», а из конкретной техники: что именно мог сделать атакующий, какой наблюдаемый след эта техника оставляет в доступной телеметрии, и каким запросом этот след можно найти. Если один из трех элементов отсутствует — техника не связана со следом, или след не проверяется имеющимися данными, — гипотезу нужно переформулировать до начала поиска, а не в процессе.

Практический путь построения гипотезы выглядит так:

1. Возьмите одну технику, а не класс атак целиком. «Закрепление через автозапуск» — рабочая формулировка, «атака шифровальщика» — нет: слишком широко, чтобы получить конкретный запрос к данным.
2. Определите наблюдаемый след. Что именно должно быть видно в телеметрии, если техника применялась: конкретный ключ реестра, характерная командная строка, последовательность родитель-потомок процессов, обращение к определенному классу доменов.
3. Сформулируйте запрос к телеметрии. Запрос должен быть исполним на имеющихся данных сегодня, а не в теории после доработки хранилища.
4. Задайте критерий закрытия гипотезы заранее. Что будет считаться подтверждением, что — опровержением, и сколько данных достаточно проверить, прежде чем закрыть гипотезу как неподтвержденную. Без этого критерия охота рискует длиться неопределенно долго в поиске несуществующего следа.
5. Запустите запрос и разберите каждое совпадение тем же способом, каким аналитик разбирает алерт: контекст хоста, пользователя, времени и соседних событий, а не факт совпадения сам по себе.

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

Как оформить результат охоты

Охота, которая не подтвердила присутствие атакующего, не бесполезна, если она дает SOC один из трех результатов: правило детектирования, наблюдение или изменение процесса. Именно оформление результата отличает threat hunting от разового любопытства аналитика.

• Правило детектирования. Если гипотеза подтвердилась хотя бы один раз, наблюдаемый след стоит формализовать в правило, чтобы в следующий раз его нашла штатная система детектирования, а не отдельная охота. Это превращает разовую находку в постоянное покрытие.
• Наблюдение. Не каждая охота дает материал для правила — иногда результат в том, что источник телеметрии оказался неполным, или гипотеза была верной, но след слишком похож на легитимную активность для автоматического правила. Такое наблюдение стоит зафиксировать письменно: оно экономит время следующему аналитику, который придет к той же мысли.
• Изменение процесса. Часть находок threat hunting — не про атакующих, а про инфраструктуру: сервис логирует не то, что нужно, агент EDR не развернут на части узлов, доступ к телеметрии избыточен для части ролей. Это тоже результат охоты, и он часто ценнее одного найденного индикатора.

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

Как встроить охоту в смену SOC, чтобы она не съедала дежурство

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

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

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

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

Чем измерять пользу threat hunting

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

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

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

Частые ошибки

• Охота без данных. Гипотеза сформулирована, но телеметрии, которая могла бы ее подтвердить или опровергнуть, просто нет — ни по глубине, ни по сроку хранения. Итог — время потрачено, ответа не получено.
• Охота ради отчета. Цикл проводится потому, что он числится в плане, а не потому, что гипотеза интересна и проверяема. Такие охоты формально закрываются, но не дают ни правил, ни наблюдений.
• Гипотезы без критерия закрытия. Аналитик проверяет одну и ту же мысль неделями, потому что заранее не решил, какой объем проверки будет считаться достаточным. Это либо съедает ресурс смены, либо гипотеза бросается на середине без вывода.
• Смешение охоты с триажем текущих алертов. Если во время выделенного окна на охоту аналитик отвлекается на входящую очередь, ни то ни другое не доводится до конца.
• Отсутствие записи результата. Находка живет в переписке или в голове одного человека и теряется при следующей ротации смены.
• Одна и та же гипотеза без обновления. Техники атакующих меняются, и гипотеза, актуальная год назад, может не отражать текущие варианты той же техники.

С чего начать в первую неделю

1. Проверьте, чем вы располагаете: телеметрия конечных точек, журналы почты и DNS, срок их хранения, права аналитиков на самостоятельные запросы.
2. Возьмите одну технику закрепления или перемещения, которая уже разбиралась в прошлых инцидентах вашей организации, — это самый надежный источник первой гипотезы.
3. Сформулируйте наблюдаемый след и запрос к телеметрии, прежде чем садиться за инструмент поиска.
4. Заранее определите критерий закрытия гипотезы и тайм-бокс на проверку.
5. Проведите первый цикл в отдельном, защищенном от текущей очереди алертов окне времени.
6. Зафиксируйте результат письменно — даже если гипотеза не подтвердилась.
7. Если след подтвержден хотя бы раз, доведите его до правила детектирования, чтобы не искать его вручную в следующий раз.

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

Практика на стендах BI.ZONE Cybersecurity Labs

Threat hunting опирается на умение читать телеметрию так же, как расследование готового инцидента, — разница только в том, с чего аналитик начинает: с алерта или с собственной гипотезы. Курс «Внедрение и администрирование BI.ZONE EDR» дает практику именно с этой телеметрией на изолированном стенде: развертывание продукта, настройка политик защиты и работа с данными, которые становятся основой для любой гипотезы охотника.

Если ваша команда чаще сталкивается с готовыми инцидентами, чем с проактивным поиском, начните со статьи «DFIR: как расследовать инцидент пошагово» — многие находки threat hunting превращаются в гипотезы именно после разбора реального расследования, а не наоборот.