Показатели компрометации как средство снижения рисков

Владельцам IT-инфраструктур необходимо регулярно проверять свои ресурсы на наличие вредоносных компонентов. Заражение может произойти, например, в результате эксплуатации злоумышленниками уязвимостей «нулевого дня». В таких случаях о новой угрозе еще могут не знать разработчики средств защиты, установленных в информационной системе. В то же время эксперты уже могут вести расследования связанных с новой угрозой инцидентов. Более того, могут быть опубликованы некоторые результаты этих расследований.

Такие отчеты имеют практическую ценность. Типичный отчет об 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

Icefog OpenIOC Release

Darkhotel Indicators of Compromise (PDF)

Crouching Yeti — Appendixes (PDF)