Статья Threat Hunting для начинающих: от первой гипотезы до рабочей охоты в SIEM

Начало рабочей недели. Дашборд Elastic SIEM чист - ни одного критического алерта за выходные. Красота. Через два часа сетевой инженер замечает аномальный SMB-трафик между двумя серверами, которые раньше не обменивались данными. Начинаем копать: сервисная учётка, созданная полгода назад для миграции, четыре дня подряд использовалась для перемещения по сети. PowerShell с закодированными командами, WMI для удалённого запуска процессов, Certutil для загрузки инструментов - ни одного вредоносного файла на диске. Fileless, как по учебнику. SIEM молчал, потому что правила корреляции были заточены на конкретные хеши и IP из фидов. После этого postmortem я перестал верить, что алертов достаточно, и начал выстраивать в команде процесс проактивного поиска угроз. Дальше - конкретная threat hunting методология и три готовых охоты, которые можно запустить в вашем SIEM сегодня.

Зачем атакующему тишина и при чём тут ваш SOC​

По данным CrowdStrike Global Threat Report 2025, 79% атак в 2024 году прошли без малвари - атакующие работали штатными утилитами ОС: PowerShell (T1059.001), WMI (T1047, Execution), Certutil. Среднее время lateral movement после первичного доступа - 62 минуты, рекорд - 51 секунда. Mandiant M-Trends 2025 фиксирует медианное dwell time 11 дней - исторический минимум, но за 11 дней можно вынести всё. Подробнее - в нашем материале про обнаружение apt атак.

Для Blue Team это значит простую вещь: набор правил корреляции в SIEM, заточенных на известные IoC, ловит меньшую часть реальных атак. Остальное - hands-on-keyboard активность, которая маскируется под работу администратора. Скомпрометированный хост выглядит в логах нормально: сервисная учётка запускает PowerShell, рядовой сотрудник открывает документ. Отличить атакующего от админа можно только по совокупности аномалий - этим и занимается threat hunting.

Есть и финансовый аргумент. Оборотные штрафы за утечку персональных данных в России делают стоимость пропущенного инцидента несопоставимой со стоимостью аналитика, который раз в неделю проверяет одну гипотезу. Threat hunting - не замена SIEM-правил, а надстройка, закрывающая слепые зоны автоматики.

Hypothesis-driven threat hunting: как строить гипотезы по MITRE ATT&CK​

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

Подход	Преимущества	Ограничения	Когда применять	Когда не применять
Структурированный (hypothesis-driven)	Повторяемый, масштабируемый, легко передать коллегам	Зависит от качества гипотез, может пропустить неизвестные TTP	SOC с настроенной телеметрией и Sysmon	Команда без опыта формулировки гипотез
Неструктурированный (anomaly-based)	Находит неизвестное, не ограничен фреймворками	Требует насмотренности, плохо масштабируется	Опытный аналитик, разведка нового сегмента	Нет baseline, команда из джуниоров
Ситуативный (trigger-based)	Привязан к конкретному триггеру, быстрый старт	Реактивен, покрытие узкое	После публикации CVE, при подозрении без алерта	Как единственный подход - слишком узко

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

Цикл одной охоты:

1. Гипотеза. Берём технику из MITRE ATT&CK и формулируем предположение: "Атакующий мог использовать T1059.001 (PowerShell) для запуска закодированных команд на серверах домена».
2. Источник данных. Определяем телеметрию: Windows Event Log 4104 (Script Block Logging), Sysmon Event ID 1 (Process Creation).
3. Запрос. Пишем KQL- или SPL-запрос, который ищет артефакты этой техники.
4. Анализ. Разбираем результаты: отделяем легитимную активность от подозрительной по контексту - пользователь, время, родительский процесс.
5. Результат. Документируем, при необходимости передаём в IR-команду, создаём правило detection для автоматизации.

Из фреймворков, которые помогают систематизировать цикл: MITRE ATT&CK как база знаний о техниках - фундамент для формулировки гипотез. Для более зрелых команд есть PEAK (трёхфазная методология: Prepare, Execute, Act with Knowledge), TaHITI (модульный подход с плотной привязкой к threat intelligence) и OTHF (открытый фреймворк с переиспользуемыми playbook-ами). Для старта хватит MITRE ATT&CK и описанного пятишагового цикла - всё остальное наращивается по мере повышения зрелости.

Требования к окружению для первых охот​

Перед первой охотой убедитесь, что минимальный стек на месте. Без него - как искать lateral movement по логам межсетевого экрана: технически можно, но теряете 80% контекста.

Обязательно:

• SIEM с полнотекстовым поиском: Elastic Security (бесплатный тир, KQL) или Splunk Free (до 500 МБ/день, SPL)
• Windows Event Logs: Security (Event ID 4624, 4672, 4688), PowerShell (4103, 4104), System
• Sysmon на целевых хостах (Event ID 1, 3, 7, 8, 10, 11) - конфигурация SwiftOnSecurity или sysmon-modular от Olaf Hartong (GitHub, активно поддерживается)
• Глубина хранения логов: минимум 30 дней, рекомендуется 90

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

• 16 ГБ RAM для одноузлового Elastic стека (Elasticsearch + Kibana + Elastic Agent)
• 8 ГБ RAM для Splunk Free
• ОС: Ubuntu 22.04 LTS или Windows Server 2019+ для источника логов
• Sysmon 15.x (последняя стабильная версия)

Рекомендуется:

• Velociraptor для ad-hoc сбора артефактов с хостов
• Sigma CLI для конвертации Sigma-правил в KQL/SPL
• MITRE ATT&CK Navigator для визуализации покрытия

Без Sysmon threat hunting слеп на критических уровнях: не увидите аргументы командной строки процессов, сетевые соединения дочерних процессов, загрузку DLL. Искать обнаружение скрытых атак по голым Windows-логам можно, но вы теряете 80% контекста.

Три первые охоты: от гипотезы до результата​

Три готовых сценария. Каждый следует одной схеме: гипотеза, источник данных, запрос, интерпретация результатов, ограничения. Запросы написаны на KQL для Elastic Security - для Splunk логика та же, меняется синтаксис на SPL.

Охота 1: закодированный PowerShell (T1059.001, Execution)​

Гипотеза: атакующий использует PowerShell с параметрами -EncodedCommand или -e для выполнения обфусцированных команд на серверах.

Источники данных: Sysmon Event ID 1 (Process Create), PowerShell Event ID 4104 (Script Block Logging).

process.name : "powershell.exe" AND
process.command_line : (*" -enc "* OR *" -encodedcommand "*
  OR *"FromBase64String"* OR *" -w hidden"*)
AND NOT user.name : ("SYSTEM" OR "LOCAL SERVICE")

На что смотреть в результатах:

• Кто запустил: сервисная учётка или интерактивный пользователь?
• Откуда: рабочая станция бухгалтера или контроллер домена?
• Время: 3 часа ночи в субботу - нетипично для легитимного скрипта автоматизации.
• Родительский процесс: если PowerShell порождён от wmiprvse.exe или mshta.exe - красный флаг. Это указывает на удалённое выполнение или скриптовую эксплуатацию.

Ограничения: легитимные инструменты (SCCM, DSC, некоторые backup-агенты) тоже используют -EncodedCommand. Создайте whitelist по parent process и user. Атакующие обходят этот detection через powershell -version 2 (Script Block Logging (Event ID 4104) доступен только с PowerShell 5.0, поэтому downgrade до v2 обходит 4104, но сам запуск v2 engine детектируется через Event ID 400 в логе "Windows PowerShell" (не "Microsoft-Windows-PowerShell/Operational") по полю EngineVersion=2.0; на Windows Server 2019+ v2 engine отсутствует по умолчанию) или вызов System.Management.Automation.dll напрямую из C# - для покрытия этих случаев нужен мониторинг загрузки DLL через Sysmon Event ID 7.

Охота 2: нестандартный доступ к LSASS (T1003.001, Credential Access)​

Гипотеза: процесс, не являющийся штатным системным компонентом или средством защиты, обращается к памяти lsass.exe для дампа учётных данных.

Источники данных: Sysmon Event ID 10 (ProcessAccess), где TargetImage содержит lsass.exe.

event.code : "10" AND
winlog.event_data.TargetImage : *lsass.exe AND
NOT winlog.event_data.SourceImage : *lsass.exe AND
NOT winlog.event_data.SourceImage :
  (*csfalconservice* OR *MsMpEng*
   OR "C:\\Windows\\System32\\svchost.exe"
   OR "C:\\Windows\\System32\\csrss.exe"
   OR "C:\\Windows\\System32\\wininit.exe"
   OR "C:\\Windows\\System32\\lsaiso.exe")

На что смотреть:

• SourceImage: если это rundll32.exe, notepad.exe или процесс из %TEMP% - вероятность дампа credential высокая.
• GrantedAccess: значение 0x1010 (PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ) типично для чтения памяти LSASS; 0x1410 (PROCESS_QUERY_LIMITED_INFORMATION 0x1000 + PROCESS_QUERY_INFORMATION 0x0400 + PROCESS_VM_READ 0x0010) - классический паттерн старых версий mimikatz; современные варианты могут использовать 0x1010 или 0x143A; 0x1FFFFF (PROCESS_ALL_ACCESS) - полный доступ. Все три значения - индикаторы credential dumping.
• Контекст инсайдерской угрозы: скомпрометированный хост - администратор, чья рабочая станция используется атакующим - типичный сценарий. В логах всё выглядит нормально: правильная учётка, правильный хост. Только факт обращения нестандартного процесса к LSASS выдаёт атаку.

