Пріоритетні Кореляційні Правила
Вступ
- А чи детектите ви Golden Ticket та DCSync?
- А скільки у вас правил на Data Exfiltration?
- А у вас є алерти на всі види UEFI буткітів?
Питання вище можна часто почути працюючи в SOC команді чи MSSP. Хоча ці питання повністю мають сенс, вони часто ставляться без розуміння реальних ризиків та стану моніторингу. У цьому пості я поділюсь думками щодо того, на які правила варто фокусувати увагу в першу чергу, а на які в останню.
Golden Ticket та DCSync
Обидві атаки вимагають права доменного адміністратора та зазвичай виконуються у самому кінці атаки, коли зловмисники вже вкрали всю цінну інформацію та готові запускати рансомварь. Відповідно, отримати алерт на щось типу Golden Ticket рівноцінне твердженню “Ми пропустили всю атаку, хакер глибоко в мережі, наші дані, ймовірно, злиті, і з дня на день нас пошифрують”.
Рекомендації
Звісно, краще мати кореляційне правило ніж не мати. Проте, враховуючи рівень FP на Golden Ticket та вимоги до моніторингу DCSync, я б ставив впровадження цих правил в останню чергу. Натомість я б рекомендував:
- Пріоритизувати правила на перші стадії атак (Initial Access, Execution, Discovery)
- Придбати окреме рішення, як от MS Defender for Identity, для детекту типових AD атак
Спеціалізовані рішення мають автореспонс (наприклад, на DCSync), усувають потребу навантажувати SIEM сотнями тисяч подій 4769/4662, та дають непоганий захист без необхідності тримати власні правила в актуальному стані.
Правила на Data Exfiltration
Інша популярна тема це виявлення Data Exfiltration по об’єму трафіку (Splunk, Darktrace). Хоча правила звучать добре, малий-середній бізнес навряд чи матиме понад 50 GB конфіденційних даних, цікавих для зловмисників. При швидкості 100 Mbps, 50 GB можна вивантажити за одну годину. Чи встигне SOC зреагувати за одну годину?
| Стадія SIEM алерту | Час виконання стадії |
|---|---|
| Утворення SIEM алерту | 10 хвилин (трешхолд правила спрацює лише коли викачають декілька GB) |
| Обробка алерту SOCом | 20 хвилин (аналіз, перевірки, комунікація з IT - все це займає час) |
| Зупинка ексфільтрації | 10 хвилин (знайти ключі до серверної та вимкнути живлення :)) |
| Разом | 40 хвилин і 67% вже вивантажених даних |
Навіть при оптимістичному сценарії де правило спрацювало, викачували все в один захід, і SOC швидко зреагував - вчасно зупинити ексфільтрацію досить складно. А враховуючи як вміло хакери використовують сервіси типу Mega чи Amazon S3, та як легко загубити загрозу серед корпоративного трафіку (бекапи, телеметрія, ютуб) - для невеликих компаній я б не алертив на великий об’єм трафіку взагалі.
Рекомендації
В першу чергу, я б спробував ускладнити шлях зловмисників до ексфільтрації. Якщо хакери можуть провести повний цикл атаки за 40 хвилин (як от Akira), тоді жодні SIEM правила не допоможуть. Сегментація мережі, політики безпеки AD, добрий EDR - все це дасть SOCу час хоч на якийсь алертинг. Далі, я б рекомендував:
- Детектити інструменти для ексфільтрації, як от rclone, scp, kopia, WinRaR
- Детектити підозрілі RDP логіни - часто викачують через RDP сесію (Приклад)
- Пріоритизувати правила на попередні стадії (Initial Access, Discovery, Collection, etc)
Правила на UEFI Буткіти
Коли говорять про виявлення чогось дуже складного, завжди собі уявляю APT групу яка розкидує зіродеї та буткіти мережою, але не додумується глянути на процеси та побачити активний SIEM агент. Особливо дивує коли на детекті складних технік наполягає компанія з відкритим у світ RDP.
Більшість зламів є наслідком слабких паролів, застарілих систем, та відсутності антивірусу. Щомісяця трапляються новини типу “all 6.5 million of its members had had their data stolen… The hackers managed to gain entry by guessing an employee’s password, after which they encrypted the company’s data and locked its internal systems.”, де все що захищало мільйонну компанію - це пароль “123456”.
Рекомендації
Тому, на мою думку, краще спочатку на 200% переконатись що ваш SOC добре бачить топ 10 MITRE технік та IT розуміє базові правила безпеки, а лише потім приступати до складних кореляційок. Краще зробити одне якісне правило на PowerShell, ніж десять правил на екзотичні UEFI буткіти. Орієнтуючись на Mandiant M-Trends Report, для Windows я б почав з правил на:
- PowerShell: Нетиповий батьківський процес та командлети IEX/IWR (Sigma)
- Discovery: Раптовий спайк команд whoami, ipconfig, systeminfo, nltest, net (Приклад)
- RDP: Брутфорси, логіни ззовні чи в позаробочий час, логіни з нетиповою комбінацією user-source-dest
У Підсумку
Плануйте SIEM правила відштовхуючись від того, що чим швидше ви побачите загрозу, тим менше шкоди вона встигне завдати. Також, якщо ваш внутрішній SOC чи MSSP ще зелений, застосуйте правило Парето - покрийте правилами 20% технік MITRE, які трапляються у 80% атак. Чудові ресурси які можуть допомогти у цьому:
- The DFIR Report: Реальні звіти з реальних інцидентів
- Atomic Red Team: Зручні тести для перевірки правил
- Тренд-репорти Mandiant/CrowdStrike/Unit42 та інших вендорів