Полювання на загрози: що це таке і як воно працює

Полювання на загрози — це практика активного пошуку в мережах та на кінцевих точках зловмисників, які вже пройшли повз ваші існуючі виявлення. Це починається з простого, неприємного припущення: щось погане може вже перебувати всередині, і жодне сигналу тривоги за це не спрацювало. Замість очікування на спрацювання правила SIEM, мисливець формує гіпотезу й шукає докази, щоб її підтвердити або спростувати.

Чому самого виявлення недостатньо

Виявлення на основі сигнатур та правил ловить відомі шаблони. Зловмисники, які використовують living-off-the-land binaries (LOLBins), дійсні облікові дані або повільні техніки з малим обсягом, можуть залишатися під цими порогами тижнями. Полювання на загрози заповнює цей розрив, маючи людину, яка активно ставить питання до даних: чи має сенс цей виклик PowerShell з робочої станції фінансового відділу о 2 ранку? Чому svchost.exe здійснює вихідне з'єднання з IP, у якого немає зворотного DNS?

Це не реагування на інцидент. Реагування починається після того, як ви дізнаєтесь, що щось сталося. Полювання починається, коли ви ще цього не знаєте, і мета — дізнатися це до того, як більша подія змусить ставити питання.

Три звичайні вихідні точки

Більшість полювання починаються з одного з трьох напрямків:

• Керована розвідкою: новий звіт про загрозу описує TTP (наприклад, зловживання запланованим завданням для збереження), і ви перевіряєте, чи він присутній у вашому середовищі.
• Обізнаність про ситуацію: ви дивитеся, що насправді незвичайне для вашої організації — облікова запис служби, яка автентифікується з країни, з якої вона ніколи не робила цього раніше, або всплиск трафіку SMB між робочими станціями, які зазвичай розмовляють лише з серверами.
• Керована аналітикою: ви будуєте базис нормальної поведінки (дерева процесів, час входу, обсяг DNS запитів) і шукаєте статистичні викиди щодо нього.

MITRE ATT&CK — це довідник, який використовує більшість команд для структурування гіпотез. Замість "шукайте шкідливе ПЗ", ви вибираєте техніку на кшталт T1053 (Scheduled Task/Job) і запитуєте: як це виглядатиме в наших Windows Event Logs або в телеметрії EDR, і чи можу я запитати це прямо зараз?

Як виглядає фактичний робочий процес

Полювання зазвичай дотримується цього циклу:

1. Сформулювати конкретну, перевірювану гіпотезу (не "перевірте на вторгнення", а "перевірте нові запланові завдання, створені поза вікнами оновлень за останні 30 днів").
2. Визначити потрібні джерела даних — Sysmon Event ID 1 для створення процесу, Windows Security Event ID 4698 для створення запланованого завдання, дерева процесів EDR або журнали Zeek conn для контексту мережі.
3. Запитувати та шукати зв'язки. На практиці це означає написання KQL у Microsoft Sentinel, SPL у Splunk або необроблені запити проти індексу Elastic.
4. Сортувати результати — більшість будуть хибнопозитивні або безневинна активність адміністратора, і завдання звужує цей шум до того, що справді аномально.
5. Документувати результати, чи то підтвердженого компрометування, прогалини у виявленні, або просто