Threat Hunting: What It Is and How It Works

Threat hunting — это практика активного поиска по сетям и конечным точкам злоумышленников, которые уже прошли мимо существующих систем обнаружения. Она начинается с простого, неприятного предположения: что-то плохое уже может находиться внутри, и при этом никакой alert не сработал. Вместо того чтобы ждать срабатывания правила SIEM, охотник формирует гипотезу и начинает искать доказательства её подтверждения или опровержения.

Почему одного обнаружения недостаточно

Обнаружение на основе сигнатур и правил ловит известные паттерны. Злоумышленники, использующие living-off-the-land binaries (LOLBins), легальные учётные данные или медленные техники с низким объёмом трафика, могут оставаться незамеченными в течение недель. Threat hunting закрывает этот пробел, привлекая человека, который активно ставит под сомнение данные: имеет ли смысл этот вызов PowerShell с финансовой станции в 2 часа ночи? Почему svchost.exe устанавливает исходящее соединение с IP без обратного DNS?

Это не incident response. IR начинается после того, как вы узнали, что что-то произошло. Hunting начинается, когда вы этого ещё не знаете, и целью является узнать об этом до того, как более крупное событие заставит задать этот вопрос.

Три основные точки старта

Большинство охот начинаются с одного из трёх углов:

• Intelligence-driven: новый threat report описывает TTP (например, злоупотребление scheduled task для persistence), и вы проверяете, присутствует ли оно в вашей среде.
• Situational awareness: вы смотрите на то, что действительно необычно для вашей организации — учётная запись сервиса, проходящая аутентификацию из страны, откуда она никогда ещё не подключалась, или скачок SMB-трафика между станциями, которые обычно общаются только с серверами.
• Analytics-driven: вы создаёте базовый профиль нормального поведения (деревья процессов, время входов, объём DNS-запросов) и ищите статистические выбросы относительно него.

MITRE ATT&CK — это эталон, который большинство команд используют для структурирования гипотез. Вместо того чтобы «искать малвар», вы выбираете технику вроде T1053 (Scheduled Task/Job) и спрашиваете: как это будет выглядеть в наших Windows Event Logs или телеметрии EDR, и могу ли я запросить это прямо сейчас?

Как выглядит реальный workflow

Охота обычно следует этому циклу:

1. Сформулируйте конкретную, проверяемую гипотезу (не «проверить на вторжения», а «проверить новые scheduled tasks, созданные вне окна обновлений за последние 30 дней»).
2. Определите необходимые источники данных — Sysmon Event ID 1 для создания процесса, Windows Security Event ID 4698 для создания scheduled task, деревья процессов EDR или Zeek conn logs для контекста сети.
3. Запрашивайте и развивайте. На практике это означает написание KQL в Microsoft Sentinel, SPL в Splunk или raw queries к индексу Elastic.
4. Сортируйте результаты — большинство будут ложными срабатываниями или безвредной активностью администраторов, и задача состоит в том, чтобы свести этот шум к тому, что действительно аномально.
5. Документируйте findings, будь то подтверждённый компромисс, пробел в обнаружении или просто