Threat hunting

Threat hunting или TH проактивный поиск следов взлома или функционирования вредоносных программ, которые не обнаружены стандартными средствами защиты. Сегодня мы поговорим о том, как устроен этот процесс, какие инструменты можно использовать для поиска угроз, о чем помнить при формировании и проверке гипотез.

Что такое threat hunting и зачем он нужен

В процессе threat hunting аналитик не ждет, пока сработают сенсоры систем защиты, а целенаправленно ищет следы компрометации. Для этого он вырабатывает и проверяет предположения, как злоумышленники могли проникнуть в сеть. Такие проверки должны быть последовательными и регулярными.

Правильное внедрение процесса должно учитывать принципы:

• Необходимо предполагать, что система уже взломана. Главня цель найти следы проникновения.
• Для поиска нужна гипотеза о том, как именно система была скомпрометирована.
• Поиск должен осуществляться итеративно, то есть после проверки очередной гипотезы, аналитик выдвигает новую и продолжает поиск.

Зачастую традиционные средства автоматизированной защиты пропускают сложные целевые атаки. Причина в том, что такие атаки часто распределены во времени, поэтому средства безопасности не могут провести корреляцию двух фаз атаки. При этом злоумышленники тщательно продумывают векторы проникновения и разрабатывают сценарии действий в инфраструктуре. Это позволяет им не совершить демаскирующих действий и выдавать свою активность за легитимную. Злоумышленники постоянно совершенствуют свои знания, покупают или разрабатывают новый инструментарий.

Особенно актуальны вопросы выявления целевых атак для организаций, которые были ранее взломаны. Согласно отчету FireEye M-Trends, 64% ранее скомпрометированных организаций вновь подверглись атаке. Получается, что больше половины взломанных компаний все еще находятся в зоне риска. Значит, нужно применять меры для раннего выявления фактов компрометации этого можно добиться с помощью TH.

Threat hunting помогает ИБ-специалистам сократить время на обнаружение взлома, а также актуализировать знания о защищаемой инфраструктуре. Также TH полезен при использовании threat intelligence (TI) особенно когда при выдвижении гипотезы используются TI-индикаторы.

Как формировать гипотезы для проверки

Поскольку при проведении TH априори предполагается, что злоумышленник уже проник в инфраструктуру, первое, что нужно сделать, локализовать место поиска следов взлома. Определить его можно, выдвинув гипотезу о том, как произошло проникновение и какое подтверждение этому можно найти в инфраструктуре. Сформулировав гипотезу, аналитик проверяет истинность своего предположения. Если гипотеза не подтвердилась, эксперт переходит к разработке и проверке новой. Если в результате проверки гипотезы найдены следы взлома или установлено наличие ВПО, то начинается расследование.



Рисунок 2. Схема проведения threat hunting

Идея гипотезы может родиться из личного опыта аналитика, однако существуют и другие источники для ее построения, например:

• Индикаторы threat intelligence (TI-индикаторы). Простейшая гипотеза, имеющая структуру: злоумышленник использует новую модификацию утилиты X, которая имеет MD5-хеш Y.
• Техники, тактики и процедуры атакующих (TTPs). Информацию про TTPs современных киберпреступников можно найти в базе MITRE ATT&CK. Пример гипотезы: злоумышленник взломал пользовательскую рабочую станцию и методом перебора пытается подобрать пароль от привилегированной учетной записи.
• Аналитика автоматизированных средств обработки данных об инфраструктуре. Их данные помогут выявить аномалии. Например, с помощью систем asset management можно заметить появление нового узла в сети без ведома администраторов. Резкое увеличение объема трафика на сетевом узле тоже может стать поводом для более детального изучения этого узла.
• Информация, обнаруженная в ходе проверки предыдущих гипотез.

Инструменты threat hunting

После формулирования гипотезы необходимо определить источники данных, которые могут содержать информацию для ее проверки. Часто такие источники содержат слишком много данных, среди которых нужно найти релевантные. Таким образом, процесс TH сводится к исследованию, фильтрации и анализу огромного количества данных о происходящем в инфраструктуре. Рассмотрим, в каких источниках можно найти информацию для проверки гипотезы поиска:



Рисунок 3. Классификация источников информации для проведения TH

