навигация
Охота за угрозами: зачем она нужна

Введение

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

Существуют классический триггерный подход к мониторингу (alert-driven), который заключается в реагировании на алерты средств защиты и не всегда эффективен в современном мире, и подход Threat Hunting, успешно его дополняющий.

Threat Hunting действительно эффективен, и вот доказательства.

Согласно ежегодным отчетам FireEye M-Trends, показатель Dwell Time, характеризующий медианное время с момента компрометации инфраструктуры до момента обнаружения угрозы, непрерывно уменьшается на протяжении последних трех лет. В 2017 году этот показатель составлял 101 день, в 2018 году — 78 дней, а в 2019 году — уже 56 дней. FireEye связывает сокращение Dwell Time с двумя факторами: улучшением процессов и инструментов мониторинга в организациях и возросшим количеством инцидентов с применением шифровальщиков и майнеров криптовалюты, которые быстро обнаруживаются ввиду деструктивной специфики. Безусловно, развитие таких технологий, как Threat Intelligence и Threat Hunting, и возросшее внимание к мониторингу конечных точек также внесли свой вклад.

Около 70% респондентов исследования SANS 2019 Threat Hunting связали сокращение Dwell Time в своих организациях именно с внедрением практик Threat Hunting. В исследовании также отмечается, что организации все еще не до конца понимают, в чем заключается процесс и что принесет внедрение этой технологии.

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

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

Что такое Threat Hunting

Впервые термин Threat Hunting был упомянут летом 2011 года в журнале Information Security Magazine, в статье Become a Hunter. Ричард Бейтлих, возглавлявший в то время General Electric CERT, написал: «Для повышения эффективности защиты от целевых атак специалисты по кибербезопасности должны проводить операции по противодействию угрозам. Иными словами, защитники должны охотиться на злоумышленников в своей инфраструктуре». Также он отметил, что еще в середине 2000-х Военно-воздушные силы США использовали термин hunter-killer в тренировочных упражнениях по симуляции атак на свои сети.

В настоящее время под Threat Hunting подразумевается процесс проактивного и итеративного анализа телеметрии, собираемой с конечных точек и сетевых сенсоров (например, IDS/IPS) с целью выявления угроз, обошедших используемые в сети превентивные средства защиты.

Термин «проактивный» играет здесь ключевую роль. Охотники за угрозами (Threat Hunters) не сидят в консолях средств защиты информации и не ждут появления алертов или срабатываний правил корреляции в SIEM. Вместо этого они используют свои опыт и знания для активного поиска подозрительной активности в телеметрии, непрерывно собираемой с конечных точек и сетевых сенсоров. Кроме того, охотники за угрозами активно используют в своей работе продукты киберразведки (Threat Intelligence) для изучения так называемых тактик, техник и процедур (TTP) атакующих. Получив из какого-либо источника Threat Intelligence информацию о новой технике атаки, охотник за угрозами формирует гипотезу о ее применимости к вверенной ему инфраструктуре и пытается найти следы ее присутствия в имеющейся телеметрии. Если первичная гипотеза оказалась ложной, она модифицируется и проверяется снова: в этом заключается итеративность, которая также фигурирует в приведенном выше определении. Иными словами, проверки гипотез никогда не останавливаются; получая все больше информации о новых тактиках и техниках атакующих, охотники за угрозой начинают ее применять в непрерывном цикле анализа собираемой телеметрии.

Теперь попробуем разобраться, что необходимо для успешного внедрения практик Threat Hunting в организации. И начнем мы с базовых элементов.

Что необходимо для Threat Hunting

Допустим, вы решили дополнить классический мониторинг alert-driven проактивным поиском угроз, т. е. внедрить практики Threat Hunting. Рассмотрим базовые компоненты, которые для этого понадобятся.

1. Команда

Пожалуй, самый важный компонент — это люди. Все остальное не будет иметь особого смысла без квалифицированной команды охотников за угрозами.

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

  • безопасность сетей и ОС;
  • внутреннее устройство ОС;
  • реагирование на инциденты кибербезопасности;
  • киберразведка;
  • хостовая и сетевая форензика.

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

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

