От гипотезы к инсайту: как мы проводим threat hunting
Threat hunting (TH) — это проактивный итеративный процесс, при котором специалисты формулируют гипотезы и исследуют данные, чтобы найти в них паттерны активности злоумышленников и выявить новые.
Проактивность TH заключается в поиске событий, на которые не сработали правила корреляции и СЗИ. В результате threat hunting позволяет:
- создавать детектирующий контент,
- обогащать данные threat intelligence (TI),
- автоматизировать проверки гипотез,
- выявлять атаки на раннем этапе.
Итеративный процесс состоит из четырех этапов:
- Создание гипотезы.
- Исследование событий, попадающих под логику гипотезы.
- Выявление новых паттернов, а также тактик, техник и процедур (TTPs) злоумышленников.
- Совершенствование детектирующей логики и обогащение событий.
В качестве отдельного этапа можно выделить анализ автоматизированных хантов. Полезные гипотезы, развившиеся в результате TH, которые нельзя трансформировать в правила корреляции, регулярно просматривают, чтобы найти подозрительную активность.
Общая схема TH
Рассмотрим подробнее каждый этап.
Гипотеза формируется из идеи. Источниками идей могут выступать данные TI, прошлые инциденты, статьи или посты в профильных СМИ и т. п. Отличительной чертой гипотезы является ее верифицируемость, то есть проверяемость. Поэтому, когда гипотеза сформирована, необходимо определить события для ее верификации. Подробнее о том, как это происходит в BI.ZONE TDR, рассмотрим далее в статье. Как только мы поняли, что именно необходимо для проверки гипотезы, можно приступать к следующему этапу.
В TDR мы используем телеметрию BI.ZONE EDR на конечных точках. Решение позволяет гибко настраивать собираемую телеметрию, что ускоряет поиск угроз и делает его эффективнее.
Может случиться, что события, которые были призваны подтвердить гипотезу, на практике оказываются легитимными, случайно попавшими под логику ханта (false positive, FP). В таком случае необходимо скорректировать гипотезу и исключить из рассмотрения FP. Если в результате проверки удается выявить искомые подозрительные действия, можно говорить о подтверждении гипотезы и инициировать расследование найденной активности.
Если найденная активность является вредоносной, необходимо оповестить заинтересованных лиц, например клиентов и внутренний CSIRT, зарегистрировать инцидент и начать реагировать на него. Параллельно с этим нужно собрать максимально полную информацию о случившемся: затронутые хосты и учетные данные, IP‑адреса, доменные имена C2‑серверов атакующих и т. п. В процессе сбора и анализа этой информации нередко обнаруживаются новые паттерны, инструменты и TTPs, использованные при атаке. Такие данные могут помочь как команде TI, так и команде incident response.
На последнем этапе происходит анализ причин, по которым атаку не удалось выявить до threat hunting. В результате появятся предложения по совершенствованию детектирующей логики (новые правила корреляции или автоматизированные ханты), а также будет доработана телеметрия и выявлены новые типы событий, которые необходимо собирать для детектирования схожих атак.
Подробнее о правилах корреляции мы рассказывали в статье о логике обнаружения угроз в SOC. Threat hunting позволяет более гибко подойти к поиску подозрительных действий: гипотеза не всегда дает большой процент true positive. Иными словами, при верификации гипотезы аналитику приходится отфильтровывать множество ложных срабатываний. Для TH такая ситуация является нормальной. Однако в случае с правилами корреляции любое ложное срабатывание приводит к тому, что аналитик L1–L2, анализирующий это срабатывание, тратит время. Таким образом, количество ложных срабатываний напрямую влияет на сервис SOC.
Разберем на примере: атакующие часто используют утилиту rundll32.exe в своих атаках. В качестве правил корреляции, связанных с использованием этой утилиты, можно привести:
- Запуск функции из библиотеки по ординалу (
rundll32.exe evil.dll,#2). - Запуск специфичной функции (
rundll32.exe comsvcs.dll, MiniDump 874 lsass.dmp full). - Запуск нетиповым процессом.
- Запуск без аргументов и т. д.
Можно сформировать гипотезы, которые нельзя реализовать как правила корреляции:
- Запуск библиотеки с нечитаемым (обфусцированным) названиям (
rundll32.exe Hsxjakc3jh7jh.dll). - Запуск непримечательной функции из вредоносной библиотеки (
rundll32.exe file.dll,Start).
Подобные гипотезы можно проанализировать вручную в процессе проактивного поиска угроз. Однако, реализованные в качестве правил корреляции, они приведут к огромному количеству ложных срабатываний, то есть принесут больше вреда, чем пользы.
Выделим два подхода к формированию гипотез:
- Структурированный. Гипотеза формируется на основании данных о действиях атакующих: TTPs, IoA, инструментов и т. п.
- Неструктурированный. Гипотеза основывается на аномалиях в телеметрии: спайков сетевого трафика, аномального количества событий определенного event_type и т. п.
Структурированный подход требует налаженного обмена информацией между командами. Например, распространение данных из TI в SOC и DFIR или из DFIR — в SOC и TI. Гипотезы, сформированные на основе актуальных для организации данных — ландшафта угроз, предыдущих инцидентов — оказываются наиболее полезными.
Неструктурированный подход требует понимания нормальной активности (baseline) в инфраструктуре организации. Если нет возможности понять, какая активность, повторяющаяся в организации каждый день, является нормальной, то найти аномальные действия труднее.
Можно выделить и более детально классифицируемые подходы:
- Intelligence-driven. Подход, основанный на данных threat intelligence о TTPs атакующих.
- Analytics-driven. Подход, основанный на выявлении аномалий в логах, часто использующий машинное обучение для поиска угроз и несвойственных пользователям подозрительных действий.
- Awareness-driven. Подход, основанный на понимании инфраструктуры. Формирование гипотез происходит на основе активов внутри периметра организации.
Подход hypothesis-driven
В BI.ZONE TDR мы используем собственный подход, основанный на тесном взаимодействии команд SOC, TI и EDR. Его можно назвать hypothesis‑driven. Гипотезы формируются на основе актуального для организации ландшафта угроз, который описывает команда TI. Для проверки гипотез используется телеметрия BI.ZONE EDR. Если для верификации гипотезы собираемых данных недостаточно, то команда EDR обогащает телеметрию нужными событиями. Это позволяет не только эффективно верифицировать гипотезы в рамках threat hunting, но и создавать дополнительные правила корреляции, используя добавленные поля и события телеметрии.
Теперь расскажем, как мы работаем с threat hunting.
Threat hunting в BI.ZONE TDR — это циклический процесс, состоящий из нескольких этапов
Формируем гипотезу и составляем хант на основе поставляемых TI релевантных данных об угрозах. Верхнеуровнево гипотеза отвечает на следующие вопросы: что, как и с какими целями атакующий предпринял в инфраструктуре.
checkip[.]dyndns[.]org для определения внешнего IP‑адреса. Запрос должен предоставить все события резолва домена указанного сервиса или сетевые обращения к нему. Найденные события будут проанализированы и проверены на легитимность. Таким образом, гипотеза верифицируемая.
Перед анализом исключаем явно легитимные действия из результатов запроса. Дальше анализ развивается по схеме, приведенной выше. Разберем различные сценарии:
- Ложных срабатываний мало.
Результатом анализа срабатываний становится расследование инцидента и создание нового корреляционного правила, если оно возможно. Если количество ложных срабатываний для написания корреляционного правила все еще велико, то запуск ханта автоматизируется. Результаты запроса просматриваются аналитиками на регулярной основе. - Ложных срабатываний много.
Происходит пересмотр логики ханта или отказ от гипотезы. Последнее предпочтительнее, если хант прошел через несколько итераций пересмотра логики, но так и не принес результатов. В некоторых ситуациях актуальность гипотезы предполагает периодический отсмотр подозрительных срабатываний, даже если ложных очень много. Например, тот или иной вариант добавления файлов в автозапуск. - Недостаточно специфичной телеметрии для верификации гипотезы.
Если нет возможности верифицировать гипотезу на имеющейся телеметрии и нужны специфические события, то к команде EDR формируются требования для доработки телеметрии. После обогащения телеметрии необходимыми полями или типами событий, анализ ханта продолжается.
Результаты анализа событий заносятся в базу знаний. Это позволяет избежать двойной работы и не формировать снова гипотезы, оказавшиеся неэффективными. Также база знаний служит ресурсом для обучения аналитиков.
Таким образом, формирование гипотезы и анализ событий связаны со всеми этапами threat hunting. В зависимости от условий процесс может привести к выявлению атаки, обогащению детектирующей логики, улучшению телеметрии или пополнению базы знаний.
Новые идеи для формирования гипотез можно брать из источников данных о том, чем активно пользуются злоумышленники:
- наших TI-отчетов,
- отчетов о расследовании инцидентов,
- статей и постов на профессиональных ресурсах о произошедших атаках.
Эти данные позволяют «охотиться» за тем, что фактически используют атакующие. Однако подход, при котором мы исследуем то, что уже было, оставляет нас позади злоумышленников. Чтобы это исправить, мы также черпаем идеи для гипотез из собственных исследований, анализа новых инструментов и векторов эксплуатации, а также исследований коллег по кибербезопасности из различных организаций.
Обратимся к матрице MITRE ATT&CK на портале BI.ZONE Threat Intelligence, чтобы понять какие техники атакующие чаще всего используют в атаках на российские организации.
Разберем подтехнику Windows Service техники Create or Modify System Process (T1543.003), которую атакующие используют для закрепления и повышения привилегий в системе.
- Источник: данные о релевантных для региона TTPs злоумышленников.
- Суть атаки: закрепление и повышение привилегий на хосте с помощью создания службы для дальнейшего развития атаки.
- Гипотеза: установка службы с подозрительным исполняемым файлом.
- Первичный запрос:
event_type:"ServiceInstall".
Результат такого запроса содержит больше 4 миллионов событий, что, очевидно, слишком много для анализа. Необходимо доработать гипотезу.
Для этого посмотрим более внимательно на результаты запроса.
Большая часть срабатываний приходится на службы с исполняемым файлом svchost.exe. У нас есть два варианта доработки гипотезы:
- Поиск подозрительных служб, исполняющихся в контексте
svchost.exe. - Поиск служб с подозрительными исполняемыми файлами, отличными от
svchost.exe.
Ради наглядности выберем второй, добавив в запрос соответствующий фильтр:
-(file_path:"c:\\windows\\system32\\svchost.exe" OR -(file_path.keyword://AND cmdline:"C:\\WINDOWS\\system32\\svchost.exe"))
Количество срабатываний сократилось до 522 068, что все еще много. Отфильтруем исполняемые файлы, созданные в системе более часа назад:
file_age:<3600
Количество срабатываний — 168 777. Исключим исполняемые файлы с валидной подписью и отфильтруем известные легитимные службы:
-file_sig_result:true
-service_display_name:("Kaspersky Lab" OR "BI.ZONE Sensors SP Driver" OR klids.KES-* OR "VeeamVssSupport" OR "KL Service") AND -(cmdline:"C:\\Program Files (x86)\\Google\\GoogleUpdater\\" AND service_name:googleupdaterinternalservice*) AND etc ...
Количество срабатываний сократилось до 375, что поддается ручному осмотру и анализу. Подозрительная активность, выявленная в результате проработки гипотезы, в результате оказалась легитимной службой.
Итоги итерации:
- Не всегда удается обнаружить артефакты вредоносной активности.
- Гипотеза была скорректирована для поиска нетипичных сервисов.
- Были отмечены для исследования другие векторы развития гипотезы.
Рассмотрим еще одну гипотезу:
- Источник: данные о релевантных для региона TTPs злоумышленников.
- Суть атаки: для получения первичного доступа злоумышленники используют файлы с расширением .com вместо .exe во время вредоносных рассылок для обхода механизмов защиты.
- Гипотеза: запуск процесса с исполняемым файлом с расширением .com.
- Первичный запрос:
dev_os_type:windows AND event_type:(ProcessCreate OR ProcessInfo) AND proc_file_path.keyword:/.*\.com/.
Результат запроса включает более двух миллионов событий.
Добавим фильтр, исключающий легитимные файлы, в запрос:
AND -(proc_file_sig:"microsoft windows" AND proc_file_sig_result:true) AND -(proc_file_path:("\\kaspersky lab\\" AND "avp.com") AND proc_file_sig:("ao kaspersky lab" OR "kaspersky lab jsc")) AND -(proc_file_path:"winscp.com" AND proc_file_sig:"martin prikryl" AND proc_file_sig_result:true)
В полученном результате сразу заметно единичное срабатывание запуска исполняемого файла с расширением .com из AppData\Local\temp. Рассмотрим его подробнее.
Посмотрим на командные строки родительского процесса и его родительского процесса (процесса‑прародителя) в полях proc_p_cmdline и proc_pp_cmdline соответственно:
По ним можно сделать вывод, что исполняемый файл был запущен из почтового клиента Outlook, что соответствует описанию действий атакующего, за которыми мы «охотились». Сопоставление данных с TI показало, что это активность группировки Fluffy Wolf.
Итоги итерации:
- Взаимодействовали с клиентом для расследования инцидента.
- Превратили гипотезы в правило корреляции после дополнительных доработок.
В качестве последнего примера рассмотрим следующую гипотезу:
- Источник: проверенная ранее гипотеза, получившая хант.
- Суть атаки: для различного ВПО характерно скачивание дополнительных нагрузок в директорию Temp, поскольку у всех пользователей есть возможность записи в нее.
- Гипотеза: использование curl для скачивания файла во временную директорию.
- Первичный запрос:
proc_file_path:("curl" OR "curl.exe") AND cmdline:("-o /tmp/" OR "Temp").
Количество событий в результате выполнения первичного запроса — более девяти миллионов. Посмотрим на родительские процессы curl и доработаем гипотезу.
Поищем все уникальные родительские процессы:
При дальнейшем исследовании все файлы оказались легитимными. Однако было обнаружено два скрипта. Первый использовал токен в открытом виде для сбора информации с сайта. Второй — учетные данные пользователя в открытом виде для доступа к веб‑серверу с чувствительными данными.
Итоги итерации:
- В рамках поиска угроз можно находить не только угрозы, но и мисконфигурации.
- Первоначальная гипотеза иногда приводит к совершенно другим результатам. В нашем примере удалось найти мисконфигурацию, хотя сама гипотеза не подтвердилась.
- Необходимо уметь адаптироваться к результатам гипотезы для генерации новых правил и векторов развития гипотез.
Threat hunting помогает выйти за рамки стандартных инструментов безопасности: это способ выявить угрозы, которые сложно обнаружить автоматизированными средствами. За счет постоянных итераций, проверки гипотез и обогащения TI, хантинг усиливает защиту и позволяет обнаружить атаки до того, как они нанесут ощутимый ущерб. Threat hunting важен для зрелых команд, поскольку позволяет сократить время обнаружения атакующих.
Итерации процесса не всегда приводят к выявлению атак, расследованию инцидентов или созданию корреляционного правила: иногда результатом служат найденные мисконфигурации. Threat hunting в BI.ZONE TDR позволяет значительно расширить скоуп просматриваемых событий и повышает шансы обнаружить злоумышленника на ранних стадиях атаки.
Важно отметить, что для эффективной защиты и процесса threat hunting необходима качественная телеметрия с конечных точек, из которой можно извлечь необходимые для анализа данные. Телеметрия генерируется с помощью сенсора EDR, установленного на конечной точке. В статье мы описали случай, когда вредоносная активность была найдена благодаря данным в поле командной строки процесса‑прародителя, которую предоставляет сенсор BI.ZONE EDR. Помимо этого конкретного поля, отсутствующего в стандартной телеметрии Windows, BI.ZONE EDR предоставляет большие возможности по расширению телеметрии.