Наибольшее количество релевантной информации содержится в логах и сетевом трафике. Анализировать информацию из них помогают продукты классов SIEM (security information and event management) и NTA (network traffic analysis). Внешние источники (например, TI-фиды) тоже нужно включать в процесс анализа.

Как это работает на практике

Главная цель проведения TH обнаружить взлом, который не был выявлен автоматизированными средствами защиты.

Для примера рассмотрим проверки двух гипотез. На практике покажем, как системы анализа трафика и анализа логов дополняют друг друга в процессе проверки гипотезы.

Гипотеза 1: злоумышленник проник в сеть через рабочую станцию и пытается получить контроль над другими узлами в сети, для продвижения использует исполнение команд через технологию WMI.

Нарушители получили учетные данные привилегированного пользователя. После этого они пытаются получить контроль над другими узлами в сети с целью попасть на хост с ценными данными. Один из методов запуска программ на удаленной системе использование технологии Windows Management Instrumentation (WMI). Она отвечает за централизованное управление и слежение за работой различных частей компьютерной инфраструктуры. Однако создатели предусмотрели возможность применения такого подхода к компонентам и ресурсам не только отдельно взятого хоста, но и удаленного компьютера. Для этого была реализована передача команд и ответов через протокол DCERPC.

Поэтому для проверки гипотезы нужно исследовать DCERPC-запросы. Покажем, как это можно сделать при помощи анализа трафика и SIEM-системы. На рис. 4 представлены все отфильтрованные сетевые взаимодействия по протоколу DCERPC. Для примера мы выбрали промежуток времени с 06:58 до 12:58.



Рисунок 4. Отфильтрованные DCERPC-сессии

На рис. 4 мы видим два дашборда. Слева перечислены узлы, которые выступали инициаторами DCERPC-соединений. Справа перечислены узлы, с которыми соединялись клиенты. Из рисунка видно, что все клиенты в сети обращаются только к контроллеру домена. Это легитимная активность, поскольку хосты, объединенные в домен Active Directory, обращаются по протоколу DCERPC к контроллеру домена для синхронизации. Она считалась бы подозрительной в случае такой коммуникации между пользовательскими хостами.

Поскольку ничего подозрительного за выбранный промежуток времени не выявлено, двигаясь по временной шкале, выбираем следующие 4 часа. Теперь это интервал с 12:59 по 16:46. В нем мы заметили странное изменение списка хостов назначения (см. рис. 5).



Рисунок 5. После изменения временного интервала, в списке серверов появились два новых узла

В списке хостов назначения два новых узла. Рассмотрим тот, который без DNS-имени (10.125.4.16).



Рисунок 6. Уточнение фильтра, чтобы узнать, кто подключался к 10.125.4.16

Как видно из рис. 6, к нему обращается контроллер домена 10.125.2.36 (см. рис. 4), а значит, такое взаимодействие легитимно.

Далее нужно проанализировать, кто соединялся со вторым новым узлом, на рис. 5 это win-admin-01.ptlab.ru (10.125.3.10). Из названия узла следует, что это компьютер администратора. После уточнения фильтра, остаются только два узла источника сессий.



Рисунок 7. Уточнение фильтра, чтобы узнать, кто подключался к win-admin-01

Аналогично предыдущему случаю одним из инициаторов выступил контроллер домена. Подобные сессии не вызывают подозрений, поскольку это обычное явление в среде Active Directory. Однако второй узел (w-user-01.ptlab.ru), судя по названию, пользовательский компьютер такие подключения являются аномалиями. Если с данным фильтром перейти на вкладку Сессии, то можно скачать трафик и посмотреть подробности в Wireshark.



Рисунок 8. Скачивание релевантных сессий

В трафике можно увидеть обращение к интерфейсу IWbemServices, что свидетельствует об использовании WMI-подключения.



Рисунок 9. Обращение к интерфейсу IWbemServices (Wireshark)

Причем передаваемые вызовы зашифрованы, поэтому конкретные команды неизвестны.



Рисунок 10. Трафик DCERPC зашифрован, поэтому не видно передаваемой команды (Wireshark)

Чтобы окончательно подтвердить гипотезу о том, что такое взаимодействие нелегитимно, необходимо проверить хостовые логи. Можно зайти на хост и посмотреть системные логи локально, но удобнее использовать SIEM-систему.

В интерфейсе SIEM мы ввели в фильтр условие, которое оставило только логи целевого узла в момент установления DCERPC-подключения, и увидели такую картину:



