Yara rules что это
Catena scientiarum
Yara — это и инструмент, и формат представления индикаторов компрометации (IOC), предназначенный для идентификации и классификации вредоносных программ. Он был создан Виктором Альварезом (Victor M. Alvarez) из VirusTotal для организации и распространения информации среди аналитиков.
Далее показан пример файла Yara для Linux-руткита Umbreon:
Документ разделен на три части.
— Раздел «мета» содержит информацию об IOC, такую как имя автора, время создания или ссылка на подробную документацию.
— Раздел «строк» содержит три строки — одну в шестнадцатеричном формате и две в формате ASCII, которые идентифицируют руткит.
— В разделе «условий» к исследуемым файлам применяется фильтр, чтобы найти соответствующие особым критериям. В этом примере сначала производится поиск по заголовку файла, который соответствует формату ELF (uint32(0) == 0x464c457f), а затем поиск общедоступного выходного файла (uint8(16) == 0x0003) типа ELF. Если для обоих условий найдены соответствия, Yara станет искать строки, указанные ранее. Если все они будут присутствовать в файле, то это будет расцениваться как обнаружение руткита.
Консольный инструмент Yara способен сканировать целые системы на наличие файлов, которые соответствуют сигнатурам вредоносных файлов, применив команду:
Проект правил Yara собирает IOC, выявленные аналитиками безопасности во время расследований, и делает их широкодоступными. Yara сосредоточен на файловых IOC [1].
Про написание сигнатур тут и тут.
Источники литературы:
— «Безопасный DevOps. Эффективная эксплуатация систем» (2020)
— Васильева И.Н. Расследование инцидентов информационной безопасности : учебное пособие / И.Н. Васильева. — СПб. : Изд-во СПбГЭУ, 2019. — 113 с. [PDF]
Показатели компрометации как средство снижения рисков
Владельцам IT-инфраструктур необходимо регулярно проверять свои ресурсы на наличие вредоносных компонентов. Заражение может произойти, например, в результате эксплуатации злоумышленниками уязвимостей «нулевого дня». В таких случаях о новой угрозе еще могут не знать разработчики средств защиты, установленных в информационной системе. В то же время эксперты уже могут вести расследования связанных с новой угрозой инцидентов. Более того, могут быть опубликованы некоторые результаты этих расследований.
Материал подготовлен специально для Securelist
Такие отчеты имеют практическую ценность. Типичный отчет об APT-кампании содержит следующую информацию:
Среди детальной технической информации о той или иной APT для администратора безопасности информационной системы наибольший практический интерес представляют «показатели компрометации». Это набор данных, который может помочь администратору ИТ-инфраструктуры обнаружить вредоносную активность в системе и принять соответствующие меры.
Как администраторам информационных систем на практике использовать эти показатели? В рамках данного материала мы попытаемся дать ответ на этот вопрос.
Показатель компрометации – это структурированная информация о признаках вредоносной активности, предназначенная для импорта в автоматизированные средства проверки инфраструктуры на наличие признаков заражения. Унифицированный формат описания данных индикаторов по-прежнему не разработан, однако в индустрии широкое распространение и поддержку получили несколько типов структурированных данных.
IOC (indicator of compromise) – перечень данных об угрозах (например, строки, описывающие путь к файлам или ключи реестра), который дает возможность, используя автоматизированный анализ программными средствами, выявить наличие угрозы в инфраструктуре.
Простые сценарии использования IOC подразумевают поиск специфичных файлов в системе по различным признакам: MD5-хэш, имя файла, дата создания, размер и прочие атрибуты. Кроме того, можно искать различные признаки в памяти или специфичные записи в реестре операционной системы Windows.
Существуют различные форматы представления этих данных, например, OpenIOC. Эти форматы позволяют импортировать данные в то или иное защитное решение для последующей работы с индикаторами. Администратор может осуществить интеграцию IOC, взятых из отчетов, в различные защитные решения:
Существует множество коммерческих решений для работы с IOC, однако в ряде случаев достаточно возможностей их «опенсорсных» аналогов для проверки целевой системы на наличие признаков заражения. Например, Loki – IOC сканер, распространяющийся по лицензии GPL, который позволяет осуществлять поиск в целевой системе различных признаков, появившихся в результате вредоносной активности.
Для проверки системы с помощью сканера Loki достаточно распаковать архив с утилитой и добавить нужные IOC-атрибуты в базу знаний сканера. В папке приложения «signature» находятся следующие категории IOC:
Перечень MD5-хэшей компонентов Carbanak APT в файле «hash-iocs» сканера Loki
Затем в текстовом файле «filename-iocs», описывающем атрибуты вредоносных компонентов в файловой системе, создадим индикатор в формате:
IOC для файловой системы в перечне «filename-iocs» сканера Loki
После внесение нужных индикаторов в базу знаний сканера можно приступить к началу сканирования рабочей станции. Для этого необходимо запустить исполняемый файл «loki.exe» с правами администратора (в противном случае у сканера не будет возможности осуществить проверку содержимого оперативной памяти на наличие атрибутов) и дождаться завершения процедуры.
Процесс сканирования утилитой Loki
По результатам сканирования приложение составит отчет, который будет находиться в каталоге с программой и называться «loki.txt».
YARA rules
Помимо различных IOC индикаторов к отчетам могут прилагаться файлы с расширением «.yar». В данных файлах содержатся составленные согласно специальному синтаксису правила для YARA – инструмента, предназначенного для идентификации и классификации вредоносных образцов. Так называемые YARA-rules описывают признаки наличия вредоносной активности в системе. В том случае, если выполняется одно из правил, анализатор выносит вердикт о заражении с соответствующими подробностями (например, название угрозы).
Вышеописанный сканер Loki также поддерживает YARA-правила, а значит, взятые из отчетов yar-файлы могут послужить администратору для проверки системы на наличие угрозы, о которой рассказывается в отчете. Для этого достаточно переместить yar-файл в папку «signature» и запустить проверку.
Однако, для работы с YARA-правилами куда лучше подходит официальный инструмент от создателей проекта YARA, так как его база знаний регулярно пополняется, и она куда больше, чем базы аналогичных утилит. Это позволяет в результате сканирования получить более полную картину защищенности информационной системы и более полную информацию о наличии в ней тех или иных вредоносных компонентов.
Для проверки на рабочей станции достаточно запустить утилиту YARA с нужными параметрами. Например:
где параметр «-d» используется для определения внешних переменных. При наличии каких-либо соответствий условиям правила утилита выведет уведомление с названиями правила и компонент, на котором оно сработало.
Пример уведомления о сработавшем правиле YARA
STIX и JSON
Structured Threat Information Expression (STIX) – унифицированный язык для структурированной записи информации об угрозах и последующего импорта в программные решения. Множество защитных решений позволяют импортировать информацию, описанную в формате STIX (а также JSON, о котором рассказано ниже) для ее последующего использования в инфраструктуре:
Импорт STIX-отчета можно осуществить в популярное SIEM-решение IBM QRadar, используя специально подготовленный Python-скрипт :
Где «-f» определяет расположение локального STIX-документа, «-i» определяет хост с установленной QRadar-консолью, «-t» задает сервис-токен для QRadar.
Более того, существует конвертер « OpenIOC to STIX » – Python-утилита, которая конвертирует OpenIOC-отчеты в отчеты STIX. Это позволяет импортировать индикаторы STIX в решения, которые не поддерживают формат OpenIOC.
JSON – один из наиболее популярных форматов представления данных, который также часто используется в приложениях к отчетам. Применение данных в формате JSON зависит от задач администратора и особенностей программного решения, в которое осуществляется импорт этих данных. Так, например, в случае наличия в JSON-файле IP-адресов командных центров, к которым подключаются зараженные рабочие станции, администратор защищаемой инфраструктуры может внести эти IP-адреса в черный список своего файервола, поддерживающего импорт JSON. В случае если средство межсетевого экранирование не поддерживает импорт в данном формате, то у администратора есть возможность воспользоваться каким-либо парсером (обработчиком JSON-файлов) для экспорта списка IP-адресов из файла и их последующего импорта в черный список файервола.
Готовь их правильно
«Индикаторы заражения» используются для эффективного применения данных об угрозах: выявления вредоносного ПО и оперативного реагирования на инциденты. При этом данные индикаторы очень часто прилагаются к отчетам об угрозах, которые многие читают «по диагонали». Даже в том случае, если документ очередного исследования не содержит специального раздела «Indicators of Compromise», полезные данные (информация о признаках, которые появляются в зараженной системе) всегда можно выделить из текста отчета самостоятельно, оформить в любом из вышеописанных форматах и импортировать в защитное решение.
Наши последние исследования с показателями компрометации:
Yara. Пишем правила, чтобы искать малварь и не только
Содержание статьи
В нашей прошлой статье («Хеш четкий и хеш нечеткий») мы рассказали, как загружали заранее классифицированные объекты и при этом полностью уповали на знания рандомных аналитиков и верили (конечно, не до конца!), что там действительно находится малварь конкретного семейства. Такое часто происходит в реальном мире, вредоносное ПО настолько быстро появляется, что информацию о том, как идентифицировать угрозу и быстро реализовать правило детектирования, порой бывает почти что вопросом жизни или смерти.
YARA — это опенсорсный инструмент, который помогает исследователям искать и классифицировать вредоносные семплы и даже проводить Threat Hunting. Утилита выполняет сигнатурный анализ на основе формальных YARA-описаний (правил). В них содержатся индикаторы компрометации для разных типов вредоносного ПО.
Фишка в том, что делать правила легко и не занимает много времени. Именно поэтому YARA используют в AlienVault, Avast, ESET, FireEye, Group-IB, Kaspersky, Trend Micro, Virus Total, x64dbg. В общем, почти все, кто имеет дело с анализом вредоносного ПО.
YARA-правила могут обрабатывать не только исполняемые файлы, но и документы, библиотеки, драйверы — все что угодно. Ими же можно сканировать сетевой трафик, хранилища данных, дампы памяти. Эти правила можно включать в другие инструменты, такие как SIEM, антифишинг, IDS, песочницы.
Давай разберемся, как же выглядят эти правила и как их составлять.
Структура правил
Применяем YARA
Минимально необходимые секции — это название правила и его условия. Например, правилом ниже мы будем детектировать объекты только по их imphash (на тестовых объектах из предыдущей статьи):
Сохраним файл как AT. yar и запустим на директории с семплами Agent Tesla. Посмотрим на результат и убедимся, что правило отработало на всех представителях Agent Tesla.
Результат — все из всех.
Как ты мог заметить, правила YARA поддерживают импорт полезных модулей. Соответственно, можно написать свои модули. Вот несколько наиболее часто используемых:
Полный список ты всегда можешь глянуть в официальной документации по YARA.
Пишем правила
В опциональной секции определений можно юзать маски (wildcard, подобия регулярных выражений). Например, для шестнадцатеричных строк возможны такие маски:
Рассмотрим еще один пример с несколькими правилами и продемонстрируем тебе разнообразие возможностей детектирования YARA:
Заставь малварь играть по правилам. Колонка Дениса Макрушина
Содержание статьи
Пока ты читаешь эти строки, в периметре какой-то организации происходит инцидент: вредоносное ПО под тщательным руководством киберпреступников ведет охоту за ценными данными жертвы — за информацией, утечка которой может спровоцировать крупную финансовую катастрофу или поставить под вопрос существование бизнеса.
Зачастую такие спецоперации могут длиться годами, и жертва может даже не догадываться о присутствии постороннего в ее собственной ИТ-инфраструктуре. Однако самое печальное, что о существовании, целях и средствах злоумышленников могут уже знать эксперты, которые пристально следят за активностью киберпреступных групп и развитием их инструментов и, кроме того, участвуют в расследовании аналогичных инцидентов, где использовались подобные средства. Более того, уже могут быть опубликованы материалы исследований инструментов, обнаруженных при проведении той или иной APT-атаки, и в этих материалах, кроме текста о том, как исследователь копался в исходном коде малвари, зачастую может содержаться куда более ценная информация, которая окажется полезной для «харденинга» IT-инфраструктуры.
Когда не успевают патчи
Carbanak. Как много это слово значит для администратора IT-инфраструктуры и ИБ банков. APT-кампания, о которой мы писали ранее, позволила киберпреступникам провернуть кражу в размере, по предварительным оценкам, приближающемуся к миллиарду долларов.
Помимо масштаба украденного, на фоне других угроз эта APT выделяется техниками, которые злоумышленники использовали для изучения своих жертв и закрепления в их инфраструктурах. Киберпреступники проводили разведку в ручном режиме, пытаясь взломать нужные компьютеры (например, компьютеры администраторов) и применяя инструменты, обеспечивающие дальнейшее заражение компьютеров в сети. При этом параллельно эксперты антивирусных компаний расследовали инциденты, за которыми стояли участники преступной группы Carbanak, и поспешно уведомляли жертв, у которых был обнаружены вредоносные компоненты.
Впоследствии по результатам расследования был опубликован отчет, в котором, помимо прочей информации, содержались так называемые индикаторы компрометации. Данные индикаторы предназначены для того, чтобы любой желающий при помощи специализированных инструментов смог проверить наличие вредоносных компонентов Carbanak в своей инфраструктуре и принять соответствующие меры для повышения ее защищенности. Однако приложения, в которых публикуется данная информация, очень часто остаются без нужного внимания, потому что читатель попросту не знает, что делать с различными IOC, YARA rules и прочими структурами данных, представленных в подобных отчетах.
Оперативная информация как средство снижения рисков
Владельцам IT-инфраструктур необходимо регулярно проверять свои информационные ресурсы на наличие в них вредоносных компонентов, которые могут оказаться там, например, в результате эксплуатации злоумышленниками уязвимостей нулевого дня. Но что, если о существовании подобных компонентов еще не знают даже разработчики средств защиты, установленных в информационной системе? При этом в распоряжении ее владельца оказывается экспертная информация — приватный отчет о расследовании той или иной угрозы или уже опубликованное исследование какой-либо APT.
Типичный отчет содержит приблизительно следующую информацию об APT-кампании:
Среди технической информации о деталях проведения той или иной APT-кампании для администратора безопасности информационной системы наибольший практический интерес представляют «показатели компрометации». Данная структурированная информация предназначена для импорта в автоматизированные средства проверки инфраструктуры на наличие признаков заражения.
Показатели компрометации
Показатель компрометации (indicator of compromise, IOC) — это артефакт, который при помощи специальных утилит позволяет определить факт заражения и может находиться как на конкретном узле сети, так и в сетевом трафике. Унифицированный формат описания данных индикаторов по-прежнему остается открытым вопросом, однако в индустрии широкое распространение и поддержку получили несколько типов структурированных данных.
IOC — данные для записи, определения и распространения информации об угрозах, позволяющие определить ее наличие в инфраструктуре посредством автоматизированного анализа программными средствами.
Простые сценарии использования подразумевают поиск специфичных файлов в системе по различным признакам: MD5-хешу, имени файла, дате создания, размеру и прочим атрибутам. Кроме того, можно искать различные специфичные признаки в памяти или специфичные записи в реестре операционной системы Windows.
Администратор также может интегрировать IOC, взятые из отчетов, в различные защитные решения:
Инструменты для расследования инцидентов
Существует множество коммерческих решений для работы с IOC, однако в ряде случаев достаточно возможностей их «опенсорсных» аналогов для проверки целевой системы на наличие признаков заражения. Например, Loki — IOC-сканер, распространяющийся по лицензии GPL, который позволяет искать в целевой системе различные артефакты в результате вредоносной активности.
Для проверки системы достаточно распаковать архив с утилитой и добавить нужные IOC-атрибуты. В папке приложения signature находятся следующие категории IOC:
Перечень MD5-хешей компонентов Carbanak APT в файле hash-iocs сканера Loki
Xakep #200. Тайная жизнь Windows 10
IOC для файловой системы в перечне filename-iocs сканера Loki
После внесения нужных индикаторов в базу знаний сканера можно приступить к сканированию. Для этого необходимо запустить исполняемый файл loki.exe с правами администратора (в противном случае у сканера не будет возможности проверить содержимое оперативной памяти на наличие атрибутов) и дождаться завершения процедуры.
Процесс сканирования утилитой Loki
Yara rules
Помимо IOC-индикаторов, к отчетам могут прилагаться файлы с расширением yar. В них содержатся правила, составленные согласно специальному синтаксису, для YARA — инструмента, предназначенного для идентификации и классификации вредоносных семплов. Так называемые YARA rules описывают признаки наличия малвари. В том случае, если выполняется одно из правил, анализатор выносит вердикт о заражении и конкретных экземплярах вредоносного ПО.
Сканер Loki также поддерживает YARA-правила, а значит, взятые из отчетов yar-файлы могут стать хорошим поводом для проверки своей системы на наличие угрозы, упомянутой в отчете. Для этого достаточно переместить yar-файл в папку signature и запустить проверку. Однако для работы с YARA-правилами куда лучше подходит официальный инструмент от создателей проекта YARA, так как его база знаний регулярно пополняется и она куда больше, чем базы аналогичных утилит, что позволяет в результате сканирования получить более полную картину защищенности инфраструктуры.
Для проверки наличия тех или иных вредоносных компонентов в инфраструктуре на рабочей станции достаточно запустить утилиту YARA с нужными параметрами. Например:
Пример сработавшего правила YARA
STIX/JSON
Structured Threat Information Expression (STIX) — унифицированный язык для структурированной записи информации об угрозах. STIX разработан для эффективного применения данных об угрозах и используется для задач анализа вредоносного ПО, составления индикаторов, оперативного реагирования на инциденты и публикации информации об угрозах.
Огромное количество защитных решений поддерживают правила STIX и JSON для развертывания их в инфраструктуре, в их числе:
STIX-отчета можно импортировать в популярное SIEM-решение IBM QRadar, используя специально подготовленный Python-скрипт:
JSON — один из наиболее популярных форматов представления данных, который также часто прилагается к отчетам. Применение данных в формате JSON зависит от задач администратора и особенностей программного решения, в которое импортируются эти данные. Например, если есть IP-адреса командных центров, к которым подключаются зараженные рабочие станции, администратору защищаемой инфраструктуры имеет смысл внести эти IP-адреса в черный список своего файрвола.
Кто владеет информацией, тот.
Данный материал должен еще раз напомнить (а для кого-то и открыть) читателям нашего ресурса тот факт, что отчеты об исследовании той или иной угрозы несут в себе куда больше полезной информации, чем может показаться на первый взгляд. Они должны быть полезны не только для администратора, который вынужден постоянно искать актуальную информацию об угрозах, но и для защищаемой им инфраструктуры, которая должна оперативно реагировать на появление новых угроз. Ведь, в конце концов, кто владеет информацией, тот снижает риски быть взломанным.
Вопрос для Дениса
Вышла десятая винда. Насколько объективно опасно сейчас сидеть под Windows XP, если учесть, что я не сижу под админом и у меня стоит Google Chrome и адекватный продукт класса Internet Security? Интересно неангажированное мнение Дениса Макрушина 🙂
Система больше не поддерживается разработчиком (только, возможно, в рамках индивидуальных контрактов), а это значит, что 0day-уязвимости останутся там навсегда — никто не будет их патчить. И здесь не поможет Google Chrome, потому что рейтинги по количеству «зиродеев» возглавляют другие, не менее популярные продукты (привет, Adobe!). В данном случае тебя действительно может спасти хороший продукт класса Internet Security, где имеются технологии защиты от эксплоитов или Default Deny технологии, которые не дадут заразе запуститься даже в случае, если она окажется на рабочей станции (например, попадет через USB-носитель).
В качестве конкретного примера возьмем drive-by атаки и какой-нибудь зловред семейства вымогателей (Trojan-Ransom), которые часто распространяются злодеями посредством 100500-day сплоитов к прикладному ПО. Если сплоит к PDF, то Chrome не даст злодеям загрузить троянца по той причине, что все PDF-доки по умолчанию этот браузер запускает в собственной читалке, которая, в свою очередь, находится в песочнице браузера. В том случае, если сплоит, например, к Flash, то антивирусный продукт с активной технологией защиты от эксплоитов определит подозрительное поведение. Это значит, что drive-by в данном случае не сработает.
Однако если этот троянец попадет на рабочую станцию посредством MitM-атаки (злодей подменит скачиваемый жертвой бинарь), то велика вероятность его успешного запуска. В случае с шифровальщиком толковый антивирус заметит подозрительную активность (операции открытия файлов с популярными у шифровальщика расширениями на запись и изменения его структуры требуют предварительного бэкапа) и не даст зловреду выполнить свою функцию. Однако в случае со сложным шпионским ПО ситуация может быть совершенно другая.
Тем не менее ни один разработчик средства защиты никогда не даст стопроцентной гарантии защищенности пользователя (0day в защитных продуктах и недостатки их конфигурации никто не отменял, и, кроме того, не только drive-by атаки служат средством доставки малвари), тем более пользователя, который сам делает все для того, чтобы малварь оказалась на компьютере. Именно поэтому регулярно обновляй стороннее ПО, которое используешь, обновляй базы антивирусного продукта, настрой файрвол, меняй пароли и будь параноиком.
Денис Макрушин
Специализируется на исследовании угроз и разработке технологий защиты от целевых атак. #InspiredByInsecure