Появился Remus - 64-битный наследник печально известного Lumma Stealer

Индустрия вредоносного ПО редко стоит на месте, особенно когда речь идёт о высокодоходных программах-сборщиках данных. После масштабного скандала с досье на предполагаемых создателей одного из самых опасных сборщиков, Lumma Stealer, многие эксперты предсказывали ребрендинг или раскол в команде разработчиков. Прогнозы оправдались: исследователи Gen Threat Labs обнаружили новую угрозу, получившую название Remus, которая представляет собой 64-битную эволюцию печально известной семьи Lumma.

Описание

Первые кампании с использованием Remus датируются февралём 2026 года, что хронологически следует за активной фазированной утечкой персональных данных ключевых фигур, связанных с Lumma, в период с конца августа по октябрь 2025 года. Этот новый вариант не просто заимствует функциональность предшественника, но и демонстрирует прямую генетическую связь на уровне кодовой базы, одновременно внедряя более совершенные механизмы скрытности и обфускации.

Основная задача Remus остаётся классической для сборщиков: хищение учётных данных из браузеров, файлов cookies, криптовалютных кошельков и прочей конфиденциальной информации с инфицированных систем. Однако его появление не означает прекращение активности оригинального Lumma, кампании которого продолжаются по всему миру. Скорее, Remus следует рассматривать как параллельную ветвь развития, адаптированную под современные 64-битные системы и усвоившую уроки прошлых компрометаций.

Убедительные доказательства родства двух угроз носят многослойный характер. Во-первых, это практически идентичная техника обфускации строк. Вредоносные программы используют уникальный механизм, при котором зашифрованные строки собираются в стеке с помощью последовательности инструкций mov, а затем расшифровываются циклом, трансформирующим данные побайтово. Этот процесс дополнительно затруднён использованием MBA-обфускации (Mixed Boolean-Arithmetic), что делает создание универсального статического дешифратора крайне сложной задачей. Более того, в коде обоих семейств исследователи отмечают нетипичные последовательности инструкций nop, вставленные, вероятно, в ходе кастомного этапа компиляции, что служит дополнительным маркером общности происхождения.

Наиболее же весомым аргументом в пользу общего происхождения является использование уникального, ранее документированного только для Lumma, метода обхода Application-Bound Encryption. ABE - это механизм защиты в браузерах на основе Chromium, привязывающий ключ шифрования к конкретному приложению для защиты данных, таких как сохранённые пароли. Вместо стандартных техник обхода, Remus и Lumma внедряют в процесс браузера компактный шелл-код размером менее 100 байт. Его задача - найти в памяти браузера ключ v20_master_key, который хранится в защищённом виде с помощью функции CryptProtectMemory с флагом CRYPTPROTECTMEMORY_SAME_PROCESS, и дешифровать его на месте, вызвав CryptUnprotectMemory. Поскольку дешифрование возможно только в контексте того же процесса, инъекция становится необходимым условием для успешной атаки. Алгоритм поиска ключа, включающий обход списка модулей, хеширование API и сканирование памяти по специфическим шаблонам опкодов, демонстрирует поразительное сходство в реализации у обеих семейств, вплоть до деталей в формировании шелл-кода.

Другие техники также выдают общие корни. Антивирусные проверки на основе инструкции cpuid с целью выявления известных гипервизоров, таких как KVM, QEMU, VMware, VirtualBox и Xen, реализованы идентично. Механизм прямых системных вызовов для обхода пользовательских API, хотя и различается в деталях из-за перехода с 32-битной на 64-битную архитектуру, сохраняет общую логику построения таблицы хеш-SSN и единый диспетчерский паттерн. Даже такие нюансы, как проверка наличия защитного криптера - предупреждающее диалоговое окно, появляющееся при запуске незапакованного исполняемого файла, - сближают Remus с Lumma, выделяя их на фоне других семейств.

При этом Remus не является простым портом. Он привносит ряд существенных новшеств, повышающих его живучесть и скрытность. Ключевое изменение касается механизма разрешения адресов командного центра. Если Lumma полагался на "мёртвые точки" на легитимных платформах вроде Steam и Telegram, то Remus перешёл на использование EtherHiding. Эта техника подразумевает хранение конфигурации, включая адреса C2, в смарт-контракте блокчейна Ethereum. На этапе выполнения вредоносная программа отправляет запрос к публичному RPC-узлу, извлекает данные из блокчейна и получает актуальный адрес сервера. Такой подход делает инфраструктуру практически неуязвимой для традиционного отъёма, поскольку у блокчейна нет централизованного оператора, к которому можно обратиться с жалобой.

Кроме того, Remus расширил арсенал антиотладочных проверок. Помимо классических методов детектирования виртуальных сред, он сканирует список загруженных в процесс DLL-библиотек, вычисляя их хеши CRC32 и сравнивая с заранее подготовленным списком, включающим модули таких песочниц, как Avast, Sandboxie и Comodo. Также выполняется проверка наличия в папке документов пользователя специфического файла honey@pot.com.pst, который может указывать на аналитическую среду.

Таким образом, появление Remus знаменует собой не смену игрока на рынке вредоносных сборщиков, а закономерную эволюцию одной из самых опасных и технически продвинутых семейств. Переход на 64-битную архитектуру, внедрение блокчейн-технологий для обеспечения живучести командной инфраструктуры и усиление антианалитических механизмов - всё это говорит о том, что авторы Lumma не только не сошли со сцены после серии компрометаций, но и адаптировали свой продукт к современным реалиям. Для специалистов по безопасности это означает необходимость учитывать новые техники обфускации и скрытого управления, а также пересматривать подходы к детектированию угроз, активно использующих легитимные и децентрализованные интернет-сервисы.