2. Телеметрия

Чтобы искать следы угроз в вашей инфраструктуре, вам понадобятся телеметрия — хостовая и сетевая.

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

Табл. 1. Хостовая телеметрия
Тип телеметрии Описание Возможные источники телеметрии

События активности процессов

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

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

Как правило, это следующие события:

  • создание/завершение процесса;
  • загрузка процессом DLL-библиотеки;
  • создание/изменение/переименование/удаление процессом файла;
  • модификация атрибутов безопасности файла (DACL, SACL, владелец);
  • модификация атрибутов файловой системы файла (скрытый, системный и т. д.);
  • создание/изменение/удаление/сохранение процессом ключа/значения реестра;
  • создание процессом именованного канала;
  • подключение процесса к именованному каналу;
  • сетевая активность процесса: DNS-запросы, открытие порта на прослушивание, сетевые обращения, HTTP-активность;
  • доступ процесса к памяти другого процесса — получение handle на память другого процесса, чтение из памяти другого процесса, запись в память другого процесса;
  • инжект процессом исполняемого кода в память другого процесса;
  • выполнение процессом WMI-команды;
  • выполнение процессом PowerShell-кода;
  • загрузка драйверов;
  • прописывание исполняемого файла или команды в автозагрузку: изменение специфичных ключей реестра, создание/изменение файлов в специфичных каталогах, создание/изменение сервисов, задач планировщика WMI-подписок, задач BITS
  • Sysmon;
  • Auditd;
  • EDR

Сканирование оперативной памяти

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

Сканирование оперативной памяти позволяет находить наиболее сложные угрозы, относящиеся к классу fileless, когда вся активность злоумышленника не покидает оперативной памяти. Но вместе с тем эта категория — удел только весьма продвинутых EDR-решений. К сожалению, бесплатные решения (например, Sysmon) или штатные возможности аудита ОС при fileless-атаках чаще всего бессильны, здесь на помощь могут прийти коммерческие EDR-решения, содержащие модуль периодического сканирования оперативной памяти.

Примеры событий, которые могут быть получены в рамках телеметрии этой категории:

  • обнаружение RWX-региона памяти, незамапленного в какой-либо модуль на диске, но при этом содержащего признаки исполняемых файлов (характерные заголовки) или shell-кодов;
  • обнаружение несоответствий между PEB и VAD Tree: данное событие, например, позволяет детектировать такую продвинутую технику, как Process Hollowing;
  • обнаружение признака несанкционированной модификации таблицы импорта запущенного процесса — позволяет выявлять IAT Hooking;
  • обнаружение скрытого процесса или модуля — позволяет выявлять сокрытие процессов/библиотек с использование техники DKOM (Direct Kernel Object Manipulation)

EDR

Инвентаризация точек автозапуска

Этот тип телеметрии включает события, генерируемые в результате периодического сканирования хорошо известных точек автозапуска ОС (так называемых ASEP — Autostart Extensibility Points).

Инвентаризация точек автозапуска — эффективный источник данных для Threat Hunting, своего рода путь quick wins, т. к. большая часть вредоносного ПО и атакующих стремятся закрепиться в скомпрометированной системе, чтобы переживать перезагрузку. Таким образом, анализ данных, прописанных в автозагрузку, — один из самых быстрых путей выявления прошлых компрометаций системы.

В эту категорию входят следующие события:

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

Некоторые источники могут поставлять приведенную информацию в виде единого события (объединяющего как метаданные файла, так и прописанную командную строку) на каждый обнаруженный в автозагрузке объект, некоторые — по отдельности

  • утилита Autorunsc из состава набора инструментов Sysinternals;
  • EDR;
  • скрипты собственной разработки