Рисунок 11. Системные логи win-admin-01 в момент установления DCERPC-соединения

В логах мы увидели точное совпадение со временем начала первой сессии (см. рис. 9), инициатор подключения хост w-user-01. Дальнейший анализ логов показывает, что подключились под учетной записью PTLAB\Admin и запустили команду (см. рис. 12) создания пользователя john с паролем password!!!: net user john password!!! /add.



Рисунок 12. Выполненная команда во время соединения

Мы выяснили, что с узла 10.125.3.10 некто по WMI от имени учетной записи PTLAB\Admin добавил нового пользователя на хост win-admin-01.ptlab.ru. При проведении реального TH на следующем шаге нужно выяснить, не является ли это административной активностью. Для этого нужно обратиться к владельцу аккаунта PTLAB\Admin и узнать, осуществлял ли он описанные действия. Поскольку рассматриваемый пример синтетический, будем считать, что данная активность нелегитимная. Также при проведении реального TН в случае выявления факта неправомерного использования учетной записи нужно создать инцидент и проводить детальное расследование.

Гипотеза 2: злоумышленник проник в сеть и находится на стадии эксфильтрации данных, для вывода данных использует туннелирование трафика.

Туннелирование трафика организация канала таким образом, чтобы пакеты одного сетевого протокола (возможно, в измененном виде) передавались внутри полей другого сетевого протокола. Стандартный пример туннелирования построение шифрованных каналов, например SSH. Шифрованные каналы обеспечивают конфиденциальность передаваемой информации и распространены в современных корпоративных сетях. Однако существуют экзотические варианты, например ICMP- или DNS-туннели. Такие туннели используются злоумышленниками, чтобы замаскировать свою активность под легитимную.

Начнем с поиска наиболее распространенного способа туннелирования трафика через протокол SSH. Для этого отфильтруем все сессии по протоколу SSH:



Рисунок 13. Поиск в трафике DNS-сессий

На рисунке видно, что SSH-трафика в инфраструктуре нет, поэтому нужно выбрать следующий протокол, который мог бы применяться для туннелирования. Поскольку в корпоративных сетях всегда разрешен DNS-трафик, то далее рассмотрим именно его.

Если отфильтровать трафик по DNS, то можно увидеть, что у одного из узлов аномально большое количество DNS-запросов.



Рисунок 14. Виджет со статистикой сессий DNS-клиентов

Отфильтровав сессии по источнику запросов, мы узнали, куда отправляется такое аномальное количество трафика и как оно распределяется между узлами назначения. На рис. 15 видно, что часть трафика уходит на контроллер домена, который выступает в роли локального DNS-сервера. Однако немалая доля запросов уходит на неизвестный хост. В корпоративной сети, построенной на Active Directory, пользовательские компьютеры для разрешения DNS-имен не должны обращаться к внешнему DNS-серверу в обход корпоративного. При обнаружении такой активности нужно выяснить, что передают в трафике и куда отправляются все эти запросы.



Рисунок 15. Поиск в трафике SSH-сессий

Если перейти во вкладку Сессии, то можно увидеть, что передается в запросах к подозрительному серверу. Время между запросами достаточно маленькое, а самих сессий много. Такие параметры нехарактерны для легитимного DNS-трафика.



Рисунок 16. Параметры DNS-трафика

Открыв любую карточку сессии, мы видим подробное описание запросов и ответов. Ответы от сервера не содержат ошибок, однако запрашиваемые записи выглядят очень подозрительными, поскольку обычно узлы имеют более короткие и осмысленные DNS-имена.



Рисунок 17. Подозрительный запрос DNS-записи

Анализ трафика показал, что на узле win-admin-01 происходит подозрительная активность по отправке DNS-запросов. Самое время проанализировать логи сетевого узла источника данной активности. Для этого переходим в SIEM.

Нужно найти системные логи win-admin-01 и посмотреть, что происходило в районе 17:06. Видно, что в то же время выполнялся подозрительный PowerShell-скрипт.



Рисунок 18. Исполнение PowerShell в то же время, что и отправка подозрительных запросов

В логах зафиксировано, какой именно скрипт исполнялся.



Рисунок 19. Фиксация в логах имени запущенного скрипта

Название исполненного скрипта admin_script.ps1 намекает на легитимность, но администраторы обычно дают название скриптам по конкретной функции, а тут имя общее. Более того, скрипт находится в папке для временных файлов. Маловероятно, что важный административный скрипт окажется в папке, которую в любой момент могут очистить.

Среди событий обнаружили создание необычного криптографического класса из библиотеки Logos.Utility. Эта библиотека встречается редко и уже не поддерживается разработчиком, поэтому создание ее классов необычно. Попробуем найти проекты, которые ее используют.



Рисунок 20. Создание нестандартного криптографического класса

Если воспользоваться поиском, можно второй же ссылкой найти утилиту, которая организует DNS-туннель и использует данный класс.



Рисунок 21. Поиск информации о скрипте по названию класса

Чтобы окончательно убедиться в том, что это нужная нам утилита, поищем в логах дополнительные признаки. Так обнаружились доказательства. Первое запуск утилиты nslookup с помощью скрипта.



Рисунок 22. Запуск скриптом утилиты nslookup

Утилита nslookup.exr используется во время сетевой диагностики и редко запускается обычными пользователями. В исходных кодах утилиты виден запуск.



Рисунок 23. Код запуска утилиты nslookup (GitHub)

Второе доказательство достаточно уникальная строка генерации случайных значений.



Рисунок 24. Генерация скриптом случайных значений

Если воспользоваться поиском по исходным кодам, можно увидеть именно эту строку.



Рисунок 25. Код генерации случайного значения

Гипотеза о туннеле подтвердилась, однако осталось неясной суть выполняемых действий. В ходе последующего анализа логов мы заметили два запуска процессов.



Рисунок 26. Поиск офисных документов для дальнейшей эксфильтрации

Строки запуска найденных процессов свидетельствуют о поиске документов для скачивания. Таким образом гипотеза полностью подтвердилась, злоумышленники действительно использовали туннелирование трафика для скачивания данных.

Выводы

Как показывают последние аналитические отчеты, среднее время присутствия злоумышленников в инфраструктуре остается длительным. Поэтому не ждите сигналов от средств автоматизированной защиты действуйте проактивно. Изучайте свою инфраструктуру и современные методы атак, а также используйте исследования, которые проводят TI-команды (FireEye, Cisco, PT Expert Security Center).

Я не призываю к отказу от средств автоматизированной защиты. Однако не нужно полагать, что установка и корректная настройка такой системы финальная точка. Это лишь первый необходимый шаг. Далее нужно следить за развитием и функционированием подконтрольного сетевого окружения, держать руку на пульсе.

В этом помогут следующие советы:

1. Изучайте свою инфраструктуру. Выберите для себя удобный подход к управлению сетевыми активами. Нужно в любой момент быть готовым дать ответ на вопрос о том, какую функцию выполняет тот или иной узел и дать по нему информацию.
2. Определите наиболее важные риски и периодически проверяйте гипотезы по ним. Сети бывают разных размеров, для больших и распределенных инфраструктур очень важно выделить критически значимые узлы.
3. Следите за последними трендами в сфере ИБ. В частности, будьте готовы реагировать на свежие уязвимости и новые методы атак. Периодически проверяйте свои средства защиты на возможность отражения новой угрозы. Если угроза не была выявлена, сделайте из данной атаки гипотезу для TH и проверяйте ее, пока автоматизированные средства защиты не начнут ее выявлять.
4. Автоматизируйте рутинные задачи, чтобы осталось больше времени на применение творческого подхода и апробации нестандартных решений.
5. Упрощайте процесс анализа большого объема данных. Для этого полезно использовать инструменты, которые помогают аналитику увидеть происходящее в сети и на сетевых узлах как единую картину. Среди таких инструментов платформа для обмена TI-индикаторами, система анализа трафика и SIEM-система.

Автор: Антон Кутепов, специалист экспертного центра безопасности (PT Expert Security Center) Positive Technologies.

Весь разбор проводился в системе анализа трафика PT Network Attack Discovery и системе управления событиями безопасности MaxPatrol SIEM.

Threat Hunting, он же проактивный поиск угроз, регулярно становится предметом дискуссий ИБ-специалистов. Споры возникают как вокруг того, что именно считать хантингом, так и о том, какие методы и подходы лучше использовать. Под катом мы рассмотрим все эти элементы и поделимся видением Threat Hunting, которое прижилось у нас в Jet CSIRT.