Ограничения: whitelist SourceImage требует регулярного обновления - каждый новый EDR-агент или системный апдейт добавляет легитимный процесс, обращающийся к LSASS. Используйте полные пути вместо substring-паттернов, чтобы исключить обход через T1036.005 (Match Legitimate Resource Name or Location - размещение вредоносного бинарника с именем svchost.exe в нестандартном каталоге). Продвинутые атакующие применяют direct syscalls, клонирование процесса LSASS или дамп через comsvcs.dll (T1003.001) - Sysmon Event ID 10 эти варианты может не поймать. Для полного покрытия нужны дополнительные источники: мониторинг доступа к файлу дампа, правила на MiniDumpWriteDump.

Охота 3: Certutil как загрузчик​

Гипотеза: атакующий использует штатную утилиту certutil.exe для загрузки файлов из интернета или декодирования полезной нагрузки.

Certutil - классический LOLBAS-бинарь. По каталогу LOLBAS Project, certutil.exe покрывает категории Download (T1105), Decode (T1140), Encode (T1027.013) и ADS (T1564.004). Подписанный системный файл Windows для работы с сертификатами - большинство антивирусов его не трогают. Идеальный "попутчик" для атакующего.

Источники данных: Sysmon Event ID 1 (Process Create) с аргументами командной строки.

Что искать: вызовы certutil с ключами -urlcache, -split, -decode, -encode в сочетании с внешними URL или путями в нетипичных директориях (%TEMP%, %APPDATA%, C:\Users\Public). Запрос для Elastic: фильтр по process.name: "certutil.exe" AND process.command_line: (urlcache OR decode OR encode).

Ограничения: некоторые скрипты обновления сертификатов используют certutil -urlcache легитимно. Фильтруйте по destination URL: обращения к внутренним CA-серверам - норма, к внешним IP-адресам или коротким доменам - подозрительно. Атакующие могут заменить Certutil на bitsadmin, curl (Windows 10+), Invoke-WebRequest - для полного покрытия техники T1105 нужен hunt по всем распространённым transfer-утилитам.

От находки к действию: что делать с результатами​

Результат охоты - не строка в логе. Каждая находка проходит через конкретную цепочку:

1. Верификация. Убедитесь, что это не false positive: проверьте контекст (пользователь, хост, время), сопоставьте с известной административной активностью. На практике 70-80% находок первых охот - легитимная активность. Это нормально.
2. Обогащение. Проверьте хеши, домены, IP через VirusTotal, AlienVault OTX или внутренние threat intelligence фиды.
3. Эскалация. Подтверждённая находка - передавайте в IR с полным контекстом: кто, что, когда, откуда, какая техника MITRE ATT&CK.
4. Автоматизация. Превратите ручной запрос в правило detection: Sigma-правило, конвертация в KQL/SPL, добавление в SIEM. Следующий раз эта техника поймается автоматически - суть перехода от IOC к TTP-охоте.
5. Документирование. Зафиксируйте гипотезу, запрос, результат, решение. Это ваша база знаний и основа для повышения уровня зрелости по модели Hunting Maturity Model.

Этот цикл реализует рекомендацию NIST CSF 2.0 (DE.AE-01): baseline сетевых операций и ожидаемых потоков данных должен быть установлен и управляем. Каждая охота уточняет ваш baseline - вы начинаете понимать, что нормально, а что нет, не по документации, а по реальным данным из вашей инфраструктуры.

Чеклист: запуск процесса threat hunting в команде​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Большинство SOC-команд, с которыми я работал, искренне считают, что занимаются threat hunting, потому что аналитики "смотрят логи". Но разбор алертов и проактивный поиск угроз в сети - принципиально разные вещи. Первый реактивен: сработало правило - разобрали. Второй начинается с вопроса, который аналитик формулирует сам, не дожидаясь подсказки от системы.

Из трёх описанных охот самая показательная - вторая, по LSASS. На ней я видел больше всего случаев, когда скомпрометированный хост выглядел полностью легитимно: правильная сервисная учётка, нормальный parent process, рабочее время. Единственное, что выдавало атакующего - обращение rundll32.exe к памяти LSASS с GrantedAccess 0x1010. Без целенаправленной охоты это никогда бы не всплыло ни в одном алерте.

Через пару лет hunting перестанет быть практикой только для зрелых SOC и станет обязательным - хотя бы потому, что оборотные штрафы за утечки растут быстрее, чем бюджеты на ИБ. Если в вашем SIEM пока нет готовых запросов под описанные техники - на codeby.net есть тред, где коллеги делятся Sigma-правилами для hunting по тактикам Execution и Credential Access.