События ОС

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

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

  • все, что касается аутентификации пользователей: успешные/неуспешные входы, запросы/выдача билетов Kerberos;
  • управление учетными записями и группами: создание, изменение, модификация, удаление;
  • манипуляция с объектами каталога Active Directory;
  • изменения политики безопасности / аудита событий;
  • создание/доступ к общим сетевым каталогам;
  • создание новых сервисов;
  • создание/изменение/удаление задач планировщика;
  • события выполнения PowerShell-кода;
  • создание/завершение процесса, если не используется EDR или иной специализированный агент для мониторинга активности процессов;
  • создание/изменение/удаление/сохранение процессом ключа/значения реестра, если не используется EDR или иной специализированный агент для мониторинга активности процессов;
  • сетевая активность процесса — открытие порта на прослушивание, сетевые обращения, если не используется EDR или иной специализированный агент для мониторинга активности процессов

Штатные возможности ОС

Листинг определенных каталогов, которые могут быть использованы атакующими или вредоносным ПО для хранения своих исполняемых файлов

Этот тип телеметрии включает события, генерируемые в результате периодической индексации содержимого заданных каталогов (например, Windows, Temp, ProgramData).

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

Листинг определенных каталогов наряду с инвентаризацией точек автозапуска позволяет выявлять инциденты, которые произошли в прошлом, оставили в системе определенные файловые артефакты и в настоящее время неактивны

  • утилита Sigtool из состава набора инструментов Sysinternals;
  • EDR;
  • скрипты собственной разработки

Периодические снапшоты результатов работы отдельных утилит

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

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

Примеры данных, которые попадают в эту категорию:

  • периодические слепки запущенных процессов;
  • периодические слепки активных сетевых подключений;
  • периодические слепки запрошенных билетов Kerberos;
  • периодические слепки установленных в системе служб/драйверов
  • netstat;
  • arp;
  • tasklist;
  • sc;
  • wmic;
  • klist;
  • PowerShell-скрипты;
  • KANSA

Для Threat Hunting немаловажна и сетевая телеметрия, сведения о которой представлены в табл. 2.

Табл. 2. Сетевая телеметрия
Тип телеметрии Описание Возможные источники телеметрии

Метаданные загружаемых из интернета файлов

Загрузка вредоносных файлов из интернета — популярный канал первичного проникновения вредоносного кода в защищаемые инфраструктуры. Помимо этого, уже скомпрометированный хост может осуществлять докачку своих модулей уже в ходе функционирования. Наличие телеметрии с метаданными (хеш, тип файла, информация об источнике загрузки, о соответствующих атрибутах протокола HTTP) всех загружаемых из интернета файлов может быть серьезным подспорьем как при расследованиях, так и при поиске угроз в рамках практик Threat Hunting (например, выявление фактов загрузки исполняемых файлов с неизвестных ресурсов серверами или загрузки файлов, хеши которых фигурируют в используемых фидах Threat Intelligence)

  • Zeek;
  • Suricata;
  • sandbox-решения

Метаданные HTTP-активности

Сведения о ресурсах, к которым осуществляется доступ из сети организации. Эта телеметрия может быть использована для выявления коммуникаций вредоносного кода с командными центрами, атак Drive-By, попыток эксфильтрации данных по протоколу HTTP

  • Proxy logs;
  • NGFW logs;
  • Zeek;
  • Suricata

Метаданные SSL-/TLS-трафика

Если используемый вами сетевой сенсор может поставлять телеметрию SSL-/TLS-трафика, это может стать отличным дополнением для программы Threat Hunting. Например, данная телеметрия может быть использована для:

  • детектирования коммуникаций известного вредоносного ПО с использованием JA3-/JA3S-хешей или по аномалиям TLS-протокола, характерным для заданного вредоносного ПО;
  • выявления обращений по HTTPS к фишинговым доменам, похожим на домены защищаемой компании
  • Zeek;
  • Suricata

Метаданные DNS-трафика

Классический источник для мониторинга. Также может быть использован и для Threat Hunting в рамках выявления:

  • зараженных компьютеров внутри сети, пытающихся резолвить имена известных вредоносных хостов или DGA-имена;
  • DNS-туннелей;
  • DNS-эксфильтрации
  • NGFW logs;
  • DNS Servers logs;
  • Zeek;
  • Suricata

Метаданные LDAP-трафика

