Подписаться
Читать в телеграм
Когда и зачем нужно проводить Threat Hunting?
Как SIEM может помочь во время “охоты”?
Кейс: выдвигаем и проверяем гипотезу?
Классический подход к реагированию на угрозы — реактивный. Он подразумевает, что реакция на инцидент наступает только после появления определенного триггера. Это может быть срабатывание правила корреляции SIEM, выявление вредоносной сигнатуры антивирусом, оповещение от IPS/IDS-системы и т.д. Однако, как и в книге Стивена Кови «7 навыков высокоэффективных людей», чтобы эффективно реагировать на угрозы, нужно быть проактивным. Этот принцип лежит и в основе Threat Hunting. Мы не ждем, пока средства защиты оповестят об инциденте, а сами охотимся на угрозы в инфраструктуре.
Опрос, проведенный институтом SANS в 2021 г., показал, что у 93,1% компаний-респондентов есть специальный персонал для проактивного поиска угроз. При этом большинство опрошенных в ближайшем будущем планируют увеличить расходы на специалистов и инструменты в этой области.
Скажем прямо: хороший Threat Hunter должен быть достаточно пессимистичным. Он предполагает, что злоумышленник уже проник в инфраструктуру. Вдруг прямо сейчас хакер пытается закрепиться на атакованных активах? Может быть, неделю назад он успешно повысил свои привилегии? А что, если в прошлом месяце он уже украл критичные данные и успешно вывел их за пределы компании? Это гипотезы, которые аналитик, проводящий проактивный поиск угроз, должен подтвердить или опровергнуть. Они являются ключевым элементом Threat Hunting.
Залог успеха
Как эффективно выстроить процесс Threat Hunting? Успешность охоты зависит от нескольких факторов:
- Планирование и подготовка. Наполнение и актуализация базы гипотез, следование календарю и т.д.
- Экспертный анализ. Наличие компетенций для правильного анализа данных.
- Инструменты, которые помогут проверить гипотезы.
Существует миф, что для Threat Hunting нужны специальные инструменты и аналитики с заоблачной экспертизой. На самом деле это не так. Например, вы можете предположить, что на компьютере работает майнер. Что нужно, чтобы проверить эту гипотезу? Открыть диспетчер задач или журналы событий хоста и поискать подозрительные процессы. Поздравляем, вы Threat Hunter!
Конечно, с точки зрения защиты компании эффективнее выдвинуть гипотезу, что майнер работает сразу на нескольких хостах. Для ее проверки понадобится рутинный сбор логов — лучше использовать для этого SIEM. Но в целом хантинг можно проводить с помощью любых ИБ-инструментов: IPS, FW, UEBA, EDR/XDR-систем, а кроме того, на самих рабочих станциях и серверах.
Сразу оговоримся: в этой статье мы фокусируемся на случае, когда ядром и ключевым инструментом Threat Hunting являются SIEM/LM-решения. Иными словами, мы предполагаем, что в инфраструктуре компании постоянно ведется базовый (а желательно — расширенный) сбор событий из определенных источников.
Готовимся к охоте
При формировании гипотезы нужно определить, какую нелегитимную активность вы ищете и на какой стадии потенциальной кибератаки может находиться злоумышленник. Необходима точка старта — база или фреймворк — от которой можно оттолкнуться и использовать для построения гипотез. Кроме того, источниками предположений могут быть ваши знания об инфраструктуре компании, процессах внутри нее и защищаемых активах.
Потенциальные источники гипотез:
- MITRE ATT&CK. Самый популярный фреймворк для проактивного поиска угроз. Содержит базу знаний о техниках, тактиках и процедурах (TTP), которые злоумышленники используют во время атаки.
- MITRE Cyber Analytics Repository. Репозиторий аналитики, основанный на MITRE ATT&CK. Содержит псевдокод запросов для поиска определенных TTP.
- Знание собираемых данных. Какие данные собираются в инфраструктуре (из каких источников, какого типа и др.) и какие аномалии можно в них найти.
- Знание инфраструктуры. Слабые места, уязвимые активы, а также представление о том, как злоумышленник может их эксплуатировать.
- Результаты пентестов. Данные практического анализа защищенности инфраструктуры, исследование векторов проникновения в сеть.
- Threat Intelligence. Аналитические отчеты о новых угрозах и видах атак, сведения от вендоров, из киберкриминалистических расследований и др.
- ИБ-осведомленность. Знание актуальных для вашей сферы угроз.
- Другое. Гипотеза может быть сформирована «другой стороной» (подозрения коллеги, руководства или заказчика), на основе методов OSINT (информация из онлайн-групп, открытых форумов и с теневых площадок), а также на базе ваших наблюдений и интуиции.
При формировании гипотезы важно:
- Убедиться, что она актуальна для вашей инфраструктуры и учитывает специфику компании.
- Проверить, что логи, по которым будет производиться анализ, поступают в SIEM. Также нужно убедиться, что все парсеры работают (проверить наличие нужных атрибутов в событиях и корректность их нормализации).
- Убедиться, что гипотеза будет проверяться по событиям, которые вы можете уверенно интерпретировать.
С чего начать
На старте сложно определить, какие гипотезы стоит проверять в первую очередь и что делать после этого. Как правило, специалисты используют для этого фреймворк MITRE (см. рис. 2). По крайней мере, пока не могут генерировать собственные гипотезы.
Мы в Jet CSIRT в первую очередь стремимся найти и остановить активности, которые соответствуют последним этапам Kill Chain. Это сбор данных для эксфильтрации, взаимодействие с командными серверами, нанесение урона и сама эксфильтрация.
HIGH
Уровень необходимых привилегий включает: User
Поддерживает удаленную эксплуатацию: ДА (если применимо)
Этап Kill Chain:
- CL – Collection
- CC – Command and Control
- EF – Exfiltration
- IP – Impact
MEDIUM
Уровень необходимых привилегий включает: User, Administrator, root
Этап Kill Chain:
- DE – Defense Evasion
- CA – Credential Access
- DC – Discovery
- LM – Lateral Movement
LOW
Уровень необходимых привилегий включает: User, Administrator, root
Этап Kill Chain:
- RS – Reconnaissance
- RD – Resource Development
- IA – Initial Access
SIEM как оружие
Мы фокусируемся на Threat Hunting с помощью SIEM: опишем функции и возможности системы, которые можно использовать во время охоты.
- Группировка. Как показывает практика, чаще всего под заданный поисковый запрос попадает масса активностей. Для удобства их анализа можно использовать функционал группировки событий. Перед установкой нужных атрибутов необходимо определить наиболее важные поля. Например, если поиск завязан на Windows Event ID 4688, показательными атрибутами будут: имя хоста, запускаемый и родительский процессы, командная строка процесса и имя пользователя. Для первоначального анализа этого достаточно. Если в выборке обнаружится подозрительная активность, нужно запустить новый поиск и детально ее проанализировать.
- Списки. При формировании поискового запроса можно пользоваться встроенными списками SIEM. Например, если вы ищете статистику обращений с внутренних хостов к внешним для обнаружения аномалий в трафике, удобно взять имеющийся список внутренних подсетей или прикладных портов. Также можно создавать и наполнять собственные листы — все это избавит от нагромождений в поисковом фильтре.
- Типы событий. Группируйте события по определенному типу активности и используйте их. Это позволит, к примеру, не перечислять все ID событий аутентификации.
- Репорты. Большинство SIEM позволяют сохранять фильтры — это заметно ускорит повторную проверку.
- Отчеты. Поиск событий может длиться долго. Запустите отчет заранее, чтобы сэкономить время.
- Графики. Визуализация поможет быстро и наглядно увидеть ТОП определенных событий или всплеск за конкретный промежуток времени.
- Функции. Например, использование встроенных математических функций поможет выявить аномалию в трафике — высчитать максимальное и среднее количество передаваемых данных на целевой хост.
При анализе в SIEM важно:
- Сначала запускать поиск за небольшой промежуток времени, чтобы оценить количественный масштаб вывода и корректность фильтра.
- Выбирать наиболее подходящий оператор для составления условия.
- Исключать явно легитимную активность, корректируя запрос (особенно если с группировкой генерируется много аналогичных событий). Например, процессы, в пути которых отличается версионность ПО.
- Выгружать полученные результаты и при необходимости использовать для обработки дополнительные инструменты: Excel, продвинутые текстовые редакторы и др.
Проверяем гипотезы
На этом этапе мы ищем доказательства компрометации инфраструктуры. Запускаемый в SIEM запрос может быть предельно конкретным и однозначно показывать нелегитимную активность. Или достаточно размытым — включать проверку по регулярному выражению, вхождению и т.д. В этом случае на выходе можно получить множество событий, ложноположительно подходящих под условия поиска или связанных с легитимной работой источника. Проверив эти активности, нужно исключить их из выборки.
В обоих случаях вы можете не найти подходящие под гипотезу события. Это тоже результат — ваше предположение не подтвердилось. Если же вы обнаружили активности, подтверждающие гипотезу, нужно расширить поиск: поискать следы атаки по логам из других источников, проанализировать активность в окрестностях найденного события на узле и детально раскрыть угрозу и действия атакующего.
При проверке гипотезы важно:
- Подвергать сомнению обнаруженную активность. Важно убедиться, что вы правильно отнесли ее к легитимным или нелегитимным событиям. Опирайтесь на собственный опыт, используйте информацию из открытых источников и дополнительные поисковые запросы.
- Отмечать любую подозрительную активность. Гипотеза может не подтвердиться, но у вас есть шанс обнаружить другие подозрительные события.
- Исключать ложноположительные и легитимные активности. Сразу корректируйте и сохраняйте поисковый запрос — это сэкономит время при повторной проверке.
Советы от Jet CSIRT
Прежде чем приступить к выбору и проверке гипотезы, изучите сетевую схему компании, используемые СЗИ, операционные системы и приложения.
Не отчаивайтесь: гипотезы подтверждаются далеко не всегда. Вы можете столкнуться с большим объемом выходных данных: ложноположительными совпадениями, легитимной активностью, результатом неправильной настройки устройств и т.д. Все это — тоже результат.
Следите за новостями в сфере ИБ, обнаруженными сообществом уязвимостями и новыми техниками атак.
Охотничьи трофеи
Результатом Threat Hunting является отчет, в котором описывается выдвинутая гипотеза и ее соответствие матрице MITRE ATT&CK. Документ должен содержать код поискового запроса с указанием группировки, агрегации и других функций. Необходимо описать рассуждения, указать исключенные события и сделать вывод — подтвердилась гипотеза или нет. Если во время охоты вы обнаружите другую подозрительную активность, это нужно отразить в отчете. Также нужно указать все дополнительные инструменты, которыми вы пользовались для анализа. Кроме того, необходимо описать рекомендации и действия, которые нужно выполнить при обнаружении подозрительной активности.
После проверки гипотезы и составления отчета:
- наполняйте и поддерживайте в актуальном состоянии базу гипотез;
- по возможности автоматизируйте процесс поиска событий, например, с помощью отчетов и вспомогательных правил;
- оцените возможность реализации правила в SIEM на основе вашей гипотезы.
-
Количество найденных угроз (подтвержденных гипотез). 
Рост числа гипотез и процент покрытия матрицы MITRE ATT&CK.
Количество найденных подозрительных активностей, не связанных с выдвинутой гипотезой.
Обнаруженное неправильно работающее ПО.
Количество реализованных правил.
Прогресс по уменьшению ложноположительных результатов.
Прогресс по уменьшению времени хантинга.
-
Выдвигаем гипотезу
Пользователи могут хранить пароли для доступа к сервисам в открытом виде, в том числе в простых текстовых файлах. В этом случае злоумышленнику достаточно получить доступ к рабочей станции, и все доступы жертвы будут скомпрометированы. Кроме того, при использовании консольных команд пользователи могут в открытом виде указывать пароли для доступа к сервису/программе. -
Анализ подключенных источников
В SIEM поступают события с рабочих станций на базе ОС Windows и события auditd c Linux-серверов. -
Проверка подходящих для поиска событий
В SIEM поступают события запуска процесса c Windows Event ID 4688, содержащие командлайн, а также события auditd EXECVE, в которых логируются выполняемые команды. -
Формирование запроса
vendor:"microsoft" AND event.id:"4688" AND process.name:/.*(notepad|excel|word|outlook|cmd|powershell|winrar).*/ AND command:/.*(password|pass|паро|логин|passwd|pwd).*/ -
Проверка гипотезы
Отсеиваем ложноположительные совпадения и выявляем командлайны, подходящие под наше предположение. -
Результат (скрин полученных командлайнов без привязки к заказчику или в текстовом формате)
Вывод
Гипотеза подтверждена: на рабочих станциях и серверах находятся незащищенные файлы, которые предположительно содержат пароли в открытом виде. Обнаружены текстовые файлы с характерными названиями.
Рекомендации
Необходимо проверить, действительно ли в найденных файлах хранятся пароли. Если это так, нужно удалить файлы, сбросить пароли сотрудников и провести с ними разъяснительную беседу.
Если в командлайне обнаружен пароль в открытом виде: считать пароль скомпрометированным, сбросить его, выполнить корректировку работы ПО и предпринять организационные меры в отношении пользователей.