К чему приводит путаница вокруг 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 в нем служит основным источником сбора информации и выдвижения гипотезы. Сам подход состоит из трех процессов: инициализация, хантинг и подведение итогов.

1. Инициализация. На первом этапе аналитик обрабатывает входную информацию для поиска угроз. Триггерами для запуска процесса служит набор действий, которые специалисту необходимо выполнить для работы с инцидентом.
   
   
   Триггеры процесса инициализации
2. Хантинг. На этом этапе специалист уточняет всю необходимую информацию и на основе всех собранных данных выдвигает гипотезу. Она может быть принята, отвергнута или оказаться неубедительной. В последнем случае аналитик может вернуться к предыдущему шагу для уточнения данных или наполнения выдвинутой гипотезы новой информацией. После этого на основе данных и гипотезы проводится расследование. Каждый раз, сталкиваясь с недостатком информации, специалист возвращается к этапу инициализации для сбора дополнительных данных, тем самым делая процесс хантинга итеративным.
3. Подведение итогов. Завершив все операции, аналитик создает отчет с перечнем выполненных действий. В нем также могут быть описаны рекомендации по улучшению блокирующих мер (от простых изменений конфигурации до изменений архитектуры), ведению журнала, сценариям использования мониторинга безопасности и процессам (улучшения в управлении уязвимостями или конфигурацией). В документе должен обязательно присутствовать раздел пост-инцидентная активность с объяснением того, как охота помогла аналитику стать лучше.

Endgame

Этот подход предполагает выстраивание некоего закономерного процесса, который в последующем можно сделать циклическим для уменьшения времени анализа и выдвижения гипотезы. Он также состоит из нескольких шагов.

1. Для начала необходимо предположить гипотезу. Она должна быть достаточно подробной, чтобы аналитик, проводящий охоту, мог доказать или опровергнуть ее. Источников доказательства выдвинутой гипотезы может быть несколько: имена процессов, пути, хеши, аргументы командной строки. Мы рекомендуем выбрать два-три источника.
2. Второй шаг проведение аналитики по собранным доказательствам. Специалист группирует, обогащает и анализирует данные для проведения хантинга. Результат проделанных операций включает в себя выявление аномальных действий или последовательностей событий, связанных с атаками.
3. Третий шаг является основным элементом в подходе Endgame. Он заключается в автоматизации первых двух шагов. На этом этапе аналитик должен выстроить процесс для сокращения времени хантинга и задокументировать все его составляющие.
4. Далее остается подвести результаты хантинга. По методу Endgame, одним из показателей эффективности охоты является количество и серьезность выявленных инцидентов и проблем.

Два вида хантинга: структурированный vs. неструктурированный

Согласно подходу TaHiTi, можно выделить два вида Threat Hunting: неструктурированный и структурированный. Разберемся в особенностях каждого из них.

Неструктурированный хантинг

Неструктурированный хантинг это поиск угроз на основе данных. Потенциально вредоносная активность может быть обнаружена аналитиком, который просто изучает доступные данные в поисках аномалий. Считается, что у этого вида нет четко выстроенного пути хантинга, и он не требует построения гипотез. Однако многие уверены, что поиск аномалий в данных уже гипотеза. Например, такая: Мы полагаем, что события прокси-сервера могут содержать следы компрометации.

Представьте, что вам нужно ее доказать. Для этого вам понадобится источник для поиска, т. е. события с прокси-сервера, и ответы на три вопроса.

1. Какие поля, вероятнее всего, будут содержать свидетельства компрометации?
   Речь идет о полях и атрибутах выбранного источника данных, которые могут содержать доказательства атаки. В событиях прокси-сервера это, вероятнее всего, User-Agentы, URLы, IP-адреса и FQDN.
2. Что будет являться аномалией?
   Тут нужно определить критерии аномальности выбранных атрибутов и полей. В нашем случае это могут быть названия атрибутов, имитирующие легитимные или не часто встречающиеся сущности и т. д.
3. Как можно найти доказательства в данных?
   Чтобы найти доказательства для подтверждения гипотезы, могут понадобиться различные манипуляции с данными. Возможно, найти аномалии удастся с помощью простого поиска, или же для этого придется сделать статистический анализ данных, проанализировать частоту появления интересующих событий, применить методы визуализации для обнаружения подозрительных сущностей.

Структурированный хантинг

