Threat hunting: как правильно организовать процесс поиска злоумышленников

Оглавление

Что такое threat hunting.

Зачем проводить threat hunting.

Каким должен быть специалист по TH.

Гипотеза поиска.

Инструменты TH.

Практика.

Гипотеза № 1.

Гипотеза № 2.

Выводы.

Согласно результатам исследования SANS 2019 Threat Hunting Survey, 57% компаний, рапортующих о внедрении у себя процесса threat hunting (TH), просто реагируют на оповещения средств автоматизированной защиты, но по сути это относится к области управления событиями и оповещениями (event and alert management), а не к TH.

В статье речь пойдет о том, что такое TH, как искать и проверять гипотезы и какие преимущества дает внедрение правильных процессов TH. Подробно рассмотрим, какие инструменты помогут в проведении «охоты», а также на практике покажем пользу описанного подхода.

Что такое threat hunting

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

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

• Сотрудник, осуществляющий TH, априори предполагает, что система уже взломана. Его цель — найти следы проникновения.

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

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

Зачем проводить threat hunting

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

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

TH помогает командам ИБ:

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

Каким должен быть специалист по TH

При правильной организации процесса должна быть выделена отдельная структурная единица — отдел threat hunting. Сотрудников отдела будем называть аналитиками или специалистами по TH. Однако в российских компаниях зачастую функции TH-команды выполняет SOC. Согласно SANS, профиль навыков специалиста по TH соответствует диаграмме на рис. 1 (деления указывают уровень навыка, где 0% — абсолютное незнание области, а 100% — высококлассный эксперт в области).

Рисунок 1. Диаграмма профиля наиболее ценных навыков специалиста по TH (SANS)

Специалист также должен знать современные техники, тактики и процедуры (TTPs) проведения атак, используемых нарушителями, уметь программировать и автоматизировать рутинные задачи, иметь интуицию и навык создания гипотез поиска.

Гипотеза поиска

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

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

• Индикаторы threat intelligence (TI-индикаторы). Простейшая гипотеза, имеющая структуру: злоумышленник использует новую модификацию утилиты X, которая имеет MD5-хеш Y.

• Техники, тактики и процедуры атакующих (TTPs). Информацию про TTPs современных киберпреступников можно найти в базе MITRE ATT&CK . Пример гипотезы: злоумышленник взломал пользовательскую рабочую станцию и методом перебора пытается подобрать пароль от привилегированной учетной записи.

• Аналитика автоматизированных средств обработки данных об инфраструктуре. Их данные помогут выявить аномалии. Например, с помощью систем asset management можно заметить появление нового узла в сети без ведома администраторов. Резкое увеличение объема трафика на сетевом узле тоже может стать поводом для более детального изучения этого узла.

• Информация, обнаруженная в ходе проверки предыдущих гипотез.

Инструменты TH

После формулирования гипотезы необходимо определить источники данных, которые могут содержать информацию для ее проверки. Часто такие источники содержат слишком много данных, среди которых нужно найти релевантные. Таким образом, процесс 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 к контроллеру домена для синхронизации. Она считалась бы подозрительной, если был такая коммуникация проходила между пользовательскими хостами.

Поскольку ничего подозрительного за выбранный промежуток времени не выявлено, выбираем другой. Теперь это интервал с 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. Дальнейший анализ логов показывает, что подключились под учетной записью PTLABAdmin и запустили команду (см. рис. 12) создания пользователя john с паролем password!!!: net user john password!!! /add.

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

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

Мы выяснили, что с узла 10.125.3.10 некто по WMI от имени учетной записи PTLABAdmin добавил нового пользователя на хост win-admin-01.ptlab.ru. При проведении реального TH на следующем шаге нужно выяснить, не является ли это административной активностью. Для этого нужно обратиться к владельцу аккаунта PTLABAdmin и узнать, осуществлял ли он описанные действия. Поскольку рассматриваемый пример синтетический, будем считать, что данная активность нелегитимная. При проведении реального 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 C enter ).

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

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

1. Изучайте свою инфраструктуру. Выберите для себя удобный подход к управлению сетевыми активами. Нужно в любой момент быть готовым дать ответ на вопрос о том, какую функцию выполняет тот или иной узел и дать по нему информацию.

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

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

4. Автоматизируйте рутинные задачи, чтобы осталось больше времени на применение творческого подхода и апробации нестандартных решений.

5. Упрощайте процесс анализа большого объема данных. Для этого полезно использовать инструменты, которые помогают аналитику увидеть происходящее в сети и на сетевых узлах как единую картину. Среди таких инструментов — платформа для обмена TI-индикаторами , система анализа трафика и SIEM-система .

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

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