Что такое 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 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).
Я не призываю к отказу от средств автоматизированной защиты. Однако не нужно полагать, что установка и корректная настройка такой системы — финальная точка. Это лишь первый необходимый шаг. Далее нужно следить за развитием и функционированием подконтрольного сетевого окружения, держать руку на пульсе.
В этом помогут следующие советы:
Весь разбор проводился в системе анализа трафика PT Network Attack Discovery и системе управления событиями безопасности MaxPatrol SIEM.
Активный поиск угроз (охота на угрозы, threat hunting)
Активный поиск угроз (охота на угрозы, threat hunting) — это процесс проактивного обнаружения вредоносной деятельности в компьютерных сетях.
Цель охоты на угрозы — обнаружение кибератак, не поддающихся выявлению традиционными средствами защиты, такими как брандмауэры или системы антивирусного мониторинга. Для этого проводится ручной или машинный поиск и анализ индикаторов компрометации (IoC).
Активный поиск угроз позволяет на ранней стадии выявлять новые и сложные угрозы и рассматривается как дополнение к имеющейся защите информационных систем организации, а не как ее замена. От традиционных методов защиты threat hunting отличает именно проактивность.
Как происходит активный поиск угроз
Поскольку проникновение в систему может произойти в любой момент, охота на угрозы — это непрерывный процесс. Он состоит из двух шагов:
Если гипотеза подтвердилась, компания может принять необходимые меры. Кроме того, информацию, полученную в ходе поиска угроз, можно использовать для формирования новых гипотез и улучшения защитных систем, например для обновления правил фильтрации трафика.
Hunting Maturity Model
Модель HMM (Hunting Maturity Model, «модель зрелости активного поиска угроз») — это система оценки готовности бизнеса к применению проактивного поиска угроз. В зависимости от того, какими инструментами и методами владеет организация, выделяют пять уровней зрелости компании:
Публикации на схожие темы
Стратегия защиты для крупного бизнеса
Обход обнаружения в CLR: пример атаки и способы ее выявления
Лето 2021: Friday Night Funkin’, Måneskin и поп-ит
Дети в интернете 2021: творчество без границ
Правильный поиск угроз (Threat Hunting): стратегия, люди и инструменты
Более половины компаний, утверждающих, что внедрили процесс проактивного поиска угроз, на самом деле занимаются реагированием на оповещения средств автоматизированной защиты. По сути, речь идёт об управлении событиями и уведомлениями (event and alert management), а не о Threat Hunting. Что это на самом деле такое, какие типовые ошибки реализации допускают команды ИБ, какие преимущества даёт внедрение правильных процессов поиска угроз? Знание ответов на эти вопросы, а также владение инструментами, которые помогают в проведении «охоты», существенно сказываются на эффективности Threat Hunting как подхода.
Введение
Threat Hunting (TH) — проактивный циклический поиск следов вредоносных программ или взлома, которые не обнаруживаются стандартными средствами защиты. Аналитик не ждёт, пока сработают сенсоры систем обеспечения безопасности, а целенаправленно ищет следы компрометации. Для этого он выдвигает и проверяет предположения о том, как злоумышленники проникли в сеть. Такие проверки должны быть последовательными и регулярными, а сам процесс должен учитывать следующее:
Не секрет, что традиционные средства автоматизированной защиты пропускают сложные целевые атаки. Причин тому — несколько. Во-первых, нападения нередко распределены во времени, поэтому средства безопасности не могут провести корреляцию различных фаз атаки. Во-вторых, злоумышленники тщательно продумывают векторы проникновения и разрабатывают сценарии действий во внутренней инфраструктуре. Это позволяет им избегать демаскировки, в том числе выдавая свою активность за легитимную. В-третьих, злоумышленники постоянно совершенствуют знания, покупают или разрабатывают новые инструменты.
В этой статье будет дано общее описание процесса Threat Hunting, а также подходов, которые применяются при его проведении. Мы рассмотрим основные ошибки при организации поиска угроз, профиль навыков TH-специалиста, методы создания и проверки гипотез, а также инструментарий, который поможет в проведении «охоты».
Threat Hunting: кратко о подходе
Задача выявления целевых атак особо значима для структур, которые уже бывали взломаны ранее: исследования показывают, что более 60% организаций, чьи сети были ранее скомпрометированы, вновь подвергались атакам. В таких случаях необходимо принимать меры для раннего выявления фактов компрометации. Threat Hunting может помочь командам ИБ:
Рисунок 1. Ключевые ошибки при организации процесса Threat Hunting
Конечно, при правильной организации процесса выделяют особую структурную единицу для проактивного поиска угроз; сотрудников такого подразделения называют аналитиками или специалистами по TH. Однако в российских компаниях подобное штатное расписание встречается редко, и функции TH-команды часто выполняет SOC. По данным SANS профиль навыков специалиста по TH соответствует диаграмме на рис. 2 (деления указывают уровень навыка, где 0 — абсолютное незнание области, а 100 — уровень высококлассного эксперта).
Рисунок 2. Профиль наиболее ценных навыков специалиста по TH
Специалист по TH также должен быть знаком с современными техниками, тактиками и процедурами (англ. TTP) проведения атак, используемыми нарушителями, уметь программировать и автоматизировать рутинные задачи, иметь интуицию и навык создания гипотез.
Гипотеза как отправная точка
Поскольку при проведении Threat Hunting всегда предполагается, что злоумышленник уже проник в инфраструктуру, специалисту по TH необходимо определить место для поиска следов взлома. Сделать это можно выдвинув гипотезу о том, как произошло проникновение и какое подтверждение этому можно найти в инфраструктуре. Сформулировав гипотезу, аналитик проверяет истинность своего предположения и в итоге подтверждает или опровергает его. Если гипотеза не подтвердилась, эксперт переходит к выработке и проверке нового предположения. Если же в результате проверки очередной гипотезы найдены следы взлома или факты присутствия вредоносных программ, то начинается расследование.
Рисунок 3. Схема Threat Hunting
Гипотеза может родиться из личного опыта аналитика, однако существуют и другие источники идей:
Минимальный набор инструментов
После того как аналитик сформулировал гипотезу, ему необходимо определить перечень источников, которые могут содержать информацию для проверки или опровержения предположения. Зачастую такие источники содержат огромное количество данных о происходящем в инфраструктуре, среди которых нужно найти релевантные, и процесс TH сводится к фильтрации и анализу информации. Рассмотрим, в каких источниках можно найти такие сведения.
Рисунок 4. Источники информации для TH
Наибольшее количество релевантной информации содержится в системных журналах и сетевом трафике. Для удобной работы с информацией из таких источников полезны продукты классов Security Information and Event Management (SIEM) и Network Traffic Analysis (NTA). Если используются внешние источники, например TI-фиды, то значительным «плюсом» будет возможность интеграции этих данных в процесс анализа. При правильно построенном процессе сбора журналов SIEM-система обеспечивает аналитика наглядной картиной событий, происходивших на пользовательских компьютерах и серверах. Однако при этом остаётся скрытой суть сетевых взаимодействий; эту область покрывает NTA-система. Стоит отметить, что аналитик может проводить Threat Hunting даже имея продукт только одного типа, однако использование двух систем в связке позволит увидеть картину атаки целиком. Также полезно использовать платформы для обмена TI-индикаторами (например, MISP).
Выводы
Последние аналитические отчёты показывают, что в среднем проникшие в инфраструктуру злоумышленники весьма долго остаются необнаруженными. Поэтому не стоит ждать сигналов от средств автоматизированной защиты: нужно действовать проактивно. Это совершенно не означает, что следует отказаться от средств обеспечения безопасности. Однако не стоит полагать, что установка и корректная настройка какой-то защитной системы — это финальная точка. Это — лишь первый необходимый шаг. Далее нужно следить за развитием и функционированием подконтрольного сетевого окружения, держать руку на пульсе, а именно: