Gunra: Linux-вымогатель ChaCha20, уязвимость генератора случайных чисел

Хакерская группировка Gunra, действующая с апреля 2025 года, создала программу-вымогатель, доступную в форматах EXE и ELF. Особое внимание уделено именно ELF-версии, ориентированной на Linux‑среды. В этом материале — сжатый профессиональный анализ эксплуатационных характеристик, методологии шифрования и ключевых уязвимостей, которые существенно снижают криптостойкость вредоносного ПО и дают обороне реальные шансы на восстановление.

Кратко о кампании и целях

Gunra нацелена на разные отрасли и страны; о заметных инцидентах сообщалось в Корее. Атаки реализуются через двоичные файлы форматов EXE и ELF, при этом ELF‑вариант специально разработан для Linux‑систем.

Как работает шифровальщик: ключевые технические детали

После запуска программа проводит проверку входных аргументов и ожидает точной передачи всех требуемых параметров. Основное поведение задаётся следующими параметрами командной строки:

• -path — основной целевой объект для шифрования (файл или диск); тип пути определяет режим: file encryption или disk encryption;
• -Threads (социальная сеть, принадлежащая запрещённой в России и признанной экстремистской американской корпорации Meta) — параметр управления многопоточностью (поддерживает до 100 потоков);
• -store — режим сохранения ключа: при наличии этого аргумента 32‑байтовый ключ и 12‑байтовый nonce шифруются публичным ключом RSA и сохраняются с расширением .keystore в указанном месте; если -store не задан, ключ просто добавляется в конец зашифрованных данных.

Алгоритм поточной криптографии, применяемый для шифрования данных, — ChaCha20. Для повышения производительности злоумышленники используют многопоточность — до 100 потоков параллельного шифрования.

Критическая уязвимость: слабый генератор случайных чисел

Критической уязвимостью в конструкции программы-вымогателя Gunra является её зависимость от слабого генератора случайных чисел для генерации ключей шифрования и одноразовых значений.

Этот недостаток проявляется в следующем:

• генерируемые 32‑байтовые ключи и 12‑байтовые одноразовые номера (nonce) имеют низкую энтропию;
• значения оказываются предсказуемыми и фактически ограничены диапазоном порядка 256 вариантов для некоторых байтов (0x00–0xFF);
• из‑за этого успешная атака brute‑force на зашифрованные файлы становится реальной: пространство поиска значительно уменьшается, что существенно упрощает восстановление.

Анализ показывает, что уязвимость RNG в сочетании с тем, что ключи могут быть либо зашифрованы с RSA и вынесены в отдельный файл .keystore, либо просто добавлены в конец зашифрованного файла (если -store не указан), создаёт разные сценарии по сложности восстановления.

Практические последствия

• Если ключи хранятся в .keystore и зашифрованы корректно с использованием своего публичного ключа RSA, то получение этих ключей затруднено без компрометации приватного ключа злоумышленника.
• Если -store не используется и ключы добавляются в конец зашифрованных данных, это осложняет анализ, но слабый RNG открывает путь для успешного brute‑force и вероятного восстановления.
• Низкое качество генерации случайных чисел делает атаки восстановления практически осуществимыми в реальном времени на доступном железе, особенно если удаётся изолировать типичную структуру зашифрованных файлов и стабильные паттерны nonce/key.

Индикаторы компрометации (IoC) и признаки атаки

• появление файлов с расширением .keystore в файловой системе;
• запуск исполняемых файлов форматов ELF или EXE с аргументами -path, -threads, -store в командной строке;
• внезапное интенсивное многопоточное файловое шифрование (до 100 потоков);
• модификация большого числа файлов с характерными заголовками и добавленными хвостами (в случае хранения ключа в конце файла).

Рекомендации по обнаружению и реагированию

На основе анализа рекомендуются следующие меры:

• Мониторинг процессов и командной строки: логирование запуска бинарников и их аргументов (особенно появление -path, -threads, -store);
• Файловая телеметрия: отслеживание создания файлов .keystore и массовых модификаций файлов; создание правил IDS/EDR на соответствующие шаблоны;
• Снимки памяти и forensics: при обнаружении инцидента — немедленно снять дампы памяти процессов, что может помочь извлечь ключи или сессии до их перезаписи;
• Резервное копирование и сегментация: регулярные проверенные бэкапы, ограничение привилегий и сетевое разграничение, чтобы ограничить распространение шифровальщика;
• Аналитика и попытки восстановления: привлечение специалистов по криптоанализу — слабый RNG даёт реальные шансы на восстановление данных через контролируемый brute‑force и методы перебора предсказуемых значений;
• Проактивные меры: запрет выполнения неподписанных ELF/EXE в критичных окружениях, применение whitelisting и минимизация числа систем с правами на массовую модификацию файлов.

Выводы

ELF‑вариант программы‑вымогателя Gunra сочетает в себе производительные и простые механизмы запуска (многопоточность, ChaCha20), однако критическая архитектурная ошибка — использование слабого генератора случайных чисел — делает её значительно менее надёжной с криптографической точки зрения. Это даёт обороняющимся реальные возможности по обнаружению, реагированию и восстановлению данных.

Организациям рекомендуется усилить мониторинг поведенческих индикаторов, подготовить процедуры быстрого сбора артефактов и при необходимости привлечь специалистов по крипто‑аналитике: в текущем виде уязвимости Gunra позволяют надеяться на успешное восстановление при грамотной и быстрой реакции.

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.