Структурированный хантинг это поиск угроз на основе гипотез об атаках, которые могли произойти в инфраструктуре. Этот вид имеет четко выстроенную структуру поиска и опирается на данные и знания об атаках, которые совершают злоумышленники. Для проведения такого типа проактивного поиска аналитику нужно откуда-то черпать знания о реальных атаках, нужен некий фреймворк, который поможет ему понять, как действуют злоумышленники. На сегодняшний день наиболее популярным фреймворком для проактивного поиска угроз является MITRE ATT&CK.

Для примера возьмем гипотезу о том, что злоумышленники могли использовать механизм BITS (MITRE ID: T1197) для скачивания вредоносных нагрузок, постоянного исполнения вредоносного кода или же уничтожения следов после его исполнения. Механизм BITS обычно применяется приложениями и сервисами, которые работают в фоновом режиме и используют свободную полосу пропускания. Задачи BITS содержатся во внутренней базе, никак не модифицируют реестр и не зависят от перезагрузок системы. Управление такими задачами может осуществляться через Powershell или специальный инструмент BITSadmin.


Фрагмент статьи на сайте MITRE

По аналогии с предыдущим примером попробуем ответить на три вопроса для проверки этой гипотезы.

1. Какие данные нужны для проверки гипотезы?
   Для ответа на этот вопрос нужно понять, какие требуются события и из какого источника. В нашем примере, вероятно, мы сможем найти интересующую информацию в журнале аудита Windows Security в событиях EventID:4688 (A new process has been created) или Sysmon EventID:1.
2. Какие следы атаки можно найти?
   Для этого можно обратиться к той же статье на MITRE. В разделе Detection написано, в каком направлении следует двигаться для того, чтобы найти подозрительную активность:
3. Каким образом можно обнаружить эти следы?
   Ответ на этот вопрос будет таким же, как и в предыдущем примере.

Таким образом, псевдокод нашего хантинга может выглядеть вот так:

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*

Так шансов получается больше, и такой поиск может вернуть сотни тысяч совпадений. Здесь как раз и понадобится глаз опытного хантера.

Где искать источники для гипотез

1. MITRE ATT&CK Matrix. Уже упомянутая база знаний о применяемых техниках, тактиках и процедурах (TTP), которые злоумышленники применяют в реальных атаках. Помимо рекомендаций по обнаружению, MITRE также содержит ссылки на отчеты, где та или иная TTP была замечена in-the-wild:
   
   
   Там же можно найти референсы, которые помогут понять, как работает механизм, применяющийся в атаке, что нужно сделать, чтобы включить аудит его событий, и прочее.
   
   
2. 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
3. Знание о данных. Информация о типах и источниках данных в инфраструктуре, а также об аномалиях, которые можно найти в этих данных.
4. Знание инфраструктуры. Информация о слабых местах или уязвимых активах защищаемой инфраструктуры и понимание того, как злоумышленник может их проэксплуатировать. Например, зная, что в тестовом контуре имеются непропатченные активы и это может стать лазейкой для хакеров, можно построить гипотезу о том, как злоумышленник может использовать их расположение для проведения атаки.
5. Результаты пентестов. Результаты практического анализа защищенности инфраструктуры, исследований векторов проникновения в сеть. По сути, тот же самый репозиторий аналитики, который содержит информацию об атаках именно на вашу инфраструктуру. Лучшего источника для проверки гипотез и придумать сложно.
6. Threat Intelligence. Аналитические отчеты о новых угрозах и видах атак, сведения, полученные от ИБ-организаций, производителей ИБ-решений, из киберкриминалистических расследований.
7. ИБ-осведомленность. Оценка актуальных угроз в сфере ИБ, геополитической ситуации, угроз ИБ для сферы деятельности защищаемой инфраструктуры.
8. Гипотеза также может быть сформирована на основе подозрений коллег, руководства или заказчика, на основе методов OSINT (информация, полученная из групп, форумов, теневых площадок), наблюдений, собственной интуиции и предположений.

Кейс: гипотеза об эксплуатации уязвимости SIGRed

Особое внимание в качестве источника идей для хантинга привлекает Threat Intelligence. Чтобы продемонстрировать, как TI может служить основой для гипотез при проактивном поиске угроз, давайте рассмотрим недавно обнаруженную уязвимость SIGRed. В своем отчете специалисты Check Point Software Technologies подробно разобрали ее суть.

