Владельцам IT-инфраструктур необходимо регулярно проверять свои ресурсы на наличие вредоносных компонентов. Заражение может произойти, например, в результате эксплуатации злоумышленниками уязвимостей «нулевого дня». В таких случаях о новой угрозе еще могут не знать разработчики средств защиты, установленных в информационной системе. В то же время эксперты уже могут вести расследования связанных с новой угрозой инцидентов. Более того, могут быть опубликованы некоторые результаты этих расследований.
Материал подготовлен специально для Securelist
Такие отчеты имеют практическую ценность. Типичный отчет об APT-кампании содержит следующую информацию:
- Жертвы атаки и цели, которые преследуют злоумышленники
- Перечень узлов (IP-адреса) жертв
- Текущая активность вредоносных компонентов и/или киберпреступных групп
- Детальное описание инструментов и вредоносных компонент, которые используют злоумышленники
- Описания инфраструктуры командных центров (C&C)
- Показатели компрометации
Среди детальной технической информации о той или иной APT для администратора безопасности информационной системы наибольший практический интерес представляют «показатели компрометации». Это набор данных, который может помочь администратору ИТ-инфраструктуры обнаружить вредоносную активность в системе и принять соответствующие меры.
Как администраторам информационных систем на практике использовать эти показатели? В рамках данного материала мы попытаемся дать ответ на этот вопрос.
Показатель компрометации – это структурированная информация о признаках вредоносной активности, предназначенная для импорта в автоматизированные средства проверки инфраструктуры на наличие признаков заражения. Унифицированный формат описания данных индикаторов по-прежнему не разработан, однако в индустрии широкое распространение и поддержку получили несколько типов структурированных данных.
IOC
IOC (indicator of compromise) – перечень данных об угрозах (например, строки, описывающие путь к файлам или ключи реестра), который дает возможность, используя автоматизированный анализ программными средствами, выявить наличие угрозы в инфраструктуре.
Простые сценарии использования IOC подразумевают поиск специфичных файлов в системе по различным признакам: MD5-хэш, имя файла, дата создания, размер и прочие атрибуты. Кроме того, можно искать различные признаки в памяти или специфичные записи в реестре операционной системы Windows.
Существуют различные форматы представления этих данных, например, OpenIOC. Эти форматы позволяют импортировать данные в то или иное защитное решение для последующей работы с индикаторами. Администратор может осуществить интеграцию IOC, взятых из отчетов, в различные защитные решения:
- Средства защиты класса «Endpoint Security»
- SIEM
- IDS/IPS
- HIDS/HIPS
- Различные инструменты для расследования инцидентов
Существует множество коммерческих решений для работы с IOC, однако в ряде случаев достаточно возможностей их «опенсорсных» аналогов для проверки целевой системы на наличие признаков заражения. Например, Loki – IOC сканер, распространяющийся по лицензии GPL, который позволяет осуществлять поиск в целевой системе различных признаков, появившихся в результате вредоносной активности.
Для проверки системы с помощью сканера Loki достаточно распаковать архив с утилитой и добавить нужные IOC-атрибуты в базу знаний сканера. В папке приложения «signature» находятся следующие категории IOC:
- «filename-iocs» – текстовый файл, в котором содержатся списки различных атрибутов файловой системы, которые являются результатом активности той или иной угрозы;
- «hash-iocs» – перечень MD5, SHA1 и SHA256 хэшей вредоносных компонентов, которые присутствуют в системе после ее заражения;
- «falsepositive-hashes» – список исключений MD5, SHA1 и SHA256 хэшей, которые при детекте соответствующих компонентов помечаются сканером как «ложное срабатывание».
В качестве примера возьмем наш отчет об исследовании APT Carbanak. На странице 36 данного отчета содержится перечень MD5-хэшей всех вредоносных компонентов, которые могут оказаться в системе после ее заражения. Откроем файл «hash-iocs» сканера и внесем соответствующее правило в следующем формате: <MD5>;<description> .
Перечень MD5-хэшей компонентов Carbanak APT в файле «hash-iocs» сканера Loki
Затем в текстовом файле «filename-iocs», описывающем атрибуты вредоносных компонентов в файловой системе, создадим индикатор в формате:
# COMMENT
# REGULAREXPRESSION;SCORE
IOC для файловой системы в перечне «filename-iocs» сканера Loki
После внесение нужных индикаторов в базу знаний сканера можно приступить к началу сканирования рабочей станции. Для этого необходимо запустить исполняемый файл «loki.exe» с правами администратора (в противном случае у сканера не будет возможности осуществить проверку содержимого оперативной памяти на наличие атрибутов) и дождаться завершения процедуры.
Процесс сканирования утилитой Loki
По результатам сканирования приложение составит отчет, который будет находиться в каталоге с программой и называться «loki.txt».
YARA rules
Помимо различных IOC индикаторов к отчетам могут прилагаться файлы с расширением «.yar». В данных файлах содержатся составленные согласно специальному синтаксису правила для YARA – инструмента, предназначенного для идентификации и классификации вредоносных образцов. Так называемые YARA-rules описывают признаки наличия вредоносной активности в системе. В том случае, если выполняется одно из правил, анализатор выносит вердикт о заражении с соответствующими подробностями (например, название угрозы).
Вышеописанный сканер Loki также поддерживает YARA-правила, а значит, взятые из отчетов yar-файлы могут послужить администратору для проверки системы на наличие угрозы, о которой рассказывается в отчете. Для этого достаточно переместить yar-файл в папку «signature» и запустить проверку.
Однако, для работы с YARA-правилами куда лучше подходит официальный инструмент от создателей проекта YARA, так как его база знаний регулярно пополняется, и она куда больше, чем базы аналогичных утилит. Это позволяет в результате сканирования получить более полную картину защищенности информационной системы и более полную информацию о наличии в ней тех или иных вредоносных компонентов.
Для проверки на рабочей станции достаточно запустить утилиту YARA с нужными параметрами. Например:
yara32.exe –d md5= <MD5_hash><this_is_yara_rule.yar><dir_for_check>
где параметр «-d» используется для определения внешних переменных. При наличии каких-либо соответствий условиям правила утилита выведет уведомление с названиями правила и компонент, на котором оно сработало.
Пример уведомления о сработавшем правиле YARA
Администратор может осуществлять запуск подобных проверок, например, при загрузке системы. Для этого достаточно написать простой PowerShell-скрипт, который будет запускать утилиты с нужными параметрами и, если потребуется, назначить его запуск для всех хостов при помощи Active Directory: User configuration -> Windows configuration -> Scenarios ->Logon.
STIX и JSON
Structured Threat Information Expression (STIX) – унифицированный язык для структурированной записи информации об угрозах и последующего импорта в программные решения. Множество защитных решений позволяют импортировать информацию, описанную в формате STIX (а также JSON, о котором рассказано ниже) для ее последующего использования в инфраструктуре:
- SIEM
- Защитные решения, основанные на индикаторах (например, сканеры)
- Forensic-платформы
- Решения класса «Endpoint Security» и прочее
Импорт STIX-отчета можно осуществить в популярное SIEM-решение IBM QRadar, используя специально подготовленный Python-скрипт:
./stix_import.py -f STIXDocument.xml -i 192.168.56.2 -t XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -r MyReferenceSet
Где «-f» определяет расположение локального STIX-документа, «-i» определяет хост с установленной QRadar-консолью, «-t» задает сервис-токен для QRadar.
Кроме того, отчеты в формате STIX поддерживаются системой сбора и анализа информации «Splunk App for Enterprise Security«. Файл STIX-отчет должен быть в формате XML и иметь соответствующее расширение .xml.
Более того, существует конвертер «OpenIOC to STIX» – Python-утилита, которая конвертирует OpenIOC-отчеты в отчеты STIX. Это позволяет импортировать индикаторы STIX в решения, которые не поддерживают формат OpenIOC.
JSON – один из наиболее популярных форматов представления данных, который также часто используется в приложениях к отчетам. Применение данных в формате JSON зависит от задач администратора и особенностей программного решения, в которое осуществляется импорт этих данных. Так, например, в случае наличия в JSON-файле IP-адресов командных центров, к которым подключаются зараженные рабочие станции, администратор защищаемой инфраструктуры может внести эти IP-адреса в черный список своего файервола, поддерживающего импорт JSON. В случае если средство межсетевого экранирование не поддерживает импорт в данном формате, то у администратора есть возможность воспользоваться каким-либо парсером (обработчиком JSON-файлов) для экспорта списка IP-адресов из файла и их последующего импорта в черный список файервола.
Готовь их правильно
«Индикаторы заражения» используются для эффективного применения данных об угрозах: выявления вредоносного ПО и оперативного реагирования на инциденты. При этом данные индикаторы очень часто прилагаются к отчетам об угрозах, которые многие читают «по диагонали». Даже в том случае, если документ очередного исследования не содержит специального раздела «Indicators of Compromise», полезные данные (информация о признаках, которые появляются в зараженной системе) всегда можно выделить из текста отчета самостоятельно, оформить в любом из вышеописанных форматах и импортировать в защитное решение.
Наши последние исследования с показателями компрометации:
Wild Neutron – Economic espionage threat actor returns with new tricks
The Mystery of Duqu 2.0: a sophisticated cyberespionage actor returns
The Great Bank Robbery: the Carbanak APT
Darkhotel Indicators of Compromise (PDF)
Crouching Yeti — Appendixes (PDF)
