Чому “тиха” присутність у мережі небезпечніша за сам злам?

Уявіть: зловмисник отримав доступ до вашої мережі. Він не запускає ransomware. Не видаляє файли. Не піднімає алертів. Він просто… живе всередині. Дивиться. Вчиться. Готується.

Саме цей сценарій є найбільш руйнівним — і найменш помітним.

Що таке dwell time і чому він вирішує все?

Dwell time (час перебування) — це проміжок між початковою компрометацією і моментом виявлення атаки. За даними Mandiant M-Trends 2024, глобальний медіанний показник становить близько 10 днів. Але медіана — це не вся картина. У складних цільових атаках цифри сягають місяців.

Що відбувається за цей час? Зловмисник проходить повний kill chain:

Кожна з цих фаз може тривати дні або тижні. І кожна виглядає підозріло… нормально.

Чому класичний захист “не бачить”?

Сучасні атаки все рідше використовують класичне шкідливе ПЗ. Замість цього — Living off the Land (LotL): атакуючі використовують те, що вже є в системі.

Реальні приклади:

• PowerShell для збору даних про середовище — системні адміністратори роблять це щодня
• PsExec або WMI для переміщення між хостами — легітимний інструмент для remote management
• RDP для підключення до серверів — нічого незвичайного у робочий час
• certutil.exe для завантаження файлів — вбудована утиліта Windows
• Mimikatz — так, його сигнатури відомі, але існують десятки модифікацій, що обходять AV

Антивірус не піднімає алерт на PowerShell. SIEM отримує тисячі подій від RDP і не знає, яка з них аномальна. Команда SOC тоне в шумі.

Behavioral detection: від сигнатур до поведінки

Якщо атакуючий використовує легітимні інструменти — шукати потрібно не інструменти, а патерни поведінки.

Ось що відрізняє нормальну активність від аномальної:

Приклад 1: Lateral Movement

Нормально: адміністратор підключається до 2-3 серверів протягом дня
Аномалія: обліковий запис підключається до 47 хостів за 20 хвилин

Приклад 2: Credential Dumping

Нормально: доступ до lsass.exe від антивірусного агента
Аномалія: доступ до lsass.exe від процесу notepad.exe або cmd.exe

Приклад 3: Reconnaissance

Нормально: DNS-запити до зовнішніх ресурсів у робочий час
Аномалія: 10,000 DNS-запитів о 3:00 ночі від одного хоста

Саме на цьому базується UEBA (User and Entity Behavior Analytics) — підхід, який встановлює “baseline” нормальної поведінки для кожного користувача та хоста, а потім виявляє відхилення.

Threat Hunting: не чекати алертів — шукати самому

Reactive defense — відповідь на алерти — вже недостатня. Threat hunting — це проактивний пошук ознак компрометації до того, як спрацює автоматика.

Базовий цикл threat hunting:

1. Hypothesis — формулюємо гіпотезу: “у нас може бути active reconnaissance через ldap”
2. Data Collection — збираємо відповідні логи (DC Security logs, netflow)
3. Analysis — шукаємо аномалії: незвичні акаунти, нехарактерний час, нетипові обсяги
4. Response — якщо знайдено — ескалація та реагування
5. Improvement — якщо не знайдено — покращуємо detection rules

Ефективний threat hunting вимагає не лише інструментів, але й контексту: хто які системи адмініструє, які процеси нормальні для конкретного середовища, яка типова активність у неробочий час.

Метрики, які мають значення

Більшість організацій моніторять uptime і кількість заблокованих загроз. Але для реальної оцінки зрілості SOC важливіші інші показники:

• MTTD (Mean Time to Detect) — скільки часу минає від компрометації до виявлення
• MTTR (Mean Time to Respond) — від виявлення до локалізації
• Dwell Time — реальний час присутності зловмисника в мережі

Якщо ці метрики не вимірюються — вони не покращуються.

За даними IBM Cost of a Data Breach Report 2024, організації з зрілим SOC і автоматизацією виявлення економлять у середньому $1.76 млн порівняно з організаціями без цих процесів — при однаковому факті злому.

Що робити вже сьогодні?

Для компаній, які хочуть знизити dwell time, є кілька практичних кроків:

Короткострокові (1-4 тижні):

• Увімкнути розширений аудит у Active Directory (логи 4688, 4624, 4625, 4648, 4768)
• Налаштувати централізований збір логів з критичних хостів
• Переглянути правила кореляції в SIEM — більшість дефолтних правил надто гучні або надто тихі

Середньострокові (1-3 місяці):

• Побудувати baseline нормальної поведінки для привілейованих акаунтів
• Впровадити моніторинг lateral movement (логи WMI, RDP, SMB)
• Провести перший tabletop exercise або purple team сесію

Стратегічні:

• Впровадити UEBA або EDR з поведінковим аналізом
• Розробити playbooks для типових сценаріїв атак
• Регулярно вимірювати і публічно звітувати по MTTD/MTTR

Висновок

Питання вже давно не “чи буде атака”, а “як швидко ми її побачимо”.

Класичний периметровий захист розрахований на загрози, що приходять ззовні з гучним сигналом. Сучасні атаки виглядають як тихий гість, якого ніхто не запрошував — але який вже відкрив холодильник і переписав замки.

Захист, який не вимірює час — не знає, чи він працює.