nextcry Шифровальщик NEXTCRY

[sh00m]

Коллеги, обнаружил нового зловреда (он себя называет NextCry) на своём linux-сервере NextCloud.

Антивирус Касперского его не обнаруживает!

Во вложении (пароль 123) файлы с промежуточными результатами моего анализа (логи strace, ltrace, gdb, телом шифровальщика, зашифрованными файлами и файлами которые он распаковывает во временную папку). Шифровальщик целенаправленно поражает nextcloud сервера (читает директорию с данными из его конфига и их шифрует). Написан на python и предположительно упакован в исполняемый elf-файл программой pyinstall, после чего динамически обсфуцирован pwnstaller. К нам на сервер его залили пайлоадом из Kali через уязвимость PHP.

Прошу помощи в расшифровке и надеюсь мои изыскания помогут сделать антивирус лучше. Спасибо.

nextcry_data.rar

Изменено 15 ноября, 2019 пользователем Sandor
Вложение прикрепил к сообщению

[Sandor]

Здравствуйте!

 

Инструменты лечения, используемые в этом разделе, нацелены на системы семейства Windows.

При наличии лицензии на любой из продуктов Касперского создайте запрос на расшифровку.

[sh00m]

Уже создал, но подумал, может у кого-то есть релевантный опыт и он сможет помочь ... или мои материалы будут кому-то полезны. 

[Sandor]

Результат обращения в ТП сообщите здесь, пожалуйста.

[sh00m]

Результат обращения в ТП сообщите здесь, пожалуйста.

 

Обязательно отпишу, собственно сейчас основная задача получить питоновский исходник из приложенного к первому посту elf'а, это по силам любому реверс-инженеру знакомому с отладчиком под никсами, как только увидим сам скрипт nextcry.py сразу всё станет понятно(есть возможность расшифровать или нет). У меня есть надежда, что кто-то на форуме сможет это сделать ... 

Изменено 15 ноября, 2019 пользователем sh00m

[sh00m]

Всё - расходимся:

 

Алгоритм работы этого зловреда такой:

1. Файлы размером < 1000000 байт шифруются полностью. У файлов, бОльших указанного размера, шифруются первые 1000000 байт и записываются в конец файла. Исходные данные перезаписываются мусором;
2. Generate_key возвращает криптостойкий ключ для алгоритма (AES) шифрования файлов;
3. Для каждого файла генерируется свой уникальный ключ;
4. В теле шифровальщика зашит публичный ключ RSA (он нужен для шифрования использованных ключей AES);
5. Файл keys.enc содержит зашифрованные с помощью этого паблик-ключа RSA использованные файловые AES-ключи.

Итого:

Секрет, который нужно знать для расшифровки файлов, - это приватный ключ RSA, парный известному паблик-ключу, зашитому в енкодере. В использованной криптосхеме этот секрет никак не разглашается.
Вычислить же его, во всяком случае за практически разумное время мне не представляется возможным. Следовательно, получить ключ для расшифровки файлов можно только у того, кто им владеет (вообще говоря, только у автора/хозяина троянца).

 

[Добавлено]

Техническая поддержка Касперского подтвердила. Уважаемый пользователь, вирусные аналитики сообщили следующее: 

 

nextcry_elf - Trojan-Ransom.Python.NextCry.a Детектирование будет добавлено в базы продукта, благодарим за помощь.

 

1. Троян содержит в себе публичный ключ злоумышленника RSA-2048 (RSAPUBLICKEY);
2. Для каждого шифруемого файла троян генерирует новый ключ длиной 128 бит, кодирует его в base64 (generate_key). Затем от этого вычисляется sha256 (AESCipher.init), и результат используется как ключ AES-256 в режиме CBC для шифрования содержимого файла;
3. Сгенерированные 128-битные ключи впоследствии шифруются RSA на RSAPUBLICKEY, результат сохраняется в "keys.ENC".

 

Чтобы расшифровать файлы, нужно знать приватный ключ RSA злоумышленника, который соответствует публичному ключу RSAPUBLICKEY. Троян не содержит его.

 

P.S. Исходники сего зловреда могу выслать по запросу, т.к. тут публиковать вредоносный код не комильфо.

P.P.S. Ребята на смежном форуме заметили, что как то странно формируются ключи: автор зловреда рассчитывает его на основе 32-байтового размера блока, а AES использует только 16 байтов для своих блоков. Но по этому поводу есть и такое мнение.

Изменено 15 ноября, 2019 пользователем sh00m

[sh00m]

Анализ показал, что если на фазе шифрования файлов энкодер прервали - всё очень плохо:
в этом случае в stdout'е ничего ещё не будет и файл keys.enc еще не будет создан.

Последовательность такая:

1. проход по дереву фс и шифрование файлов
2. переименование зашифрованных файлов (base64- кодирование оригинальных имен )
3. вывод ключей в stdout
4. шифрование ключей и запись keys.enc

Прерывание на фазе 1 или 2 фатально в смысле потери ключей для всех!

Изменено 16 ноября, 2019 пользователем sh00m