Project Ire обнаружила новый вариант LOTUSLITE, не попадающий в сигнатуры

Microsoft Research представила успешный случай использования Project Ire, автономного агента на основе LLM для классификации вредоносных программ через статический анализ, когда сигнатурные методы отказывают.
Образец (SHA-256: 47e51e82229e80a387c3cb100d39d3705e6360bbf9bfa1601dbc484e8d02e653), это новый вариант LOTUSLITE, DLL-бэкдора, описанного ранее компанией Acronis. На момент обнаружения (28 мая) образец не был в листе IOC Acronis и не детектился основными EDR (CrowdStrike Falcon, SentinelOne, Sophos, Trellix, Palo Alto, ESET). Неделю спустя его начали ловить 7 из 70 вендоров на VirusTotal, Microsoft Trojan:Win32/Malgent, Kaspersky HEUR:Trojan-Dropper и другие, но полумеры остаются узнаваемыми по наличию основных признаков.
Project Ire провел анализ за один вызов, используя только инструменты декомпиляции, и вынес вердикт «вредоносный». Агент выстроил полный цепочку доказательств: функция-за-функцией разобрал установочный код (DLL копирует загрузчик EXE и себя в C:\ProgramData\SmartPrint, добавляет себя в Run с параметром, DaDaBar), структуру пакетов C2, команды, механизм персистентности через HKCU, обфускацию и маскировку трафика под Google/Microsoft сервисы. Все детали совпадают с анализом Acronis, хотя имена файлов отличаются (SmartPrintScreen.exe vs SmartPrint.dll вместо названных у Acronis).
Особенность: бинарь содержит в открытом виде строку «BelievemeIamMustang-Panda» (то же имя, что приписал образцу Acronis через анализ инфраструктуры), однако Ire сознательно не строит на этом предположение, fokusируется на поведении. Обнаружены и неправильные срабатывания: функция nf_unRegisterDriver по названию выглядит как работа с ядром, но на самом деле только пишет в реестр Run, Ire отметил это как подозрительное имя, но не добавил в вердикт как доказательство актуального перехвата пакетов.
Ваэитат показывает, что когда сигнатуры и ручные проверки отказывают, поведенческий анализ на основе дизассемблирования ловит варианты по TTPs без попадания в IOC-листы.
Ключевые факты
- Project Ire за один статический анализ выявил вариант LOTUSLITE, который пропустили сигнатуры и основные EDR
- Образец содержит все характерные для семейства поведения: заразитель/DLL-сплит, HTTPS C2 с пользовательским бинарным протоколом, персистентность через Run, маскировка трафика
- Агент корректно обработал противоречивые сигналы (функция с ядерным названием, но в реестре) и не добавил их в вердикт без подтверждения фактического поведения
- LLM-агент не нуждался в метаданных происхождения, телеметрии или подсказках аналитика, работал вслепую на основе дизассемблирования
- Строковое имя актора в бинаре может служить противоборствующим входом для LLM, смещая вердикт, поэтому нужна критическая оценка
Почему это важно
Сигнатурные методы обнаружения вредоноса полагаются на известные IoC (хэши, строки, сетевые индикаторы). Варианты, которые изменяют эти поверхностные признаки, но сохраняют то же поведение, проскальзывают мимо защиты. Поведенческий анализ на уровне дизассемблирования, особенно если его проводит LLM-агент без человеческих предубеждений, способен выловить такие варианты и достичь вердикта без опоры на IOC. Это расширяет палитру обнаружения угроз за пределы сигнатур.
Кому это важно
Защитникам, вендорам EDR/SIEM, аналитикам угроз, которые сталкиваются с новыми вариантами известных семейств; разработчикам инструментов анализа вредоноса; исследователям в области безопасности, интересующимся применением LLM для обратного инжиниринга. Также актуально для организаций, полагающихся на сигнатурные системы и ищущих дополнительные слои защиты.
Как это применить
Project Ire, исследовательский инструмент Microsoft Research, открытый на Github, но, похоже, не является коммерческим EDR. Однако подход может быть адаптирован в существующие системы анализа: добавить в pipeline статический дизассемблирование + поведенческую классификацию через LLM для неопознанных образцов, особенно для вариантов известных семейств. Для лучшей точности следует избегать чрезмерной полноты на строках и метаданных, а сфокусироваться на функциональном поведении (структуры данных, адреса, системные вызовы).
Можно ли доверять
Исследование проведено крупной компанией (Microsoft Research), опубликовано с полной цепочкой доказательств, исходными образцами (хэш на VirusTotal) и полным отчётом Ire на Github. Анализ согласуется с независимым анализом Acronis Threat Research Unit. Однако автор сам отмечает риски LLM-подхода: строки и имена функций могут стать противоборствующими входами и смещать вердикт. Обнаруженное имя актора в бинаре не трактуется как прямое доказательство авторства, верно, что это может быть артефактом, трофеем или деаболической посадкой. Выводы о семействе обоснованы, вердикт вредоноса, справедлив.
Риски и подводные камни
LLM-агент может быть введён в ошибку функциями с потенциально ядерными названиями (nf_unRegisterDriver выглядит как работа с драйверами, но это не так); нужна двойная проверка цепочки логики. Строки в бинаре, особенно имена акторов, могут быть специально внедрены или быть артефактами разработки, не полагаться на них как на доказательство. Само по себе поведенческое совпадение с известным семейством ещё не даёт всей картины TTPs, если нет доступа к инфраструктуре или телеметрии. Project Ire, проектный прототип, а не боевой инструмент; масштабируемость и надёжность в high-volume окружении пока не демонстрировались.
«Ire статически выполняет обратный инжиниринг бинарников и идентифицирует поведение от уровня функции до системного, чтобы описать, что именно делает ПО, и вынести вердикт. Ire никогда не назвала LOTUSLITE в своём отчёте или цепочке доказательств. Сопоставление с семейством, уже наше, после факта, когда мы сравнили отчёт Ire с отчётом Acronis.»
— Microsoft Research