Охота за угрозами: зачем она нужна
Существуют классический триггерный подход к мониторингу (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 был упомянут летом 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. Рассмотрим базовые компоненты, которые для этого понадобятся.
Пожалуй, самый важный компонент — это люди. Все остальное не будет иметь особого смысла без квалифицированной команды охотников за угрозами.
Развивайте и обучайте своих сотрудников, это важно. Threat Hunting потребует от них серьезных технических знаний в следующих дисциплинах:
- безопасность сетей и ОС;
- внутреннее устройство ОС;
- реагирование на инциденты кибербезопасности;
- киберразведка;
- хостовая и сетевая форензика.
Охотник за угрозами также должен критически мыслить, иметь аналитический склад ума, быть любопытным, настойчивым и внимательным к деталям. Он должен стремиться докопаться до самой сути изучаемого вопроса.
Однако на рынке мало специалистов с необходимой квалификацией, поэтому не нужно пытаться заполнить все позиции готовыми экспертами. Вы можете взять хорошего эксперта и лидера — и он сам наберет команду и обучит ее.
Чтобы искать следы угроз в вашей инфраструктуре, вам понадобятся телеметрия — хостовая и сетевая.
В табл. 1 содержится информация о телеметрии с конечных точек, которая может быть использована в рамках активностей Threat Hunting.
Табл. 1. Хостовая телеметрия| Тип телеметрии | Описание | Возможные источники телеметрии |
|---|---|---|
| События активности процессов | Этот тип телеметрии включает события, генерируемые установленным на хост агентом либо непосредственно ОС в результате совершения запущенными процессами различных действий. События активности процессов — наиболее важная хостовая телеметрия для Threat Hunting, т. к. в большинстве случаев действия атакующих или вредоносного ПО на скомпрометированных хостах порождают за собой активность запущенных процессов, отражаемую в событиях этой категории телеметрии. Как правило, это следующие события:
|
|
| Сканирование оперативной памяти | Этот тип телеметрии включает события, генерируемые в результате периодического сканирования памяти запущенных процессов и обнаружения в ходе такого сканирования аномалий, потенциально указывающих на наличие в памяти вредоносного кода или признаков несанкционированной модификации важных структур и объектов ОС. Сканирование оперативной памяти позволяет находить наиболее сложные угрозы, относящиеся к классу fileless, когда вся активность злоумышленника не покидает оперативной памяти. Но вместе с тем эта категория — удел только весьма продвинутых EDR-решений. К сожалению, бесплатные решения (например, Sysmon) или штатные возможности аудита ОС при fileless-атаках чаще всего бессильны, здесь на помощь могут прийти коммерческие EDR-решения, содержащие модуль периодического сканирования оперативной памяти. Примеры событий, которые могут быть получены в рамках телеметрии этой категории:
| EDR |
| Инвентаризация точек автозапуска | Этот тип телеметрии включает события, генерируемые в результате периодического сканирования хорошо известных точек автозапуска ОС (так называемых ASEP — Autostart Extensibility Points). Инвентаризация точек автозапуска — эффективный источник данных для Threat Hunting, своего рода путь quick wins, т. к. большая часть вредоносного ПО и атакующих стремятся закрепиться в скомпрометированной системе, чтобы переживать перезагрузку. Таким образом, анализ данных, прописанных в автозагрузку, — один из самых быстрых путей выявления прошлых компрометаций системы. В эту категорию входят следующие события:
Некоторые источники могут поставлять приведенную информацию в виде единого события (объединяющего как метаданные файла, так и прописанную командную строку) на каждый обнаруженный в автозагрузке объект, некоторые — по отдельности |
|
| События ОС | Этот тип телеметрии включает события, генерируемые штатной подсистемой аудита ОС. Служит отличным дополнением телеметрии активности процессов, так как многие техники атакующих могут быть выявлены исключительно по событиям ОС. Состав событий этой категории для различных ОС может отличаться. Так, в отношении ОС семейства Windows можно выделить следующие группы событий, потенциально интересных для Threat Hunting (отметим, что список не является исчерпывающим, в ОС Windows есть большое количество интересных событий, разбросанных по разным журналам, перечисление их всех выходит за рамки настоящей статьи):
| Штатные возможности ОС |
| Листинг определенных каталогов, которые могут быть использованы атакующими или вредоносным ПО для хранения своих исполняемых файлов | Этот тип телеметрии включает события, генерируемые в результате периодической индексации содержимого заданных каталогов (например, Windows, Temp, ProgramData). Результатом такого сканирования является отдельное событие на каждый обнаруженный в каталоге файл, подходящий под заданный фильтр. Наряду с фактом наличия исполняемого файла или скрипта в соответствующем каталоге событие должно содержать метаданные обнаруженного файла (хеши, даты создания и модификации, атрибуты файловой системы, сведения о подписи и т. д.). Листинг определенных каталогов наряду с инвентаризацией точек автозапуска позволяет выявлять инциденты, которые произошли в прошлом, оставили в системе определенные файловые артефакты и в настоящее время неактивны |
|
| Периодические снапшоты результатов работы отдельных утилит | Этот тип телеметрии включает события, генерируемые в результате периодического запуска различных утилит или периодических запросов к штатным интерфейсам управления ОС (например, WMI) и сопоставления возвращаемых результатов с результатами прошлого запуска. Такой способ сбора информации может быть использован в тех случаях, когда по каким-либо причинам отсутствует возможность непрерывного мониторинга системы с помощью устанавливаемого агента. Примеры данных, которые попадают в эту категорию:
|
|
Для Threat Hunting немаловажна и сетевая телеметрия, сведения о которой представлены в табл. 2.
Табл. 2. Сетевая телеметрия| Тип телеметрии | Описание | Возможные источники телеметрии |
|---|---|---|
|
Метаданные загружаемых из интернета файлов |
Загрузка вредоносных файлов из интернета — популярный канал первичного проникновения вредоносного кода в защищаемые инфраструктуры. Помимо этого, уже скомпрометированный хост может осуществлять докачку своих модулей уже в ходе функционирования. Наличие телеметрии с метаданными (хеш, тип файла, информация об источнике загрузки, о соответствующих атрибутах протокола HTTP) всех загружаемых из интернета файлов может быть серьезным подспорьем как при расследованиях, так и при поиске угроз в рамках практик Threat Hunting (например, выявление фактов загрузки исполняемых файлов с неизвестных ресурсов серверами или загрузки файлов, хеши которых фигурируют в используемых фидах Threat Intelligence) |
|
|
Метаданные HTTP-активности |
Сведения о ресурсах, к которым осуществляется доступ из сети организации. Эта телеметрия может быть использована для выявления коммуникаций вредоносного кода с командными центрами, атак Drive-By, попыток эксфильтрации данных по протоколу HTTP |
|
|
Метаданные SSL-/TLS-трафика |
Если используемый вами сетевой сенсор может поставлять телеметрию SSL-/TLS-трафика, это может стать отличным дополнением для программы Threat Hunting. Например, данная телеметрия может быть использована для:
|
|
|
Метаданные DNS-трафика |
Классический источник для мониторинга. Также может быть использован и для Threat Hunting в рамках выявления:
|
|
|
Метаданные LDAP-трафика |
Протокол LDAP зачастую используются атакующими либо для получения сведений о скомпрометированной доменной инфраструктуре (например, используя известный инструмент BloodHound), либо как подготовительный этап к выполнению Roasting-атак (AS-REP Roasting, Kerberoasting). Кроме того, через LDAP атакующий может выполнять перебор паролей доменных учетных записей. При наличии телеметрии в виде метаданных внутреннего LDAP-трафика охотники за угрозами могут выявлять все перечисленное |
|
|
Метаданные Kerberos-трафика |
Kerberos — стандартный протокол аутентификации в доменных сетях. Известно множество различных атак на реализацию этого протокола в Windows (Pass-the-Ticket, Golden Ticket, Silver Ticket, атаки на механизмы делегирования). Часть этих атак может быть обнаружена по метаданным Kerberos-трафика |
|
|
Метаданные SMB / DCE RPC |
Протоколы SMB / DCE RPC служат транспортом для многих сервисных функций ОС Windows. Сбор метаданных этих протоколов позволяет выявить широкий спектр техник постэксплуатации в инфраструктуре Windows:
|
|
|
Метаданные файлов, передаваемых внутри сети по SMB |
Протокол SMB служит транспортом для многих сервисных функций ОС Windows. Наряду с взаимодействием с различными управляющими интерфейсами атакующие могут использовать этот протокол непосредственно для передачи файлов внутри скомпрометированной сети. Наличие метаданных этих файлов позволит выявлять различные аномалии, связанные с активными действиями атакующих в инфраструктуре (например, передача исполняемых файлов между рабочими станциями или файлов-дампов веток реестра Windows) |
|
|
Метаданные электронных писем, сведения о файлах и ссылках, получаемых по электронной почте |
Электронная почта — самый популярный канал доставки вредоносного контента. Этот контент может приходить как в виде вложенных файлов, так и в виде ссылок с предложениями по ним перейти. Наличие источника событий, который предоставляет не только почтовые заголовки, но и сведения о файлах (хеш, тип, размер, в отдельных случаях результаты проверки YARA-правилами) и ссылках из электронных писем с привязкой к метаданным из почтовых заголовков и заголовков письма, дает охотникам за угрозами мощные возможности по выявлению и расследованию инцидентов, где канал электронной почты задействован в качестве первичного вектора проникновения |
|
|
NetFlow |
Данные NetFlow хоть и не самый ценный источник телеметрии для Threat Hunting, но в отдельных случаях все же могут быть полезны. Примеры инцидентов, которые могут быть выявлены с помощью NetFlow:
|
|
Наибольшей результативности Threat Hunting можно достичь, комбинируя хостовую и сетевую телеметрию, обогащая ее данными из различных источников Threat Intelligence. Это обеспечит максимальное покрытие всех стадий возможных атак, однако потребует существенных инвестиций в инфраструктуру, а также в опытных квалифицированных аналитиков, которые справятся с таким разнообразным потоком данных.
Основой вашей платформы Threat Hunting может стать SIEM-система, осуществляющая сбор, нормализацию и корреляцию событий безопасности, а также обеспечивающая быстрый поиск по собранным данным, удобную визуализацию, последующий разбор и реагирование на инциденты.
Однако помните, что потребуется адаптация инструментария со стороны команды охотников за угрозами. В конечном счете лучшие инструменты будут созданы или доработаны вашими людьми. Например, отличная платформа Threat Hunting может быть построена на базе стека ELK (Elasticsearch, Logstash, Kibana). При наличии в команде квалифицированного DevOps-инженера и специалиста, знающего и умеющего разрабатывать pipeline обработки и обогащения событий, вы сможете создать из Open Source очень качественный инструмент для Threat Hunting, ничем не уступающий, а в отдельных случаях и превосходящий коммерческие решения. В интернете можно найти очень много качественных материалов по использованию стека ELK в качестве платформы Threat Hunting, например вот или вот.
Охотники за угрозами используют инструменты и собранную телеметрию для проактивного поиска угроз в инфраструктуре. Однако для получения наилучшего результата и максимальной пользы практики 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. Опытный охотник за угрозами исследует эту технику, определяет телеметрию, необходимую для разработки детектирующего правила, и при помощи инструментов выполняет проактивный поиск следов использования данной техники в защищаемой инфраструктуре.
Наиболее продвинутые охотники за угрозами используют последние два подхода. Рассмотрим на конкретном примере, как это работает.
Начнем с небольшого сценария. Анализ последнего отчета 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).
| 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 |
Использование временного файла с характерным именем, начинающимся 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, далее копирует файл с полезной нагрузкой и создает сервис со случайно сгенерированным именем для запуска этого файла |
|
|
|
Использует механизм именованных каналов для коммуникации с атакуемым хостом |
Создание процессом нетипичного именованного канала (для большинства процессов в целом это аномальная активность) |
|
|
После успешного выполнения команды удаляет сервис и его исполняемый файл |
Удаление исполняемого файла, который до этого запускался в качестве сервиса |
Сигнатура для выявления в сетевом трафике вызова метода 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 |
|
|
|
“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. Помните, что главный элемент, соединяющий все воедино, — это люди. Правильная команда, вооруженная инструментами и необходимой телеметрией, — залог успеха. Удачной вам охоты!