Протокол LDAP зачастую используются атакующими либо для получения сведений о скомпрометированной доменной инфраструктуре (например, используя известный инструмент BloodHound), либо как подготовительный этап к выполнению Roasting-атак (AS-REP Roasting, Kerberoasting). Кроме того, через LDAP атакующий может выполнять перебор паролей доменных учетных записей. При наличии телеметрии в виде метаданных внутреннего LDAP-трафика охотники за угрозами могут выявлять все перечисленное

  • Zeek;
  • Suricata

Метаданные Kerberos-трафика

Kerberos — стандартный протокол аутентификации в доменных сетях. Известно множество различных атак на реализацию этого протокола в Windows (Pass-the-Ticket, Golden Ticket, Silver Ticket, атаки на механизмы делегирования). Часть этих атак может быть обнаружена по метаданным Kerberos-трафика
  • Zeek;
  • Suricata

Метаданные SMB / DCE RPC

Протоколы SMB / DCE RPC служат транспортом для многих сервисных функций ОС Windows. Сбор метаданных этих протоколов позволяет выявить широкий спектр техник постэксплуатации в инфраструктуре Windows:

  • техники для горизонтальных перемещений внутри скомпрометированной инфраструктуры — WMI, сервисы, задачи планировщика, DCOM;
  • техники сбора информации об окружении — активные сессии, группы, учетные записи и т. п.;
  • техники дампа учетных записей пользователей — DCSync, дамп по сети ветки реестра SAM и др.
  • Zeek;
  • Suricata

Метаданные файлов, передаваемых внутри сети по SMB

Протокол SMB служит транспортом для многих сервисных функций ОС Windows. Наряду с взаимодействием с различными управляющими интерфейсами атакующие могут использовать этот протокол непосредственно для передачи файлов внутри скомпрометированной сети. Наличие метаданных этих файлов позволит выявлять различные аномалии, связанные с активными действиями атакующих в инфраструктуре (например, передача исполняемых файлов между рабочими станциями или файлов-дампов веток реестра Windows)
  • Zeek;
  • Suricata

Метаданные электронных писем, сведения о файлах и ссылках, получаемых по электронной почте

Электронная почта — самый популярный канал доставки вредоносного контента. Этот контент может приходить как в виде вложенных файлов, так и в виде ссылок с предложениями по ним перейти. Наличие источника событий, который предоставляет не только почтовые заголовки, но и сведения о файлах (хеш, тип, размер, в отдельных случаях результаты проверки YARA-правилами) и ссылках из электронных писем с привязкой к метаданным из почтовых заголовков и заголовков письма, дает охотникам за угрозами мощные возможности по выявлению и расследованию инцидентов, где канал электронной почты задействован в качестве первичного вектора проникновения
  • Zeek;
  • Suricata;
  • Email Server logs;
  • самописные скрипты;
  • sandbox-решения

NetFlow

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

  • зараженные хосты по коммуникациям с известными адресами командных центров вредоносного ПО;
  • появление нового неавторизованного хоста или сетевого сервиса в защищаемом сегменте сети;
  • сканирования сети;
  • попытки передачи больших объемов данных;
  • аномальная межхостовая активность (например, большое количество трафика SMB / DCE RPC между рабочими станциями);
  • скрытые каналы передачи данных (например, большой объем трафика DNS/ICMP может указывать на использование механизмов туннелирования)
  • Suricata;
  • SiLK;
  • nfcapd;
  • nfdump



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

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

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

Однако помните, что потребуется адаптация инструментария со стороны команды охотников за угрозами. В конечном счете лучшие инструменты будут созданы или доработаны вашими людьми. Например, отличная платформа Threat Hunting может быть построена на базе стека ELK (Elasticsearch, Logstash, Kibana). При наличии в команде квалифицированного DevOps-инженера и специалиста, знающего и умеющего разрабатывать pipeline обработки и обогащения событий, вы сможете создать из Open Source очень качественный инструмент для Threat Hunting, ничем не уступающий, а в отдельных случаях и превосходящий коммерческие решения. В интернете можно найти очень много качественных материалов по использованию стека ELK в качестве платформы Threat Hunting, например вот или вот.

4. Процессы

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

Рассмотрим, почему это важно, на примере.

Допустим, в результате проведения Threat Hunting exercise во внутреннем сегменте сети организации были обнаружены признаки вредоносной активности, свидетельствующие о компрометации привилегированной учетной записи. Готовы ли вы к такому развитию событий? Что вы будете делать дальше? Иными словами, есть ли у вас выстроенный процесс реагирования на инциденты, в рамках которого полученные от охотников за угрозами сведения могут быть корректно обработаны?

Если такого процесса нет, скорее всего, результаты работы охотников за угрозами будут либо обрабатываться несистемно в режиме Ad-Hoc, либо же вообще складываться в стол. В таком случае назревает вопрос: а зачем инвестировать ресурсы в дорогие технологии (EDR, платформа Threat Hunting) и специалистов, если результатами их работы не будут пользоваться? Таким образом, отлаженный процесс реагирования на инциденты жизненно необходим для успешного внедрения практик Threat Hunting.

Теперь скажем пару слов о киберразведке и ее необходимости для Threat Hunting. Охотникам за угрозами нужно постоянно откуда-то черпать знания о новых техниках и инструментах атакующих для генерации гипотез. Для этого необходим выстроенный процесс непрерывного анализа информации о новых угрозах/атаках/инструментах, публикуемой доверенными источниками (вендоры продуктов в области кибербезопасности, известные исследователи, выступления на профильных конференциях и т. п.). Если этого нет, то применить методы Threat Hunting все еще возможно, но в этом случае действия охотников за угрозами будут хаотичны, а их работа — непредсказуема.

Подходы к Threat Hunting

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

Пирамида боли
Пирамида боли

Каждая ступень пирамиды характеризует различные типы индикаторов компрометации, которые могут быть использованы для поиска следов атакующего. Ширина ступени отражает количество индикаторов, а ее цвет и расположение по высоте — степень неудобств или «боли», которые могут быть причинены атакующему при детектировании или блокировании его индикаторов.

Например, блокировка IP-адресов или доменных имен C2 не доставит атакующему много неудобств, т. к. IP-адреса могут быть легко изменены, а новые домены — зарегистрированы. Вместе с тем блокировка специфичных утилит, используемых атакующим, способна причинить немало неудобств, т. к. для обхода такой защиты потребуется либо серьезно переработать уже имеющийся в его распоряжении инструмент, либо разработать или купить новый, что довольно затратно и неприятно. И наконец, TTPs (тактики, техники и процедуры), используемые атакующим, могут быть обнаружены посредством разработки детектирующих правил. Такой подход доставит атакующему максимально много «боли», т. к. это вынудит его либо изменить свои техники, несмотря на то что это может быть очень сложно, а зачастую даже невозможно, либо отступить.

Теперь, когда мы познакомились с пирамидой боли, рассмотрим, какие подходы к Threat Hunting существуют в настоящее время:

  • IoC-based — первые четыре ступени пирамиды. Поиск следов атакующего ведется по специфичным индикаторам, например по хеш-суммам известных хакерских инструментов, таких как Mimikatz или Empire, или по специфичным доменным именам командных центров атакующего. Менее волатильные индикаторы — специфичные ключи реестра, изменяемые malware или строки User-Agent.
  • Tools-based — предпоследняя ступень пирамиды боли, включающая детектирование по признакам, характерным для специфичных инструментов. Например, командные строки, которые мы можем получить из событий запуска процессов, или атрибуты VERSIONINFO исполняемых файлов, поставляемые EDR-решениями, в том числе уже ранее упомянутым Sysmon.
  • TTPs-based — верхняя ступень пирамиды боли с тактиками, техниками и процедурами. Допустим, что для lateral movement и закрепления в системе атакующий использует технику удаленного выполнения кода T1035 — Service Execution. Опытный охотник за угрозами исследует эту технику, определяет телеметрию, необходимую для разработки детектирующего правила, и при помощи инструментов выполняет проактивный поиск следов использования данной техники в защищаемой инфраструктуре.

Наиболее продвинутые охотники за угрозами используют последние два подхода. Рассмотрим на конкретном примере, как это работает.

Hunting for Impacket

Начнем с небольшого сценария. Анализ последнего отчета Threat Intelligence показал, что преступная группировка атакует компании вашей отрасли и при этом активно использует техники удаленного выполнения кода посредством набора хакерских утилит из состава Impacket. Краткое описание из GIT-репозитория Impacket гласит, что это «a collection of Python classes for working with network protocols. Impacket is focused on providing low-level programmatic access to the packets and for some protocols (e. g. SMB1-3 and MSRPC) the protocol implementation itself».

Рассмотрим различные подходы к Threat Hunting на примере утилит удаленного выполнения кода из состава Impacket: psexec, smbexec и wmiexec.

При помощи подхода IoC-based охотник за угрозами может скачать исполняемые файлы и скрипты из GIT-репозитория и рассчитать их хеш-суммы, получив таким образом индикаторы компрометации (табл. 3).

Табл. 3. Хостовые индикаторы компрометации утилит psexec, smbexec и wmiexec
Tools MD5 SHA1 SHA256

psexec.py

2773C4094DACED9F193C3B310B6CC287

1CB2D13297C7A82DEF2A8408CEAB05FD9A25A5CA

7369300FBEDF4F3440A01F4439D39C681B5D9BDBA91177A356E7F68FF4E9CD09

smbexec.py

DC8094A0E2A5AA30677C4D6B31523356

A6265D68F7AB1FACED6B0652E2D4C189AD0DE2B8

EE44915454BB006C9BAAC1EE270BD6430EAF6430E3F1C34FA595F68F88007918

wmiexec.py

15CF3D5B72D037EAE9D1CE18F9179B4B

81D9A370D3C1C64E1F9C0DCDABBB241A7C1EF20F

BE1FE5F978D21367E3654883035391C9608068C0479D309E1F6C20EC842D735E


Полученные индикаторы могут быть помещены в правило для Sysmon, загружены в IOC-сканер или ваш собственный инструмент. Мы также можем использовать событие FileCreate (EventID 11) Sysmon и написать правило о создании файлов с именами smbexec, psexec или wmiexec для рабочих станций под управлением ОС Windows.

Такой подход реализуется довольно быстро и будет очень точным. Однако атакующему в этом случае будет просто уйти от наших детектов. Утилитам могут быть даны безобидные имена, а изменение всего одного байта изменит хеш-суммы файлов. Кроме того, вы вряд ли найдете эти файлы на ваших рабочих станциях: наиболее вероятно, что они будут запущены атакующим удаленно, с неконтролируемого вами хоста. Несмотря на это, такой подход не бесполезен: он может служить хорошим дополнением к другим подходам, особенно в процессе реагирования на инциденты, обеспечивая быстрый поиск артефактов вредоносной активности и их удаление. При этом сам по себе для Threat Hunting он не очень хорош.

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

Собранные нами индикаторы Tools-based утилит smbexec и wmiexec представлены в табл. 4 и табл. 5.

Табл. 4. Специфичные признаки утилиты smbexec
Фрагменты исходного кода Хостовые индикаторы Сетевые индикаторы

Фрагменты исходного кода

Фрагменты исходного кода

Фрагменты исходного кода


Специфичные командные строки процессов:

C:\Windows\system32\cmd.exe /Q /c echo cd ^> \\127.0.0.1\C$\__output 2^>^&1 >

C:\Windows\TEMP\execute.bat & C:\Windows\system32\cmd.exe /Q /c

C:\Windows\TEMP\execute.bat & del C:\Windows\TEMP\execute.bat

Специфичное имя создаваемого по сети сервиса:

content: “B|00|T|00|O|00|B|00|T|00|O”

Специфичная командная строка создаваемого сервиса (lpBinaryPathName):

content: “%|00|C|00|O|00|M|00|S|00|P|00|E|00|C|00|%|00| |00|/|00|Q|00| |00|/|00|c|00| |00|e|00|c|00|h|00|o|00| ”;

Специфичное имя хоста, переданное в качестве аргумента функции ROpenSCManagerW:

content: “D|00|U|00|M|00|M|00|Y”


Табл. 5. Специфичные признаки утилиты wmiexec
Фрагменты исходного кода Хостовые индикаторы Сетевые индикаторы

Фрагменты исходного кода

Фрагменты исходного кода

Фрагменты исходного кода

Фрагменты исходного кода


Специфичные командные строки процессов:

cmd.exe /Q /c cmd.exe 1> \\127.0.0.1\ADMIN$\__1565402391.05 2>&1
cmd.exe /Q /c cd 1> \\127.0.0.1\ADMIN$\__1565402391.05 2>&1

Использование временного файла с характерным именем, начинающимся c “__”, и unix timestamp для передачи по сети содержимого буферов ввода/вывода запускаемой на удаленном хосте команды:

content: “|05 00|”; distance: 8; within: 2; content: “_|00|_|00|1|00|”; distance: 106; within: 6; content: “|00|.|00|”


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

Как мы видим, использование утилит smbexec и wmiexec оставляет за собой очень много специфичных следов, по которым их можно выявлять. Однако для продвинутого атакующего не составит особого труда модифицировать исходный код утилит и тем самым обойти все наши детекты tool-based. Именно здесь охотнику за угрозами помогает подход TTPs-based.

Суть подхода TTPs-based сводится к выявлению специфичных поведенческих паттернов техник или инструментов атакующего. Посмотрим, как работает утилита psexec, и попробуем выявить такие паттерны.

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

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

Табл. 6. Гипотезы для TTP-детекта
Поведение утилиты psexec.py Гипотезы для TTP-детекта (на основе хостовой телеметрии) Гипотезы для TTP-детекта (на основе сетевой телеметрии)

Устанавливает соединение с удаленным хостом по протоколу SMB, далее копирует файл с полезной нагрузкой и создает сервис со случайно сгенерированным именем для запуска этого файла

  • Сетевой вход на хост (тип входа 3) с последующим созданием нового сервиса в рамках полученной сессии.
  • Создание и последующее удаление сервиса в короткий промежуток времени.
  • Создание сервиса с именем, представляющим собой случайно сгенерированную строку
  • Сигнатура для выявления в сетевом трафике вызова методов RCreateServiceW/RCreateServiceA в рамках установленной сессии протокола MS-SCMR.
  • Сигнатура для выявления в сетевом трафике вызова методов RStartServiceW/RStartServiceA в рамках установленной сессии протокола MS-SCMR

Использует механизм именованных каналов для коммуникации с атакуемым хостом

Создание процессом нетипичного именованного канала (для большинства процессов в целом это аномальная активность)


После успешного выполнения команды удаляет сервис и его исполняемый файл

Удаление исполняемого файла, который до этого запускался в качестве сервиса

Сигнатура для выявления в сетевом трафике вызова метода RDeleteService в рамках установленной сессии протокола MS-SCMR


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

Откуда черпать идеи для гипотез Threat Hunting

Threat Hunting начинается с появления идеи и формирования гипотезы. Охотники за угрозами могут черпать идеи для гипотез из следующих источников:

  • Матрица MITRE ATT&CK, представляющая собой обширный справочник известных тактик, техник и процедур, используемых атакующими. Исследование техник матрицы MITRE и их эмуляция в тестовой среде могут послужить отличным источником гипотез.
  • Отчеты Threat Intelligence, содержащие много полезной информации о техниках и процедурах атакующих, использованных ими в реальных инцидентах. Организация процесса анализа таких отчетов даст охотникам за угрозами много полезных идей.
  • Блоги, Twitter, выступления на конференциях исследователей и специалистов по кибербезопасности, которые охотно делятся результатами исследований. Зачастую данные источники являются первой точкой появления информации о какой-то новой технике атаки еще до того, как ей активно начинают пользоваться атакующие. Своевременное изучение такой информации позволит охотникам за угрозами срабатывать на опережение, не дожидаясь, когда новая техника атаки уйдет в массы.
  • Практика реагирования и расследования инцидентов, помогающая погрузиться в сам процесс. Непосредственное участие в реагировании на инциденты и проведении расследований позволит получить наиболее полную и глубокую информацию о TTPs, используемых атакующими.
  • Опыт специалистов по тестированию на проникновение, изучение которого позволяет ознакомиться с актуальными методиками. Современные атакующие зачастую используют инструменты и техники, аналогичные используемым опытными специалистами по проведению тестов на проникновение. Соответственно, изучение подобного опыта — ценный источник знаний для формирования гипотез Threat Hunting.

Рассмотрим на примере, как анализ отчета Threat Intelligence может помочь охотникам за угрозами в создании гипотез.

В недавнем отчете компании Zscaler описана активность продвинутого банковского трояна Ursnif, также известного как Gozi, или Dreambot. В качестве начального вектора проникновения Ursnif использует фишинговые письма с вредоносными вложениями. Обфусцированные multi-staged payloads трояна обеспечивают эффективный обход классических средств защиты.

Мы взяли несколько примеров интересных техник, используемых Ursnif, и попробовали сгенерировать гипотезы для Threat Hunting. Полученные результаты с маппингом техник на матрицу MITRE и необходимой для детектирования телеметрией представлены в табл. 7.

Табл. 7. Примеры гипотез для Threat Hunting, выделенных на основе результатов анализа отчета об активности трояна Ursnif
Фрагменты отчета MITRE-техники Гипотезы для TTP-детекта Необходимая для реализации детекта телеметрия

“As mentioned earlier, the malware’s initial payload was being

delivered via document files with the name info_03_24.doc during the time of our analysis.

The document didn’t contain any exploits but used macro code to drop the second-stage payload.”

T1193 — Spearphishing attachment

T1204 — User Execution

T1064 — Scripting

Порождение приложением Microsoft Word дочернего процесса в виде скриптового интерпретатора

События создания процессов: Windows Security, Sysmon, EDR

“Copy the mshta.exe code to microsoft.com (possibly to reduce footprints).

Write the second stage payload to index.html.

Execute the index.html with microsoft.com.”

T1170 — Mshta

T1036 — Masquerading

  • Создание в системе исполняемого файла, представляющего собой переименованный файл известной системной утилиты.
  • Запуск переименованной системной утилиты.
  • Использование утилиты mshta для запуска HTA-файлов из нетипичного расположения (например, из %TEMP% или ProgramData) или с отсутствующим расширением .hta
  • События создания файлов, содержащие атрибуты VERSIONINFO создаваемых исполняемых файлов: EDR.
  • События создания процессов, содержащие атрибуты VERSIONINFO запускаемых файлов: EDR, Sysmon.
  • События создания процессов: Windows Security, Sysmon, EDR

“Get the path %temp% and append index.dll (the final payload filename) to it.

Execute the downloaded DLL using regsvr32.”

T1117 — Regsvr32

Использование утилиты regsrv32.exe для запуска кода из DLL-библиотеки, расположенной в каталоге временных файлов (%TEMP%)

События создания процессов: Windows Security, Sysmon, EDR

“Command and control communication with newly registered campaign domains”

T1071 — Standard Application Layer Protocol

Процесс, не являющийся браузером, пытается отрезолвить имя недавно зарегистрированного домена

EDR-агент, позволяющий фиксировать DNS-запросы процессов


Полученные гипотезы могут быть использованы для написания правил корреляции и проведения проактивного поиска угроз в сети и служат примером подхода TTPs-based к Threat Hunting.

Заключение

Не очень просто рассказать о Threat Hunting в одной статье. Надеемся, у нас получилось дать представление о том, что это такое, и рассказать, какие преимущества принесет внедрение этой технологии.

Используйте различные подходы к Threat Hunting в комплексе и делайте акцент на подходе TTPs-based. Помните, что главный элемент, соединяющий все воедино, — это люди. Правильная команда, вооруженная инструментами и необходимой телеметрией, — залог успеха. Удачной вам охоты!

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