ПРЕДУПРЕЖДЕНИЕ: Статья предназначена для повышения осведомленности о киберугрозах и методах защиты. Все методы и инструменты, упомянутые в статье, должны использоваться только в законных целях, с разрешения владельцев систем и в рамках действующего законодательства РФ.
YARA правила и почему девять из десяти не работают
Я написал своё первое YARA-правило за десять минут. Протестировал на одном образце, сработало, обрадовался. Через три дня коллега показал мне дашборд с 3800 алертами на легитимные файлы. Я думал что правило проверяет размер файла перед поиском строк. Оказалось наоборот. Сначала поиск всех строк по всему файлу, потом проверка условий. Даже если файл 50GB. Все гайды показывают синтаксис и примеры, но никто не объясняет что реально происходит внутри когда YARA обрабатывает правило. Без этого понимания пишешь вслепую и получаешь либо шум либо пропуски.
Что такое YARA и зачем она нужна
YARA это инструмент для поиска определённых паттернов в файлах. Представь, у тебя есть подозрительный файл. Или тысяча файлов. Нужно понять есть ли там вредоносный код. Антивирусы ищут по базам известных угроз. А если угроза новая? Тогда пишешь правило. Если в файле есть вот эти строки в такой-то комбинации, это подозрительно. YARA берёт твоё правило и проверяет файлы. Если нашлось совпадение, тогда выдаёт предупреждение.
Что происходит когда запускаешь правило
Пишем текстовый файл с расширением .yar. Внутри описываете, что искать. Сначала перечислим подозрительные фрагменты, потом задаём условие, при котором правило считается сработавшим. Запускаем команду в терминале. Выглядит так - yara rule.yar sample.exe
Первая часть rule.yar файл с правилом которое я написал.
Вторая часть sample.exe файл который проверяю. Кажется очевидным. YARA прочитает правило, найдёт строки которые указали, проверит условия. Всё по порядку.
На самом деле порядок совсем другой. И из-за непонимания этого большинство правил работают не так как ожидалось. YARA берёт правило и объединяет в автомат. Все строки из секции strings превращаются в структуру для быстрого поиска.
Секция strings часть YARA-правила, где перечисляешь то, что нужно найти в файле. Строки, байты, шестнадцатеричные последовательности. Выглядит так:
```yara
rule Example {
strings:
$a = "malware"
$b = {E8 00 00 00 00}
$c = "http://evil.com" wide
condition:
$a or $b
}
Обычно это алгоритм Aho-Corasick для текста или Boyer-Moore для hex-последовательностей. Секция condition становится набором логических операций. Файл читается один раз. YARA ищет сразу все объявленные строки параллельно, не по очереди. Даже если в condition написано `$s1 and $s2`, поиск переменной $s2 не ждёт пока найдётся $s1. Автомат проверяет обе строки за один проход по файлу.
После сканирования YARA знает про каждую строку. Нашлась или нет, сколько раз, на каких смещениях. Только после этого вычисляется condition. Которая работает с готовыми данными. Она не может повлиять на поиск, поиск уже завершён. Я видел как аналитик пишет:
```yara
condition:
filesize < 1MB and $suspicious_string
И думает, если файл большой, строку искать не будут, это же логично. Нет. Строка ищется в любом случае. Сначала полное сканирование файла на все строки, потом проверка filesize, потом вычисление AND. Если файл 100GB, YARA просканирует его целиком, найдёт все вхождения $suspicious_string, а потом вернёт false потому что filesize не прошёл проверку. Оптимизация работает только снаружи. Не запускать YARA на огромных файлах вообще, делать фильтр до запуска сканера.
Meta существует отдельно от логики детекции
Секция meta это документация. YARA физически не может прочитать её при вычислении condition.
```yara
meta:
confidence = "critical"
priority = 9999
threat_level = "apocalypse_now"
Ноль влияния на срабатывание. Правило сработает или не сработает независимо от того что написано в meta. Meta читают внешние системы вроде SIEM, SOAR, дашбордов, систем корреляции. Они берут эти значения для приоритизации алертов, маршрутизации инцидентов, визуализации. YARA-движок meta игнорирует полностью. Бывали случаи когда аналитик менял confidence с low на high и ждал что правило начнёт лучше детектить. Изменится только то как SIEM обработает алерт, если вообще изменится.
Any of them детектит легитимное ПО
Один написал правило на "powershell" с any of them думал, ловит вредоносные скрипты. Получил алерты на каждый легитимный .ps1 из Windows, на обновления, на скрипты админов. Другой добавил "base64" и привет, тысячи ложняков на зашифрованных конфигах и лицензиях. Суть в том, что any of them самая слабая логика, которую можно придумать.
```yara
strings:
$s1 = "http"
$s2 = "POST"
$s3 = "GET"
condition:
any of them
Аналитик думает, ловлю сетевую активность. На практике срабатывает на каждом втором легитимном файле. Браузеры, обновлялки, антивирусы, мессенджеры, всё что делает HTTP-запросы. False positive rate под 80-90%. Проблема в логике. "Any of" означает достаточно чего угодно из списка. Хотя бы одна строка нашлась, условие истинно. Для детекции слишком слабо. Комбинация работает лучше:
```yara
condition:
2 of them
Но ещё лучше группировать по смыслу:
```yara
strings:
$net_1 = "http://"
$net_2 = "POST"
$cmd_1 = "cmd.exe"
$cmd_2 = "powershell"
condition:
any of ($net_*) and any of ($cmd_*)
Теперь нужна комбинация из разных категорий. Сетевая активность плюс запуск командной оболочки.
Неиспользуемые строки всё равно ищутся
Я часто добавляю в правило лишнюю строку просто для проверки.
```yara
strings:
$s1 = "malware"
$s2 = "virus"
$s3 = "unused_string"
condition:
$s1 and $s2
Переменная $s3 никак не участвует в condition. Казалось бы, можно не искать. YARA ищет все объявленные строки независимо от того используются они или нет. Архитектурное решение. Автомат поиска строится для всех строк сразу, разделение на используемые и неиспользуемые усложнило бы компиляцию. Не объявляйте лишние строки. Каждая строка это вычисления при сканировании.
Memory scan требует других правил чем file scan
Memory scan и file scan работают по-разному. Правило для файла на диске может не работать в памяти процесса.
Cobalt Strike Beacon:
```yara
rule Beacon_File {
strings:
$mz = "MZ"
$loader = "ReflectiveLoader"
condition:
$mz at 0 and $loader
}
Работает если Beacon записан на диск как PE-файл с расширением .exe, .dll, .sys. В памяти MZ-заголовок может отсутствовать. Beacon часто грузится как shellcode, чистый машинный код без структуры файла. ReflectiveLoader удаляется после загрузки. Для memory нужны артефакты которые присутствуют во время работы:
```yara
rule Beacon_Memory {
strings:
$api1 = "VirtualAlloc"
$api2 = "CreateThread"
$sleep = "Sleep"
condition:
all of them
}
API-вызовы остаются в памяти пока процесс живой. Устойчивее для детекции во время выполнения.
SOC запустил YARA-сканер на хостах с файловыми правилами и получил либо тишину либо ложные срабатывания. Правила не адаптированы под memory.
For в YARA это не цикл
Синтаксис выглядит как loop (цикл):
```yara
for any i in (0..filesize) : ( uint8(i) == 0x90 )
Но это квантор существования. Проверяется есть ли хотя бы одна позиция i в диапазоне от 0 до filesize где байт равен 0x90. YARA не проходит каждую позицию последовательно. Она оптимизирует выражение внутренне. Логически это предикат, не цикл.
```yara
for 2 of ($s*) : ( @ < 1024 )
Как минимум две строки из группы $s найдены в первом килобайте файла.
Символ @ это смещение текущего совпадения, позиция в файле где найдена строка.
Regex в десятки раз медленнее строкового поиска
Регулярные выражения кажутся удобными:
```yara
$ip = /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
Один паттерн вместо нескольких строк. Проблема в скорости. Regex-движок медленнее строкового поиска. Для простых паттернов разница 10x-100x. Хуже того, этот regex ловит не только IP-адреса. "Version 255.255.255.255" тоже подходит.
Нужны якоря, проверка диапазонов, ещё больше усложнений. Альтернатива через строки:
```yara
strings:
$ip_1 = "192.168."
$ip_2 = "10.0."
$ip_3 = "172.16."
condition:
any of them
Быстрее и точнее для типичных внутренних подсетей. Regex оправдан только когда паттерн действительно сложный и не выражается фиксированными строками. Закодированный payload с переменной длиной например. Даже тогда попробуйте упростить через несколько обычных строк сначала.
PE-модуль открывает структурный анализ файла
```yara
import "pe"
Файл перестаёт быть последовательностью байт. Становится структурированным объектом. Без модуля доступны filesize и содержимое. С модулем появляются секции PE-файла, импорты, экспорты, timestamp, характеристики, энтропия.
Детекция упакованного малвара:
```yara
import "pe"
import "math"
rule Packed_Entropy {
condition:
pe.is_pe and
pe.number_of_sections > 0 and
for any i in (0..pe.number_of_sections - 1):
(pe.sections[i].characteristics & 0x20000000) and
math.entropy(pe.sections[i].raw_data_offset, pe.sections[i].raw_data_size) > 7.0
}
Если есть исполняемая секция с энтропией выше 7.0, вероятно упаковка или шифрование. Высокая энтропия означает данные близки к случайным. Легитимный код имеет энтропию 5-6, упакованный 7-8.
Анализ свойств файла, не поиск строк.
PE-модуль даёт метаданные которые невозможно получить простым строковым поиском.
Правила устаревают когда атакующие меняют инструменты
Правило 2020 года:
```yara
rule Mimikatz_Old {
strings:
$author = "gentilkiwi"
condition:
$author
}
Работало. Benjamin Delpy, автор Mimikatz, оставлял свой ник в каждом билде. Атакующие компилируют Mimikatz из исходников, убирают строку. Правило уже не работает. Не потому что YARA сломалась. Потому что индикатор непостоянный, легко удаляется без потери функциональности. Устойчивые правила детектят то что нельзя убрать:
```yara
rule Mimikatz_Structural {
strings:
$api1 = "LsaEnumerateLogonSessions"
$api2 = "LsaGetLogonSessionData"
$api3 = "LsaFreeReturnBuffer"
condition:
all of them
}
Эти API необходимы для дампа LSASS, процесса который хранит пароли в Windows. Убрать их значит убрать функциональность.
Чеклист перед загрузкой правила в продакшн
Правило должно сработать на файле который оно должно детектить. Если не срабатывает, либо строки неправильные, либо логика condition.
Прогнать по C:\Windows\System32, /usr/bin, типичным приложениям. Срабатывает? Ложное срабатывание. Ужесточать condition или менять строки.
Если есть несколько версий инструмента, правило должно ловить все или большинство. Ловит только одну сборку? Слишком специфично, умрёт при обновлении.
Правило должно быть ограничено форматом. pe.is_pe для Windows, elf.type для Linux. Без фильтра будет срабатывать на текстовых файлах, логах, конфигах.
Meta не влияет на детекцию, но влияет на обработку алерта. Поля должны соответствовать реальному риску. Через полгода забудете почему выбрали эти строки. Напишите пояснение логики. Многие правила в проде которые срабатывали на calc.exe и notepad.exe. Никто не проверил на легитимных бинарниках перед загрузкой.
Когда YARA бесполезна
YARA хороша для статического сигнатурного анализа, поиска известных паттернов в неактивных файлах. Не подходит для нескольких задач.
Например YARA не видит что файл делает, только что в нём лежит. Для поведения во время выполнения нужен EDR. Работает только по чётким правилам. Не может догадаться что файл подозрительный если не совпадают известные паттерны.
Если каждая копия малвари уникальна, сигнатуры бесполезны. Нужен эмулятор или sandbox.
Весь код упакован или зашифрован и распаковывается только в памяти, file scan ничего не найдёт. Memory scan может помочь, но только после распаковки.
YARA один из инструментов, не универсальное решение. В SOC она работает вместе с EDR, SIEM, sandbox, threat intel. Отдельное YARA-правило обходится. Комплекс мер обойти сложнее.
Wide modifier обязателен для Windows-строк
```yara
$s = "powershell.exe"
В PE-ресурсах Windows использует UTF-16LE. Каждый символ занимает 2 байта. "p" становится 70 00, "o" становится 6F 00. Без wide YARA ищет ASCII. Выглядит так - 70 6F 77 65 72 73 68 65 6C 6C 2E 65 78 65.
Если строка в файле UTF-16, она выглядит как 70 00 6F 00 77 00, ASCII-поиск не найдёт. Правильно:
```yara
$s = "powershell.exe" wide
Или для надёжности:
```yara
$s1 = "powershell.exe" ascii
$s2 = "powershell.exe" wide
condition:
any of them
Правила не срабатывали на Windows-малварь именно из-за отсутствия wide. Формально строка там есть, но в другой кодировке.
Почему YARA называется YARA и при чём тут VirusTotal
Каждый Threat intelligence отчёт о кибератаке заканчивается одинаково. Внизу, после анализа, всегда есть раздел "YARA Rules". Набор строк кода который выглядит примерно так:
rule APT_Malware {
strings:
$s1 = "malicious_string"
condition:
$s1
}
Это язык на котором весь мир описывает малварь. Google использует его в VirusTotal. Антивирусные компании пишут на нём детекторы. Исследователи делятся правилами в отчётах. Но мало кто знает что весь этот стандарт появился потому что один человек устал делать одну и ту же скучную работу.
Парень по имени Виктор Альварес работает аналитиком малвари. Каждый день одно и то же. Открываешь подозрительный файл в hex-редакторе. Смотришь на тысячи строк шестнадцатеричного кода. Ищешь глазами что-то подозрительное. Повторяющиеся последовательности байтов. Странные строки. API-вызовы которых не должно быть. Находишь что-то интересное. Копируешь в блокнот. Открываешь следующий файл. Снова ищешь то же самое вручную.
Пять файлов в день - нормально. Десять - уже устаёшь. А когда приходит новая волна атак и нужно проанализировать сотни образцов, это превращается в ад.
Антивирусы не помогают. Их сигнатуры закрыты, работают как чёрный ящик. ClamAV открытый, но он ищет точные хеши файлов. А малварь постоянно мутирует. Один троян может иметь тысячу модификаций с разными хешами, но один и тот же характерный код внутри.
Альваресу нужен инструмент который ищет не точное совпадение файла, а паттерн внутри. Что-то что остаётся постоянным между версиями.
Он начинает писать сам. Вечерами, после работы. Чистый C, без фреймворков. Парсер для описания правил и движок для быстрого поиска по файлам. Через несколько месяцев работает. Можешь описать что ищешь текстом, запустить - получишь все файлы где это есть.
Нужно название. В IT каждый второй инструмент называется акронимом из трёх букв. GREP, CURL, WGET, JSON, YAML. Альварес называет свой инструмент YARA - Yet Another Ridiculous Acronym. Ещё один нелепый акроним.
Код выкладывается на GitHub. Без пиара, без статей. Просто репозиторий. Несколько человек находят, пробуют, пишут issues.
Альваресу приходит предложение от компании VirusTotal. Это сервис который проверяет файлы сразу всеми антивирусами одновременно. К 2009 году у них миллионы образцов малвари в базе. Проблема - искать можно только по хешу файла. Нужен способ искать похожие образцы по содержимому.
Раньше исследователь находил новый троян, анализировал его, писал отчёт. Всё. Следующий образец анализировался с нуля.
Теперь можно написать YARA-правило с характеристиками трояна и найти все похожие файлы среди миллионов за секунды. Проследить эволюцию малвари. Понять связи между разными атаками. Увидеть тактику группировки.
Антивирусные компании замечают. Kaspersky начинает использовать YARA для классификации. ESET пишет правила для продуктов. FireEye публикует наборы правил для APT-групп. Появляются репозитории - YaraRules с тысячами правил от сообщества, awesome-yara с инструментами.
Google покупает VirusTotal и запускает VirusTotal Intelligence охоту за угрозами по миллиардам файлов. YARA в центре всего. Почему именно YARA стала стандартом, а не альтернативы?
OpenIOC от Mandiant описывает индикаторы в XML - сложно, многословно, нужен парсер чтобы просто прочитать. Sigma делает правила для логов SIEM - совсем другая задача. STIX/TAXII для обмена данными между организациями - протоколы, форматы, интеграции, головная боль.
Как установить YARA на компьютер
Зайди на GitHub в репозиторий VirusTotal/yara и скачай последнюю версию из раздела Releases. На Windows получишь zip-архив с файлами yara.exe и yarac.exe. Распакуй в любую папку и запускай команды оттуда в cmd или PowerShell. На Linux проще всего ввести sudo apt install yara для Ubuntu/Debian или аналогичную команду для твоего дистрибутива. Проверь установку командой yara --version. Первая проверка выглядит так: yara мое_правило.yar подозрительный_файл.exe. Без этой программы ничего дальше не пойдёт.
Как писать правила YARA в удобном редакторе
Лучше всего использовать VS Code бесплатный редактор, который ставят почти все. Скачай его с code.visualstudio.com. В магазине расширений найди YLS от Avast (avast-threatlabs-yara.vscode-yls). После установки он сразу начинает помогать: подсвечивает синтаксис, предлагает автодополнение, показывает ошибки красным и объясняет при наведении мышкой, что значит каждая часть правила. Новичку без него очень тяжело — будешь часами искать пропущенную запятую или забытый wide.
Если хочешь не только писать текст, но и сразу смотреть содержимое файла, возьми Malcat. Скачай с malcat.fr (есть бесплатная версия). Открываешь файл, видишь hex или дизасм, выделяешь кусок байтов — и программа сама делает из него правило YARA. На Windows работает нативно, на Linux — через Wine. Это сильно ускоряет работу, когда разбираешься в сэмпле вручную.
Ещё вариант YaraEditor от Adlice. Скачай на adlice.com/yaraeditor. Пишешь правило, выбираешь папку с файлами, жмёшь тест и сразу видишь, где оно сработало.
Как автоматически создать правило YARA
Чтобы не придумывать всё вручную, используй yarGen-Go от Florian Roth. Скачивается одним файлом, без Python. Даёшь две папки: с подозрительными файлами и с обычными (например, C:\Windows\System32). Программа сравнивает, находит уникальные строки в плохих файлах, отсеивает шум и выдаёт готовое правило. Запуск простой: yarGen-Go -m bad_samples -g good_samples -o правило.yar. Есть режим с подсказками от ИИ.
Как проверить правило YARA на ложные срабатывания
Готовое правило обязательно нужно протестировать, иначе будет много ложных тревог. Запусти yaraQA мое_правило.yar получишь отчёт: где строка слишком общая, где regex замедлит сканирование, где риск ложняков высокий. Я всегда прогоняю через него перед использованием.
Ещё есть онлайн-сервис YaraDbg. Загружаешь правило и файл в браузере — видишь пошагово, где нашёл совпадения и почему условие сработало или нет. Помогает понять, почему правило молчит или срабатывает не там.
Какие сканеры YARA использовать для проверки файлов и компьютера
Самый удобный бесплатный сканер сейчас THOR Lite от Nextron Systems. Скачай после регистрации на nextron-systems.com/thor-lite. Один файл, работает на Windows, Linux и macOS. Сам распаковывает архивы, не грузит процессор, использует правила от сообщества (YARA Forge). Подходит для проверки дисков или станций.
Если не хочешь регистрироваться — возьми Loki-RS от Neo23x0. Один бинарник, многопоточный, сканирует файлы, процессы, память и архивы. Всё свежее.
Для проверки правила на огромном объёме используй VirusTotal. Заходишь на virustotal.com в раздел Intelligence, загружаешь правило. Оно прогоняется по миллиардам файлов. Livehunt следит за новыми совпадениями, Retrohunt ищет по старым. Бесплатно можно не очень много, но для теста одного правила хватает.
С чего начать новичку с YARA
Вот простой порядок действий:
1. Установи YARA core и проверь yara --version.
2. Поставь VS Code и расширение YLS — пиши первое правило там.
3. Напиши простое правило (например, ищи строку http://evil.com).
4. Протестируй командой yara.
5. Скачай yarGen-Go и сгенерируй правило из 3–5 файлов.
6. Проверь в yaraQA.
7. Для сканирования папки или диска возьми THOR Lite или Loki-RS.
8. Прогоняй на VirusTotal для уверенности.
YARA делает одно ищет паттерн в файле. Синтаксис простой, правило пишется за минуту, читается как обычный код. Движок быстрый - алгоритм Aho-Corasick обрабатывает тысячи паттернов параллельно.
#информационнаябезопасность #кибербезопасность #инфобез #киберзащита #безопасностьданных #YARA #threatdetection #SOC #киберугрозы #защита #IT #технологии