Threat hunting что это
В погоне за «неправильными» инцидентами, или Как мы строим Threat Hunting
Инциденты с 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\ — в указанные директории возможно писать и запускать исполняемые файлы, не имея прав локального администратора);
Событие создания именного канала Pipe (Sysmon id 17)
Как известно, вредоносное программное обеспечение очень часто создает именованный канал для собственного межпроцессорного взаимодействия. И зачастую именованный канал имеет определенную маску в имени и какой-то генерируемый параметр, например, Evil_090920 (Evil – маска, 090920 – генерируемый параметр). Если имя именованного канала не находится в индикаторах компрометации, то само создание данного pipe не вызовет подозрения, тем не менее аналитик может обратить внимание на то, что в определенный момент времени (или через любой интервал времени) подобные неизвестные именованные каналы создавались на нескольких системах, что может косвенно свидетельствовать о распространении вредоносного кода.
В данном посте, рассказывая о том, как мы строим процесс Threat Hunting, мы опирались на события ОС Windows и Sysmon, выступающие в качестве источника для SIEM-системы. В действительности же источник событий и конечная система (лишь бы она это позволяла) для работы по проактивному поиску угроз для аналитика значения не имеет – ровно такую же философию можно применить, например, к EDR или NTA.
Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети
Threat hunting: как правильно организовать процесс поиска злоумышленников
В статье речь пойдет о том, что такое TH, как искать и проверять гипотезы и какие преимущества дает внедрение правильных процессов TH
Согласно результатам исследования 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 помогает командам ИБ:
Каким должен быть специалист по TH
При правильной организации процесса должна быть выделена отдельная структурная единица — отдел threat hunting. Сотрудников отдела будем называть аналитиками или специалистами по TH. Однако в российских компаниях зачастую функции TH-команды выполняет SOC. Согласно SANS, профиль навыков специалиста по TH соответствует диаграмме на рис. 1 (деления указывают уровень навыка, где 0% — абсолютное незнание области, а 100% — высококлассный эксперт в области).
Рисунок 1. Диаграмма профиля наиболее ценных навыков специалиста по TH (SANS)
Специалист также должен знать современные техники, тактики и процедуры (TTPs) проведения атак, используемых нарушителями, уметь программировать и автоматизировать рутинные задачи, иметь интуицию и навык создания гипотез поиска.
Гипотеза поиска
Идея гипотезы может родиться из личного опыта аналитика, однако существуют и другие источники для ее построения, например:
Индикаторы 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. Дальнейший анализ логов показывает, что подключились под учетной записью 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).
Я не призываю к отказу от средств автоматизированной защиты. Однако не нужно полагать, что установка и корректная настройка такой системы — финальная точка. Это лишь первый необходимый шаг. Далее нужно следить за развитием и функционированием подконтрольного сетевого окружения, держать руку на пульсе.
В этом помогут следующие советы:
Изучайте свою инфраструктуру. Выберите для себя удобный подход к управлению сетевыми активами. Нужно в любой момент быть готовым дать ответ на вопрос о том, какую функцию выполняет тот или иной узел и дать по нему информацию.
Определите наиболее важные риски и периодически проверяйте гипотезы по ним. Сети бывают разных размеров, для больших и распределенных инфраструктур очень важно выделить критически значимые узлы.
Следите за последними трендами в сфере ИБ. В частности, будьте готовы реагировать на свежие уязвимости и новые методы атак. Периодически проверяйте свои средства защиты на возможность отражения новой угрозы. Если угроза не была выявлена, сделайте из данной атаки гипотезу для TH и проверяйте ее, пока автоматизированные средства защиты не начнут ее выявлять.
Автоматизируйте рутинные задачи, чтобы осталось больше времени на применение творческого подхода и апробации нестандартных решений.
Упрощайте процесс анализа большого объема данных. Для этого полезно использовать инструменты, которые помогают аналитику увидеть происходящее в сети и на сетевых узлах как единую картину. Среди таких инструментов — платформа для обмена TI-индикаторами, система анализа трафика и SIEM-система.
Автор: Антон Кутепов, специалист экспертного центра безопасности (PT Expert Security Center) Positive Technologies.