02.10.2020 14:18:50 |
Автор: 
К чему приводит путаница вокруг Threat Hunting
В 2019 г. аналитики Authentic8 провели большой опрос ИБ-специалистов, которые занимаются проактивным поиском угроз в средних и крупных организациях, чтобы выяснить, как этот процесс выстроен в их компаниях. Об успешном опыте заявили далеко не все респонденты: почти 11% опрошенных отметили, что с введением Threat Hunting не заметили улучшений с точки зрения информационной безопасности. В то же время опрос показал довольно опасные тенденции. Например, среди самых популярных методов проактивного поиска угроз были названы использование индикаторов компрометации (Indicator of Compromise, IoC) и применение алертов от систем безопасности, что напрямую противоречит всем best practices от ведущих специалистов и организаций.
Результаты опросов по методам проактивного поиска угроз
Исходя из результатов опроса, можно сделать вывод, что до сих пор не все специалисты правильно понимают, что такое Threat Hunting. Об этом говорит и малочисленное использование гипотез при проведении хантинга. Так, лишь 35% опрошенных опираются на hypothesis-driven хантинг, и за последние три года этот показатель значительно снизился. Применяя неправильные подходы, компании испытывают разочарование в Threat Hunting и лишаются возможности усилить безопасность защищаемой инфраструктуры.
При охоте, основанной на гипотезах, специалисты проводят анализ угроз. Это помогает понять, как злоумышленник может атаковать организацию. Допуская, что атака уже произошла, аналитики делают предположение о том, какие действия были предприняты злоумышленником и какое ПО использовалось для компрометации инфраструктуры, после чего ищут доказательства за и против своей гипотезы. Это позволяет им понять тактику атакующего, алгоритм атаки и внутреннюю структуру организации. Кроме того, охота, основанная на гипотезах, выявляет слепые зоны в безопасности компаний в процессе расследования инцидентов. Принятие или отклонение гипотезы вместо использования только доступных данных дает возможность дополнительно обнаружить пробелы в подходах к хантингу.
Алгоритм проведения охоты, основанной на гипотезах
Четыре ответа на вопрос Зачем охотиться?
Целей, которые ставят перед собой специалисты по Threat Hunting, насчитывается достаточно много. Вот какие мы в Jet CSIRT выделяем для себя:
- обнаружение слепых зон мониторинга из-за недостатков корреляционной логики;
- обнаружение слепых зон мониторинга из-за недостаточного количества охваченных источников;
- обнаружение атак с техниками, эксплуатирующими уязвимости zero-day, которые априори не всегда возможно учесть;
- реализация мониторинга в тех областях, где автоматический детект вызовет слишком большое количество ложноположительных срабатываний.
С чего начинается охота на угрозы?
В отличие от процесса реагирования, который детально описан в NIST 800-61, у Threat Hunting нет четкой стандартизации. Поэтому для проведения проактивного поиска угроз компаниям приходится создавать собственные подходы на основе общедоступных практик построения хантинга.
Определений хантинга достаточно много, мы в команде выделяем для себя следующее:
Threat Hunting это процесс проактивного и итеративного поиска киберугроз, которые не были обнаружены существующими средствами детектирования и мониторинга. В основе Threat Hunting лежит понятие проактивного подхода к инцидентам ИБ, который противопоставляется реактивному подходу.
В чем их отличия? При реактивном подходе аналитик приступает к реагированию на инцидент, получив информацию о нем из средств детектирования или мониторинга (SIEM, IPS/IDS, AV и т. д.) либо из других источников: от сотрудников, подрядчиков, органов надзора. При проактивном подходе аналитик пробует вручную, с помощью доступных инструментов (SIEM, EDR, DLP, анализаторы трафика и т. д.), найти в инфраструктуре следы компрометации, на основании которых можно сформировать или скорректировать правила для автоматического выявления обнаруженных инцидентов. Особенность этого метода заключается в том, что его нельзя полностью автоматизировать.
Важно помнить: сеанс Threat Hunting не всегда приводит к выявлению реальной угрозы. Иногда можно обнаружить неправильно настроенные активы, некорректные действия пользователей, нелогичную работу прикладных систем или вообще ничего всё это является результатом.
Структура Threat Hunting достаточно обширна, в статье мы ограничимся следующей:
Структура Threat Hunting
Выбираем подход к охоте
Выбор подхода наиболее важная часть хантинга. Существует несколько подходов к проведению Threat Hunting, каждый из которых предусматривает свой алгоритм действий и список информации, необходимой для успешной охоты. В качестве примера рассмотрим два похода: TaHiTi и Endgame.
TaHiTi
Этот подход объединил в себе элементы Threat Hunting и Threat Intelligence (TI). TI в нем служит основным источником сбора информации и выдвижения гипотезы. Сам подход состоит из трех процессов: инициализация, хантинг и подведение итогов.
- Инициализация. На первом этапе аналитик обрабатывает
входную информацию для поиска угроз. Триггерами для запуска
процесса служит набор действий, которые специалисту необходимо
выполнить для работы с инцидентом.
Триггеры процесса инициализации - Хантинг. На этом этапе специалист уточняет всю необходимую информацию и на основе всех собранных данных выдвигает гипотезу. Она может быть принята, отвергнута или оказаться неубедительной. В последнем случае аналитик может вернуться к предыдущему шагу для уточнения данных или наполнения выдвинутой гипотезы новой информацией. После этого на основе данных и гипотезы проводится расследование. Каждый раз, сталкиваясь с недостатком информации, специалист возвращается к этапу инициализации для сбора дополнительных данных, тем самым делая процесс хантинга итеративным.
- Подведение итогов. Завершив все операции, аналитик создает отчет с перечнем выполненных действий. В нем также могут быть описаны рекомендации по улучшению блокирующих мер (от простых изменений конфигурации до изменений архитектуры), ведению журнала, сценариям использования мониторинга безопасности и процессам (улучшения в управлении уязвимостями или конфигурацией). В документе должен обязательно присутствовать раздел пост-инцидентная активность с объяснением того, как охота помогла аналитику стать лучше.
Endgame
Этот подход предполагает выстраивание некоего закономерного процесса, который в последующем можно сделать циклическим для уменьшения времени анализа и выдвижения гипотезы. Он также состоит из нескольких шагов.
- Для начала необходимо предположить гипотезу. Она должна быть достаточно подробной, чтобы аналитик, проводящий охоту, мог доказать или опровергнуть ее. Источников доказательства выдвинутой гипотезы может быть несколько: имена процессов, пути, хеши, аргументы командной строки. Мы рекомендуем выбрать два-три источника.
- Второй шаг проведение аналитики по собранным доказательствам. Специалист группирует, обогащает и анализирует данные для проведения хантинга. Результат проделанных операций включает в себя выявление аномальных действий или последовательностей событий, связанных с атаками.
- Третий шаг является основным элементом в подходе Endgame. Он заключается в автоматизации первых двух шагов. На этом этапе аналитик должен выстроить процесс для сокращения времени хантинга и задокументировать все его составляющие.
- Далее остается подвести результаты хантинга. По методу Endgame, одним из показателей эффективности охоты является количество и серьезность выявленных инцидентов и проблем.
Два вида хантинга: структурированный vs. неструктурированный
Согласно подходу TaHiTi, можно выделить два вида Threat Hunting: неструктурированный и структурированный. Разберемся в особенностях каждого из них.
Неструктурированный хантинг
Неструктурированный хантинг это поиск угроз на основе данных. Потенциально вредоносная активность может быть обнаружена аналитиком, который просто изучает доступные данные в поисках аномалий. Считается, что у этого вида нет четко выстроенного пути хантинга, и он не требует построения гипотез. Однако многие уверены, что поиск аномалий в данных уже гипотеза. Например, такая: Мы полагаем, что события прокси-сервера могут содержать следы компрометации.
Представьте, что вам нужно ее доказать. Для этого вам понадобится источник для поиска, т. е. события с прокси-сервера, и ответы на три вопроса.
- Какие поля, вероятнее всего, будут содержать
свидетельства компрометации?
Речь идет о полях и атрибутах выбранного источника данных, которые могут содержать доказательства атаки. В событиях прокси-сервера это, вероятнее всего, User-Agentы, URLы, IP-адреса и FQDN. - Что будет являться аномалией?
Тут нужно определить критерии аномальности выбранных атрибутов и полей. В нашем случае это могут быть названия атрибутов, имитирующие легитимные или не часто встречающиеся сущности и т. д. - Как можно найти доказательства в данных?
Чтобы найти доказательства для подтверждения гипотезы, могут понадобиться различные манипуляции с данными. Возможно, найти аномалии удастся с помощью простого поиска, или же для этого придется сделать статистический анализ данных, проанализировать частоту появления интересующих событий, применить методы визуализации для обнаружения подозрительных сущностей.
Структурированный хантинг
Структурированный хантинг это поиск угроз на основе гипотез об атаках, которые могли произойти в инфраструктуре. Этот вид имеет четко выстроенную структуру поиска и опирается на данные и знания об атаках, которые совершают злоумышленники. Для проведения такого типа проактивного поиска аналитику нужно откуда-то черпать знания о реальных атаках, нужен некий фреймворк, который поможет ему понять, как действуют злоумышленники. На сегодняшний день наиболее популярным фреймворком для проактивного поиска угроз является MITRE ATT&CK.
Для примера возьмем гипотезу о том, что злоумышленники могли использовать механизм BITS (MITRE ID: T1197) для скачивания вредоносных нагрузок, постоянного исполнения вредоносного кода или же уничтожения следов после его исполнения. Механизм BITS обычно применяется приложениями и сервисами, которые работают в фоновом режиме и используют свободную полосу пропускания. Задачи BITS содержатся во внутренней базе, никак не модифицируют реестр и не зависят от перезагрузок системы. Управление такими задачами может осуществляться через Powershell или специальный инструмент BITSadmin.
Фрагмент статьи на сайте MITRE
По аналогии с предыдущим примером попробуем ответить на три вопроса для проверки этой гипотезы.
- Какие данные нужны для проверки гипотезы?
Для ответа на этот вопрос нужно понять, какие требуются события и из какого источника. В нашем примере, вероятно, мы сможем найти интересующую информацию в журнале аудита Windows Security в событиях EventID:4688 (A new process has been created) или Sysmon EventID:1. - Какие следы атаки можно найти?
Для этого можно обратиться к той же статье на MITRE. В разделе Detection написано, в каком направлении следует двигаться для того, чтобы найти подозрительную активность: - Каким образом можно обнаружить эти следы?
Ответ на этот вопрос будет таким же, как и в предыдущем примере.
Таким образом, псевдокод нашего хантинга может выглядеть вот так:
EvenID:4688 AND ProcessName contains BITSAdmin.exe AND
CommandLine in [Transfer, 'Create', 'AddFile', 'SetNotifyFlags',
'SetNotifyCmdLine', 'SetMinRetryDelay', 'SetCustomHeaders',
'Resume']Вы можете сказать, что легче настроить правило на детектирование таких инцидентов и, наверное, будете правы. Однако приведенный псевдокод не гарантирует, что вы найдёте все факты использования механизма BITS.
EvenID:4688 AND ProcessName contains *bits*Так шансов получается больше, и такой поиск может вернуть сотни тысяч совпадений. Здесь как раз и понадобится глаз опытного хантера.
Где искать источники для гипотез
- MITRE ATT&CK Matrix. Уже упомянутая база знаний о
применяемых техниках, тактиках и процедурах (TTP), которые
злоумышленники применяют в реальных атаках. Помимо рекомендаций по
обнаружению, MITRE также содержит ссылки на отчеты, где та или иная
TTP была замечена in-the-wild:
Там же можно найти референсы, которые помогут понять, как работает механизм, применяющийся в атаке, что нужно сделать, чтобы включить аудит его событий, и прочее.
- MITRE
Cyber Analytics Repository. Репозиторий аналитики,
основанный на MITRE ATT&CK, содержащий псевдокод запросов для
поиска определенных TTP, который сразу же можно применять в своей
системе. Вот пример, позволяющий обнаружить удаление теневых копий
Windows:
process-search Process:Create
vssadmin_processes = filter processes where(
command_line = * delete shadows and
image_path = C:\Windows\System32\vssadmin.exe)
output vssadmin_processes - Знание о данных. Информация о типах и источниках данных в инфраструктуре, а также об аномалиях, которые можно найти в этих данных.
- Знание инфраструктуры. Информация о слабых местах или уязвимых активах защищаемой инфраструктуры и понимание того, как злоумышленник может их проэксплуатировать. Например, зная, что в тестовом контуре имеются непропатченные активы и это может стать лазейкой для хакеров, можно построить гипотезу о том, как злоумышленник может использовать их расположение для проведения атаки.
- Результаты пентестов. Результаты практического анализа защищенности инфраструктуры, исследований векторов проникновения в сеть. По сути, тот же самый репозиторий аналитики, который содержит информацию об атаках именно на вашу инфраструктуру. Лучшего источника для проверки гипотез и придумать сложно.
- Threat Intelligence. Аналитические отчеты о новых угрозах и видах атак, сведения, полученные от ИБ-организаций, производителей ИБ-решений, из киберкриминалистических расследований.
- ИБ-осведомленность. Оценка актуальных угроз в сфере ИБ, геополитической ситуации, угроз ИБ для сферы деятельности защищаемой инфраструктуры.
- Гипотеза также может быть сформирована на основе подозрений коллег, руководства или заказчика, на основе методов OSINT (информация, полученная из групп, форумов, теневых площадок), наблюдений, собственной интуиции и предположений.
Кейс: гипотеза об эксплуатации уязвимости SIGRed
Особое внимание в качестве источника идей для хантинга привлекает Threat Intelligence. Чтобы продемонстрировать, как TI может служить основой для гипотез при проактивном поиске угроз, давайте рассмотрим недавно обнаруженную уязвимость SIGRed. В своем отчете специалисты Check Point Software Technologies подробно разобрали ее суть.
Исходя из отчета, можно прийти к выводу, что уязвимость детектируется по подозрительным дочерним процессам службы DNS Windows и нетипичным DNS-ответам (>6k бит), указывающим на попытки переполнения буфера. Такое заключение будет служить основой для гипотезы.
Вот как может выглядеть гипотеза: Злоумышленники могли проэксплуатировать уязвимость SIGRed (CVE-2020-1350) и получить права администратора домена защищаемой инфраструктуры.
Руководствуясь подходом структурированного Threat Hunting (Attack Based), ответим на вопросы для проведения поиска.
- Какие данные нужны, чтобы найти следы
компрометации?
Согласно отчёту Check Point Software Technologies, можно выделить два способа детектирования атаки SIGRed:
- Порождение процессом dns.exe неидентифицированных
подозрительных процессов. В этом случае поиск может выглядеть
примерно так (применимо только для Windows 10):
EvenID:4688 AND ParentProcessName:dns.exe AND process.name != conhost.exe - Выявление слишком тяжелого DNS-ответа, которое свидетельствует
о переполнении буфера. В этом случае поиск может выглядеть примерно
так:
EventType: NetworkTraffic AND DestinationPort:53 AND ReceivedBytes>60000
Соответственно, для проведения поиска нам нужны данные запуска процессов Windows (EID:4688, Sysmon EID:1) и сетевого трафика (например, Zeek, Suricata). - Порождение процессом dns.exe неидентифицированных
подозрительных процессов. В этом случае поиск может выглядеть
примерно так (применимо только для Windows 10):
- Какие следы атаки можно обнаружить в данных?
- В первом случае мы можем обнаружить неидентифицированные процессы, порождаемые dns.exe, что может говорить о попытках исполнения RCE в результате эксплуатации уязвимости SIGRed.
- Во втором мы можем обнаружить большие ответы DNS, что может указывать на попытки переполнения буфера нашего DNS-сервера удаленным злоумышленником.
- Какие манипуляции с данными необходимо проделать, чтобы
выявить следы атаки?
- Мы можем сделать поиск всех процессов, порождаемых dns.exe, и вывести их командлайны. Выполнить визуальный осмотр, при необходимости сделать группировку по наиболее частым и отфильтровать легитимную активность.
- В случае с сетевым трафиком достаточно выполнить поиск. Обнаружение ответов DNS более 60000 байт будет требовать дальнейшего разбирательства.
Этот пример проактивного поиска следов SIGRed всё же достаточно просто автоматизировать для выявления в будущем, поскольку он сконцентрирован на частном случае конкретной уязвимости. Многие компании, адаптировавшие Threat Hunting, даже следуют золотому принципу hunt once detect forever, однако он далеко не всегда применим.
Существуют техники, которые при переводе на автоматический детект будут генерировать огромное число ложноположительных срабатываний. Например, сегодня существует 62 известных способа обхода UAC, основанных на уязвимостях в перечне исполняемых файлов Windows. Настроить правило, которое будет без ошибок обнаруживать каждое, невозможно.
***
Существует множество подходов к проактивному поиску угроз, в статье мы поделились видением хантинга нашей команды. По нашему опыту применение правильных подходов при адаптации новых практик защиты способствует усилению безопасности организации, и Threat Hunting это очередной раз доказывает.
Авторы: Никита Комаров и Александр Ахремчик, Центр мониторинга и реагирования на инциденты ИБ Jet CSIRT компании Инфосистемы Джет
Категории: 
Рыцари справедливости. Кадр из фильма