Исходя из отчета, можно прийти к выводу, что уязвимость детектируется по подозрительным дочерним процессам службы DNS Windows и нетипичным DNS-ответам (>6k бит), указывающим на попытки переполнения буфера. Такое заключение будет служить основой для гипотезы.

Вот как может выглядеть гипотеза: Злоумышленники могли проэксплуатировать уязвимость SIGRed (CVE-2020-1350) и получить права администратора домена защищаемой инфраструктуры.

Руководствуясь подходом структурированного Threat Hunting (Attack Based), ответим на вопросы для проведения поиска.

1. Какие данные нужны, чтобы найти следы компрометации?
   Согласно отчёту 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).
2. Какие следы атаки можно обнаружить в данных?
   
   • В первом случае мы можем обнаружить неидентифицированные процессы, порождаемые dns.exe, что может говорить о попытках исполнения RCE в результате эксплуатации уязвимости SIGRed.
   • Во втором мы можем обнаружить большие ответы DNS, что может указывать на попытки переполнения буфера нашего DNS-сервера удаленным злоумышленником.
3. Какие манипуляции с данными необходимо проделать, чтобы выявить следы атаки?
   
   • Мы можем сделать поиск всех процессов, порождаемых dns.exe, и вывести их командлайны. Выполнить визуальный осмотр, при необходимости сделать группировку по наиболее частым и отфильтровать легитимную активность.
   • В случае с сетевым трафиком достаточно выполнить поиск. Обнаружение ответов DNS более 60000 байт будет требовать дальнейшего разбирательства.

Этот пример проактивного поиска следов SIGRed всё же достаточно просто автоматизировать для выявления в будущем, поскольку он сконцентрирован на частном случае конкретной уязвимости. Многие компании, адаптировавшие Threat Hunting, даже следуют золотому принципу hunt once detect forever, однако он далеко не всегда применим.

Существуют техники, которые при переводе на автоматический детект будут генерировать огромное число ложноположительных срабатываний. Например, сегодня существует 62 известных способа обхода UAC, основанных на уязвимостях в перечне исполняемых файлов Windows. Настроить правило, которое будет без ошибок обнаруживать каждое, невозможно.

***

Существует множество подходов к проактивному поиску угроз, в статье мы поделились видением хантинга нашей команды. По нашему опыту применение правильных подходов при адаптации новых практик защиты способствует усилению безопасности организации, и Threat Hunting это очередной раз доказывает.

Авторы: Никита Комаров и Александр Ахремчик, Центр мониторинга и реагирования на инциденты ИБ Jet CSIRT компании Инфосистемы Джет

Инциденты с SLA-таймингами должны детектироваться с минимальным числом False Positive, а также иметь четкий workflow обработки. При таком устройстве SOC гарантирует, что инцидент будет обработан за определённое время для дальнейшего своевременного реагирования Такой подход многие годы был справедлив для любого SOC (и нашего в том числе). Но в какой-то момент пришло осознание, что мы частично теряем полноту картины происходящего. Причина в тех самых объективных ограничениях, накладываемых на сценарии. Ведь во множестве малорелевантных сработок (которые не могут быть обработаны на линиях мониторинга разумными ресурсами и в рамках SLA) порой таится самая соль происходящего инцидента.



Погоня за исключением False Positive приводит к периодическому False Negative, который, как известно, случается в самый неподходящий момент. С осознанием этого факта в мир SOC пришло такое явление, как Threat Hunting, призванное усилить классический процесс по мониторингу и закрыть указанные выше недостатки.

Само понятие Threat Hunting сейчас мелькает на всех коммерческих буклетах, но вопросов и споров о том, что это и как организовать процесс проактивного поиска угроз при работе SOC, достаточно много. Даже в своей команде мы периодически любим поспорить на эту тему, и наш лагерь JSOC в этом вопросе делится на две группы:

1. Одни верят, что процесс Threat Hunting основывается на гипотезах, которые уже были выдвинуты различными исследователями или были сформированы в результате анализа работы вредоносного файла или деятельности какой-либо хакерской группировки.

2. Другие верят, что процесс Threat Hunting основывается на гипотезах, которые специалист формирует и проверяет сам в нужный момент времени.

Так как определиться мы не смогли, стали использовать оба подхода к слову, оба они имеют достоинства и недостатки. Давайте чуть ближе посмотрим на то, что же мы делаем вокруг каждого из вариантов.

