На исходе каждого года, а также в первые дни января любая отрасль коллективно обсуждает тенденции и прогнозы, которые будут формировать нашу действительность на протяжении всего календаря. Большая и дружная IT-индустрия и, в частности, сфера информационной безопасности в лице многочисленных экспертов, энтузиастов и комьюнити активно протирают хрустальные шары и делятся видением ситуации. В основном в наступившем 2021-м предрекают дальнейшее распространение цифрового вымогательства, а точнее — целевых атак на крупные компании с целью не менее крупного шантажа.

Мы в «Доктор Веб» не очень любим давать прогнозы, но в ушедшем году атаки шифровальщиков сформировали настолько явную тенденцию, что есть все основания полагать: наконец-то предновогоднее предсказание сработает. Что, конечно же, добавит работы всем нам.
В качестве небольшой иллюстрации мы решили опубликовать небольшой разбор шифровальщика, который впервые был обнаружен в сентябре прошлого года, но уже успел натворить много бед. Его образец оказался в нашей вирусной лаборатории, после чего был подвергнут стандартной процедуре.

Что за Egregor?

Предыстории подробно касаться не будем — о происхождении этой вредоносной программы написано достаточно. Она является дальнейшим развитием шифровальщиков Maze и Sekhmet, с которыми имеет много общего. Как и Maze, Egregor стал распространяться по модели Ransomware-as-a-Service и использоваться операторами для целевых атак на корпоративный сектор. Помимо известных IT-компаний (Crytek, Ubisoft) от шифровальщика также пострадал крупный чилийский ритейлер, причем принтеры в скомпрометированной сети начали печатать записки о выкупе.

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

Наш образец (f73e31d11f462f522a883c8f8f06d44f8d3e2f01) представляет собой исполняемую библиотеку, написанную на C++. Для шифрования пользовательских файлов используются алгоритмы ChaCha20 и RSA. В настоящий момент расшифровка пострадавших файлов невозможна.

Принцип действия

Исследованный образец представляет собой исполняемый DLL-файл с оригинальной точкой входа и тремя экспортами:



Статический анализ кода показывает, что вредоносная активность содержится в функции DllRegisterServer. При запуске образца на виртуальных машинах троян не выполняется. Поскольку шифровальщик предназначен для целевых атак, мы полагаем, что он запускается по команде через командную строку. Для начального запуска используется команда rundll32.exe

C:\Windows\%SAMPLE%,DllRegisterServer -passegregor10.

После этого троян запускает полезную нагрузку, предварительно расшифровав ее по тому же алгоритму, который используется для шифрования пользовательских файлов (ChaCha20). Однако в этом случае ключ и одноразовый код (nonce) лежат в открытом доступе. Для расшифровки необходимы 32-байтная строка KojihuDJUFDHGufhdjnbgDfgudfhdfg3 в качестве ключа и 8-байтная строка O_IJDhfs в качестве nonce:



Содержимое полезной нагрузки зашито в теле трояна и зашифровано:



Полезная нагрузка представляет собой загрузчик в виде powershell-скрипта, который подключается к amajai-technologies.industries. На момент анализа этот сервер уже не отвечал, и загружаемый файл остается неизвестным. При этом стоит отметить, что через него операторы шифровальщика могли похищать информацию. Функциональность управления принтерами для печати записок о выкупе в исследованном образце не найдена и, возможно, содержится в загружаемом файле.



Для запуска дальнейшего шифрования используется пакетный файл, который запускает рассматриваемый образец с функцией DllRegisterServer, но с другими параметрами командной строки:



Полезная нагрузка в системе маскируется под продукты компании LogMeIn:



Следует отдельно отметить, что шифровальщик использует именно алгоритм ChaCha20 (разновидность шифра Salsa20), а не AES, как написано в некоторых источниках. Это подтверждается строками expand 16-byte k и expand 32-byte k:



На использование ChaCha20 также указывает алгоритм шифрования в функции quarter-round:



Ниже представлено сравнение quarter-round Salsa20 (слева) и ChaCha20 (справа):



Для генерации самого ключа используется функция RtlGenRandom через вызов SystemFunction036. Генератор на основе RtlGenRandom оценивается как криптостойкий. Подбор ключей в этом случае невозможен:



Большая часть кода написана вручную и обфусцирована, что многократно затрудняет анализ. Данные об оригинальном расположении проекта содержатся в отладочной информации: M:\sc\p\testbuild.pdb.

Одна из особенностей шифровальщика – в том, что расширения каждого файла отличаются даже в пределах одного компьютера. Аналогично Sekhmet, для каждого файла используется новое случайное расширение. Для идентификации зашифрованных файлов используется файловый маркер из четырех DWORD в конце файла (EOF): 00 00 00 00, 00 00 XX XX, 00 00 XX XX, XX XX 6B B1 (байты вместо XX отличаются для каждого файла). По этим значениям можно определить, что файл был заражен именно этим шифровальщиком.



Переход по ссылке, предоставляемой вымогателями после заражения, ведет на их страницу, доступную через сеть Tor.

Заключение

2020 год уже стал своеобразным рекордсменом по числу громких и, к сожалению, зачастую успешных целевых атак вымогателей. Развитие модели RaaS, видимый для хакерских группировок результат и все более халатное отношение организаций к собственной безопасности действительно могут привести к тому, что в этом году подобных инцидентов станет еще больше.

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