Вариант 1

Сюда мы относим написанные нами правила корреляции на различные атомарные события, простые детекты, которые могут косвенно свидетельствовать о происходящем инциденте, при этом данные детекты в отрыве от контекста могут быть абсолютно малозначимы, их логически сложно профильтровать на признаки False Positive и однозначно построить вокруг них workflow для инженеров с линии не представляется возможным.

О чем же речь? Приведем примеры двух правил, чтобы понять особенности неправильных инцидентов.

В этой категории у нас есть, например, правило, выявляющее наличие в параметрах запускаемого процесса IP-адреса или FQDN. В действительности данное правило очень сложно пропустить сквозь сито False Positive, но при этом оно достаточно эффективное при обнаружении подозрительной активности.

Или вот, например, правило, детектирующее запуск макроса при открытии Word-документа (отслеживается запись в так называемые Trusted Records Registry Key значения, содержащего последовательность FF FF FF 7F). В большой инфраструктуре такое правило будет срабатывать очень часто, но при современных объёмах фишинга с использованием технологии макросов игнорировать его нельзя.

Понятное дело, что степень фолсовости у этих правил разная. Поэтому для каждого из них мы прописываем (а после запуска у заказчиков динамически изменяем) некий внутренний скоринг, который, используя механизмы ретроспективного анализа, показывает вероятность боевого детекта. Правила с высоким скорингом в том числе попадают в ServiceDesk для подсвечивания активностей по отношению к типовым инцидентам.

Workflow вокруг таких правил выглядит иначе. Сработки попадают не на линию, а к аналитикам, занимающимся проактивным поиском угроз. Они в свою очередь ищут взаимосвязи между сработками данных правил и инцидентами, которые ушли на линию (по ключевым параметрам хост, учетная запись, процесс), параллельно подключая механизм ретроспективного анализа инцидентов, о котором мы рассказывали выше. Стоит отметить, что в этом моменте отсутствует понятие SLA, так эти сработки не подразумевают сразу же возникновения инцидента и необходимости реагирования. При таком подходе мы получаем расширенную картину происходящего и минимизируем вероятность пропуска подозрительной активности.

Вариант 2

В данном варианте работы к аналитику, занимающемуся проактивным поиском угроз, в качестве входных данных поступают не сработки каких-либо детектирующих правил, а так называемые raw events, вокруг которых можно строить гипотезы. И уже результатом этой активности становятся задачи по разработке правил, если удалось найти действительно что-то интересное, не покрытое текущими детектами. И снова приведем два примера.

Событие создания процесса Event id 4688 (Sysmon id 1)

Обрабатывая и анализируя данные по всем запущенным в инфраструктуре процессам, аналитик угроз ищет подозрительные события, анализируя различную информацию. Например:

параметры запускаемых процессов: собрать статистику, обратить внимание на самые редкие командлайны, поискать в них ключевой набор слов/фраз, поискать наличие кодировки base64;

путь до исполняемого файла: обратить внимание на запуск из особых директорий
(например, С:\User\Public, C:\Windows\Temp, C:\Windows\Debug\wia, C:\Windows\Tracing\ в указанные директории возможно писать и запускать исполняемые файлы, не имея прав локального администратора);

поискать интересные взаимосвязи Parent -> Process, которые не покрыты текущими правилами детекта.

Событие создания именного канала Pipe (Sysmon id 17)

Как известно, вредоносное программное обеспечение очень часто создает именованный канал для собственного межпроцессорного взаимодействия. И зачастую именованный канал имеет определенную маску в имени и какой-то генерируемый параметр, например, Evil_090920 (Evil маска, 090920 генерируемый параметр). Если имя именованного канала не находится в индикаторах компрометации, то само создание данного pipe не вызовет подозрения, тем не менее аналитик может обратить внимание на то, что в определенный момент времени (или через любой интервал времени) подобные неизвестные именованные каналы создавались на нескольких системах, что может косвенно свидетельствовать о распространении вредоносного кода.

_________
В данном посте, рассказывая о том, как мы строим процесс Threat Hunting, мы опирались на события ОС Windows и Sysmon, выступающие в качестве источника для SIEM-системы. В действительности же источник событий и конечная система (лишь бы она это позволяла) для работы по проактивному поиску угроз для аналитика значения не имеет ровно такую же философию можно применить, например, к EDR или NTA.

Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети